* refcounting on dgram Unix sockets for poll(POLLOUT)
From: Alban Crequy @ 2010-12-08 21:01 UTC (permalink / raw)
To: netdev
Hi,
When a connected datagram Unix socket is polled for POLLOUT events, the
poller is added in the wait_queue_head_t of the "server" socket:
net/unix/af_unix.c::unix_dgram_poll()
other = unix_peer_get(sk);
if (other) {
if (unix_peer(other) != sk) {
sock_poll_wait(file, &unix_sk(other)->peer_wait,
wait);
...
I wonder what prevent the "server" socket ("other") to be released
while the poller is still waiting for POLLOUT events.
There is a reference taken on the "server" socket when the client
connects:
net/unix/af_unix.c::unix_dgram_connect()
other = unix_find_other(net, sunaddr, alen, sock->type,
hash, &err);
But that reference could be released when the client socket
disconnects from another thread in one of the 3 possible locations:
1. unix_dgram_connect() when connecting to a different socket
if (other != old_peer)
unix_dgram_disconnected(sk, old_peer);
sock_put(old_peer);
2. unix_dgram_sendmsg() when the server socket is SOCK_DEAD:
unix_dgram_disconnected(sk, other);
sock_put(other);
3. unix_release_sock() when the client socket is released:
skpair = unix_peer(sk);
if (skpair != NULL) {
sock_put(skpair); /* It may now die */
I tried to release all the references to server_sockfd with
close(server_sockfd) on the server thread and with
connect(client_sockfd) to a different socket while client_sockfd is
being polled for POLLOUT events in a different thread, hoping to crash
the poller with the stack:
free_poll_entry()->remove_wait_queue()->spin_lock_irqsave()
But I didn't manage to crash the kernel.
Am I missing something? Is there another reference taken on
server_sockfd to protect the kernel from this scenario?
And btw, what is the test (unix_peer(other) != sk) in unix_dgram_poll()?
Alban
^ permalink raw reply
* Re: [PATCH 1/2] via-velocity: set sleep speed to 10Mbps for powersaving.
From: David Miller @ 2010-12-08 20:56 UTC (permalink / raw)
To: davidlv.linux; +Cc: netdev, romieu, DavidLv, ShirleyHu, AndersMa
In-Reply-To: <AANLkTi==2E1VxbXatjEN7hORfPbxmiSTbD6SwqH5JGEu@mail.gmail.com>
From: David Lv <davidlv.linux@gmail.com>
Date: Wed, 8 Dec 2010 12:10:53 +0800
> I am sending this patch for setting speed to 10Mbps when entering into
> sleep mode.
> It is for power saving.
> Thanks!
>
> Signed-off-by: David Lv <DavidLv@viatech.com.cn>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
...
> + velocity_set_int_opt((int *) &opts->sleep_speed_10m, sleep_speed_10M[index],
> + SLEEP_SPEED_DISABLE, SLEEP_SPEED_ENABLE, SLEEP_SPEED_DEF, "Sleep
> Speed Forced 10M", devname);
...
Same problem here, you email client corrupted the patch,
please fix this and resubmit.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] via-velocity: fix the WOL bug on 1000M full duplex forced mode
From: David Miller @ 2010-12-08 20:56 UTC (permalink / raw)
To: davidlv.linux; +Cc: netdev, romieu, DavidLv, ShirleyHu, AndersMa
In-Reply-To: <AANLkTi=+r4cjE-3RJgrsrVaPBz0Ok_7XqZ+dxZgFCCUg@mail.gmail.com>
From: David Lv <davidlv.linux@gmail.com>
Date: Wed, 8 Dec 2010 13:47:19 +0800
> The VIA velocity card can't be waken up by WOL tool on 1000M full
> duplex forced mode.
> This patch fixes the bug.
> Thanks!
>
> Signed-off-by: David Lv <DavidLv@viatech.com.cn>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
...
>
> - MII_REG_BITS_OFF(ADVERTISE_1000FULL | ADVERTISE_1000HALF,
> MII_CTRL1000, vptr->mac_regs);
Your email client has corrupted the patch by chopping up long lines
etc., please correct this and resubmit your patch.
^ permalink raw reply
* Re: IPsecv6 tunnel mode fragmentation
From: David Miller @ 2010-12-08 20:37 UTC (permalink / raw)
To: herbert; +Cc: latten, netdev, samudrala, rashmin
In-Reply-To: <20101208071109.GA14537@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 8 Dec 2010 15:11:09 +0800
> Joy Latten <latten@austin.ibm.com> wrote:
>>
>> We have come across an ipsec problem that I think was
>> noted a while back in the following link.
>> http://www.mail-archive.com/netdev@vger.kernel.org/msg61659.html
>
> Looks like a configuration issue to me. One end is using the
> same IP address (*::1234) both within and outside the tunnel.
> Thus when the ICMP error message is sent it ends up outside the
> tunnel causing it to be discarded by the other side.
>
> So if you're using tunnel mode you really should use distinct
> IP addresses.
Agreed.
^ permalink raw reply
* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Paweł Staszewski @ 2010-12-08 20:30 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, Paul Mackerras, bugzilla-daemon, bugme-daemon,
pstaszewski
In-Reply-To: <20101208122233.835a4997.akpm@linux-foundation.org>
W dniu 2010-12-08 21:22, Andrew Morton pisze:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed, 8 Dec 2010 20:14:45 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>>
>> Summary: Kernel panic - not syncing: Fatal Exception
>> Product: Drivers
>> Version: 2.5
>> Kernel Version: 2.6.36.1
>> Platform: All
>> OS/Version: Linux
>> Tree: Mainline
>> Status: NEW
>> Severity: normal
>> Priority: P1
>> Component: Network
>> AssignedTo: drivers_network@kernel-bugs.osdl.org
>> ReportedBy: pstaszewski@artcom.pl
>> Regression: No
>>
>>
>> Created an attachment (id=39332)
>> --> (https://bugzilla.kernel.org/attachment.cgi?id=39332)
>> Kernel Panic
>>
>> Hello i have problems with ppp driver and pppoe
>> I have random kernel panics
>>
>> In attached image is Call Trace from panic.
>>
>>
> ppp_unregister_channel() appears to be using a bad pointer.
> --
Yes.
I see kernel panics when connection is terminated - but this happend
randomly
Sometimes to reproduce i need to connect->disconnect 50 - 60 times
before kernel panic.
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* Re: [PATCH] tcp: protect sysctl_tcp_cookie_size reads
From: David Miller @ 2010-12-08 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: Martin, netdev, bhutchings, william.allen.simpson
In-Reply-To: <1291760447.5324.31.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 23:20:47 +0100
> Make sure sysctl_tcp_cookie_size is read once in
> tcp_cookie_size_check(), or we might return an illegal value to caller
> if sysctl_tcp_cookie_size is changed by another cpu.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tcp: avoid a possible divide by zero
From: David Miller @ 2010-12-08 20:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, Martin, netdev
In-Reply-To: <1291759435.5324.25.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 23:03:55 +0100
> [PATCH v2] tcp: avoid a possible divide by zero
>
> sysctl_tcp_tso_win_divisor might be set to zero while one cpu runs in
> tcp_tso_should_defer(). Make sure we dont allow a divide by zero by
> reading sysctl_tcp_tso_win_divisor exactly once.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/3] bonding: add the debugfs interface to see RLB hash table
From: Jay Vosburgh @ 2010-12-08 20:33 UTC (permalink / raw)
To: Taku Izumi; +Cc: netdev@vger.kernel.org, eric.dumazet, shemminger
In-Reply-To: <4CF89A00.8030902@jp.fujitsu.com>
Taku Izumi <izumi.taku@jp.fujitsu.com> wrote:
>Hi Jay,
>
>Thank you for your quick review. I update my patchset according to your comment.
>But I didn't take measures against your concern about seq_file. If I come up with
>a good idea, I'll correct it.
>
>--
>This patchset provides the debugfs facility to the bonding driver and
>the interface to see RLB hashtable in it.
>
> *[PATCH 1/3] bonding: add the debugfs facility to the bonding driver
> *[PATCH 2/3] bonding: migrate some macros from bond_alb.c to bond_alb.h
> *[PATCH 3/3] bonding: add the debugfs interface to see RLB hash table
After applying your patches to net-next-2.6, I'm seeing the
following crash when executing "rmmod bonding":
BUG: unable to handle kernel paging request at 6b6b6b9f
IP: [<c0201f11>] debugfs_remove_recursive+0x1e/0x11a
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/net/bond0/flags
Modules linked in: bonding(-) ipv6 mperf microcode loop tg3 e1000 libphy sworks_agp agpgart edd ext3 mbcache jbd pata_serverworks mptspi mptscsih mptbase [last unloaded: speedstep_lib]
Pid: 5237, comm: rmmod Not tainted 2.6.37-rc1-cur+ #11 /eserver xSeries 335 -[8676GBX]-
EIP: 0060:[<c0201f11>] EFLAGS: 00010202 CPU: 2
EIP is at debugfs_remove_recursive+0x1e/0x11a
EAX: 6b6b6b6b EBX: f4d99480 ECX: 00000000 EDX: f3d5a5d4
ESI: f4d99950 EDI: f2d445b8 EBP: f4d03eb8 ESP: f4d03ea8
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process rmmod (pid: 5237, ti=f4d02000 task=f3d5a240 task.ti=f4d02000)
Stack:
f4d03ec0 f4d99480 f4d99950 f4d99000 f4d03ec0 f801dc05 f4d03ef4 f8015c5b
c0156ab6 f4d03ed8 c0134ff0 f4d9949c f4d03ee4 c037ec67 f4d99150 f4d03ef4
f4d99000 f4d03f20 f4d99000 f4d03f08 c030eafe f4d03f20 c0ce4140 f80233a4
Call Trace:
[<f801dc05>] ? bond_debug_unregister+0xe/0x10 [bonding]
[<f8015c5b>] ? bond_uninit+0x324/0x36d [bonding]
[<c0156ab6>] ? trace_hardirqs_on+0xb/0xd
[<c0134ff0>] ? local_bh_enable_ip+0x97/0xae
[<c037ec67>] ? _raw_spin_unlock_bh+0x2f/0x32
[<c030eafe>] ? rollback_registered_many+0x187/0x1fb
[<c030eb81>] ? unregister_netdevice_many+0xf/0x4d
[<c0318890>] ? __rtnl_link_unregister+0x56/0x8a
[<c0318f45>] ? rtnl_link_unregister+0x19/0x21
[<f801e32d>] ? bonding_exit+0x30/0x3c [bonding]
[<c0162ddc>] ? sys_delete_module+0x184/0x1dc
[<c01555fe>] ? put_lock_stats+0xd/0x22
[<c0155708>] ? lock_release_holdtime+0xf5/0xfa
[<c01a8fa3>] ? sys_munmap+0x39/0x3f
[<c037f098>] ? restore_all_notrace+0x0/0x18
[<c010294c>] ? sysenter_do_call+0x12/0x32
Code: fc ff 89 d8 e8 27 77 fc ff 5b 5e 5d c3 55 89 e5 57 89 c7 56 53 83 ec 04 85 c0 0f 84 01 01 00 00 8b 40 40 85 c0 0f 84 f6 00 00 00 <83> 78 34 00 0f 84 ec 00 00 00 8b 47 34 31 d2 89 fe 05 a4 00 00
EIP: [<c0201f11>] debugfs_remove_recursive+0x1e/0x11a SS:ESP 0068:f4d03ea8
CR2: 000000006b6b6b9f
---[ end trace e274f539dfd6ed30 ]---
This happens regardless of activity; e.g., "insmod bonding
mode=balance-alb" followed immediately by "rmmod bonding" generates the
above.
Any thoughts?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: ctnetlink loop
From: Holger Eitzenberger @ 2010-12-08 20:31 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20101208.095020.245408999.davem@davemloft.net>
Hi,
> Holger, this replay -EAGAIN loop in nfnetlink processing was added by
> Pablo to handle module loading properly, I think. So it might not be
> safe to just unilaterally remove it.
thanks for your reply!
Pablo, do we really need the replay loop really? I now have several
boxes with problems due to this replay. 'perf report' always gives me
something like:
18.88% ulogd [kernel]
[k] __nla_put
10.73% ulogd [kernel]
[k] nla_parse
8.72% ulogd [kernel]
[k] __nla_reserve
6.64% ulogd [kernel]
[k] nla_put
5.14% ulogd [kernel]
[k] validate_nla
5.03% ulogd [kernel]
[k] pskb_expand_head
4.92% ulogd [kernel]
[k] ctnetlink_fill_info [nf_conntrack_netlink]
3.07% ulogd [kernel]
[k] skb_put
3.03% ulogd [kernel]
[k] ctnetlink_dump_counters [nf_conntrack
And 'strace' shows me that ulogd is stuck in its 'select' call.
/holger
^ permalink raw reply
* Re: [Bugme-new] [Bug 24472] New: Kernel panic - not syncing: Fatal Exception
From: Andrew Morton @ 2010-12-08 20:22 UTC (permalink / raw)
To: netdev, Paul Mackerras; +Cc: bugzilla-daemon, bugme-daemon, pstaszewski
In-Reply-To: <bug-24472-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 8 Dec 2010 20:14:45 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=24472
>
> Summary: Kernel panic - not syncing: Fatal Exception
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: pstaszewski@artcom.pl
> Regression: No
>
>
> Created an attachment (id=39332)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=39332)
> Kernel Panic
>
> Hello i have problems with ppp driver and pppoe
> I have random kernel panics
>
> In attached image is Call Trace from panic.
>
>
ppp_unregister_channel() appears to be using a bad pointer.
^ permalink raw reply
* Re: WARNING at local_bh_enable while tcp_retransmit
From: Jarek Poplawski @ 2010-12-08 20:20 UTC (permalink / raw)
To: Ilya Loginov; +Cc: netdev, davem
In-Reply-To: <20101208123645.84091844.isloginov@gmail.com>
Ilya Loginov wrote:
> On Tue, 07 Dec 2010 21:56:19 +0100
> Jarek Poplawski <jarkao2@gmail.com> wrote:
>
>> Hi, isn't any of your drivers disabling irqs on this path?
>
> No. But we are in soft_irq because tcp_retransmit. So, may be,
> interrupts were really disabled.
Should be easy to check by copying this WARN_ON_ONCE from
kernel/softirq.c:143 local_bh_enable to the beginning of
your rioth_start_xmit.
Jarek P.
^ permalink raw reply
* Re: [PATCH] ehea: Fixing LRO configuration
From: David Miller @ 2010-12-08 20:19 UTC (permalink / raw)
To: leitao; +Cc: bhutchings, shemminger, netdev
In-Reply-To: <1291834280-30787-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Wed, 8 Dec 2010 16:51:20 -0200
> In order to set LRO on ehea, the user must set a module parameter, which
> is not the standard way to do so. This patch adds a way to set LRO using
> the ethtool tool.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied, thanks Breno.
^ permalink raw reply
* Re: [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: David Miller @ 2010-12-08 20:16 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <alpine.DEB.2.00.1012081139180.2652@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 8 Dec 2010 11:42:38 -0800 (PST)
> Rather than printing the message to the log, use a mib counter to keep
> track of the count of occurences of time wait bucket overflow. Reduces
> spam in logs.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH] atm: correct sysfs 'device' link creation and parent relationships
From: David Miller @ 2010-12-08 20:15 UTC (permalink / raw)
To: kay.sievers-tD+1rO4QERM
Cc: dcbw-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
duncan.sands-GANU6spQydw, linux-usb-u79uwXL29TY76Z2rM5mHXA,
chas-vT06rRrALxcmhCb6mdbn6A
In-Reply-To: <20101208.101121.71114237.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 08 Dec 2010 10:11:21 -0800 (PST)
> From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
> Date: Tue, 7 Dec 2010 08:35:53 +0100
>
>> On Sun, Dec 5, 2010 at 23:17, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> The ATM subsystem was incorrectly creating the 'device' link for ATM
>>> nodes in sysfs. This led to incorrect device/parent relationships
>>> exposed by sysfs and udev. Instead of rolling the 'device' link by hand
>>> in the generic ATM code, pass each ATM driver's bus device down to the
>>> sysfs code and let sysfs do this stuff correctly.
>>
>> Looks good to me.
>
> I've applied this to net-2.6, thanks Dan.
Actually I'm reverting, it breaks the build.
Did you even grep for "atm_dev_register()" after changning the number
of arguments, or were you depending upon build failures to guide you?
Please never do the latter, as it always leads to things like this.
drivers/atm/fore200e.c:2577:7: error: too few arguments to function 'atm_dev_register'
drivers/atm/iphase.c:3175:2: error: too few arguments to function 'atm_dev_register'
...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: Tom Herbert @ 2010-12-08 19:42 UTC (permalink / raw)
To: davem, netdev; +Cc: eric.dumazet
Rather than printing the message to the log, use a mib counter to keep
track of the count of occurences of time wait bucket overflow. Reduces
spam in logs.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_minisocks.c | 2 +-
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index ebb0c80..12b2b18 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -230,6 +230,7 @@ enum
LINUX_MIB_TCPMINTTLDROP, /* RFC 5082 */
LINUX_MIB_TCPDEFERACCEPTDROP,
LINUX_MIB_IPRPFILTER, /* IP Reverse Path Filter (rp_filter) */
+ LINUX_MIB_TCPTIMEWAITOVERFLOW, /* TCPTimeWaitOverflow */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 1b48eb1..b14ec7d 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -253,6 +253,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPMinTTLDrop", LINUX_MIB_TCPMINTTLDROP),
SNMP_MIB_ITEM("TCPDeferAcceptDrop", LINUX_MIB_TCPDEFERACCEPTDROP),
SNMP_MIB_ITEM("IPReversePathFilter", LINUX_MIB_IPRPFILTER),
+ SNMP_MIB_ITEM("TCPTimeWaitOverflow", LINUX_MIB_TCPTIMEWAITOVERFLOW),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 43cf901..a66735f 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -347,7 +347,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
* socket up. We've got bigger problems than
* non-graceful socket closings.
*/
- LIMIT_NETDEBUG(KERN_INFO "TCP: time wait bucket table overflow\n");
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPTIMEWAITOVERFLOW);
}
tcp_update_metrics(sk);
--
1.7.3.1
^ permalink raw reply related
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:39 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835681.2560.53.camel@bwh-desktop>
On Wed, 2010-12-08 at 19:14 +0000, Ben Hutchings wrote:
> On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > > The implementation of the -U
> > > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > > vlan_tag and user_def are not specified.
> > >
> >
> > Having said that, don't u think that it could be more user friendly to
> > extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> > user_def and drop the n-tuple interface at all?
>
> No, we can't remove userland interfaces.
Having said that, this particular interface is fairly broken...
$ cat test.c
#include <stddef.h>
#include <stdio.h>
#include <linux/ethtool.h>
int main(void)
{
printf("%zd\n", offsetof(struct ethtool_rx_flow_spec, ring_cookie));
return 0;
}
$ cc -m64 -Wall test.c
$ ./a.out
152
$ cc -m32 -Wall test.c
$ ./a.out
148
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 19:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835644.2560.52.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
>> Ben Hutchings wrote:
>>> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>>>> It's a bit worse than that. Currently one can only append filters, not
>>>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>>>> a new filter for the same index.
>>>>> It looks like drivers for devices that use TCAMs should implement the
>>>>> RXNFC interface instead.
>>>>>
>>>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>>>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>>>> the destination Rx queue for a stream specified by a filter/filters.
>>> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
>>> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>>>
>>>> The
>>>> semantics for a specification of the steam is also quite different. For
>>>> instance, how do u define a rule to drop all packets with source IP
>>>> address 192.168.10.200 by means of RXNFC?
>>> Something like this, I think:
>>>
>>> struct ethtool_rxnfc insert_rule = {
>>> .cmd = ETHTOOL_SRXCLSRLINS,
>>> .flow_type = IP_USER_SPEC,
>>> .fs = {
>>> .flow_type = IP_USER_SPEC,
>>> .h_u.usr_ip4_spec = {
>>> .ip4src = inet_aton("192.168.10.200"),
>>> .ip_ver = ETH_RX_NFC_IP4
>>> },
>>> .m_u.usr_ip4_spec = {
>>> .ip4dst = 0xffffffff,
>>> .l4_4_bytes = 0xffffffff,
>>> .tos = 0xff,
>>> .proto = 0xff
>>> },
>>> .ring_cookie = RX_CLS_FLOW_DISC,
>>> .location = 0,
>>> }
>>> };
>> I think the mask would be 0 for don't care fields and 1 for care, so
>>
>> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
>> .m_u.usr_ip4_spec.ip4dst = htonl(0)
>> etc
>
> That is definitely the opposite of what ixgbe and sfc do for
> ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
> niu does for ethtool_rx_flow_spec.
These are the values as our HW at least wants them. The care bits are 1 in
the mask. It's not a huge deal, the driver can complement the masks.
>
> [...]
>>>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>>>> last in general may override the decision made based on the hash result.
>>>> So, it sounds like applying rules of SRXNTUPLE should come before
>>>> applying the RSS logic and only if there was no match RSS should be
>>>> applied to that frame. Do I get it right?
>>> That's right.
>> It can be more involved than this. Our HW allows a rule to select a
>> different part of the RSS table so you get a filter hit and still do RSS
>> afterwards if you want. Current ethtool interfaces do not support this,
>> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> So does the rule specify an offset added to the output of the RSS hash
> and indirection table, or can it also select a different indirection
> table? Our current hardware also has a filter flag for the former
> behaviour... There are still plenty of bits to spare in 'action' and
> 'ring_cookie' so perhaps we could define a flag for this?
You can partition the indirection table and then a rule can specify that
matching packets should consult region X of the table. The hash value is
not altered, just the part of the overall table it indexes into.
>
> Ben.
>
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835453.24019.13.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > The implementation of the -U
> > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > vlan_tag and user_def are not specified.
> >
>
> Having said that, don't u think that it could be more user friendly to
> extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> user_def and drop the n-tuple interface at all?
No, we can't remove userland interfaces.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Dimitris Michailidis
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <4CFFD470.5090407@chelsio.com>
On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
> Ben Hutchings wrote:
> > On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> >>>> It's a bit worse than that. Currently one can only append filters, not
> >>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
> >>>> field. For devices that use TCAMs, where position matters, it's quite an
> >>>> obstacle. It also means one cannot modify an existing filter by specifying
> >>>> a new filter for the same index.
> >>> It looks like drivers for devices that use TCAMs should implement the
> >>> RXNFC interface instead.
> >>>
> >> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> >> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> >> the destination Rx queue for a stream specified by a filter/filters.
> >
> > By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> > ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> >
> >> The
> >> semantics for a specification of the steam is also quite different. For
> >> instance, how do u define a rule to drop all packets with source IP
> >> address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
>
> I think the mask would be 0 for don't care fields and 1 for care, so
>
> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
> .m_u.usr_ip4_spec.ip4dst = htonl(0)
> etc
That is definitely the opposite of what ixgbe and sfc do for
ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
niu does for ethtool_rx_flow_spec.
[...]
> >> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> >> last in general may override the decision made based on the hash result.
> >> So, it sounds like applying rules of SRXNTUPLE should come before
> >> applying the RSS logic and only if there was no match RSS should be
> >> applied to that frame. Do I get it right?
> >
> > That's right.
>
> It can be more involved than this. Our HW allows a rule to select a
> different part of the RSS table so you get a filter hit and still do RSS
> afterwards if you want. Current ethtool interfaces do not support this,
> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
So does the rule specify an offset added to the output of the RSS hash
and indirection table, or can it also select a different indirection
table? Our current hardware also has a filter flag for the former
behaviour... There are still plenty of bits to spare in 'action' and
'ring_cookie' so perhaps we could define a flag for this?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 19:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291834931.2560.42.camel@bwh-desktop>
> The implementation of the -U
> option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> vlan_tag and user_def are not specified.
>
Having said that, don't u think that it could be more user friendly to
extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
user_def and drop the n-tuple interface at all?
thanks,
vlad
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:02 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291833578.17102.69.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 20:39 +0200, Vladislav Zolotarov wrote:
> > > The
> > > semantics for a specification of the steam is also quite different. For
> > > instance, how do u define a rule to drop all packets with source IP
> > > address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
> >
>
> Aha. Ok. From the remarks in the upstream ethtool.h I see now that
> ethtool_rxnfc has quite wide configuration possibilities (including the
> above). I missed it before. ;)
>
> Ben, could u, pls., explain me then what's the difference between
> defining the rule as u wrote above on top of -N option (nfc) and
> defining the rule doing the same thing on top on -U (n-tuple) option and
> when I as a user should prefer one option to another? Are they expected
> to be implemented differently from FW/HW perspective?
The -N option modifies the hash function for all flows of a specific
type (using ETHTOOL_SRXFH) whereas the -U option steers a specific flow
or set of flows (using ETHTOOL_SRXNTUPLE). The implementation of the -U
option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
vlan_tag and user_def are not specified.
> thanks,
> vlad
>
> P.S. I see that ethtool.h from the 2.6.36 tree already has the
> ethtool_rxnfc that would allow such a filtering definition however from
> the man page of the 2.6.36 version of the ethtool package it's unclear
> what should be a command line for such a configuration. Is it supported
> with the current ethtool version or maybe I'm missing something in a man
> page?
It's not supported. Santwona Behera implemented the kernel side of this
but so far as I know he never sent any patches for ethtool.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 18:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291828940.2560.17.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>> It's a bit worse than that. Currently one can only append filters, not
>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>> a new filter for the same index.
>>> It looks like drivers for devices that use TCAMs should implement the
>>> RXNFC interface instead.
>>>
>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>> the destination Rx queue for a stream specified by a filter/filters.
>
> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>
>> The
>> semantics for a specification of the steam is also quite different. For
>> instance, how do u define a rule to drop all packets with source IP
>> address 192.168.10.200 by means of RXNFC?
>
> Something like this, I think:
>
> struct ethtool_rxnfc insert_rule = {
> .cmd = ETHTOOL_SRXCLSRLINS,
> .flow_type = IP_USER_SPEC,
> .fs = {
> .flow_type = IP_USER_SPEC,
> .h_u.usr_ip4_spec = {
> .ip4src = inet_aton("192.168.10.200"),
> .ip_ver = ETH_RX_NFC_IP4
> },
> .m_u.usr_ip4_spec = {
> .ip4dst = 0xffffffff,
> .l4_4_bytes = 0xffffffff,
> .tos = 0xff,
> .proto = 0xff
> },
> .ring_cookie = RX_CLS_FLOW_DISC,
> .location = 0,
> }
> };
I think the mask would be 0 for don't care fields and 1 for care, so
.m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
.m_u.usr_ip4_spec.ip4dst = htonl(0)
etc
There's a lot of overlap between SRXCLSRLINS and SRXNTUPLE and neither is a
superset. SRXCLSRLINS has the advantage of specifying position but
SRXNTUPLE includes vlan and a device-specific field that are handy.
Also for reporting rules GRXNTUPLE is more flexible than GRXCLSRULE as it
lets the driver specify the information it reports. In fact I've been
thinking of using SRXCLSRLINS and GRXNTUPLE for cxgb4 but haven't gotten
over the ugliness of that yet.
>
> [...]
>> I also agree with Dimitris: what we have here is an offload of some
>> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
>> not) if it's allowed to configure more than one rule for the same
>> protocol the ordering of filtering rules is important: for instance if u
>> change the order of applying the rules in the example below the result
>> of the filtering for the traffic with both VLAN 4 and destination port
>> 3000 will be different.
>
> Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
> specific types of matching. There is some control of precedence between
> different types of match, but that's all.
>
>> ethtool -U ethX flow-type tcp4 vlan 4 action 0
>> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>>
>> By the way it's also unclear from the ethtool man page if it's allowed
>> to configure more than one rule for the same protocol. If it's not then
>> the above example is void... ;)
>
> It's allowed, but precedence is unspecified.
>
>> However, if we want to define a proper
>> filtering interface I think we shouldn't restrict the driver
>> implementation from defining a set of rules for the same protocol,
>> allowing not to though.
>>
>> So, I think that attaching an index to each rule could be a good idea -
>> this would allow us both inserting rules at the desired positions in the
>> filtering rule table and editing the existing rules.
>
> This really sounds like the RXNFC interface.
>
>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>> last in general may override the decision made based on the hash result.
>> So, it sounds like applying rules of SRXNTUPLE should come before
>> applying the RSS logic and only if there was no match RSS should be
>> applied to that frame. Do I get it right?
>
> That's right.
It can be more involved than this. Our HW allows a rule to select a
different part of the RSS table so you get a filter hit and still do RSS
afterwards if you want. Current ethtool interfaces do not support this,
basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> Ben.
>
^ permalink raw reply
* Re: [PATCH] X.25: decrement netdev reference counts on unload
From: David Miller @ 2010-12-08 18:55 UTC (permalink / raw)
To: apollon; +Cc: netdev
In-Reply-To: <20101207194330.GA22608@noc.grnet.gr>
From: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Date: Tue, 7 Dec 2010 21:43:30 +0200
> x25 does not decrement the network device reference counts on module unload.
> Thus unregistering any pre-existing interface after unloading the x25 module
> hangs and results in
>
> unregister_netdevice: waiting for tap0 to become free. Usage count = 1
>
> This patch decrements the reference counts of all interfaces in x25_link_free,
> the way it is already done in x25_link_device_down for NETDEV_DOWN events.
>
> Signed-off-by: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH] ehea: Fixing LRO configuration
From: leitao @ 2010-12-08 18:51 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, davem, netdev, Breno Leitao
In-Reply-To: <1291833849.2560.26.camel@bwh-desktop>
In order to set LRO on ehea, the user must set a module parameter, which
is not the standard way to do so. This patch adds a way to set LRO using
the ethtool tool.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 75b099c..1f37ee6 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -261,6 +261,13 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
}
+static int ehea_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO
+ | ETH_FLAG_TXVLAN
+ | ETH_FLAG_RXVLAN);
+}
+
const struct ethtool_ops ehea_ethtool_ops = {
.get_settings = ehea_get_settings,
.get_drvinfo = ehea_get_drvinfo,
@@ -273,6 +280,8 @@ const struct ethtool_ops ehea_ethtool_ops = {
.get_ethtool_stats = ehea_get_ethtool_stats,
.get_rx_csum = ehea_get_rx_csum,
.set_settings = ehea_set_settings,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ehea_set_flags,
.nway_reset = ehea_nway_reset, /* Restart autonegotiation */
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a84c389..c7132e8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -675,7 +675,7 @@ static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
int vlan_extracted = ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) &&
pr->port->vgrp);
- if (use_lro) {
+ if (skb->dev->features & NETIF_F_LRO) {
if (vlan_extracted)
lro_vlan_hwaccel_receive_skb(&pr->lro_mgr, skb,
pr->port->vgrp,
@@ -777,7 +777,7 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
cqe = ehea_poll_rq1(qp, &wqe_index);
}
- if (use_lro)
+ if (dev->features & NETIF_F_LRO)
lro_flush_all(&pr->lro_mgr);
pr->rx_packets += processed;
@@ -3265,6 +3265,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
+
+ if (use_lro)
+ dev->features |= NETIF_F_LRO;
INIT_WORK(&port->reset_task, ehea_reset_port);
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] isdn/hisax: fix compiler warning on hisax_pci_tbl
From: David Miller @ 2010-12-08 18:51 UTC (permalink / raw)
To: namhyung; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1291733346-11573-1-git-send-email-namhyung@gmail.com>
From: Namhyung Kim <namhyung@gmail.com>
Date: Tue, 7 Dec 2010 23:49:06 +0900
> Annotate hisax_pci_tbl as '__used' to fix following warning:
>
> CC drivers/isdn/hisax/config.o
> drivers/isdn/hisax/config.c:1920: warning: ‘hisax_pci_tbl’ defined but not used
>
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
This only happens because the hisax driver doesn't actually use this table
for probing. Each sub-driver does it's own thing.
What a mess.
Anyways, applied, thank you.
^ 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