* Patrick McHardy [EMAIL PROTECTED] wrote:
this means that this particular use could be fixed by converting the
preempt_disable()/enable() pair in nf_ct_l4proto_find_get() to
rcu_read_lock()/unlock(), correct?
That is another bug (all uses of preempt_disable in netfilter
actually),
From: Ingo Molnar [EMAIL PROTECTED]
Date: Wed, 7 Feb 2007 09:07:22 +0100
Dave, Patrick, can we lift the nack on PREEMPT_RCU, as far as networking
goes?
After Patrick's fixups, sure.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Wed, 7 Feb 2007 09:07:22 +0100
Dave, Patrick, can we lift the nack on PREEMPT_RCU, as far as networking
goes?
After Patrick's fixups, sure.
I'm about to send my queued netfilter patches, after which I will look
into this.
* Patrick McHardy [EMAIL PROTECTED] wrote:
David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Wed, 7 Feb 2007 09:07:22 +0100
Dave, Patrick, can we lift the nack on PREEMPT_RCU, as far as networking
goes?
After Patrick's fixups, sure.
I'm about to send my
On Mon, 5 Feb 2007, David Miller wrote:
Let's audit NF_CT_STAT_INC() usage to make sure :-)
net/netfilter/nf_conntrack_core.c:
destroy_conntrack: Inside write_{lock,unlock}_bh().
death_by_timeout: Ditto.
__nf_conntrack_find: Inside read_{lock,unlock}_bh() via callers.
* Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller
[EMAIL PROTECTED] wrote:
I bet this rcu_read_lock()-implies-preempt_disable() assumption has
spread into other areas of the tree as well.
Me too. Although one expects that other holes
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 6 Feb 2007 13:34:01 +0100
* Andrew Morton [EMAIL PROTECTED] wrote:
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller
[EMAIL PROTECTED] wrote:
I bet this rcu_read_lock()-implies-preempt_disable() assumption has
spread into
* David Miller [EMAIL PROTECTED] wrote:
that was pretty much the only place in the whole kernel that got hit
by some rcu-preempt side-effect - and even this appears to show that
it's a real bug that was in hiding.
No, rather, it's the only location that triggered an automated
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 6 Feb 2007 22:02:51 +0100
So i'm wondering what other assumptions there are (or can be)
about rcu_read_lock() also being a preempt-off point. Thanks!
I showed the examples in my detailed analysis yesterday.
Beause I love hearing myself say the
* David Miller [EMAIL PROTECTED] wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Tue, 6 Feb 2007 22:02:51 +0100
So i'm wondering what other assumptions there are (or can be) about
rcu_read_lock() also being a preempt-off point. Thanks!
I showed the examples in my detailed analysis
Ingo Molnar wrote:
* David Miller [EMAIL PROTECTED] wrote:
net/netfilter/nf_conntrack_core.c, calls:
l4proto = __nf_ct_l4proto_find((u_int16_t)pf, protonum);
whichs assumes that preemption is disabled.
Yes, that is certainly broken.
you are right - i mistakenly read that mail only up
From: Andrew Morton [EMAIL PROTECTED]
using smp_processor_id() in preemptible code
Cc: Patrick McHardy [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/net/netfilter/nf_conntrack.h |7 ++-
1 file changed, 6
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:11 -0800
From: Andrew Morton [EMAIL PROTECTED]
using smp_processor_id() in preemptible code
Cc: Patrick McHardy [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
We NAK'd this
On Mon, 05 Feb 2007 18:10:26 -0800 (PST) David Miller [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:31:11 -0800
From: Andrew Morton [EMAIL PROTECTED]
using smp_processor_id() in preemptible code
Cc: Patrick McHardy [EMAIL PROTECTED]
Cc: David S.
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 5 Feb 2007 18:18:10 -0800
I think the finger was pointed at preemptible rcu, in -mm. iirc,
the net stats code is assuming that rcu_read_lock() disables
preemption as a side-effect, which rcu-preempt makes no-longer-true.
Not sure what to do
On Mon, 05 Feb 2007 18:44:08 -0800 (PST) David Miller [EMAIL PROTECTED] wrote:
I bet this rcu_read_lock()-implies-preempt_disable() assumption has
spread into other areas of the tree as well.
Me too. Although one expects that other holes will cause might_sleep or
lockdep warnings pretty
16 matches
Mail list logo
