* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: Patrick McHardy @ 2010-03-25 10:25 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Jozsef Kadlecsik, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel
In-Reply-To: <4BAAE496.8000701@linux-ipv6.org>
YOSHIFUJI Hideaki wrote:
> (2010/03/24 5:10), Jozsef Kadlecsik wrote:
>
>> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
>>
>>>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>>>> so in my opinion the transparent thing to do would be to still send
>>>> them. Of course only if reassembly is done on an end host.
>>>
>>> Well, no. conntrack should just forward even uncompleted fragments
>>> to next process (e.g. core ipv6 code), and then the core would send
>>> ICMP error back. ICMP should be sent by the core ipv6 code according
>>> to decision of itself, not according to netfilter.
>>
>> But what state could be associated by conntrack to the uncompleted
>> fragments but the INVALID state? In consequence, in any sane setup, the
>> uncompleted fragments will be dropped silently by a filter table rule
>> and no ICMP error message will be sent back.
>>
>> Therefore I think iff the destination of the fragments is the host
>> itself, then conntrack should generate an ICMP error message. But that
>> error message must be processed by conntrack to set its state and then
>> the fate of the generated packet can be decided by a rule.
>
> Well.... no.
>
> First of all. in "sane" setup, people should configure according
> to their own requirements. They may or may not want send back
> icmp packet. And, even if the core is to send icmp back, the
> state would be correctly assigned.
>
> We cannot (and should not) do something "cleaver" (excluding
> packet drops) in conntrack in PRE_ROUTING chain.
>
> One reason is that in PRE_ROUTING context, we can NOT determine
> if the address we see in the IP header is really the final
> destination. The overall situation is the same even if the
> routing entry corresponding the "current" destination points
> the node itself, or even if the node is configured as host.
Agreed, that is a problem.
> It might seems that we could do something in the "filter"
> table in LOCAL_IN, FORWARD or LOCAL_OUT (after routing header
> process).
>
> But well, we unfortunately cannot do this (at least
> automatically) because even in LOCAL_IN, the final
> destination has not been decided until we process all
> of extension headers.
>
> Sending ICMP in netfilter (especially in conntrack) is too
> patchy, and is not right. If we do the right thing (and
> I believe we should do so), I'd propose to have hooks
> around handlers inside ip6_input_finish().
>
> ...I remember that I was thinking about this before.
>
> For my conclusion, first option is just to drop
> uncompleted fragments as we do today. Second option
> would be to forward them to the next process so that
> core code could send ICMPv6 etc. or, we could have
> new code to send ICMPV6_TIME_EXCEED in REJECT target.
> In longer term, I think it is better to introduce
> per-exthdr hooks.
We'd need something that allows to process the incomplete fragments
long enough so they can actually reach the IPv6 core (people usually
don't allow incoming fragments when using conntrack).
But for now you've convinced me that this patch is wrong.
^ permalink raw reply
* Re: debugging kernel during packet drops
From: Patrick McHardy @ 2010-03-25 10:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jorrit Kronjee, netfilter-devel, netdev
In-Reply-To: <1269509574.3626.9.camel@edumazet-laptop>
Eric Dumazet wrote:
> Here is patch I cooked for xt_hashlimit (on top of net-next-2.6) to make
> it use RCU and scale better in your case (allowing several concurrent
> cpus once RPS is activated), but also on more general cases.
>
> [PATCH] xt_hashlimit: RCU conversion
>
> xt_hashlimit uses a central lock per hash table and suffers from
> contention on some workloads.
>
> After RCU conversion, central lock is only used when a writer wants to
> add or delete an entry. For 'readers', updating an existing entry, they
> use an individual lock per entry.
This clashes with some recent cleanups in nf-next-2.6.git. I'm
also expecting a patch from Jan to remove the old v0 revision
very soon (probably today). Please rediff once I've pushed that out.
^ permalink raw reply
* Re: debugging kernel during packet drops
From: Eric Dumazet @ 2010-03-25 11:02 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Jorrit Kronjee, netfilter-devel, netdev
In-Reply-To: <4BAB3C8B.3030104@trash.net>
Le jeudi 25 mars 2010 à 11:35 +0100, Patrick McHardy a écrit :
> Eric Dumazet wrote:
> > Here is patch I cooked for xt_hashlimit (on top of net-next-2.6) to make
> > it use RCU and scale better in your case (allowing several concurrent
> > cpus once RPS is activated), but also on more general cases.
> >
> > [PATCH] xt_hashlimit: RCU conversion
> >
> > xt_hashlimit uses a central lock per hash table and suffers from
> > contention on some workloads.
> >
> > After RCU conversion, central lock is only used when a writer wants to
> > add or delete an entry. For 'readers', updating an existing entry, they
> > use an individual lock per entry.
>
> This clashes with some recent cleanups in nf-next-2.6.git. I'm
> also expecting a patch from Jan to remove the old v0 revision
> very soon (probably today). Please rediff once I've pushed that out.
Sure, this patch was mainly for Jorrit tests (and he uses net-next-2.6),
I will submit several patches for mainline :)
Thanks
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] NETLABEL: Fix an RCU warning
From: David Howells @ 2010-03-25 11:06 UTC (permalink / raw)
To: paul.moore; +Cc: netdev, David Howells
Fix an RCU warning in the netlabel code due to missing rcu read locking around
an rcu_dereference() in netlbl_unlhsh_hash() when called from
netlbl_unlhsh_netdev_handler():
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/netlabel/netlabel_unlabeled.c:246 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
2 locks held by ip/5108:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff812c4a36>] rtnl_lock+0x12/0x14
#1: (netlbl_unlhsh_lock){+.+...}, at: [<ffffffff8134daa4>] netlbl_unlhsh_netdev_handler+0x1e/0x86
stack backtrace:
Pid: 5108, comm: ip Not tainted 2.6.34-rc2-cachefs #114
Call Trace:
[<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
[<ffffffff8134d781>] netlbl_unlhsh_hash+0x3e/0x50
[<ffffffff8134d7a1>] netlbl_unlhsh_search_iface+0xe/0x84
[<ffffffff8134daaf>] netlbl_unlhsh_netdev_handler+0x29/0x86
[<ffffffff81048362>] notifier_call_chain+0x32/0x5e
[<ffffffff810483fe>] raw_notifier_call_chain+0xf/0x11
[<ffffffff812ba924>] call_netdevice_notifiers+0x16/0x18
[<ffffffff812bac22>] __dev_notify_flags+0x37/0x5b
[<ffffffff812bac8c>] dev_change_flags+0x46/0x52
[<ffffffff812c41af>] do_setlink+0x250/0x3cd
[<ffffffff812c4ee8>] rtnl_newlink+0x2b6/0x49d
[<ffffffff812c4cdd>] ? rtnl_newlink+0xab/0x49d
[<ffffffff812c4c17>] rtnetlink_rcv_msg+0x1b7/0x1d2
[<ffffffff812c4a60>] ? rtnetlink_rcv_msg+0x0/0x1d2
[<ffffffff812cc1dc>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff812c4a59>] rtnetlink_rcv+0x21/0x28
[<ffffffff812cbefe>] netlink_unicast+0x218/0x28f
[<ffffffff812cc76e>] netlink_sendmsg+0x26b/0x27a
[<ffffffff812a9f1d>] sock_sendmsg+0xd4/0xf5
[<ffffffff81096dca>] ? might_fault+0x4e/0x9e
[<ffffffff81096dca>] ? might_fault+0x4e/0x9e
[<ffffffff81096e13>] ? might_fault+0x97/0x9e
[<ffffffff81096dca>] ? might_fault+0x4e/0x9e
[<ffffffff812b4122>] ? verify_iovec+0x59/0x97
[<ffffffff812aa1d9>] sys_sendmsg+0x209/0x273
[<ffffffff810976dc>] ? __do_fault+0x395/0x3cd
[<ffffffff8109928f>] ? handle_mm_fault+0x324/0x69d
[<ffffffff81051e4e>] ? trace_hardirqs_on_caller+0x10c/0x130
[<ffffffff81074972>] ? audit_syscall_entry+0x17d/0x1b0
[<ffffffff81364154>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/netlabel/netlabel_unlabeled.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 852d9d7..7ea64e4 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -799,6 +799,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
/* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
if (event == NETDEV_DOWN) {
+ rcu_read_lock();
spin_lock(&netlbl_unlhsh_lock);
iface = netlbl_unlhsh_search_iface(dev->ifindex);
if (iface != NULL && iface->valid) {
@@ -807,6 +808,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
} else
iface = NULL;
spin_unlock(&netlbl_unlhsh_lock);
+ rcu_read_unlock();
}
if (iface != NULL)
^ permalink raw reply related
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: Eric Dumazet @ 2010-03-25 11:28 UTC (permalink / raw)
To: David Howells; +Cc: paul.moore, netdev
In-Reply-To: <20100325110621.5348.32020.stgit@warthog.procyon.org.uk>
Le jeudi 25 mars 2010 à 11:06 +0000, David Howells a écrit :
> Fix an RCU warning in the netlabel code due to missing rcu read locking around
> an rcu_dereference() in netlbl_unlhsh_hash() when called from
> netlbl_unlhsh_netdev_handler():
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> net/netlabel/netlabel_unlabeled.c:246 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 2 locks held by ip/5108:
> #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff812c4a36>] rtnl_lock+0x12/0x14
> #1: (netlbl_unlhsh_lock){+.+...}, at: [<ffffffff8134daa4>] netlbl_unlhsh_netdev_handler+0x1e/0x86
>
> stack backtrace:
> Pid: 5108, comm: ip Not tainted 2.6.34-rc2-cachefs #114
> Call Trace:
> [<ffffffff8105121f>] lockdep_rcu_dereference+0xaa/0xb2
> [<ffffffff8134d781>] netlbl_unlhsh_hash+0x3e/0x50
> [<ffffffff8134d7a1>] netlbl_unlhsh_search_iface+0xe/0x84
> [<ffffffff8134daaf>] netlbl_unlhsh_netdev_handler+0x29/0x86
> [<ffffffff81048362>] notifier_call_chain+0x32/0x5e
> [<ffffffff810483fe>] raw_notifier_call_chain+0xf/0x11
> [<ffffffff812ba924>] call_netdevice_notifiers+0x16/0x18
> [<ffffffff812bac22>] __dev_notify_flags+0x37/0x5b
> [<ffffffff812bac8c>] dev_change_flags+0x46/0x52
> [<ffffffff812c41af>] do_setlink+0x250/0x3cd
> [<ffffffff812c4ee8>] rtnl_newlink+0x2b6/0x49d
> [<ffffffff812c4cdd>] ? rtnl_newlink+0xab/0x49d
> [<ffffffff812c4c17>] rtnetlink_rcv_msg+0x1b7/0x1d2
> [<ffffffff812c4a60>] ? rtnetlink_rcv_msg+0x0/0x1d2
> [<ffffffff812cc1dc>] netlink_rcv_skb+0x3e/0x8f
> [<ffffffff812c4a59>] rtnetlink_rcv+0x21/0x28
> [<ffffffff812cbefe>] netlink_unicast+0x218/0x28f
> [<ffffffff812cc76e>] netlink_sendmsg+0x26b/0x27a
> [<ffffffff812a9f1d>] sock_sendmsg+0xd4/0xf5
> [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> [<ffffffff81096e13>] ? might_fault+0x97/0x9e
> [<ffffffff81096dca>] ? might_fault+0x4e/0x9e
> [<ffffffff812b4122>] ? verify_iovec+0x59/0x97
> [<ffffffff812aa1d9>] sys_sendmsg+0x209/0x273
> [<ffffffff810976dc>] ? __do_fault+0x395/0x3cd
> [<ffffffff8109928f>] ? handle_mm_fault+0x324/0x69d
> [<ffffffff81051e4e>] ? trace_hardirqs_on_caller+0x10c/0x130
> [<ffffffff81074972>] ? audit_syscall_entry+0x17d/0x1b0
> [<ffffffff81364154>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> net/netlabel/netlabel_unlabeled.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
> index 852d9d7..7ea64e4 100644
> --- a/net/netlabel/netlabel_unlabeled.c
> +++ b/net/netlabel/netlabel_unlabeled.c
> @@ -799,6 +799,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
>
> /* XXX - should this be a check for NETDEV_DOWN or _UNREGISTER? */
> if (event == NETDEV_DOWN) {
> + rcu_read_lock();
> spin_lock(&netlbl_unlhsh_lock);
> iface = netlbl_unlhsh_search_iface(dev->ifindex);
> if (iface != NULL && iface->valid) {
> @@ -807,6 +808,7 @@ static int netlbl_unlhsh_netdev_handler(struct notifier_block *this,
> } else
> iface = NULL;
> spin_unlock(&netlbl_unlhsh_lock);
> + rcu_read_unlock();
> }
>
> if (iface != NULL)
>
> --
Sorry this is not the right fix.
Fix is to change the dereference check to take into account the lock
owned here.
^ permalink raw reply
* Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()
From: Sergey Senozhatsky @ 2010-03-25 11:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Oleg Nesterov, David Miller, Francois Romieu, netdev
In-Reply-To: <1268765284.2932.17.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hello,
On (03/16/10 19:48), Eric Dumazet wrote:
[..]
> OK thanks for the report, this rtl8169_reset_task() seems pretty buggy,
> or multiple invocation...
>
> Did you tried removing the rtl8169_schedule_work() call from
> rtl8169_rx_interrupt() ?
>
> Maybe the reset is not necessary at all in case of fifo overflow..
>
> Cumulative patch :
>
[..]
Eric, I think you can put Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
on the cumulative patch as I don't see any errors with pktgen over LAN testing.
Thanks.
Sergey
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: David Howells @ 2010-03-25 11:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dhowells, paul.moore, netdev
In-Reply-To: <1269516484.3626.21.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Sorry this is not the right fix.
>
> Fix is to change the dereference check to take into account the lock
> owned here.
Then the comments on netlbl_unlhsh_hash(), netlbl_unlhsh_search_iface(),
netlbl_unlhsh_search_iface_def() and netlbl_unlhsh_add_iface() are all wrong,
for all of them say:
* The caller is responsible for calling the rcu_read_[un]lock()
* functions.
Furthermore, netlabel_unlhsh_add() and netlabel_unlhsh_remove() _do_ wrap the
calls to those functions in rcu_read_lock'd sections.
David
^ permalink raw reply
* Re: debugging kernel during packet drops
From: Jan Engelhardt @ 2010-03-25 12:42 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Jorrit Kronjee, netfilter-devel, netdev
In-Reply-To: <4BAB3C8B.3030104@trash.net>
On Thursday 2010-03-25 11:35, Patrick McHardy wrote:
>Eric Dumazet wrote:
>> Here is patch I cooked for xt_hashlimit (on top of net-next-2.6) to make
>> it use RCU and scale better in your case (allowing several concurrent
>> cpus once RPS is activated), but also on more general cases.
>>
>> [PATCH] xt_hashlimit: RCU conversion
>
>This clashes with some recent cleanups in nf-next-2.6.git. I'm
>also expecting a patch from Jan to remove the old v0 revision
>very soon (probably today).
I was waiting for you to process
http://marc.info/?l=netfilter-devel&m=126936212932683&w=2
which is a prerequisite for the hashlimit v0 removal.
(I expected that you might miss some mails due to trash.net
having been down yesterday. No biggie.)
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Restart rt_intern_hash after emergency rebuild (v2)
From: Neil Horman @ 2010-03-25 13:17 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Eric Dumazet, Linux Netdev List
In-Reply-To: <4BAB15FA.20108@openvz.org>
On Thu, Mar 25, 2010 at 10:51:22AM +0300, Pavel Emelyanov wrote:
> The the rebuild changes the genid which in turn is used at
> the hash calculation. Thus if we don't restart and go on with
> inserting the rt will happen in wrong chain.
>
> (Fixed Neil's comment about the index passed into the rt_intern_hash)
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Thanks! I think this is pretty reasonable.
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()
From: Eric Dumazet @ 2010-03-25 13:19 UTC (permalink / raw)
To: Sergey Senozhatsky; +Cc: Oleg Nesterov, David Miller, Francois Romieu, netdev
In-Reply-To: <20100325113038.GA3471@swordfish.minsk.epam.com>
Le jeudi 25 mars 2010 à 13:30 +0200, Sergey Senozhatsky a écrit :
> Hello,
>
> On (03/16/10 19:48), Eric Dumazet wrote:
> [..]
> > OK thanks for the report, this rtl8169_reset_task() seems pretty buggy,
> > or multiple invocation...
> >
> > Did you tried removing the rtl8169_schedule_work() call from
> > rtl8169_rx_interrupt() ?
> >
> > Maybe the reset is not necessary at all in case of fifo overflow..
> >
> > Cumulative patch :
> >
> [..]
>
> Eric, I think you can put Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> on the cumulative patch as I don't see any errors with pktgen over LAN testing.
>
Hi
Thanks for the report. Problem is I am not confident enough on this
driver.
I believe François Romieu is the one that can possibly push a patch ?
Thanks
^ permalink raw reply
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: Eric Dumazet @ 2010-03-25 13:32 UTC (permalink / raw)
To: David Howells; +Cc: paul.moore, netdev, Paul E. McKenney
In-Reply-To: <6522.1269517044@redhat.com>
Le jeudi 25 mars 2010 à 11:37 +0000, David Howells a écrit :
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Sorry this is not the right fix.
> >
> > Fix is to change the dereference check to take into account the lock
> > owned here.
>
> Then the comments on netlbl_unlhsh_hash(), netlbl_unlhsh_search_iface(),
> netlbl_unlhsh_search_iface_def() and netlbl_unlhsh_add_iface() are all wrong,
> for all of them say:
>
> * The caller is responsible for calling the rcu_read_[un]lock()
> * functions.
>
> Furthermore, netlabel_unlhsh_add() and netlabel_unlhsh_remove() _do_ wrap the
> calls to those functions in rcu_read_lock'd sections.
Current code is probably fine.
Comments are not up to date (as many other comments BTW)
Only the dereference check is bad, as it assumes the rcu_read lock is
held.
Its not the case, we own a spinlock.
You suggest adding a surrounding rcu lock, but this surrounding lock
adds overhead on normal kernels, to correct checker warnings only.
If a mutex was protecting existing code, instead of a spinlock, then
adding rcu_read_lock() would be no correct anyway (existing code would
not be allowed to call a might_sleep function)
Please take a look at rcu_dereference_check() in :
__sk_free() (file net/core/sock.c)
__in6_dev_get() (file include/net/addrconf.h)
rcu_dereference_check_fdtable (file include/linux/fdtable.h)
task_subsys_state() (file include/linux/cgroup.h)
rcu_dereference_check_sched_domain (file kernel/sched.c)
...
for examples of proper checks.
Yes, its more difficult, but its the right thing.
^ permalink raw reply
* Re: [PATCH] r8169: Fix rtl8169_rx_interrupt()
From: Sergey Senozhatsky @ 2010-03-25 13:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sergey Senozhatsky, Oleg Nesterov, David Miller, Francois Romieu,
netdev
In-Reply-To: <1269523180.3626.25.camel@edumazet-laptop>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
On (03/25/10 14:19), Eric Dumazet wrote:
> > Eric, I think you can put Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > on the cumulative patch as I don't see any errors with pktgen over LAN testing.
> >
>
> Hi
>
> Thanks for the report. Problem is I am not confident enough on this
> driver.
> I believe François Romieu is the one that can possibly push a patch ?
>
Thanks.
Hm. François' patch introduced new 'problems'/'stack traces' with pktgen testing...
François, any comments?
Sergey
[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH] NETLABEL: Fix an RCU warning
From: Paul Moore @ 2010-03-25 14:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Howells, netdev, Paul E. McKenney
In-Reply-To: <1269523940.3626.37.camel@edumazet-laptop>
On Thursday 25 March 2010 09:32:20 am Eric Dumazet wrote:
> Le jeudi 25 mars 2010 à 11:37 +0000, David Howells a écrit :
> > Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > Sorry this is not the right fix.
> > >
> > > Fix is to change the dereference check to take into account the lock
> > > owned here.
> >
> > Then the comments on netlbl_unlhsh_hash(), netlbl_unlhsh_search_iface(),
> > netlbl_unlhsh_search_iface_def() and netlbl_unlhsh_add_iface() are all
> > wrong,
> >
> > for all of them say:
> > * The caller is responsible for calling the rcu_read_[un]lock()
> > * functions.
> >
> > Furthermore, netlabel_unlhsh_add() and netlabel_unlhsh_remove() _do_ wrap
> > the calls to those functions in rcu_read_lock'd sections.
>
> Current code is probably fine.
> Comments are not up to date (as many other comments BTW)
>
> Only the dereference check is bad, as it assumes the rcu_read lock is
> held.
>
> Its not the case, we own a spinlock.
>
> You suggest adding a surrounding rcu lock, but this surrounding lock
> adds overhead on normal kernels, to correct checker warnings only.
The rcu_dereference call, and the outdated comments for that matter, are
likely artifacts from an early patch. When the code was originally being
developed I had assumed that you _always_ needed to hold the RCU read lock
when doing RCU operations, regardless of if you were already holding the
associated spinlock. Thankfully, Paul McKenney was able to review the code
and helped me to understand RCU a bit better, unfortunately, it looks like I
still missed a few spots :/
Give me a day or two to go through the comments again and do some sanity
checks and I'll send out a patch. However, if you've already got something
that is tested and ready to go don't let me stand in your way.
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
From: YOSHIFUJI Hideaki @ 2010-03-25 14:14 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Patrick McHardy, Shan Wei, YOSHIFUJI Hideaki, David Miller,
Alexey Dobriyan, Yasuyuki KOZAKAI, netdev@vger.kernel.org,
netfilter-devel, YOSHIFUJI Hideaki
In-Reply-To: <alpine.DEB.2.00.1003251004200.21825@blackhole.kfki.hu>
(2010/03/25 18:23), Jozsef Kadlecsik wrote:
>> First of all. in "sane" setup, people should configure according
>> to their own requirements. They may or may not want send back
>> icmp packet. And, even if the core is to send icmp back, the
>> state would be correctly assigned.
>
> I meant the state of the fragmented packets. If we let the uncompleted
> fragments to enter conntrack, as far as I see their state will be INVALID.
> Or should we add an exception and set their state to UNTRACKED in
> conntrack?
Got it. INVALID seems fine to me so far
while further consideration might be needed.
>> For my conclusion, first option is just to drop
>> uncompleted fragments as we do today. Second option
>> would be to forward them to the next process so that
>> core code could send ICMPv6 etc. or, we could have
>> new code to send ICMPV6_TIME_EXCEED in REJECT target.
>> In longer term, I think it is better to introduce
>> per-exthdr hooks.
>
> I agree with your conclusion too, except a few question.
>
> It is unclear for me how can you forward the packets to the next process:
> above you pointed out that in defrag/reassembly before conntrack we do not
> know yet whether the packets are destined to the host or not. So again,
> how would you let through the fragments on conntrack then?
>
> I don't know how could the REJECT target help in any way.
Argh, more explanation.
If you unconditionally send ICMPv6, behavior would be
broken.
If you do really want to send ICMP in netfilter,
you could pretend additional rules in filter table.
For example, ICMP to be sent back only if other exthdrs
do not exist, and other packets to be silently dropped.
This cannot be our clean/final/full answer, so I said it'd
be better to introduce per-exthdr hooks in longer term.
Regards,
--yoshfuji
^ permalink raw reply
* Re: 2.6.34-rc1: bluetooth oops
From: Pavel Machek @ 2010-03-25 14:26 UTC (permalink / raw)
To: Marcel Holtmann, netdev, Rafael J. Wysocki
Cc: kernel list, linux-bluetooth, Rafael J. Wysocki
In-Reply-To: <20100314204434.GB5208@elf.ucw.cz>
On Sun 2010-03-14 21:44:34, Pavel Machek wrote:
> Hi!
>
> > > I got this after trying to use bnep for few minutes... Machine locked
> > > after that, not sure if it is related.
> >
> > I can't explain it since we haven't changed the BNEP code. So that might
> > be a problem in the networking layer. So posting it to netdev might be a
> > good idea.
>
> Ok, I'll try using bnep some more. I had bad problems with cellphone
> connection at that point, so maybe it is not easy to repeat, and it
> the fact I have not seen it before may not mean much...
So it seems to repeat about twice a week, definitely a regression :-(.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [Bugme-new] [Bug 15571] New: TCP madness - some packets are shunned.
From: Arnd Hannemann @ 2010-03-25 15:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, jasen
In-Reply-To: <20100322143711.b78c7a93.akpm@linux-foundation.org>
Am 22.03.2010 22:37, schrieb Andrew Morton:
>
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 18 Mar 2010 02:46:29 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=15571
>>
>> URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=53646
>> 2
>> Summary: TCP madness - some packets are shunned.
>> Product: Networking
>> Version: 2.5
>> Kernel Version: 2.6.30
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Other
>> AssignedTo: acme@ghostprotocols.net
>> ReportedBy: jasen@treshna.com
>> Regression: No
>>
>>
>> The host http://www.cv-it.com is virtually unreachable with kernel 2.6.26
>> (and later) slow with kernel 2.6.18 and just fine with windows XP.
>>
>> I used telnet to port 80 for testing.
>>
>> it seems to be a TCP issue, as the having the XP machine behind a linux based
>> iptables firewall pc causes no problems, but telnet from the firewall pc itself
>> to port 80 on www.cv-it.com does not work
For me it seems to be the host is messing up with the window scale option.
Although it claims to support window scaling:
16:23:17.466592 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [S], seq 2159265664, win 5840, options [mss 1460,sackOK,TS val 8382141 ecr 0,nop,wscale 7], length 0
16:23:17.761697 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [S.], seq 3910885479, ack 2159265665, win 65535, options [mss 1448,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 8], length 0
My host (linux 2.6.32) is offering a window of 5888 (46<<7):
16:23:17.761740 IP x.x.x.x.51151 > 121.199.32.220.80: Flags [.], ack 1, win 46, length 0
And cv-it.com seems to think there is only a window of 46 ignoring the previously negotiated window scaling:
16:23:23.066318 IP 121.199.32.220.80 > x.x.x.x.51151: Flags [.], seq 1:47, ack 112, win 65160, length 46
You can disable window scaling with:
sysctl -w "net.ipv4.tcp_window_scaling=0"
Best regards,
Arnd
^ permalink raw reply
* [PATCH 1/1] [TIPC] Removed inactive maintainer
From: Jon Paul Maloy @ 2010-03-25 15:35 UTC (permalink / raw)
To: David Miller; +Cc: Maloy, netdev, tipc-discussion, Jon
In-Reply-To: </home/lmcjoma/tipc/git-tipc/outgoing_patches/>
From: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 449d444..5c99bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5423,7 +5423,6 @@ S: Maintained
F: sound/soc/codecs/twl4030*
TIPC NETWORK LAYER
-M: Per Liden <per.liden@ericsson.com>
M: Jon Maloy <jon.maloy@ericsson.com>
M: Allan Stephens <allan.stephens@windriver.com>
L: tipc-discussion@lists.sourceforge.net
--
1.5.4.3
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply related
* Problem with talking to the kernel and iproute2/ifconfig
From: Paweł Staszewski @ 2010-03-25 16:00 UTC (permalink / raw)
To: Linux Network Development list
Hello
I have strange problem with kernel 2.6.33.1
I have script with 6267 ip's
cat gateways.conf | grep 'addr add' | wc -l
6267
and when i want to commit this interfaces by command:
ip -batch gateways.conf
I have only 680 ip interfaces
ip a | grep inet | grep ' 10.' | wc -l
680
I test this on kernels 2.6.29.1 and 2.6.30.1 and all was OK.
on kernel 2.6.29.1
ip -batch gateways.conf
ip a | grep inet | grep ' 10.' | wc -l
6267
on kernel 2.6.30.1
ip -batch gateways.conf
ip a | grep inet | grep ' 10.' | wc -l
6267
And also weird thing is that on kernel 2.6.33.1
ip addr ls dev vlan0100
158: vlan0100@eth2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noqueue
state DOWN qlen 100
link/ether 00:30:48:67:fd:2e brd ff:ff:ff:ff:ff:ff
the same machine - the same interface but ifconfig use to list ip's
ifconfig vlan0100
vlan0100 Link encap:Ethernet HWaddr 00:30:48:67:fd:2e
inet addr:10.0.0.1 Bcast:0.0.0.0 Mask:255.255.255.248
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
The same machine - with the same script that loads gateways but on
kernel 2.6.29.1
ip a ls dev vlan0100
8: vlan0100@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb
state UP qlen 100
link/ether 00:30:48:d3:33:d6 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/29 brd 10.0.0.7 scope global vlan0100:1
inet 10.0.0.25/29 brd 10.0.0.31 scope global vlan0100:2
inet 10.0.0.49/29 brd 10.0.0.55 scope global vlan0100:3
inet 10.0.0.121/29 brd 10.0.0.127 scope global vlan0100:4
inet 10.0.0.129/29 brd 10.0.0.135 scope global vlan0100:5
inet 10.0.0.153/29 brd 10.0.0.159 scope global vlan0100:6
Bests Regards
Paweł
^ permalink raw reply
* [PATCH] xt_hashlimit: IPV6 bugfix
From: Eric Dumazet @ 2010-03-25 16:17 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, Netfilter Development Mailinglist, David Miller
A missing break statement in hashlimit_ipv6_mask(), and masks
between /64 and /95 are not working at all...
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 8f3e0c0..7ac6ea7 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -487,6 +487,7 @@ static void hashlimit_ipv6_mask(__be32 *i, unsigned int p)
case 64 ... 95:
i[2] = maskl(i[2], p - 64);
i[3] = 0;
+ break;
case 96 ... 127:
i[3] = maskl(i[3], p - 96);
break;
^ permalink raw reply related
* Re: [PATCH] xt_hashlimit: IPV6 bugfix
From: Patrick McHardy @ 2010-03-25 16:26 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Netfilter Development Mailinglist, David Miller
In-Reply-To: <1269533869.3626.41.camel@edumazet-laptop>
Eric Dumazet wrote:
> A missing break statement in hashlimit_ipv6_mask(), and masks
> between /64 and /95 are not working at all...
Applied, thanks Eric.
^ permalink raw reply
* Re: mmotm 2010-03-23 - IPv6 warnings...
From: Valdis.Kletnieks @ 2010-03-25 16:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
In-Reply-To: <20100324184226.3bf42d8f.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Wed, 24 Mar 2010 18:42:26 EDT, Andrew Morton said:
> On Wed, 24 Mar 2010 21:36:41 -0400 Valdis.Kletnieks@vt.edu wrote:
>
> > On Tue, 23 Mar 2010 15:34:59 PDT, akpm@linux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-03-23-15-34 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > Seen in my dmesg. It may be relevant that I'm at home, and my IPv6
> > prefix arrives via a PPP VPN connection. This happened about 20-25 seconds
> > after I launched pppd.
>
> Yes, thanks, I get the same - it doesn't seem to break anything. It
> also happens some time after boot has completed.
Just doing an 'ifup eth0' on a network with IPv6 on it is sufficient.
And it does break stuff:
% ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:E8:C6:AD:17
inet addr:128.173.14.107 Bcast:128.173.15.255 Mask:255.255.252.0
inet6 addr: fe80::224:e8ff:fec6:ad17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
With 2.6.34-rc1-mmotm0309, I see:
% ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:24:E8:C6:AD:17
inet addr:128.173.14.107 Bcast:128.173.15.255 Mask:255.255.252.0
inet6 addr: 2001:468:c80:2103:224:e8ff:fec6:ad17/64 Scope:Global
inet6 addr: fe80::224:e8ff:fec6:ad17/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Something ate my IPv6 address. We run a lot of IPv6 in production, so stuff
is acting wonky.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Question about e06e7c615877026544ad7f8b309d1a3706410383 -- [IPV4]: The scheduled removal of multipath cached routing support.
From: Richard Hartmann @ 2010-03-25 17:11 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: davem
Hi all,
I was wondering what the rationale for commit
e06e7c615877026544ad7f8b309d1a3706410383 is. We upgraded our custom
image to 2.6.33 recently and found those options to be missing.
Thanks,
Richard Hartmann
^ permalink raw reply
* RE: [PATCH] e1000e: export some settings using ethtool private flags
From: Tantilov, Emil S @ 2010-03-25 17:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev@vger.kernel.org
In-Reply-To: <20100227082305.GA18194@havoc.gtf.org>
Jeff Garzik wrote:
> The ethtool private flags interface exists to get/set driver-specific
> settings at runtime, in a flexible manner.
>
> Use this facility to export a couple e1000e features, that were
> previously only set at module initialization time.
>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> ---
> drivers/net/e1000e/ethtool.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Jeff,
What is the use case for the ethtool private flags? At least I don't see an option in ethtool that would make use of them.
Thanks,
Emil
^ permalink raw reply
* Re: Question about e06e7c615877026544ad7f8b309d1a3706410383 -- [IPV4]: The scheduled removal of multipath cached routing support.
From: Nick Bowler @ 2010-03-25 17:21 UTC (permalink / raw)
To: Richard Hartmann; +Cc: linux-kernel, netdev, davem
In-Reply-To: <2d460de71003251011y2d8d1931u683b396f40df4ed1@mail.gmail.com>
On 18:11 Thu 25 Mar , Richard Hartmann wrote:
> I was wondering what the rationale for commit
> e06e7c615877026544ad7f8b309d1a3706410383 is. We upgraded our custom
> image to 2.6.33 recently and found those options to be missing.
>From the diff of that commit:
-What: Multipath cached routing support in ipv4
-When: in 2.6.23
-Why: Code was merged, then submitter immediately disappeared leaving
- us with no maintainer and lots of bugs. The code should not have
- been merged in the first place, and many aspects of it's
- implementation are blocking more critical core networking
- development. It's marked EXPERIMENTAL and no distribution
- enables it because it cause obscure crashes due to unfixable bugs
- (interfaces don't return errors so memory allocation can't be
- handled, calling contexts of these interfaces make handling
- errors impossible too because they get called after we've
- totally commited to creating a route object, for example).
- This problem has existed for years and no forward progress
- has ever been made, and nobody steps up to try and salvage
- this code, so we're going to finally just get rid of it.
-Who: David S. Miller <davem@davemloft.net>
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: [BUG] i.MX25: Broken include in mach-mx25pdk.c
From: Matthias Kaehlcke @ 2010-03-25 17:28 UTC (permalink / raw)
To: Baruch Siach; +Cc: Sascha Hauer, linux-arm-kernel, David S. Miller, netdev
In-Reply-To: <20100325164147.GA27698@jasper.tkos.co.il>
hi,
El Thu, Mar 25, 2010 at 06:41:47PM +0200 Baruch Siach ha dit:
> On Thu, Mar 25, 2010 at 05:16:35PM +0100, Matthias Kaehlcke wrote:
> > compiling arch/arm/mach-mx25/mach-mx25pdk.c fails due to the missing
> > include "linux/fec.h" and incomplete types that are supposed to
> > defined in this header
> >
> > i'd send a fix, but greping through the kernel tree i haven't been
> > able to identify the file defining the missing elements, i suppose it's still
> > sitting bored in some development tree waiting to be merged
>
> Apply the patch at http://patchwork.ozlabs.org/patch/41235/.
>
> For some reason this patch never made it to the mainline even after my
> repeated nagging :(.
thanks for the pointer, baruch!
david: is there any inconvenience to merge the patch to netdev? if so,
what can be done to make it mergeable?
regards
--
Matthias Kaehlcke
Embedded Linux Developer
Barcelona
The assumption that what currently exists must necessarily
exist is the acid that corrodes all visionary thinking
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox