* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: David Miller @ 2010-12-09 20:20 UTC (permalink / raw)
To: ebiederm
Cc: shemminger, brian.haley, netdev, maheshkelkar, lorenzo, yoshfuji,
stable
In-Reply-To: <m1y67y3fqf.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 09 Dec 2010 11:31:36 -0800
> You fix the problem. You introduced the regression, and you didn't test
> that keeping addresses actually worked. This is not the first patch
> that has been applied to fix regressions in this area.
Exactly, I fully agree with Eric.
^ permalink raw reply
* Re: [trivial PATCH 00/15] remove duplicate unlikely from IS_ERR
From: Joe Perches @ 2010-12-09 20:32 UTC (permalink / raw)
To: netdev, Tobias Klauser
Cc: uclinux-dist-devel, rtc-linux, linux-s390, osd-dev, linux-arm-msm,
linux-usb, linux-ext4, linux-nfs, linux-mm, Jiri Kosina,
dri-devel, linux-kernel, linux-scsi, linux-wireless, devel
In-Reply-To: <cover.1291923888.git.joe@perches.com>
On Thu, 2010-12-09 at 12:03 -0800, Joe Perches wrote:
> Tobias Klauser <tklauser@distanz.ch> sent a patch to remove
> an unnecessary unlikely from drivers/misc/c2port/core.c,
> https://lkml.org/lkml/2010/12/9/199
It seems that Tobias did send all the appropriate patches,
not as a series, but as individual patches to kernel-janitor.
c2port was the only one that went to lkml.
Please ignore this series and apply Tobias' patches.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH 1/4] net: implement mechanism for HW based QOS
From: Eric Dumazet @ 2010-12-09 20:46 UTC (permalink / raw)
To: John Fastabend; +Cc: davem, netdev, hadi, shemminger, tgraf
In-Reply-To: <20101209195956.3554.49511.stgit@jf-dev1-dcblab>
Le jeudi 09 décembre 2010 à 11:59 -0800, John Fastabend a écrit :
> This patch provides a mechanism for lower layer devices to
> steer traffic using skb->priority to tx queues. This allows
> for hardware based QOS schemes to use the default qdisc without
> incurring the penalties related to global state and the qdisc
> lock. While reliably receiving skbs on the correct tx ring
> to avoid head of line blocking resulting from shuffling in
> the LLD. Finally, all the goodness from txq caching and xps/rps
> can still be leveraged.
>
> Many drivers and hardware exist with the ability to implement
> QOS schemes in the hardware but currently these drivers tend
> to rely on firmware to reroute specific traffic, a driver
> specific select_queue or the queue_mapping action in the
> qdisc.
>
> By using select_queue for this drivers need to be updated for
> each and every traffic type and we lose the goodness of much
> of the upstream work. Firmware solutions are inherently
> inflexible. And finally if admins are expected to build a
> qdisc and filter rules to steer traffic this requires knowledge
> of how the hardware is currently configured. The number of tx
> queues and the queue offsets may change depending on resources.
> Also this approach incurs all the overhead of a qdisc with filters.
>
> With the mechanism in this patch users can set skb priority using
> expected methods ie setsockopt() or the stack can set the priority
> directly. Then the skb will be steered to the correct tx queues
> aligned with hardware QOS traffic classes. In the normal case with
> a single traffic class and all queues in this class everything
> works as is until the LLD enables multiple tcs.
>
> To steer the skb we mask out the lower 4 bits of the priority
> and allow the hardware to configure upto 15 distinct classes
> of traffic. This is expected to be sufficient for most applications
> at any rate it is more then the 8021Q spec designates and is
> equal to the number of prio bands currently implemented in
> the default qdisc.
>
> This in conjunction with a userspace application such as
> lldpad can be used to implement 8021Q transmission selection
> algorithms one of these algorithms being the extended transmission
> selection algorithm currently being used for DCB.
>
Very nice Changelog !
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---
>
> include/linux/netdevice.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
> net/core/dev.c | 39 ++++++++++++++++++++++++++-
> 2 files changed, 103 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index a9ac5dc..c0d4fb1 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -646,6 +646,12 @@ struct xps_dev_maps {
> (nr_cpu_ids * sizeof(struct xps_map *)))
> #endif /* CONFIG_XPS */
>
> +/* HW offloaded queuing disciplines txq count and offset maps */
> +struct netdev_tc_txq {
> + u16 count;
> + u16 offset;
> +};
> +
> /*
> * This structure defines the management hooks for network devices.
> * The following hooks can be defined; unless noted otherwise, they are
> @@ -1146,6 +1152,10 @@ struct net_device {
> /* Data Center Bridging netlink ops */
> const struct dcbnl_rtnl_ops *dcbnl_ops;
> #endif
> + u8 max_tc;
> + u8 num_tc;
> + struct netdev_tc_txq *_tc_to_txq;
Given that this is up to 16*4 bytes (64), shouldnt we embed this in
net_device struct to avoid one dereference ?
> + u8 prio_tc_map[16];
>
> #if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
> /* max exchange id for FCoE LRO by ddp */
> @@ -1162,6 +1172,58 @@ struct net_device {
> #define NETDEV_ALIGN 32
>
> static inline
> +int netdev_get_prio_tc_map(const struct net_device *dev, u32 prio)
> +{
> + return dev->prio_tc_map[prio & 15];
> +}
> +
> +static inline
> +int netdev_set_prio_tc_map(struct net_device *dev, u8 prio, u8 tc)
> +{
> + if (tc >= dev->num_tc)
> + return -EINVAL;
> +
> + dev->prio_tc_map[prio & 15] = tc & 15;
> + return 0;
> +}
> +
> +static inline
> +int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset)
> +{
> + struct netdev_tc_txq *tcp;
> +
> + if (tc >= dev->num_tc)
> + return -EINVAL;
> +
> + tcp = &dev->_tc_to_txq[tc];
> + tcp->count = count;
> + tcp->offset = offset;
> + return 0;
> +}
> +
> +static inline
> +struct netdev_tc_txq *netdev_get_tc_queue(const struct net_device *dev, u8 tc)
> +{
> + return &dev->_tc_to_txq[tc];
> +}
> +
> +static inline
> +int netdev_set_num_tc(struct net_device *dev, u8 num_tc)
> +{
> + if (num_tc > dev->max_tc)
> + return -EINVAL;
> +
> + dev->num_tc = num_tc;
> + return 0;
> +}
> +
> +static inline
> +u8 netdev_get_num_tc(const struct net_device *dev)
> +{
> + return dev->num_tc;
> +}
> +
> +static inline
> struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
> unsigned int index)
> {
> @@ -1386,6 +1448,9 @@ static inline void unregister_netdevice(struct net_device *dev)
> unregister_netdevice_queue(dev, NULL);
> }
>
> +extern int netdev_alloc_max_tc(struct net_device *dev, u8 tc);
> +extern void netdev_free_tc(struct net_device *dev);
> +
> extern int netdev_refcnt_read(const struct net_device *dev);
> extern void free_netdev(struct net_device *dev);
> extern void synchronize_net(void);
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 55ff66f..cc00e66 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2118,6 +2118,8 @@ static u32 hashrnd __read_mostly;
> u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
> {
> u32 hash;
> + u16 qoffset = 0;
> + u16 qcount = dev->real_num_tx_queues;
>
> if (skb_rx_queue_recorded(skb)) {
> hash = skb_get_rx_queue(skb);
> @@ -2126,13 +2128,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
> return hash;
> }
>
> + if (dev->num_tc) {
> + u8 tc = netdev_get_prio_tc_map(dev, skb->priority);
> + struct netdev_tc_txq *tcp = netdev_get_tc_queue(dev, tc);
> + qoffset = tcp->offset;
> + qcount = tcp->count;
> + }
> +
> if (skb->sk && skb->sk->sk_hash)
> hash = skb->sk->sk_hash;
> else
> hash = (__force u16) skb->protocol ^ skb->rxhash;
> hash = jhash_1word(hash, hashrnd);
>
> - return (u16) (((u64) hash * dev->real_num_tx_queues) >> 32);
> + return (u16) ((((u64) hash * qcount)) >> 32) + qoffset;
> }
> EXPORT_SYMBOL(skb_tx_hash);
>
> @@ -5091,6 +5100,33 @@ void netif_stacked_transfer_operstate(const struct net_device *rootdev,
> }
> EXPORT_SYMBOL(netif_stacked_transfer_operstate);
>
> +int netdev_alloc_max_tc(struct net_device *dev, u8 tcs)
> +{
> + struct netdev_tc_txq *tcp;
> +
> + if (tcs > 16)
> + return -EINVAL;
> +
> + tcp = kcalloc(tcs, sizeof(*tcp), GFP_KERNEL);
common risk : allocating less than one cache line, and this possibly can
have false sharing.
I would just embed the thing.
^ permalink raw reply
* Re: 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
From: Paul Moore @ 2010-12-09 20:49 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: James Morris, Stephen Smalley, NetDev, Linux Kernel Mailing List
In-Reply-To: <1291923746.5339.20.camel@sifl>
On Thu, 2010-12-09 at 14:42 -0500, Paul Moore wrote:
> On Wed, 2010-12-08 at 13:09 -0800, Jeremy Fitzhardinge wrote:
> > I just got this oops in a freshly booted 2.6.37-rc5 Xen domain, while
> > sitting idle at the login prompt:
> >
> > BUG: unable to handle kernel NULL pointer dereference at 0000000000000210
> > IP: [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> > PGD 1c99d067 PUD 1cb03067 PMD 0
> > Oops: 0000 [#1] SMP
> > last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
> > CPU 0
> > Modules linked in: sunrpc dm_mirror dm_region_hash dm_log [last unloaded: scsi_wait_scan]
> >
> > Pid: 2297, comm: at-spi-registry Not tainted 2.6.37-rc5+ #293 /
> > RIP: e030:[<ffffffff811d55d4>] [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> > RSP: e02b:ffff880006e7dd68 EFLAGS: 00010292
> > RAX: ffff88001d1ed8c0 RBX: ffff88001d06d9a0 RCX: 0000000000000022
> > RDX: ffff88001d1ed580 RSI: 0000000000000000 RDI: ffff88001b7d6ac0
> > RBP: ffff880006e7de18 R08: 00000000ffff0201 R09: ffff88001e78c968
> > R10: 000000001f47e9c2 R11: ffff88001fbf4400 R12: ffff88001d1ed8c0
> > R13: ffff88001d1ed580 R14: ffff88001ca00cc0 R15: 0000000000000000
> > FS: 00007fa643031920(0000) GS:ffff88001ff85000(0000) knlGS:0000000000000000
> > CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: 0000000000000210 CR3: 000000001d78a000 CR4: 0000000000002660
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process at-spi-registry (pid: 2297, threadinfo ffff880006e7c000, task ffff88001cdd1140)
> > Stack:
> > ffff88001d4c0bc0 000000004cffecc5 ffff880006e7ddc8 ffffffff81028dc5
> > ffff8800ffffffff 0001628b2ec3fe22 ffff880006e7dde8 ffff88001d1edb80
> > 0000000000000001 0000936a4da34099 0000000000000000 00000000000000fa
> > Call Trace:
> > [<ffffffff81028dc5>] ? pvclock_clocksource_read+0x48/0xb1
> > [<ffffffff810074ab>] ? xen_clocksource_read+0x20/0x22
> > [<ffffffff81008fd9>] ? xen_spin_lock+0xc6/0xd9
> > [<ffffffff811d1d1e>] security_unix_stream_connect+0x16/0x18
> > [<ffffffff81484366>] unix_stream_connect+0x215/0x3ff
> > [<ffffffff813f351d>] sys_connect+0x7a/0xa0
> > [<ffffffff8108cd9d>] ? audit_syscall_entry+0x1c2/0x1ee
> > [<ffffffff8100bb42>] system_call_fastpath+0x16/0x1b
> > Code: c9 c3 55 48 89 e5 41 55 41 54 53 48 81 ec 98 00 00 00 0f 1f 44 00 00 b9 22 00 00 00 48 8b 47 20 48 8b 76 20 48 8b 98 10 02 00 00 <4c> 8b a6 10 02 00 00 31 c0 4c 8b aa 10 02 00 00 4c 8d 85 50 ff
> > RIP [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
> > RSP <ffff880006e7dd68>
> > CR2: 0000000000000210
> > ---[ end trace 50030b578c1ee27e ]---
> >
> > This corresponds to:
> >
> > (gdb) list *0xffffffff811d55d4
> > 0xffffffff811d55d4 is in selinux_socket_unix_stream_connect (/home/jeremy/git/upstream/security/selinux/hooks.c:3929).
> > 3924 static int selinux_socket_unix_stream_connect(struct socket *sock,
> > 3925 struct socket *other,
> > 3926 struct sock *newsk)
> > 3927 {
> > 3928 struct sk_security_struct *sksec_sock = sock->sk->sk_security;
> > 3929 struct sk_security_struct *sksec_other = other->sk->sk_security;
> > 3930 struct sk_security_struct *sksec_new = newsk->sk_security;
> > 3931 struct common_audit_data ad;
> > 3932 int err;
> > 3933
> >
> >
> > The system is a somewhat out of date Fedora 13 with
> > selinux-policy-3.7.19-73.fc13.noarch and
> > selinux-policy-targeted-3.7.19-73.fc13.noarch installed.
> >
> > I'm not sure what at-spi-registry is or what it is trying to do here.
> > The crash seems non-deterministic; I rebooted the domain without any issues.
> >
> > Thanks,
> > J
>
> Thanks for the report.
>
> Unfortunately I don't have any great ideas off the top of my head but it
> has been a couple of months since I've played with that code; I'll take
> a look and see if anything jumps out at me.
>
> For what it's worth, a quick Google makes me think that at-spi-registry
> is part of Gnome's assistive technology functionality. That said, I
> have no idea what it does exactly, but evidently it does it over a UNIX
> domain socket ...
>
> If you're ever able to recreate the problem or if you can think of
> anything else that might be useful please let me know.
>
> Thanks.
There were some concerns that this may be due to the other end of a UNIX
socket going away during connect() and causing sk_free() to be called
which could result in sk_security being NULL/garbage in line 3929 above.
However, I just walked through the relevant bits in net/unix/af_unix.c
and it would appear that the sock_hold() and sock_put()s are all in the
right spots. I suppose there is the possibility that sk_security is not
being initialized correctly in the first place but that seems odd to me
as I would expect massive failures elsewhere if that was the case.
I'm hesitant to bring this up, but is there any chance you're having
memory corruption issues on the system? Maybe Xen?
--
paul moore
linux @ hp
^ permalink raw reply
* Re: 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
From: Jeremy Fitzhardinge @ 2010-12-09 21:07 UTC (permalink / raw)
To: Paul Moore
Cc: James Morris, Stephen Smalley, NetDev, Linux Kernel Mailing List
In-Reply-To: <1291927787.5339.33.camel@sifl>
On 12/09/2010 12:49 PM, Paul Moore wrote:
> On Thu, 2010-12-09 at 14:42 -0500, Paul Moore wrote:
>> On Wed, 2010-12-08 at 13:09 -0800, Jeremy Fitzhardinge wrote:
>>> I just got this oops in a freshly booted 2.6.37-rc5 Xen domain, while
>>> sitting idle at the login prompt:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000210
>>> IP: [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
>>> PGD 1c99d067 PUD 1cb03067 PMD 0
>>> Oops: 0000 [#1] SMP
>>> last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
>>> CPU 0
>>> Modules linked in: sunrpc dm_mirror dm_region_hash dm_log [last unloaded: scsi_wait_scan]
>>>
>>> Pid: 2297, comm: at-spi-registry Not tainted 2.6.37-rc5+ #293 /
>>> RIP: e030:[<ffffffff811d55d4>] [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
>>> RSP: e02b:ffff880006e7dd68 EFLAGS: 00010292
>>> RAX: ffff88001d1ed8c0 RBX: ffff88001d06d9a0 RCX: 0000000000000022
>>> RDX: ffff88001d1ed580 RSI: 0000000000000000 RDI: ffff88001b7d6ac0
>>> RBP: ffff880006e7de18 R08: 00000000ffff0201 R09: ffff88001e78c968
>>> R10: 000000001f47e9c2 R11: ffff88001fbf4400 R12: ffff88001d1ed8c0
>>> R13: ffff88001d1ed580 R14: ffff88001ca00cc0 R15: 0000000000000000
>>> FS: 00007fa643031920(0000) GS:ffff88001ff85000(0000) knlGS:0000000000000000
>>> CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 0000000000000210 CR3: 000000001d78a000 CR4: 0000000000002660
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process at-spi-registry (pid: 2297, threadinfo ffff880006e7c000, task ffff88001cdd1140)
>>> Stack:
>>> ffff88001d4c0bc0 000000004cffecc5 ffff880006e7ddc8 ffffffff81028dc5
>>> ffff8800ffffffff 0001628b2ec3fe22 ffff880006e7dde8 ffff88001d1edb80
>>> 0000000000000001 0000936a4da34099 0000000000000000 00000000000000fa
>>> Call Trace:
>>> [<ffffffff81028dc5>] ? pvclock_clocksource_read+0x48/0xb1
>>> [<ffffffff810074ab>] ? xen_clocksource_read+0x20/0x22
>>> [<ffffffff81008fd9>] ? xen_spin_lock+0xc6/0xd9
>>> [<ffffffff811d1d1e>] security_unix_stream_connect+0x16/0x18
>>> [<ffffffff81484366>] unix_stream_connect+0x215/0x3ff
>>> [<ffffffff813f351d>] sys_connect+0x7a/0xa0
>>> [<ffffffff8108cd9d>] ? audit_syscall_entry+0x1c2/0x1ee
>>> [<ffffffff8100bb42>] system_call_fastpath+0x16/0x1b
>>> Code: c9 c3 55 48 89 e5 41 55 41 54 53 48 81 ec 98 00 00 00 0f 1f 44 00 00 b9 22 00 00 00 48 8b 47 20 48 8b 76 20 48 8b 98 10 02 00 00 <4c> 8b a6 10 02 00 00 31 c0 4c 8b aa 10 02 00 00 4c 8d 85 50 ff
>>> RIP [<ffffffff811d55d4>] selinux_socket_unix_stream_connect+0x29/0xa0
>>> RSP <ffff880006e7dd68>
>>> CR2: 0000000000000210
>>> ---[ end trace 50030b578c1ee27e ]---
>>>
>>> This corresponds to:
>>>
>>> (gdb) list *0xffffffff811d55d4
>>> 0xffffffff811d55d4 is in selinux_socket_unix_stream_connect (/home/jeremy/git/upstream/security/selinux/hooks.c:3929).
>>> 3924 static int selinux_socket_unix_stream_connect(struct socket *sock,
>>> 3925 struct socket *other,
>>> 3926 struct sock *newsk)
>>> 3927 {
>>> 3928 struct sk_security_struct *sksec_sock = sock->sk->sk_security;
>>> 3929 struct sk_security_struct *sksec_other = other->sk->sk_security;
>>> 3930 struct sk_security_struct *sksec_new = newsk->sk_security;
>>> 3931 struct common_audit_data ad;
>>> 3932 int err;
>>> 3933
>>>
>>>
>>> The system is a somewhat out of date Fedora 13 with
>>> selinux-policy-3.7.19-73.fc13.noarch and
>>> selinux-policy-targeted-3.7.19-73.fc13.noarch installed.
>>>
>>> I'm not sure what at-spi-registry is or what it is trying to do here.
>>> The crash seems non-deterministic; I rebooted the domain without any issues.
>>>
>>> Thanks,
>>> J
>> Thanks for the report.
>>
>> Unfortunately I don't have any great ideas off the top of my head but it
>> has been a couple of months since I've played with that code; I'll take
>> a look and see if anything jumps out at me.
>>
>> For what it's worth, a quick Google makes me think that at-spi-registry
>> is part of Gnome's assistive technology functionality. That said, I
>> have no idea what it does exactly, but evidently it does it over a UNIX
>> domain socket ...
>>
>> If you're ever able to recreate the problem or if you can think of
>> anything else that might be useful please let me know.
>>
>> Thanks.
> There were some concerns that this may be due to the other end of a UNIX
> socket going away during connect() and causing sk_free() to be called
> which could result in sk_security being NULL/garbage in line 3929 above.
> However, I just walked through the relevant bits in net/unix/af_unix.c
> and it would appear that the sock_hold() and sock_put()s are all in the
> right spots. I suppose there is the possibility that sk_security is not
> being initialized correctly in the first place but that seems odd to me
> as I would expect massive failures elsewhere if that was the case.
>
> I'm hesitant to bring this up, but is there any chance you're having
> memory corruption issues on the system? Maybe Xen?
Well, I considered the possibility of this being Xen specific, but I
really couldn't see how. Xen operates at the level of CPU instructions
and pagetable entries; if something is going wrong there it would cause
widespread chaos. Even if there's some rare corruption, why would it
pick on this specific SELinux thing? The system seems otherwise stable;
kernel builds work, etc.
It seems to me that if there's is a higher tendency for it to happen
under Xen, its because there's an existing race in the code which
happens to trigger more easily because of how the virtual CPUs are
scheduled. If that were the case, I'd also expect to see it under any
other virtualization system. I could try reproducing it with more VCPUs.
I have seen this specific crash before in earlier -rcs, so it isn't a
once-off. But is a while since I've seen it, so I guess its fairly
rare. It only seems to happen near bootup; once the system is running
it seems stable (but it could just be because I don't have many things
doing stuff with unix domain sockets).
Thanks,
J
^ permalink raw reply
* brcm80211 hangs when disabling wireless
From: Dave Hansen @ 2010-12-09 21:26 UTC (permalink / raw)
To: John W. Linville, Johannes Berg, Brett Rudley, Henry Ptasinski,
Nohee Ko
Cc: linux-kernel@vger.kernel.org
I've been getting hard hangs when I toggle the wireless on a Lenovo
S10-3. It happens both with the physical switch and the Fn-F5 key
combo. It's quite repeatable. The system is quite stable when I'm not
trying to disable the wireless, though.
I've been able to get some screenshots, but the console messages don't
make it out to the disk:
http://picasaweb.google.com/hansendc/BrcmOops#
netconsole also isn't working on this hardware. Any other suggestions
for getting an oops out of a serial-port-challenged netbook?
It isn't completely clear to me where this bug actually is. The stack
dump looks almost completely confined to net/mac80211/ functions, but
there are a few error printk's from brcm80211.
The first printk's are from this code, but it's apparently trying to
transmit in the mac80211 stack anyway:
static int wl_ops_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
{
int status;
wl_info_t *wl = hw->priv;
WL_LOCK(wl);
if (!wl->pub->up) {
WL_ERROR(("ops->tx called while down\n"));
status = -ENETDOWN;
goto done;
}
status = wl_start(skb, wl);
done:
WL_UNLOCK(wl);
return status;
}
I'm not completely sure that this is what is causing the hang that I'm
seeing, but it's certainly the last thing I see on the console.
With the hardware driver in -staging, I don't expect anybody to jump out
of their seats to fix this, I just figured someone might want to see the
bug report.
-- Dave
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: remove me from tulip
From: Grant Grundler @ 2010-12-09 21:33 UTC (permalink / raw)
To: Kyle McMartin; +Cc: netdev, davem, grundler
In-Reply-To: <20101209195008.GV25668@bombadil.infradead.org>
On Thu, Dec 09, 2010 at 02:50:08PM -0500, Kyle McMartin wrote:
> It was a nice idea, but -ENOTIME and -ENOHW. I never got around to doing
> a lot of the clean up that I intended to.
>
> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Yeah, I can understand. I basically just review incoming patches and
haven't done any work on the outstanding bugs over the past year or so.
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Dave, please apply.
thanks,
grant
> ---
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1a1c27b..a54a738 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5932,7 +5932,6 @@ F: include/linux/tty.h
>
> TULIP NETWORK DRIVERS
> M: Grant Grundler <grundler@parisc-linux.org>
> -M: Kyle McMartin <kyle@mcmartin.ca>
> L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/tulip/
^ permalink raw reply
* Re: brcm80211 hangs when disabling wireless
From: Greg KH @ 2010-12-09 21:43 UTC (permalink / raw)
To: Dave Hansen
Cc: John W. Linville, Johannes Berg, Brett Rudley, Henry Ptasinski,
Nohee Ko, Jason Cooper, Mike Rapoport, Andy Shevchenko,
linux-wireless, netdev, devel, linux-kernel@vger.kernel.org
In-Reply-To: <1291930010.7960.30.camel@nimitz>
On Thu, Dec 09, 2010 at 01:26:50PM -0800, Dave Hansen wrote:
> I've been getting hard hangs when I toggle the wireless on a Lenovo
> S10-3. It happens both with the physical switch and the Fn-F5 key
> combo. It's quite repeatable. The system is quite stable when I'm not
> trying to disable the wireless, though.
What kernel version is this?
Linus's latest tree has a known bug when the wireless is suspended and
then resumed. Broadcom is working on it but no patch is forthcoming
yet. Perhaps this is the same issue.
thanks,
greg k-h
^ permalink raw reply
* biosdevname v0.3.3
From: Matt Domsch @ 2010-12-09 21:51 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.3.
I re-added the PCI IRQ Routing Table lookup code. This is used as a
fallback, in the event system BIOS doesn't provide index and label
information in a way we can get at via sysfs, or via reading SMBIOS
directly. This is necessary as quite a few systems I want to
have this feature on do not yet expose this info via SMBIOS, yet the
values in $PIR are perfectly usable for this purpose.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
shortlog:
Matt Domsch (5):
add back in PCI IRQ Routing Table lookups, as a fallback
add in the pirq.[ch] files too
sort PCI device list, set embedded_index better, use PIRQ info
as a last resort
remove Dell-specific code from make_release.sh
bump version
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH net-next-26] cxgb4vf: Ingress Queue Entry Size needs to be 64 bytes
From: Casey Leedom @ 2010-12-09 21:52 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <1291923504-3589-1-git-send-email-leedom@chelsio.com>
Urk. Sorry about that: the subject prefix should have read "net-26" since
this is a fairly critical bug fix. Let me know if you'd like me to resubmit the
patch.
Casey
^ permalink raw reply
* Re: brcm80211 hangs when disabling wireless
From: Dave Hansen @ 2010-12-09 21:54 UTC (permalink / raw)
To: Greg KH
Cc: John W. Linville, Johannes Berg, Brett Rudley, Henry Ptasinski,
Nohee Ko, Jason Cooper, Mike Rapoport, Andy Shevchenko,
linux-wireless, netdev, devel, linux-kernel@vger.kernel.org
In-Reply-To: <20101209214347.GA15172@suse.de>
On Thu, 2010-12-09 at 13:43 -0800, Greg KH wrote:
> On Thu, Dec 09, 2010 at 01:26:50PM -0800, Dave Hansen wrote:
> > I've been getting hard hangs when I toggle the wireless on a Lenovo
> > S10-3. It happens both with the physical switch and the Fn-F5 key
> > combo. It's quite repeatable. The system is quite stable when I'm not
> > trying to disable the wireless, though.
>
> What kernel version is this?
>
> Linus's latest tree has a known bug when the wireless is suspended and
> then resumed. Broadcom is working on it but no patch is forthcoming
> yet. Perhaps this is the same issue.
Yeah, it's 2.6.37-rc5 plus a pull from:
http://kernel.ubuntu.com/git?p=ikepanhc/ideapad-laptop.git;a=summary
That could easily be it. Thanks, Greg.
-- Dave
^ permalink raw reply
* [PATCH net-next-2.6 1/2] ethtool: Report link-down while interface is down
From: Ben Hutchings @ 2010-12-09 22:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
While an interface is down, many implementations of
ethtool_ops::get_link, including the default, ethtool_op_get_link(),
will report the last link state seen while the interface was up. In
general the current physical link state is not available if the
interface is down.
Define ETHTOOL_GLINK to reflect whether the interface *and* any
physical port have a working link, and consistently return 0 when the
interface is down.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
David,
I know you weren't keen on this, but if you don't accept it then please
say what you think the proper semantics are.
Ben.
include/linux/ethtool.h | 4 +++-
net/core/ethtool.c | 17 +++++++++++++++--
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6628a50..1908929 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -691,7 +691,9 @@ struct ethtool_ops {
#define ETHTOOL_GMSGLVL 0x00000007 /* Get driver message level */
#define ETHTOOL_SMSGLVL 0x00000008 /* Set driver msg level. */
#define ETHTOOL_NWAY_RST 0x00000009 /* Restart autonegotiation. */
-#define ETHTOOL_GLINK 0x0000000a /* Get link status (ethtool_value) */
+/* Get link status for host, i.e. whether the interface *and* the
+ * physical port (if there is one) are up (ethtool_value). */
+#define ETHTOOL_GLINK 0x0000000a
#define ETHTOOL_GEEPROM 0x0000000b /* Get EEPROM data */
#define ETHTOOL_SEEPROM 0x0000000c /* Set EEPROM data. */
#define ETHTOOL_GCOALESCE 0x0000000e /* Get coalesce config */
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d5bc2881..1774178 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -891,6 +891,20 @@ static int ethtool_nway_reset(struct net_device *dev)
return dev->ethtool_ops->nway_reset(dev);
}
+static int ethtool_get_link(struct net_device *dev, char __user *useraddr)
+{
+ struct ethtool_value edata = { .cmd = ETHTOOL_GLINK };
+
+ if (!dev->ethtool_ops->get_link)
+ return -EOPNOTSUPP;
+
+ edata.data = netif_running(dev) && dev->ethtool_ops->get_link(dev);
+
+ if (copy_to_user(useraddr, &edata, sizeof(edata)))
+ return -EFAULT;
+ return 0;
+}
+
static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
{
struct ethtool_eeprom eeprom;
@@ -1530,8 +1544,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
rc = ethtool_nway_reset(dev);
break;
case ETHTOOL_GLINK:
- rc = ethtool_get_value(dev, useraddr, ethcmd,
- dev->ethtool_ops->get_link);
+ rc = ethtool_get_link(dev, useraddr);
break;
case ETHTOOL_GEEPROM:
rc = ethtool_get_eeprom(dev, useraddr);
--
1.7.3.2
--
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 related
* [PATCH net-next-2.6 2/2] netdev: Use default implementation of ethtool_ops::get_link where possible
From: Ben Hutchings @ 2010-12-09 22:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
Various drivers are using implementations of ethtool_ops::get_link
that are equivalent to the default ethtool_op_get_link(). Change
them to use that instead.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
I've tested the e1000e and sfc changes but not the others.
Ben.
drivers/net/e1000e/ethtool.c | 16 +---------------
drivers/net/ibmveth.c | 7 +------
drivers/net/igbvf/ethtool.c | 7 +------
drivers/net/iseries_veth.c | 7 +------
drivers/net/mv643xx_eth.c | 7 +------
drivers/net/pxa168_eth.c | 7 +------
drivers/net/sfc/ethtool.c | 9 +--------
drivers/net/sunlance.c | 10 +---------
8 files changed, 8 insertions(+), 62 deletions(-)
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 8984d16..3612900 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -194,20 +194,6 @@ static int e1000_get_settings(struct net_device *netdev,
return 0;
}
-static u32 e1000_get_link(struct net_device *netdev)
-{
- struct e1000_adapter *adapter = netdev_priv(netdev);
- struct e1000_hw *hw = &adapter->hw;
-
- /*
- * Avoid touching hardware registers when possible, otherwise
- * link negotiation can get messed up when user-level scripts
- * are rapidly polling the driver to see if link is up.
- */
- return netif_running(netdev) ? netif_carrier_ok(netdev) :
- !!(er32(STATUS) & E1000_STATUS_LU);
-}
-
static int e1000_set_spd_dplx(struct e1000_adapter *adapter, u16 spddplx)
{
struct e1000_mac_info *mac = &adapter->hw.mac;
@@ -2024,7 +2010,7 @@ static const struct ethtool_ops e1000_ethtool_ops = {
.get_msglevel = e1000_get_msglevel,
.set_msglevel = e1000_set_msglevel,
.nway_reset = e1000_nway_reset,
- .get_link = e1000_get_link,
+ .get_link = ethtool_op_get_link,
.get_eeprom_len = e1000_get_eeprom_len,
.get_eeprom = e1000_get_eeprom,
.set_eeprom = e1000_set_eeprom,
diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
index c454b45..5522d45 100644
--- a/drivers/net/ibmveth.c
+++ b/drivers/net/ibmveth.c
@@ -729,11 +729,6 @@ static void netdev_get_drvinfo(struct net_device *dev,
sizeof(info->version) - 1);
}
-static u32 netdev_get_link(struct net_device *dev)
-{
- return 1;
-}
-
static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
{
struct ibmveth_adapter *adapter = netdev_priv(dev);
@@ -918,7 +913,7 @@ static void ibmveth_get_ethtool_stats(struct net_device *dev,
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
- .get_link = netdev_get_link,
+ .get_link = ethtool_op_get_link,
.set_tx_csum = ibmveth_set_tx_csum,
.get_rx_csum = ibmveth_get_rx_csum,
.set_rx_csum = ibmveth_set_rx_csum,
diff --git a/drivers/net/igbvf/ethtool.c b/drivers/net/igbvf/ethtool.c
index abb3606..ed6e3d9 100644
--- a/drivers/net/igbvf/ethtool.c
+++ b/drivers/net/igbvf/ethtool.c
@@ -110,11 +110,6 @@ static int igbvf_get_settings(struct net_device *netdev,
return 0;
}
-static u32 igbvf_get_link(struct net_device *netdev)
-{
- return netif_carrier_ok(netdev);
-}
-
static int igbvf_set_settings(struct net_device *netdev,
struct ethtool_cmd *ecmd)
{
@@ -515,7 +510,7 @@ static const struct ethtool_ops igbvf_ethtool_ops = {
.get_msglevel = igbvf_get_msglevel,
.set_msglevel = igbvf_set_msglevel,
.nway_reset = igbvf_nway_reset,
- .get_link = igbvf_get_link,
+ .get_link = ethtool_op_get_link,
.get_eeprom_len = igbvf_get_eeprom_len,
.get_eeprom = igbvf_get_eeprom,
.set_eeprom = igbvf_set_eeprom,
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 38e15be..63ac531 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1009,15 +1009,10 @@ static int veth_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
return 0;
}
-static u32 veth_get_link(struct net_device *dev)
-{
- return 1;
-}
-
static const struct ethtool_ops ops = {
.get_drvinfo = veth_get_drvinfo,
.get_settings = veth_get_settings,
- .get_link = veth_get_link,
+ .get_link = ethtool_op_get_link,
};
static const struct net_device_ops veth_netdev_ops = {
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index dd2b6a7..ce31e74 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1514,11 +1514,6 @@ static int mv643xx_eth_nway_reset(struct net_device *dev)
return genphy_restart_aneg(mp->phy);
}
-static u32 mv643xx_eth_get_link(struct net_device *dev)
-{
- return !!netif_carrier_ok(dev);
-}
-
static int
mv643xx_eth_get_coalesce(struct net_device *dev, struct ethtool_coalesce *ec)
{
@@ -1658,7 +1653,7 @@ static const struct ethtool_ops mv643xx_eth_ethtool_ops = {
.set_settings = mv643xx_eth_set_settings,
.get_drvinfo = mv643xx_eth_get_drvinfo,
.nway_reset = mv643xx_eth_nway_reset,
- .get_link = mv643xx_eth_get_link,
+ .get_link = ethtool_op_get_link,
.get_coalesce = mv643xx_eth_get_coalesce,
.set_coalesce = mv643xx_eth_set_coalesce,
.get_ringparam = mv643xx_eth_get_ringparam,
diff --git a/drivers/net/pxa168_eth.c b/drivers/net/pxa168_eth.c
index 18c0297..04ed27d 100644
--- a/drivers/net/pxa168_eth.c
+++ b/drivers/net/pxa168_eth.c
@@ -1450,16 +1450,11 @@ static void pxa168_get_drvinfo(struct net_device *dev,
strncpy(info->bus_info, "N/A", 32);
}
-static u32 pxa168_get_link(struct net_device *dev)
-{
- return !!netif_carrier_ok(dev);
-}
-
static const struct ethtool_ops pxa168_ethtool_ops = {
.get_settings = pxa168_get_settings,
.set_settings = pxa168_set_settings,
.get_drvinfo = pxa168_get_drvinfo,
- .get_link = pxa168_get_link,
+ .get_link = ethtool_op_get_link,
};
static const struct net_device_ops pxa168_eth_netdev_ops = {
diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
index aae756b..e1489f9 100644
--- a/drivers/net/sfc/ethtool.c
+++ b/drivers/net/sfc/ethtool.c
@@ -620,13 +620,6 @@ static int efx_ethtool_nway_reset(struct net_device *net_dev)
return mdio45_nway_restart(&efx->mdio);
}
-static u32 efx_ethtool_get_link(struct net_device *net_dev)
-{
- struct efx_nic *efx = netdev_priv(net_dev);
-
- return efx->link_state.up;
-}
-
static int efx_ethtool_get_coalesce(struct net_device *net_dev,
struct ethtool_coalesce *coalesce)
{
@@ -1058,7 +1051,7 @@ const struct ethtool_ops efx_ethtool_ops = {
.get_msglevel = efx_ethtool_get_msglevel,
.set_msglevel = efx_ethtool_set_msglevel,
.nway_reset = efx_ethtool_nway_reset,
- .get_link = efx_ethtool_get_link,
+ .get_link = ethtool_op_get_link,
.get_coalesce = efx_ethtool_get_coalesce,
.set_coalesce = efx_ethtool_set_coalesce,
.get_ringparam = efx_ethtool_get_ringparam,
diff --git a/drivers/net/sunlance.c b/drivers/net/sunlance.c
index 2cf84e5..767e1e2 100644
--- a/drivers/net/sunlance.c
+++ b/drivers/net/sunlance.c
@@ -1295,17 +1295,9 @@ static void sparc_lance_get_drvinfo(struct net_device *dev, struct ethtool_drvin
strcpy(info->version, "2.02");
}
-static u32 sparc_lance_get_link(struct net_device *dev)
-{
- /* We really do not keep track of this, but this
- * is better than not reporting anything at all.
- */
- return 1;
-}
-
static const struct ethtool_ops sparc_lance_ethtool_ops = {
.get_drvinfo = sparc_lance_get_drvinfo,
- .get_link = sparc_lance_get_link,
+ .get_link = ethtool_op_get_link,
};
static const struct net_device_ops sparc_lance_ops = {
--
1.7.3.2
--
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 related
* Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support
From: Stephen Hemminger @ 2010-12-09 22:51 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, brian.haley, netdev, maheshkelkar, lorenzo, yoshfuji,
stable
In-Reply-To: <20101209.122033.183046393.davem@davemloft.net>
On Thu, 09 Dec 2010 12:20:33 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 9 Dec 2010 11:16:11 -0800
>
> > No but since removing address propagates up to user space daemons
> > like Quagga please analyze and fix the problem, don't just look
> > for band aid.
>
> Stephen, we lived with the previous behavior for 12+ years.
>
> You broke stuff that did work before your change.
>
> Putting the onus on Eric to fix it exactly how you want it to
> be fixed is therefore not appropriate.
>
> You seem to be putting exactly zero effort into trying to reproduce
> the problem yourself and fixing a bug you introduced. And hey we
> have a standard way to deal with a regression when the guilty party
> is uncooperative, revert.
>
> There are therefore three choices:
>
> 1) Revert. And this is the one I'm favoring because of how you are
> handling this issue. The responsibility to resolve this regression
> is your's not Eric's.
>
> Frankly, Eric is being incredibly nice by working on trying to fix
> a bug which you introduced.
>
> 2) Accept Eric's proposed fix.
>
> 3) Figure out the real bug yourself and fix the problem the way you
> find acceptable in a reasonable, short, amount of time.
>
> Loopback has always been special, especially on ipv6. When we don't
> have a device to point something at, we point it at loopback.
>
> Also destination cache entries which still have references when they
> get zapped get pointed at loopback.
Quit being a grinch. I am working on it, just don't know the answer.
I want to try a couple solutions, so far Eric's looks okay, just want
to make sure that it doesn't break anything.
You are over reacting. Doing on the fly re-enabling of ipv6 is a corner case.
The problem was only discovered a couple of days ago, it is not like
the world is burning down.
--
^ permalink raw reply
* [PATCH] fix hostap registration order
From: Meelis Roos @ 2010-12-09 23:19 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In 2.6.37-rc4, hostap_pci init gives a WARNING with backtrace telling
that netif_stop_queue is called before register_netdev. Fix it by moving
this call after register_netdev. Removes the warning and seems to work,
but why is the call to netif_stop_queue needed at all after
register_netdev?
Signed-off-by: Meelis Roos <mroos-Y27EyoLml9s@public.gmane.org>
diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c
index b7cb165..cc760c5 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -3253,6 +3253,8 @@ while (0)
}
printk(KERN_INFO "%s: Registered netdevice %s\n", dev_info, dev->name);
+ netif_stop_queue(dev);
+
hostap_init_data(local);
return dev;
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 25a2722..0f1b202 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -100,6 +100,7 @@ struct net_device * hostap_add_interface(struct local_info *local,
printk(KERN_DEBUG "%s: registered netdevice %s\n",
mdev->name, dev->name);
+ netif_stop_queue(dev);
return dev;
}
@@ -891,7 +892,6 @@ void hostap_setup_dev(struct net_device *dev, local_info_t *local,
SET_ETHTOOL_OPS(dev, &prism2_ethtool_ops);
- netif_stop_queue(dev);
}
static int hostap_enable_hostapd(local_info_t *local, int rtnl_locked)
--
Meelis Roos (mroos-Y27EyoLml9s@public.gmane.org)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 related
* Re: [RFC PATCH 1/4] net: implement mechanism for HW based QOS
From: John Fastabend @ 2010-12-10 0:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, hadi@cyberus.ca,
shemminger@vyatta.com, tgraf@infradead.org
In-Reply-To: <1291927591.2803.14.camel@edumazet-laptop>
On 12/9/2010 12:46 PM, Eric Dumazet wrote:
> Le jeudi 09 décembre 2010 à 11:59 -0800, John Fastabend a écrit :
>> This patch provides a mechanism for lower layer devices to
>> steer traffic using skb->priority to tx queues. This allows
>> for hardware based QOS schemes to use the default qdisc without
>> incurring the penalties related to global state and the qdisc
>> lock. While reliably receiving skbs on the correct tx ring
>> to avoid head of line blocking resulting from shuffling in
>> the LLD. Finally, all the goodness from txq caching and xps/rps
>> can still be leveraged.
>>
>> Many drivers and hardware exist with the ability to implement
>> QOS schemes in the hardware but currently these drivers tend
>> to rely on firmware to reroute specific traffic, a driver
>> specific select_queue or the queue_mapping action in the
>> qdisc.
>>
>> By using select_queue for this drivers need to be updated for
>> each and every traffic type and we lose the goodness of much
>> of the upstream work. Firmware solutions are inherently
>> inflexible. And finally if admins are expected to build a
>> qdisc and filter rules to steer traffic this requires knowledge
>> of how the hardware is currently configured. The number of tx
>> queues and the queue offsets may change depending on resources.
>> Also this approach incurs all the overhead of a qdisc with filters.
>>
>> With the mechanism in this patch users can set skb priority using
>> expected methods ie setsockopt() or the stack can set the priority
>> directly. Then the skb will be steered to the correct tx queues
>> aligned with hardware QOS traffic classes. In the normal case with
>> a single traffic class and all queues in this class everything
>> works as is until the LLD enables multiple tcs.
>>
>> To steer the skb we mask out the lower 4 bits of the priority
>> and allow the hardware to configure upto 15 distinct classes
>> of traffic. This is expected to be sufficient for most applications
>> at any rate it is more then the 8021Q spec designates and is
>> equal to the number of prio bands currently implemented in
>> the default qdisc.
>>
>> This in conjunction with a userspace application such as
>> lldpad can be used to implement 8021Q transmission selection
>> algorithms one of these algorithms being the extended transmission
>> selection algorithm currently being used for DCB.
>>
>
> Very nice Changelog !
>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>>
>> include/linux/netdevice.h | 65 +++++++++++++++++++++++++++++++++++++++++++++
>> net/core/dev.c | 39 ++++++++++++++++++++++++++-
>> 2 files changed, 103 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index a9ac5dc..c0d4fb1 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -646,6 +646,12 @@ struct xps_dev_maps {
>> (nr_cpu_ids * sizeof(struct xps_map *)))
>> #endif /* CONFIG_XPS */
>>
>> +/* HW offloaded queuing disciplines txq count and offset maps */
>> +struct netdev_tc_txq {
>> + u16 count;
>> + u16 offset;
>> +};
>> +
>> /*
>> * This structure defines the management hooks for network devices.
>> * The following hooks can be defined; unless noted otherwise, they are
>> @@ -1146,6 +1152,10 @@ struct net_device {
>> /* Data Center Bridging netlink ops */
>> const struct dcbnl_rtnl_ops *dcbnl_ops;
>> #endif
>> + u8 max_tc;
>> + u8 num_tc;
>> + struct netdev_tc_txq *_tc_to_txq;
>
> Given that this is up to 16*4 bytes (64), shouldnt we embed this in
> net_device struct to avoid one dereference ?
>
>
>> + u8 prio_tc_map[16];
>>
>> #if defined(CONFIG_FCOE) || defined(CONFIG_FCOE_MODULE)
>> /* max exchange id for FCoE LRO by ddp */
>> @@ -1162,6 +1172,58 @@ struct net_device {
>> #define NETDEV_ALIGN 32
>>
>> static inline
>> +int netdev_get_prio_tc_map(const struct net_device *dev, u32 prio)
>> +{
>> + return dev->prio_tc_map[prio & 15];
>> +}
>> +
>> +static inline
>> +int netdev_set_prio_tc_map(struct net_device *dev, u8 prio, u8 tc)
>> +{
>> + if (tc >= dev->num_tc)
>> + return -EINVAL;
>> +
>> + dev->prio_tc_map[prio & 15] = tc & 15;
>> + return 0;
>> +}
>> +
>> +static inline
>> +int netdev_set_tc_queue(struct net_device *dev, u8 tc, u16 count, u16 offset)
>> +{
>> + struct netdev_tc_txq *tcp;
>> +
>> + if (tc >= dev->num_tc)
>> + return -EINVAL;
>> +
>> + tcp = &dev->_tc_to_txq[tc];
>> + tcp->count = count;
>> + tcp->offset = offset;
>> + return 0;
>> +}
>> +
>> +static inline
>> +struct netdev_tc_txq *netdev_get_tc_queue(const struct net_device *dev, u8 tc)
>> +{
>> + return &dev->_tc_to_txq[tc];
>> +}
>> +
>> +static inline
>> +int netdev_set_num_tc(struct net_device *dev, u8 num_tc)
>> +{
>> + if (num_tc > dev->max_tc)
>> + return -EINVAL;
>> +
>> + dev->num_tc = num_tc;
>> + return 0;
>> +}
>> +
>> +static inline
>> +u8 netdev_get_num_tc(const struct net_device *dev)
>> +{
>> + return dev->num_tc;
>> +}
>> +
>> +static inline
>> struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
>> unsigned int index)
>> {
>> @@ -1386,6 +1448,9 @@ static inline void unregister_netdevice(struct net_device *dev)
>> unregister_netdevice_queue(dev, NULL);
>> }
>>
>> +extern int netdev_alloc_max_tc(struct net_device *dev, u8 tc);
>> +extern void netdev_free_tc(struct net_device *dev);
>> +
>> extern int netdev_refcnt_read(const struct net_device *dev);
>> extern void free_netdev(struct net_device *dev);
>> extern void synchronize_net(void);
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 55ff66f..cc00e66 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2118,6 +2118,8 @@ static u32 hashrnd __read_mostly;
>> u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
>> {
>> u32 hash;
>> + u16 qoffset = 0;
>> + u16 qcount = dev->real_num_tx_queues;
>>
>> if (skb_rx_queue_recorded(skb)) {
>> hash = skb_get_rx_queue(skb);
>> @@ -2126,13 +2128,20 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
>> return hash;
>> }
>>
>> + if (dev->num_tc) {
>> + u8 tc = netdev_get_prio_tc_map(dev, skb->priority);
>> + struct netdev_tc_txq *tcp = netdev_get_tc_queue(dev, tc);
>> + qoffset = tcp->offset;
>> + qcount = tcp->count;
>> + }
>> +
>> if (skb->sk && skb->sk->sk_hash)
>> hash = skb->sk->sk_hash;
>> else
>> hash = (__force u16) skb->protocol ^ skb->rxhash;
>> hash = jhash_1word(hash, hashrnd);
>>
>> - return (u16) (((u64) hash * dev->real_num_tx_queues) >> 32);
>> + return (u16) ((((u64) hash * qcount)) >> 32) + qoffset;
>> }
>> EXPORT_SYMBOL(skb_tx_hash);
>>
>> @@ -5091,6 +5100,33 @@ void netif_stacked_transfer_operstate(const struct net_device *rootdev,
>> }
>> EXPORT_SYMBOL(netif_stacked_transfer_operstate);
>>
>> +int netdev_alloc_max_tc(struct net_device *dev, u8 tcs)
>> +{
>> + struct netdev_tc_txq *tcp;
>> +
>> + if (tcs > 16)
>> + return -EINVAL;
>> +
>> + tcp = kcalloc(tcs, sizeof(*tcp), GFP_KERNEL);
>
> common risk : allocating less than one cache line, and this possibly can
> have false sharing.
>
> I would just embed the thing.
>
Yes, I think you are right plus this simplifies the code a bit. I'll go ahead and do this. Thanks!
^ permalink raw reply
* Re: [PATCH v2 3/4] kthread: NUMA aware kthread_create_on_cpu()
From: Andrew Morton @ 2010-12-10 0:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andi Kleen, linux-kernel, netdev, David Miller, Tejun Heo,
Rusty Russell, Tony Luck, Fenghua Yu
In-Reply-To: <1291043695.3435.980.camel@edumazet-laptop>
On Mon, 29 Nov 2010 16:14:55 +0100
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> All kthreads being created from a single helper task, they all use
> memory from a single node for their kernel stack and task struct.
>
> This patch suite creates kthread_create_on_cpu(), adding a 'cpu'
> parameter to parameters already used by kthread_create().
>
> This parameter serves in allocating memory for the new kthread on its
> memory node if possible.
The name "kthread_create_on_cpu" is pretty misleading.
One would expect such a function to create a kthread which is bound to
that CPU. But what it in fact does is to create a kthread which is
bound to all CPUs and whose stack, task_struct and thread_info were
allocated from the node which contains `cpu'.
Also, a saner interface would be one which takes the numa_node_id, not
the cpu number.
>
> ...
>
> /**
> - * kthread_create - create a kthread.
> + * kthread_create_on_cpu - create a kthread.
> * @threadfn: the function to run until signal_pending(current).
> * @data: data ptr for @threadfn.
> + * @cpu: cpu number.
> * @namefmt: printf-style name for the thread.
> *
> * Description: This helper function creates and names a kernel
> * thread. The thread will be stopped: use wake_up_process() to start
> * it. See also kthread_run().
> *
> + * If thread is going to be bound on a particular cpu, give its number
> + * in @cpu, to get NUMA affinity for kthread stack, or else give -1.
This is a bit presumptuous. The caller might wish to later bind this
thread to some or all of the CPUs on the node, rather than to a single
CPU (eg, kswapd()).
So what to do? Maybe add a new kthread_create_node() which prepares a
kthread whose memory is bound to that node, then add a
kthread_create_cpu() convenience wrapper around that?
>
> ...
>
^ permalink raw reply
* [PATCH] Link directly to the archive files rather than using search paths.
From: Diego Elio Pettenò @ 2010-12-10 0:56 UTC (permalink / raw)
To: netdev; +Cc: Daniel Kurtz, Mike Frysinger
While the previous code was supposed to work nonetheless, it could be
messed up if further -L were used in LDFLAGS to list the path where glibc's
libutil was to be found.
References: https://bugs.gentoo.org/347489
CC: Daniel Kurtz <djkurtz@google.com>
CC: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
---
Makefile | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index c03d74c..d1ace1f 100644
--- a/Makefile
+++ b/Makefile
@@ -33,11 +33,10 @@ CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall
CFLAGS = $(CCOPTS) -I../include $(DEFINES)
YACCFLAGS = -d -t -v
-LDLIBS += -L../lib -lnetlink -lutil
-
SUBDIRS=lib ip tc misc netem genl
LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
+LDLIBS += $(LIBNETLINK)
all: Config
@set -e; \
--
1.7.3.3
^ permalink raw reply related
* ip rule and/or route problem in 2.6.37-rc5+
From: Ben Greear @ 2010-12-10 1:06 UTC (permalink / raw)
To: NetDev
This problem appears to have happened between 2.6.36.1 and 2.6.37-rc2.
We haven't fully bisected the problem yet.
The basic test:
* one normal interface using DHCP
* A second interface specified to use it's own routing table.
* 'ip rules' to determine behaviour.
After running these commands abelow, the system can no longer
route out it's normal interface. It appears that the final line
is the one that messes things up. If you flush table 10001 after
that, things start working again.
The 'pref 20' rule is also important. It should not have
any affect on this ping, but it appears that it does, somehow.
If you remove it, the problem also goes away, regardless of
the routes in table 10001.
ip rule add pref 512 lookup local
ip rule del pref 0 lookup local
ip link set eth2 up
ip -4 addr add 172.16.0.102/24 broadcast 172.16.0.255 dev eth2
ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
ip rule add iif eth2 lookup 10001 pref 20
ip route add 172.16.0.0/24 dev eth2 table 10001
ip route add unreachable 0/0 table 10001
[root@ct503-60 ~]# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.257 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.285 ms
\x03
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1290ms
rtt min/avg/max/mdev = 0.257/0.271/0.285/0.014 ms
[root@ct503-60 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:DA:60:1C
inet addr:192.168.100.173 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:feda:601c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:99 errors:0 dropped:0 overruns:0 frame:0
TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10562 (10.3 KiB) TX bytes:9634 (9.4 KiB)
Memory:fa7e0000-fa800000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:54 errors:0 dropped:0 overruns:0 frame:0
TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5280 (5.1 KiB) TX bytes:5280 (5.1 KiB)
[root@ct503-60 ~]# ip rule add pref 512 lookup local
local[root@ct503-60 ~]# ip rule del pref 0 lookup local
[root@ct503-60 ~]# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.266 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.238 ms
\x03
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1101ms
rtt min/avg/max/mdev = 0.238/0.252/0.266/0.014 ms
[root@ct503-60 ~]# ip link set eth2 up
adcast 172.16.0.255 dev eth2Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
Dec 10 11:50:01 localhost kernel: e1000e 0000:08:00.0: irq 49 for MSI/MSI-X
Dec 10 11:50:01 localhost kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
2root@ct503-60 ~]# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.247 ms
Dec 10 11:50:04 localhost kernel: e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Dec 10 11:50:04 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.271 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=0.263 ms
\x03
--- 192.168.100.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2317ms
rtt min/avg/max/mdev = 0.247/0.260/0.271/0.016 ms
[root@ct503-60 ~]# ip rule add to 172.16.0.102 iif eth2 lookup local pref 10
001 pref 20[root@ct503-60 ~]# ip rule add iif eth2 lookup 10001 pref 20
[root@ct503-60 ~]# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=0.346 ms
Dec 10 11:50:14 localhost kernel: eth2: no IPv6 routers present
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.251 ms
\x03
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1245ms
rtt min/avg/max/mdev = 0.251/0.298/0.346/0.050 ms
[root@ct503-60 ~]# ip route add 172.16.0.0/24 dev eth2 table 10001
10001[root@ct503-60 ~]# ip route add unreachable 0/0 table 10001
[root@ct503-60 ~]# ping 192.168.100.1
connect: Invalid argument
[root@ct503-60 ~]# ip route show
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.173
172.16.0.0/24 dev eth2 proto kernel scope link src 172.16.0.102
169.254.0.0/16 dev eth0 scope link metric 1003
default via 192.168.100.1 dev eth0
You have new mail in /var/spool/mail/root
[root@ct503-60 ~]# ip route show table 10001
172.16.0.0/24 dev eth2 scope link
unreachable default
[root@ct503-60 ~]#
[root@ct503-60 ~]# ip route flush table 10001
[root@ct503-60 ~]# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=4.10 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=0.260 ms
\x03
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1300ms
rtt min/avg/max/mdev = 0.260/2.181/4.102/1.921 ms
[root@ct503-60 ~]#
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/3] bonding: add the debugfs facility to the bonding driver
From: Taku Izumi @ 2010-12-10 1:17 UTC (permalink / raw)
To: netdev@vger.kernel.org, Jay Vosburgh; +Cc: eric.dumazet, shemminger
In-Reply-To: <4CF89A6E.4090303@jp.fujitsu.com>
This patch provides the debugfs facility to the bonding driver.
The "bonding" directory is created in the debugfs root and directories of
each bonding interface (like bond0, bond1...) are created in that.
# mount -t debugfs none /sys/kernel/debug
# ls /sys/kernel/debug/bonding
bond0 bond1
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/bonding/Makefile | 2
drivers/net/bonding/bond_debugfs.c | 96 +++++++++++++++++++++++++++++++++++++
drivers/net/bonding/bond_main.c | 10 +++
drivers/net/bonding/bonding.h | 9 +++
4 files changed, 115 insertions(+), 2 deletions(-)
Index: net-next/drivers/net/bonding/bond_main.c
===================================================================
--- net-next.orig/drivers/net/bonding/bond_main.c
+++ net-next/drivers/net/bonding/bond_main.c
@@ -3507,6 +3507,8 @@ static int bond_event_changename(struct
bond_remove_proc_entry(bond);
bond_create_proc_entry(bond);
+ bond_debug_reregister(bond);
+
return NOTIFY_DONE;
}
@@ -4789,6 +4791,8 @@ static void bond_uninit(struct net_devic
bond_remove_proc_entry(bond);
+ bond_debug_unregister(bond);
+
__hw_addr_flush(&bond->mc_list);
list_for_each_entry_safe(vlan, tmp, &bond->vlan_list, vlan_list) {
@@ -5191,6 +5195,8 @@ static int bond_init(struct net_device *
bond_prepare_sysfs_group(bond);
+ bond_debug_register(bond);
+
__hw_addr_init(&bond->mc_list);
return 0;
}
@@ -5312,6 +5318,8 @@ static int __init bonding_init(void)
if (res)
goto err_link;
+ bond_create_debugfs();
+
for (i = 0; i < max_bonds; i++) {
res = bond_create(&init_net, NULL);
if (res)
@@ -5322,7 +5330,6 @@ static int __init bonding_init(void)
if (res)
goto err;
-
register_netdevice_notifier(&bond_netdev_notifier);
register_inetaddr_notifier(&bond_inetaddr_notifier);
bond_register_ipv6_notifier();
@@ -5346,6 +5353,7 @@ static void __exit bonding_exit(void)
bond_unregister_ipv6_notifier();
bond_destroy_sysfs();
+ bond_destroy_debugfs();
rtnl_link_unregister(&bond_link_ops);
unregister_pernet_subsys(&bond_net_ops);
Index: net-next/drivers/net/bonding/Makefile
===================================================================
--- net-next.orig/drivers/net/bonding/Makefile
+++ net-next/drivers/net/bonding/Makefile
@@ -4,7 +4,7 @@
obj-$(CONFIG_BONDING) += bonding.o
-bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o
+bonding-objs := bond_main.o bond_3ad.o bond_alb.o bond_sysfs.o bond_debugfs.o
ipv6-$(subst m,y,$(CONFIG_IPV6)) += bond_ipv6.o
bonding-objs += $(ipv6-y)
Index: net-next/drivers/net/bonding/bond_debugfs.c
===================================================================
--- /dev/null
+++ net-next/drivers/net/bonding/bond_debugfs.c
@@ -0,0 +1,96 @@
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/netdevice.h>
+
+#include "bonding.h"
+
+#ifdef CONFIG_DEBUG_FS
+
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+
+static struct dentry *bonding_debug_root;
+
+void bond_debug_register(struct bonding *bond)
+{
+ if (!bonding_debug_root)
+ return;
+
+ bond->debug_dir =
+ debugfs_create_dir(bond->dev->name, bonding_debug_root);
+
+ if (!bond->debug_dir) {
+ pr_warning("%s: Warning: failed to register to debugfs\n",
+ bond->dev->name);
+ return;
+ }
+}
+
+void bond_debug_unregister(struct bonding *bond)
+{
+ if (!bonding_debug_root)
+ return;
+
+ debugfs_remove_recursive(bond->debug_dir);
+}
+
+void bond_debug_reregister(struct bonding *bond)
+{
+ struct dentry *d;
+
+ if (!bonding_debug_root)
+ return;
+
+ d = debugfs_rename(bonding_debug_root, bond->debug_dir,
+ bonding_debug_root, bond->dev->name);
+ if (d) {
+ bond->debug_dir = d;
+ } else {
+ pr_warning("%s: Warning: failed to reregister, "
+ "so just unregister old one\n",
+ bond->dev->name);
+ bond_debug_unregister(bond);
+ }
+}
+
+void bond_create_debugfs(void)
+{
+ bonding_debug_root = debugfs_create_dir("bonding", NULL);
+
+ if (!bonding_debug_root) {
+ pr_warning("Warning: Cannot create bonding directory"
+ " in debugfs\n");
+ }
+}
+
+void bond_destroy_debugfs(void)
+{
+ debugfs_remove_recursive(bonding_debug_root);
+ bonding_debug_root = NULL;
+}
+
+
+#else /* !CONFIG_DEBUG_FS */
+
+void bond_debug_register(struct bonding *bond)
+{
+}
+
+void bond_debug_unregister(struct bonding *bond)
+{
+}
+
+void bond_debug_reregister(struct bonding *bond)
+{
+}
+
+void bond_create_debugfs(void)
+{
+}
+
+void bond_destroy_debugfs(void)
+{
+}
+
+#endif /* CONFIG_DEBUG_FS */
Index: net-next/drivers/net/bonding/bonding.h
===================================================================
--- net-next.orig/drivers/net/bonding/bonding.h
+++ net-next/drivers/net/bonding/bonding.h
@@ -259,6 +259,10 @@ struct bonding {
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct in6_addr master_ipv6;
#endif
+#ifdef CONFIG_DEBUG_FS
+ /* debugging suport via debugfs */
+ struct dentry *debug_dir;
+#endif /* CONFIG_DEBUG_FS */
};
/**
@@ -380,6 +384,11 @@ void bond_select_active_slave(struct bon
void bond_change_active_slave(struct bonding *bond, struct slave *new_active);
void bond_register_arp(struct bonding *);
void bond_unregister_arp(struct bonding *);
+void bond_create_debugfs(void);
+void bond_destroy_debugfs(void);
+void bond_debug_register(struct bonding *bond);
+void bond_debug_unregister(struct bonding *bond);
+void bond_debug_reregister(struct bonding *bond);
struct bond_net {
struct net * net; /* Associated network namespace */
^ permalink raw reply
* Re: [PATCH v2 0/3] bonding: add the debugfs interface to see RLB hash table
From: Taku Izumi @ 2010-12-10 1:24 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev@vger.kernel.org, eric.dumazet, shemminger
In-Reply-To: <3778.1291840382@death>
Hi Jay,
I updated the patch 1/3. The problem seems to be fixed.
The problem is not reproduced at least in my test by applying my new patch.
Could you test again?
Best regards,
Taku Izumi
^ permalink raw reply
* Re: [PATCH] Link directly to the archive files rather than using search paths.
From: Stephen Hemminger @ 2010-12-10 1:56 UTC (permalink / raw)
To: Diego Elio Pettenò; +Cc: netdev, Daniel Kurtz, Mike Frysinger
In-Reply-To: <1291942572-12653-1-git-send-email-flameeyes@gmail.com>
On Fri, 10 Dec 2010 01:56:12 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> While the previous code was supposed to work nonetheless, it could be
> messed up if further -L were used in LDFLAGS to list the path where glibc's
> libutil was to be found.
>
> References: https://bugs.gentoo.org/347489
>
> CC: Daniel Kurtz <djkurtz@google.com>
> CC: Mike Frysinger <vapier@gentoo.org>
> Signed-off-by: Diego Elio Pettenò <flameeyes@gmail.com>
> ---
> Makefile | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index c03d74c..d1ace1f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -33,11 +33,10 @@ CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall
> CFLAGS = $(CCOPTS) -I../include $(DEFINES)
> YACCFLAGS = -d -t -v
>
> -LDLIBS += -L../lib -lnetlink -lutil
> -
> SUBDIRS=lib ip tc misc netem genl
>
> LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
> +LDLIBS += $(LIBNETLINK)
>
> all: Config
> @set -e; \
Please be more clear in your subject, yes I can tell this is for
iproute utilities but others may not.
When refering to "previous code" either reply to the original
message thread or provide a link to the changes.
--
^ permalink raw reply
* Re: [PATCH] Link directly to the archive files rather than using search paths.
From: Diego Elio Pettenò @ 2010-12-10 2:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Daniel Kurtz, Mike Frysinger
In-Reply-To: <20101209175644.00feca1d@nehalam>
Il giorno gio, 09/12/2010 alle 17.56 -0800, Stephen Hemminger ha
scritto:
> Please be more clear in your subject, yes I can tell this is for
> iproute utilities but others may not.
Sorry, I should have used --subject-prefix, will make sure to set it
into the configuration file for the future.
> When refering to "previous code" either reply to the original
> message thread or provide a link to the changes.
Uhm, the "previous code" in here is "the Makefile as it was before the
patch", want me to rephrase and resend?
--
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/
If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/
^ permalink raw reply
* Re: [PATCH] kptr_restrict for hiding kernel pointers from unprivileged users
From: Dan Rosenberg @ 2010-12-10 2:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, linux-security-module, netdev
In-Reply-To: <1291901420.4063.24.camel@edumazet-laptop>
>
> Well, it seems difficult to make a check here, its a generic function
> that happens to be used from different contexts.
>
> Even using in_irq() might be a problem.
I agree it seems difficult - my only goal was to prevent subsequent
breakage with the capability check. Does anyone have any suggestions
for a better approach here?
-Dan
^ permalink raw reply
* bridge: Use consistent NF_DROP returns in nf_pre_routing
From: Herbert Xu @ 2010-12-10 3:38 UTC (permalink / raw)
To: David S. Miller, netdev
Hi:
bridge: Use consistent NF_DROP returns in nf_pre_routing
The nf_pre_routing functions in bridging have collected two
distinct ways of returning NF_DROP over the years, inline and
via goto. There is no reason for preferring either one.
So this patch arbitrarily picks the inline variant and converts
the all the gotos.
Also removes a redundant comment.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 865fd76..3fb35fb 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -566,26 +566,26 @@ static unsigned int br_nf_pre_routing_ipv6(unsigned int hook,
u32 pkt_len;
if (skb->len < sizeof(struct ipv6hdr))
- goto inhdr_error;
+ return NF_DROP;
if (!pskb_may_pull(skb, sizeof(struct ipv6hdr)))
- goto inhdr_error;
+ return NF_DROP;
hdr = ipv6_hdr(skb);
if (hdr->version != 6)
- goto inhdr_error;
+ return NF_DROP;
pkt_len = ntohs(hdr->payload_len);
if (pkt_len || hdr->nexthdr != NEXTHDR_HOP) {
if (pkt_len + sizeof(struct ipv6hdr) > skb->len)
- goto inhdr_error;
+ return NF_DROP;
if (pskb_trim_rcsum(skb, pkt_len + sizeof(struct ipv6hdr)))
- goto inhdr_error;
+ return NF_DROP;
}
if (hdr->nexthdr == NEXTHDR_HOP && check_hbh_len(skb))
- goto inhdr_error;
+ return NF_DROP;
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
@@ -598,9 +598,6 @@ static unsigned int br_nf_pre_routing_ipv6(unsigned int hook,
br_nf_pre_routing_finish_ipv6);
return NF_STOLEN;
-
-inhdr_error:
- return NF_DROP;
}
/* Direct IPv6 traffic to br_nf_pre_routing_ipv6.
@@ -619,11 +616,11 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
__u32 len = nf_bridge_encap_header_len(skb);
if (unlikely(!pskb_may_pull(skb, len)))
- goto out;
+ return NF_DROP;
p = br_port_get_rcu(in);
if (p == NULL)
- goto out;
+ return NF_DROP;
br = p->br;
if (skb->protocol == htons(ETH_P_IPV6) || IS_VLAN_IPV6(skb) ||
@@ -645,8 +642,7 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
nf_bridge_pull_encap_header_rcsum(skb);
if (br_parse_ip_options(skb))
- /* Drop invalid packet */
- goto out;
+ return NF_DROP;
nf_bridge_put(skb->nf_bridge);
if (!nf_bridge_alloc(skb))
@@ -660,9 +656,6 @@ static unsigned int br_nf_pre_routing(unsigned int hook, struct sk_buff *skb,
br_nf_pre_routing_finish);
return NF_STOLEN;
-
-out:
- return NF_DROP;
}
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
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