From: Robert Olsson <[EMAIL PROTECTED]>
Date: Mon, 26 Mar 2007 11:29:04 +0200
> Paul E. McKenney writes:
>
> > Those of use who dive into networking only occasionally would much
> > appreciate this. ;-)
>
> No problem here...
>
> Cheers
> --ro
>
> Ac
Paul E. McKenney writes:
> Those of use who dive into networking only occasionally would much
> appreciate this. ;-)
No problem here...
Cheers
--ro
Acked-by: Robert Olsson <[EMAIL PROTECTED]>
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]> (bu
Paul E. McKenney writes:
> > We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
> > both are holding RTNL. So there shouldn't be need for this preempt stuff.
> > This is assumed to a leftover from an older RCU-take.
>
> True enough! One request -- would it be reasona
On Fri, Mar 16, 2007 at 01:38:31PM +0100, Robert Olsson wrote:
>
> Hello, Just discussed this Patrick...
>
> We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
> both are holding RTNL. So there shouldn't be need for this preempt stuff.
> This is assumed to a leftover from a
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Fri, 16 Mar 2007 13:38:31 +0100
>
> Hello, Just discussed this Patrick...
>
> We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
> both are holding RTNL. So there shouldn't be need for this preempt stuff.
> This is assumed to a
Hello, Just discussed this Patrick...
We have two users of trie_leaf_remove, fn_trie_flush and fn_trie_delete
both are holding RTNL. So there shouldn't be need for this preempt stuff.
This is assumed to a leftover from an older RCU-take.
> Mhh .. I think I just remembered something - me incorr
On Thu, Mar 15, 2007 at 08:43:59AM +0100, Patrick McHardy wrote:
...
> Yes, Robert already sent me a patch to remove the bogus preempt_disable,
It looks like RCU could be endangered now.
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
On Thu, Mar 15, 2007 at 10:15:44AM +0100, Jarek Poplawski wrote:
...
> BTW: it seems fib_tree wasn't used too much, so probably,
> before killing fib_hash, fib_tree should be made Kconfig
> default for some time.
Sorry! Let fib_tree stay out of Kconfig and make fib_trie
the default.
Jarek P.
-
To
On Thu, Mar 15, 2007 at 08:43:59AM +0100, Patrick McHardy wrote:
...
> > On 14-03-2007 23:49, Patrick McHardy wrote:
...
> >>BUG: sleeping function called from invalid context at mm/slab.c:3032
> >>in_atomic():1, irqs_disabled():0
...
> Yes, Robert already sent me a patch to remove the bogus preemp
Jarek Poplawski wrote:
> On 14-03-2007 23:49, Patrick McHardy wrote:
> ...
>
>>I noticed this a couple of times, but didn't manage to look
>>into it yet:
>>
>>BUG: sleeping function called from invalid context at mm/slab.c:3032
>>in_atomic():1, irqs_disabled():0
>>no locks held by ip/14309.
>>
>>C
On 14-03-2007 23:49, Patrick McHardy wrote:
...
> I noticed this a couple of times, but didn't manage to look
> into it yet:
>
> BUG: sleeping function called from invalid context at mm/slab.c:3032
> in_atomic():1, irqs_disabled():0
> no locks held by ip/14309.
>
> Call Trace:
> [] debug_show_he
David Miller wrote:
> Another thing I'd like to accomplish is to kill off
> fib_hash leaving just fib_trie.
>
> I can't do that until any and all functionality regressions
> which may or may not exist in fib_trie vs. fib_hash are
> discussed and resolved.
>
> So can we start composing a list of s
Another thing I'd like to accomplish is to kill off
fib_hash leaving just fib_trie.
I can't do that until any and all functionality regressions
which may or may not exist in fib_trie vs. fib_hash are
discussed and resolved.
So can we start composing a list of stuff to look into in this
thread so
13 matches
Mail list logo
