* Re: [PATCH v2 1/6] netfilter: sanity checks on NFPROTO_NUMPROTO
From: Pablo Neira Ayuso @ 2012-05-14 19:04 UTC (permalink / raw)
To: Alban Crequy
Cc: Patrick McHardy, Vincent Sanders, Javier Martinez Canillas,
netfilter-devel, netdev
In-Reply-To: <20120514170410.6c2f1c5b@rainbow.cbg.collabora.co.uk>
On Mon, May 14, 2012 at 05:04:10PM +0100, Alban Crequy wrote:
> Le Mon, 14 May 2012 16:39:49 +0100,
> Alban Crequy <alban.crequy@collabora.co.uk> a écrit :
>
> > Le Mon, 14 May 2012 16:42:35 +0200,
> > Pablo Neira Ayuso <pablo@netfilter.org> a écrit :
> >
> > > On Mon, May 14, 2012 at 02:56:34PM +0100, Alban Crequy wrote:
> > > > With the NFPROTO_* constants introduced by commit 7e9c6e
> > > > ("netfilter: Introduce NFPROTO_* constants"), it is too easy to
> > > > confuse PF_* and NFPROTO_* constants in new protocols.
> > > >
> > > > Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
> > > > Reviewed-by: Javier Martinez Canillas
> > > > <javier.martinez@collabora.co.uk> Reviewed-by: Vincent Sanders
> > > > <vincent.sanders@collabora.co.uk> ---
> > > > net/netfilter/core.c | 5 +++++
> > > > 1 files changed, 5 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> > > > index e1b7e05..4f16552 100644
> > > > --- a/net/netfilter/core.c
> > > > +++ b/net/netfilter/core.c
> > > > @@ -67,6 +67,11 @@ int nf_register_hook(struct nf_hook_ops *reg)
> > > > struct nf_hook_ops *elem;
> > > > int err;
> > > >
> > > > + if (reg->pf >= NFPROTO_NUMPROTO || reg->hooknum >=
> > > > NF_MAX_HOOKS) {
> > > > + BUG();
> > > > + return 1;
> > >
> > > nf_register_hook returns a negative value on error. -EINVAL can be
> > > fine.
> >
> > Is it the patch you mean? Do you want me to do a series repost?
>
> Please disregard the previous patch, this is the correct one.
>
>
> From: Alban Crequy <alban.crequy@collabora.co.uk>
>
> netfilter: sanity checks on NFPROTO_NUMPROTO
>
> With the NFPROTO_* constants introduced by commit 7e9c6e ("netfilter: Introduce
> NFPROTO_* constants"), it is too easy to confuse PF_* and NFPROTO_* constants
> in new protocols.
>
> Signed-off-by: Alban Crequy <alban.crequy@collabora.co.uk>
> ---
> net/netfilter/core.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/net/netfilter/core.c b/net/netfilter/core.c
> index e1b7e05..7422989 100644
> --- a/net/netfilter/core.c
> +++ b/net/netfilter/core.c
> @@ -67,6 +67,14 @@ int nf_register_hook(struct nf_hook_ops *reg)
> struct nf_hook_ops *elem;
> int err;
>
> + if (reg->pf >= NFPROTO_NUMPROTO || reg->hooknum >= NF_MAX_HOOKS) {
> + WARN(reg->pf >= NFPROTO_NUMPROTO,
> + "netfilter: Invalid nfproto %d\n", reg->pf);
> + WARN(reg->hooknum >= NF_MAX_HOOKS,
> + "netfilter: Invalid hooknum %d\n", reg->hooknum);
Then, better add two checkings. One to spot the first warning, and
another to spot the second.
I havent seen such a code in any netfilter code and I like that things
remain consistent.
> + return -EINVAL;
> + }
> +
> err = mutex_lock_interruptible(&nf_hook_mutex);
> if (err < 0)
> return err;
> --
> 1.7.2.5
>
^ permalink raw reply
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Eric Dumazet @ 2012-05-14 19:02 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Stephen Hemminger, David S. Miller, Joe Perches, Jason Wang,
netdev, linux-kernel, Ian.Campbell, kvm
In-Reply-To: <20120514170412.GA17086@redhat.com>
On Mon, 2012-05-14 at 20:04 +0300, Michael S. Tsirkin wrote:
> On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
> > On Sun, 13 May 2012 18:52:06 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > > + /* Userspace may produce vectors with count greater than
> > > + * MAX_SKB_FRAGS, so we need to linearize parts of the skb
> > > + * to let the rest of data to be fit in the frags.
> > > + */
> > Rather than complex partial code, just go through slow path for
> > requests with too many frags (or for really small requests).
> > Creating mixed skb's seems too easy to get wrong.
>
> I don't object in principle but macvtap has same code
> so seems better to stay consistent.
>
If I remember well, code in vtap was buggy and still is.
Jason Wang fixes are not yet in, so maybe wait a bit, so that we dont
add a pile of new bugs ?
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HMARK: endian bugs
From: Pablo Neira Ayuso @ 2012-05-14 19:02 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Hans Schillstrom, Eric Dumazet, Jan Engelhardt, kaber@trash.net,
jengelh@medozas.de, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, dan.carpenter@oracle.com,
hans@schillstrom.com
In-Reply-To: <alpine.DEB.2.00.1205142032570.28548@blackhole.kfki.hu>
On Mon, May 14, 2012 at 08:35:26PM +0200, Jozsef Kadlecsik wrote:
> On Mon, 14 May 2012, Hans Schillstrom wrote:
>
> > On Monday 14 May 2012 18:24:34 Eric Dumazet wrote:
> > > On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
> > >
> > > > This context can contain both le & be machines,
> > > > so at least in hmark it make sense
> > >
> > > Before jhash() and its shuffle ? What do you mean ?
> >
> > I want that a Big endian machine should produce the same
> > hash value independent of flow direction as a Little endian.
> >
> > OK, I missed ntohl() before calling jhash_3words()
> >
> > Correct me if I'm wrong here (have no big endian machine available for test)
> > jhash_3words() and __jhash_final() seems to be "endian" safe.
>
> No, but as Eric wrote: what is the point in forcing the same hash value
> for the same input on big endian and little endian machines? Are you going
> to transfer the hash value between machines?
IIRC, Hans wants that, in case you have a cluster composed of system
with different endianess, the hash mark calculated will be the same
in both systems. To ensure that the distribution is consistent with
independency of the endianess.
^ permalink raw reply
* Re: [PATCH 1/4] netfilter: ipset: fix timeout value overflow bug
From: Pablo Neira Ayuso @ 2012-05-14 19:00 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Eric Dumazet, David Laight, netfilter-devel, davem, netdev
In-Reply-To: <alpine.DEB.2.00.1205141943240.28291@blackhole.kfki.hu>
On Mon, May 14, 2012 at 07:45:07PM +0200, Jozsef Kadlecsik wrote:
> On Mon, 14 May 2012, Eric Dumazet wrote:
>
> > On Mon, 2012-05-14 at 16:36 +0200, Pablo Neira Ayuso wrote:
> > > On Mon, May 14, 2012 at 03:19:49PM +0100, David Laight wrote:
> > > >
> > > > > --- a/include/linux/netfilter/ipset/ip_set_timeout.h
> > > > > +++ b/include/linux/netfilter/ipset/ip_set_timeout.h
> > > > > @@ -30,6 +30,10 @@ ip_set_timeout_uget(struct nlattr *tb)
> > > > > {
> > > > > unsigned int timeout = ip_set_get_h32(tb);
> > > > >
> > > > > + /* Normalize to fit into jiffies */
> > > > > + if (timeout > UINT_MAX/1000)
> > > > > + timeout = UINT_MAX/1000;
> > > > > +
> > > >
> > > > Doesn't that rather assume that HZ is 1000 ?
> > >
> > > Indeed. I overlooked that. Thanks David.
> >
> > I dont think so.
> >
> > 1000 here is really MSEC_PER_SEC
> >
> > (All occurrences should be changed in this file)
>
> Yes, exactly. Pablo, shall I produce a little patch or could you change
> 1000 to MSEC_PER_SEC?
I'll mangle this myself. No need to send a new patch.
^ permalink raw reply
* RE: [PATCH ethtool] Add command to dump module EEPROM
From: Yaniv Rosner @ 2012-05-14 18:57 UTC (permalink / raw)
To: Stuart Hodgson, Ben Hutchings
Cc: David Miller, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <4FB1267E.2090006@solarflare.com>
> On 14/05/12 15:18, Ben Hutchings wrote:
> > On Mon, 2012-05-14 at 18:13 +0300, Yaniv Rosner wrote:
> >> Hi Ben,
> >> This patch adds a new option to dump (SFP+, XFP, ...) module EEPROM following
> >> recent support to kernel side. Below some examples:
> >>
> >> bash-3.00# ethtool -m eth1 offset 0x14 length 32 raw on
> >> JDSU PLRXPLSCS432
> >>
> >> bash-3.00# ethtool -m eth1 offset 0x14 length 32
> >> Offset Values
> >> ------ ------
> >> 0x0014 4a 44 53 55 20 20 20 20 20 20 20 20 20 20 20 20
> >> 0x0024 00 00 01 9c 50 4c 52 58 50 4c 53 43 53 34 33 32
> >>
> >> Please consider applying to ethtool.
> >
> > I agree there should be ASCII-hex and binary dump modes, but we should
> > also support decoding of recognised EEPROM types (as Stuart proposed
> > earlier).
>
> I have a patch to do this as well, but also parse the SFP+ EEPROM.
> I need to fix it up after some of the changes to the patches that added
> kernel support but can submit in the next day or so if this would be of
> use.
>
> Stu
Sounds good. I'll wait for your patch.
^ permalink raw reply
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Michael S. Tsirkin @ 2012-05-14 18:39 UTC (permalink / raw)
To: Shirley Ma
Cc: David S. Miller, Stephen Hemminger, Joe Perches, Jason Wang,
netdev, linux-kernel, Ian.Campbell, kvm
In-Reply-To: <1337016890.3851.20.camel@oc3660625478.ibm.com>
On Mon, May 14, 2012 at 10:34:50AM -0700, Shirley Ma wrote:
> On Sun, 2012-05-13 at 18:52 +0300, Michael S. Tsirkin wrote:
> > Let vhost-net utilize zero copy tx when the experimental
> > zero copy mode is enabled and when used with tun. This works on
> > top of the patchset 'copy aside frags with destructors' that I posted
> > previously. This is not using tcp so doesn't have the
> > issue with early skb cloning noticed by Ian.
> >
> > For those that wish to test this with kvm, I intend to post a patchset
> > +
> > git tree with just the necessary bits from the destructor patch
> > a bit later.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> Hello Mike,
>
> Have you tested this patch? I think the difference between macvtap and
> tap is tap forwarding the packet to bridge. The zerocopy is disabled in
> this case.
>
> Shirley
Testing in progress, but the patchset I pointed to enables
zerocopy with bridge.
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HMARK: endian bugs
From: Jozsef Kadlecsik @ 2012-05-14 18:35 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Eric Dumazet, Jan Engelhardt, Pablo Neira Ayuso, kaber@trash.net,
jengelh@medozas.de, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, dan.carpenter@oracle.com,
hans@schillstrom.com
In-Reply-To: <201205141951.36692.hans.schillstrom@ericsson.com>
On Mon, 14 May 2012, Hans Schillstrom wrote:
> On Monday 14 May 2012 18:24:34 Eric Dumazet wrote:
> > On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
> >
> > > This context can contain both le & be machines,
> > > so at least in hmark it make sense
> >
> > Before jhash() and its shuffle ? What do you mean ?
>
> I want that a Big endian machine should produce the same
> hash value independent of flow direction as a Little endian.
>
> OK, I missed ntohl() before calling jhash_3words()
>
> Correct me if I'm wrong here (have no big endian machine available for test)
> jhash_3words() and __jhash_final() seems to be "endian" safe.
No, but as Eric wrote: what is the point in forcing the same hash value
for the same input on big endian and little endian machines? Are you going
to transfer the hash value between machines?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HMARK: endian bugs
From: Eric Dumazet @ 2012-05-14 18:28 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Jan Engelhardt, Pablo Neira Ayuso, kaber@trash.net,
jengelh@medozas.de, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, dan.carpenter@oracle.com,
hans@schillstrom.com
In-Reply-To: <201205141951.36692.hans.schillstrom@ericsson.com>
On Mon, 2012-05-14 at 19:51 +0200, Hans Schillstrom wrote:
> On Monday 14 May 2012 18:24:34 Eric Dumazet wrote:
> > On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
> >
> > > This context can contain both le & be machines,
> > > so at least in hmark it make sense
> >
> > Before jhash() and its shuffle ? What do you mean ?
>
> I want that a Big endian machine should produce the same
> hash value independent of flow direction as a Little endian.
>
So one machine can be both le and be ? at the same time ?
> OK, I missed ntohl() before calling jhash_3words()
>
> Correct me if I'm wrong here (have no big endian machine available for test)
> jhash_3words() and __jhash_final() seems to be "endian" safe.
>
> So by doing the expensive ntohl on addresses and ports into jhash_3words()
> it will produce the same value on both be and le.
>
And what is the purpose of the jhash output ? Is is sent to other
machines on the network, or only localy used ?
> That's why I want to have the ntohs() / ntohl() when comparing.
If xt_HMARK depends on a particular bit ordering to jhash() input, then
something is really wrong. I mean it.
jhash() primary purpose it to shuffle input.
We use (__force u32) everywhere in network tree to avoid sparse
warnings. Please grep for them.
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-05-14 18:28 UTC (permalink / raw)
To: Arvid Brodin
Cc: netdev@vger.kernel.org, David S. Miller, Bruno Ferreira,
Christian Borntraeger, Herbert Xu
In-Reply-To: <4FB14ADD.3050708@xdin.com>
On Mon, 14 May 2012 18:11:44 +0000
Arvid Brodin <Arvid.Brodin@xdin.com> wrote:
> On 2012-03-27 15:20, Arvid Brodin wrote:
> > Hi!
>
> *snip*
> >
> > 2) I have a locking problem that I haven't managed to figure out. This happens
> > the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called
> > from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send
> > one copy):
> >
> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 2.6.37 #118
> > ---------------------------------------------
> > swapper/0 is trying to acquire lock:
> > (_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152
> >
> > but task is already holding lock:
> > (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
> >
> > other info that might help us debug this:
> > 4 locks held by swapper/0:
> > #0: (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
> > #1: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
> > #2: (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
> > #3: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
> >
> > stack backtrace:
> > Call trace:
> > [<9001c640>] dump_stack+0x18/0x20
> > [<90040eac>] validate_chain+0x40c/0x9ac
> > [<90041a58>] __lock_acquire+0x60c/0x670
> > [<90042f32>] lock_acquire+0x3a/0x48
> > [<902201a4>] _raw_spin_lock+0x20/0x44
> > [<901bf38e>] sch_direct_xmit+0x24/0x152
> > [<901b4c14>] dev_queue_xmit+0x218/0x3cc
> > [<9021c2e0>] slave_xmit+0x10/0x14
> > [<9021c540>] hsr_dev_xmit+0x88/0x8c
> > [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
> > [<901b4d34>] dev_queue_xmit+0x338/0x3cc
> > [<901e3cd8>] arp_xmit+0x8/0xc
> > [<901e4436>] arp_send+0x2a/0x2c
> > [<901e4e74>] arp_solicit+0x15c/0x170
> > [<901bad0c>] neigh_timer_handler+0x1c0/0x204
> > [<9002bc8a>] run_timer_softirq+0x102/0x184
> > [<900287d8>] __do_softirq+0x64/0xe0
> > [<9002896a>] do_softirq+0x26/0x48
> > [<90028a66>] irq_exit+0x2e/0x64
> > [<90019f16>] do_IRQ+0x46/0x5c
> > [<90018428>] irq_level0+0x18/0x60
> > [<9021cc16>] rest_init+0x72/0x98
> > [<9000063c>] start_kernel+0x21c/0x258
> > [<00000000>] 0x0
> >
> > Any idea why this happens? I need help!
>
>
> I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.
>
> The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual
> hsr device and then, recursively, for each of the slaves in turn. (At least that's where
> lockdep complains - at __netif_tx_lock(), that is.)
>
> At first I just could not understand why both the VLAN and the bonding code got away with
> recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I
> found some references to the NETIF_F_LLTX flag (here's one:
> http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And
> sure enough, if I set it for my hsr device lockdep does not complain any more.
>
> But NETIF_F_LLTX is described as deprecated in both netdevice.h and in
> Documentation/networking/netdevices.txt. Is there an alternative solution that I should
> use instead?
>
> (To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves.
> This gives redundancy with instant failover, and since nodes are connected in a ring
> topology, uses less cabling than duplication.)
>
LLTX is deprecated (ie should not be used) for physical devices.
Also, for virtual devices, there should be non transmit queue, this
causes mulit-queue lockless semantics to be preserved as the call passes
through the virtual device.
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HMARK: endian bugs
From: Jan Engelhardt @ 2012-05-14 18:24 UTC (permalink / raw)
To: Hans Schillstrom
Cc: Eric Dumazet, Pablo Neira Ayuso, kaber@trash.net,
jengelh@medozas.de, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, dan.carpenter@oracle.com,
hans@schillstrom.com
In-Reply-To: <201205141951.36692.hans.schillstrom@ericsson.com>
On Monday 2012-05-14 19:51, Hans Schillstrom wrote:
>On Monday 14 May 2012 18:24:34 Eric Dumazet wrote:
>> On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
>>
>> > This context can contain both le & be machines,
>> > so at least in hmark it make sense
>>
>> Before jhash() and its shuffle ? What do you mean ?
>
>I want that a Big endian machine should produce the same
>hash value independent of flow direction as a Little endian.
But one does not really need that, since the hash is only used locally.
^ permalink raw reply
* Re: [PATCH v5 2/2] decrement static keys on real destroy time
From: Tejun Heo @ 2012-05-14 18:12 UTC (permalink / raw)
To: Glauber Costa
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devel-GEFAQzZX7r8dnm+yROfE0A,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
netdev-u79uwXL29TY76Z2rM5mHXA, Li Zefan, Johannes Weiner,
Michal Hocko
In-Reply-To: <1336767077-25351-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
On Fri, May 11, 2012 at 05:11:17PM -0300, Glauber Costa wrote:
> We call the destroy function when a cgroup starts to be removed,
> such as by a rmdir event.
>
> However, because of our reference counters, some objects are still
> inflight. Right now, we are decrementing the static_keys at destroy()
> time, meaning that if we get rid of the last static_key reference,
> some objects will still have charges, but the code to properly
> uncharge them won't be run.
>
> This becomes a problem specially if it is ever enabled again, because
> now new charges will be added to the staled charges making keeping
> it pretty much impossible.
>
> We just need to be careful with the static branch activation:
> since there is no particular preferred order of their activation,
> we need to make sure that we only start using it after all
> call sites are active. This is achieved by having a per-memcg
> flag that is only updated after static_key_slow_inc() returns.
> At this time, we are sure all sites are active.
>
> This is made per-memcg, not global, for a reason:
> it also has the effect of making socket accounting more
> consistent. The first memcg to be limited will trigger static_key()
> activation, therefore, accounting. But all the others will then be
> accounted no matter what. After this patch, only limited memcgs
> will have its sockets accounted.
>
> [v2: changed a tcp limited flag for a generic proto limited flag ]
> [v3: update the current active flag only after the static_key update ]
> [v4: disarm_static_keys() inside free_work ]
> [v5: got rid of tcp_limit_mutex, now in the static_key interface ]
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> CC: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> CC: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
> CC: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
Generally looks sane to me. Please feel free to addmy Reviewed-by.
> + if (val == RESOURCE_MAX)
> + cg_proto->active = false;
> + else if (val != RESOURCE_MAX) {
Minor nitpick: CodingStyle says not to omit { } if other branches need
them.
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-05-14 18:11 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: David S. Miller, Stephen Hemminger, Bruno Ferreira, Arvid Brodin,
Christian Borntraeger, Herbert Xu
In-Reply-To: <4F71BEAD.5080605@enea.com>
On 2012-03-27 15:20, Arvid Brodin wrote:
> Hi!
*snip*
>
> 2) I have a locking problem that I haven't managed to figure out. This happens
> the first time I send any packet (hsr_dev_xmit() in hsr_device.c:121, called
> from hsr_device.c:147). It happens even if I set skb2 to NULL (i.e. only send
> one copy):
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.37 #118
> ---------------------------------------------
> swapper/0 is trying to acquire lock:
> (_xmit_ETHER#2){+.-...}, at: [<901bf38e>] sch_direct_xmit+0x24/0x152
>
> but task is already holding lock:
> (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
>
> other info that might help us debug this:
> 4 locks held by swapper/0:
> #0: (&n->timer){+.-...}, at: [<9002bc20>] run_timer_softirq+0x98/0x184
> #1: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
> #2: (_xmit_ETHER#2){+.-...}, at: [<901b4d1a>] dev_queue_xmit+0x31e/0x3cc
> #3: (rcu_read_lock_bh){.+....}, at: [<901b49fc>] dev_queue_xmit+0x0/0x3cc
>
> stack backtrace:
> Call trace:
> [<9001c640>] dump_stack+0x18/0x20
> [<90040eac>] validate_chain+0x40c/0x9ac
> [<90041a58>] __lock_acquire+0x60c/0x670
> [<90042f32>] lock_acquire+0x3a/0x48
> [<902201a4>] _raw_spin_lock+0x20/0x44
> [<901bf38e>] sch_direct_xmit+0x24/0x152
> [<901b4c14>] dev_queue_xmit+0x218/0x3cc
> [<9021c2e0>] slave_xmit+0x10/0x14
> [<9021c540>] hsr_dev_xmit+0x88/0x8c
> [<901b4942>] dev_hard_start_xmit+0x3c6/0x480
> [<901b4d34>] dev_queue_xmit+0x338/0x3cc
> [<901e3cd8>] arp_xmit+0x8/0xc
> [<901e4436>] arp_send+0x2a/0x2c
> [<901e4e74>] arp_solicit+0x15c/0x170
> [<901bad0c>] neigh_timer_handler+0x1c0/0x204
> [<9002bc8a>] run_timer_softirq+0x102/0x184
> [<900287d8>] __do_softirq+0x64/0xe0
> [<9002896a>] do_softirq+0x26/0x48
> [<90028a66>] irq_exit+0x2e/0x64
> [<90019f16>] do_IRQ+0x46/0x5c
> [<90018428>] irq_level0+0x18/0x60
> [<9021cc16>] rest_init+0x72/0x98
> [<9000063c>] start_kernel+0x21c/0x258
> [<00000000>] 0x0
>
> Any idea why this happens? I need help!
I've spent a few days digging into this and the key apparently is NETIF_F_LLTX.
The problem seems to be that HARD_TX_LOCK is called more than once, first for my virtual
hsr device and then, recursively, for each of the slaves in turn. (At least that's where
lockdep complains - at __netif_tx_lock(), that is.)
At first I just could not understand why both the VLAN and the bonding code got away with
recursive calls to dev_queue_xmit() but I didn't. After some gooling (a lot, actually) I
found some references to the NETIF_F_LLTX flag (here's one:
http://lwn.net/Articles/121566/). I realised both VLAN and bonding code set this flag. And
sure enough, if I set it for my hsr device lockdep does not complain any more.
But NETIF_F_LLTX is described as deprecated in both netdevice.h and in
Documentation/networking/netdevices.txt. Is there an alternative solution that I should
use instead?
(To recap, a hsr device is a virtual device which uses two Ethernet devices as slaves.
This gives redundancy with instant failover, and since nodes are connected in a ring
topology, uses less cabling than duplication.)
--
Arvid Brodin | Consultant (Linux)
XDIN AB | Jan Stenbecks Torg 17 | SE-164 40 Kista | Sweden | xdin.com
^ permalink raw reply
* Re: [PATCH] netfilter: xt_HMARK: endian bugs
From: Hans Schillstrom @ 2012-05-14 17:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jan Engelhardt, Pablo Neira Ayuso, kaber@trash.net,
jengelh@medozas.de, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, dan.carpenter@oracle.com,
hans@schillstrom.com
In-Reply-To: <1337012674.8512.589.camel@edumazet-glaptop>
On Monday 14 May 2012 18:24:34 Eric Dumazet wrote:
> On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
>
> > This context can contain both le & be machines,
> > so at least in hmark it make sense
>
> Before jhash() and its shuffle ? What do you mean ?
I want that a Big endian machine should produce the same
hash value independent of flow direction as a Little endian.
OK, I missed ntohl() before calling jhash_3words()
Correct me if I'm wrong here (have no big endian machine available for test)
jhash_3words() and __jhash_final() seems to be "endian" safe.
So by doing the expensive ntohl on addresses and ports into jhash_3words()
it will produce the same value on both be and le.
That's why I want to have the ntohs() / ntohl() when comparing.
>
> Please respin your patch using (__force u16/u32) instead of
> useless/expensive ntohs() / ntohl() (in _this_ context of hashing)
>
> If you compare two 32bits values, of course they must have same
> ordering, but seeding jhash() is another matter.
>
> (Granted all calls use the same ordering of course)
>
> sparse is great tool, but if you add useless ntohl() calls to make
> sparse silent, then its probably better to not use sparse.
>
^ permalink raw reply
* [RESEND PATCH V2 12/17] NET: MIPS: lantiq: implement OF support inside the etop driver
From: John Crispin @ 2012-05-14 17:42 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, John Crispin, David S. Miller, netdev
In-Reply-To: <1337017363-14424-1-git-send-email-blogic@openwrt.org>
This patch makes it possible to load the driver for the ETOP ethernet on
Lantiq SoC from a devicetree.
Additionally we convert the driver to using the new clkdev clock in favour of
the old ltq_pmu_*() api.
Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
This patch is part of a series moving the mips/lantiq target to OF and clkdev
support. The patch, once Acked, should go upstream via Ralf's MIPS tree.
Changes in V2
* rebase on Ralf's next tree
drivers/net/ethernet/lantiq_etop.c | 63 +++++++++++++++++++++++++++++------
1 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index 5dc9cbd..c0443d4 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -29,19 +29,22 @@
#include <linux/tcp.h>
#include <linux/skbuff.h>
#include <linux/mm.h>
-#include <linux/platform_device.h>
#include <linux/ethtool.h>
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/io.h>
#include <linux/dma-mapping.h>
#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_net.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_gpio.h>
#include <asm/checksum.h>
#include <lantiq_soc.h>
#include <xway_dma.h>
-#include <lantiq_platform.h>
#define LTQ_ETOP_MDIO 0x11804
#define MDIO_REQUEST 0x80000000
@@ -73,6 +76,7 @@
#define ETOP_CGEN 0x800
/* use 2 static channels for TX/RX */
+#define LTQ_DMA_CH0_INT INT_NUM_IM2_IRL0
#define LTQ_ETOP_TX_CHANNEL 1
#define LTQ_ETOP_RX_CHANNEL 6
#define IS_TX(x) (x == LTQ_ETOP_TX_CHANNEL)
@@ -99,12 +103,17 @@ struct ltq_etop_chan {
struct ltq_etop_priv {
struct net_device *netdev;
struct platform_device *pdev;
- struct ltq_eth_data *pldata;
struct resource *res;
struct mii_bus *mii_bus;
struct phy_device *phydev;
+ struct clk *clk;
+ const void *mac;
+ int mii_mode;
+ int tx_irq;
+ int rx_irq;
+
struct ltq_etop_chan ch[MAX_DMA_CHAN];
int tx_free[MAX_DMA_CHAN >> 1];
@@ -239,7 +248,7 @@ ltq_etop_hw_exit(struct net_device *dev)
struct ltq_etop_priv *priv = netdev_priv(dev);
int i;
- ltq_pmu_disable(PMU_PPE);
+ clk_disable(priv->clk);
for (i = 0; i < MAX_DMA_CHAN; i++)
if (IS_TX(i) || IS_RX(i))
ltq_etop_free_channel(dev, &priv->ch[i]);
@@ -251,9 +260,9 @@ ltq_etop_hw_init(struct net_device *dev)
struct ltq_etop_priv *priv = netdev_priv(dev);
int i;
- ltq_pmu_enable(PMU_PPE);
+ clk_enable(priv->clk);
- switch (priv->pldata->mii_mode) {
+ switch (priv->mii_mode) {
case PHY_INTERFACE_MODE_RMII:
ltq_etop_w32_mask(ETOP_MII_MASK,
ETOP_MII_REVERSE, LTQ_ETOP_CFG);
@@ -266,7 +275,7 @@ ltq_etop_hw_init(struct net_device *dev)
default:
netdev_err(dev, "unknown mii mode %d\n",
- priv->pldata->mii_mode);
+ priv->mii_mode);
return -ENOTSUPP;
}
@@ -395,7 +404,7 @@ ltq_etop_mdio_probe(struct net_device *dev)
}
phydev = phy_connect(dev, dev_name(&phydev->dev), <q_etop_mdio_link,
- 0, priv->pldata->mii_mode);
+ 0, priv->mii_mode);
if (IS_ERR(phydev)) {
netdev_err(dev, "Could not attach to PHY\n");
@@ -643,7 +652,7 @@ ltq_etop_init(struct net_device *dev)
goto err_hw;
ltq_etop_change_mtu(dev, 1500);
- memcpy(&mac, &priv->pldata->mac, sizeof(struct sockaddr));
+ memcpy(&mac.sa_data, &priv->mac, ETH_ALEN);
if (!is_valid_ether_addr(mac.sa_data)) {
pr_warn("etop: invalid MAC, using random\n");
random_ether_addr(mac.sa_data);
@@ -707,9 +716,12 @@ static const struct net_device_ops ltq_eth_netdev_ops = {
static int __init
ltq_etop_probe(struct platform_device *pdev)
{
+ struct device_node *node = pdev->dev.of_node;
struct net_device *dev;
struct ltq_etop_priv *priv;
struct resource *res;
+ struct clk *clk;
+ struct resource irqres[2];
int err;
int i;
@@ -737,6 +749,20 @@ ltq_etop_probe(struct platform_device *pdev)
goto err_out;
}
+ err = of_irq_to_resource_table(node, irqres, 2);
+ if (err != 2) {
+ dev_err(&pdev->dev, "not enough irqs defined\n");
+ err = -EINVAL;
+ goto err_out;
+ }
+
+ clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk)) {
+ dev_err(&pdev->dev, "Failed to get clock\n");
+ err = PTR_ERR(clk);
+ goto err_out;
+ }
+
dev = alloc_etherdev_mq(sizeof(struct ltq_etop_priv), 4);
if (!dev) {
err = -ENOMEM;
@@ -748,9 +774,15 @@ ltq_etop_probe(struct platform_device *pdev)
priv = netdev_priv(dev);
priv->res = res;
priv->pdev = pdev;
- priv->pldata = dev_get_platdata(&pdev->dev);
priv->netdev = dev;
spin_lock_init(&priv->lock);
+ priv->tx_irq = irqres[0].start;
+ priv->rx_irq = irqres[1].start;
+ priv->mii_mode = of_get_phy_mode(node);
+ priv->mac = of_get_mac_address(node);
+ priv->clk = clk;
+ if (priv->mii_mode < 0)
+ priv->mii_mode = PHY_INTERFACE_MODE_MII;
for (i = 0; i < MAX_DMA_CHAN; i++) {
if (IS_TX(i))
@@ -779,21 +811,30 @@ static int __devexit
ltq_etop_remove(struct platform_device *pdev)
{
struct net_device *dev = platform_get_drvdata(pdev);
+ struct ltq_etop_priv *priv = netdev_priv(dev);
if (dev) {
netif_tx_stop_all_queues(dev);
ltq_etop_hw_exit(dev);
ltq_etop_mdio_cleanup(dev);
+ clk_put(priv->clk);
unregister_netdev(dev);
}
return 0;
}
+static const struct of_device_id ltq_etop_match[] = {
+ { .compatible = "lantiq,etop-xway" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ltq_etop_match);
+
static struct platform_driver ltq_mii_driver = {
.remove = __devexit_p(ltq_etop_remove),
.driver = {
- .name = "ltq_etop",
+ .name = "etop-xway",
.owner = THIS_MODULE,
+ .of_match_table = ltq_etop_match,
},
};
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 1/4] netfilter: ipset: fix timeout value overflow bug
From: Jozsef Kadlecsik @ 2012-05-14 17:45 UTC (permalink / raw)
To: Eric Dumazet
Cc: Pablo Neira Ayuso, David Laight, netfilter-devel, davem, netdev
In-Reply-To: <1337006844.8512.491.camel@edumazet-glaptop>
On Mon, 14 May 2012, Eric Dumazet wrote:
> On Mon, 2012-05-14 at 16:36 +0200, Pablo Neira Ayuso wrote:
> > On Mon, May 14, 2012 at 03:19:49PM +0100, David Laight wrote:
> > >
> > > > --- a/include/linux/netfilter/ipset/ip_set_timeout.h
> > > > +++ b/include/linux/netfilter/ipset/ip_set_timeout.h
> > > > @@ -30,6 +30,10 @@ ip_set_timeout_uget(struct nlattr *tb)
> > > > {
> > > > unsigned int timeout = ip_set_get_h32(tb);
> > > >
> > > > + /* Normalize to fit into jiffies */
> > > > + if (timeout > UINT_MAX/1000)
> > > > + timeout = UINT_MAX/1000;
> > > > +
> > >
> > > Doesn't that rather assume that HZ is 1000 ?
> >
> > Indeed. I overlooked that. Thanks David.
>
> I dont think so.
>
> 1000 here is really MSEC_PER_SEC
>
> (All occurrences should be changed in this file)
Yes, exactly. Pablo, shall I produce a little patch or could you change
1000 to MSEC_PER_SEC?
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH] net: codel: fix build errors
From: Sasha Levin @ 2012-05-14 17:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: edumazet, dave.taht, davem, linux-kernel, netdev
In-Reply-To: <20120514103526.1f1a4399@nehalam.linuxnetplumber.net>
On Mon, May 14, 2012 at 7:35 PM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 14 May 2012 19:14:47 +0200
> Sasha Levin <levinsasha928@gmail.com> wrote:
>
>> Fix the following build error:
>>
>> net/sched/sch_fq_codel.c: In function 'fq_codel_dump_stats':
>> net/sched/sch_fq_codel.c:464:3: error: unknown field 'qdisc_stats' specified in initializer
>> net/sched/sch_fq_codel.c:464:3: warning: missing braces around initializer
>> net/sched/sch_fq_codel.c:464:3: warning: (near initialization for 'st.<anonymous>')
>> net/sched/sch_fq_codel.c:465:3: error: unknown field 'qdisc_stats' specified in initializer
>> net/sched/sch_fq_codel.c:465:3: warning: excess elements in struct initializer
>> net/sched/sch_fq_codel.c:465:3: warning: (near initialization for 'st')
>> net/sched/sch_fq_codel.c:466:3: error: unknown field 'qdisc_stats' specified in initializer
>> net/sched/sch_fq_codel.c:466:3: warning: excess elements in struct initializer
>> net/sched/sch_fq_codel.c:466:3: warning: (near initialization for 'st')
>> net/sched/sch_fq_codel.c:467:3: error: unknown field 'qdisc_stats' specified in initializer
>> net/sched/sch_fq_codel.c:467:3: warning: excess elements in struct initializer
>> net/sched/sch_fq_codel.c:467:3: warning: (near initialization for 'st')
>> make[1]: *** [net/sched/sch_fq_codel.o] Error 1
>>
>> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> Which Gcc version, looks like your compiler is old.
gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7)
This is the latest gcc provided by gentoo.
^ permalink raw reply
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Shirley Ma @ 2012-05-14 17:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David S. Miller, Stephen Hemminger, Joe Perches, Jason Wang,
netdev, linux-kernel, Ian.Campbell, kvm
In-Reply-To: <20120513155206.GA26847@redhat.com>
On Sun, 2012-05-13 at 18:52 +0300, Michael S. Tsirkin wrote:
> Let vhost-net utilize zero copy tx when the experimental
> zero copy mode is enabled and when used with tun. This works on
> top of the patchset 'copy aside frags with destructors' that I posted
> previously. This is not using tcp so doesn't have the
> issue with early skb cloning noticed by Ian.
>
> For those that wish to test this with kvm, I intend to post a patchset
> +
> git tree with just the necessary bits from the destructor patch
> a bit later.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Hello Mike,
Have you tested this patch? I think the difference between macvtap and
tap is tap forwarding the packet to bridge. The zerocopy is disabled in
this case.
Shirley
^ permalink raw reply
* Re: [PATCH] net: codel: fix build errors
From: Stephen Hemminger @ 2012-05-14 17:35 UTC (permalink / raw)
To: Sasha Levin; +Cc: edumazet, dave.taht, davem, linux-kernel, netdev
In-Reply-To: <1337015687-17693-1-git-send-email-levinsasha928@gmail.com>
On Mon, 14 May 2012 19:14:47 +0200
Sasha Levin <levinsasha928@gmail.com> wrote:
> Fix the following build error:
>
> net/sched/sch_fq_codel.c: In function 'fq_codel_dump_stats':
> net/sched/sch_fq_codel.c:464:3: error: unknown field 'qdisc_stats' specified in initializer
> net/sched/sch_fq_codel.c:464:3: warning: missing braces around initializer
> net/sched/sch_fq_codel.c:464:3: warning: (near initialization for 'st.<anonymous>')
> net/sched/sch_fq_codel.c:465:3: error: unknown field 'qdisc_stats' specified in initializer
> net/sched/sch_fq_codel.c:465:3: warning: excess elements in struct initializer
> net/sched/sch_fq_codel.c:465:3: warning: (near initialization for 'st')
> net/sched/sch_fq_codel.c:466:3: error: unknown field 'qdisc_stats' specified in initializer
> net/sched/sch_fq_codel.c:466:3: warning: excess elements in struct initializer
> net/sched/sch_fq_codel.c:466:3: warning: (near initialization for 'st')
> net/sched/sch_fq_codel.c:467:3: error: unknown field 'qdisc_stats' specified in initializer
> net/sched/sch_fq_codel.c:467:3: warning: excess elements in struct initializer
> net/sched/sch_fq_codel.c:467:3: warning: (near initialization for 'st')
> make[1]: *** [net/sched/sch_fq_codel.o] Error 1
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Which Gcc version, looks like your compiler is old.
^ permalink raw reply
* Re: [net-next 06/12] ixgbe: Hardware Timestamping + PTP Hardware Clock (PHC)
From: Jacob Keller @ 2012-05-14 17:28 UTC (permalink / raw)
To: Richard Cochran
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <20120512053458.GC2190@netboy.at.omicron.at>
On 05/11/2012 10:34 PM, Richard Cochran wrote:
> On Fri, May 11, 2012 at 07:23:44PM +0000, Keller, Jacob E wrote:
>>
>>
>> I believe this very rare case might be possible, but I don't think
>> that checking the ptp seqid will fix anything. In normal cases,
>> hardware latches Rx packet timestamp, then the ptp packet goes into
>> the queue and we process it shortly after. Before we process that
>> packet there will never be another packet in the queue that needs a
>> timestamp. We know this because the hardware stops timestamping
>> until we unlatch the RX registers. This should mean we don't need to
>> check the sequence ID, and spending time doing it would never fix
>> the issue you are talking about.
>>
>> The issue is for when a packet is timestamped and then never reaches
>> the queue. Then the rx stamp registers are locked for good, because
>> we never clear them, and hardware would never timestamp another
>> receive packet. I don't know a good solution to this, except to
>> clear the registers periodically. Do you have any suggestions?
>
> Well, one solution would be to check every received packet with the
> BPF in ptp_classify.h (whenever Rx time stamping is enabled).
>
> When the driver finds an event packet in the Rx queue, and
> TSYNCRXCTL[RXTT] is set, it reads out the time stamp along with
> RXSATRL/H. If the fields match, then add the time stamp to the skb.
>
> [ Or perhaps instead of using RXSATRL/H, just use the descriptor bit.
> If *not* set, then the time stamp does not belong to this packet. ]
>
> HTH,
> Richard
Ok, this sounds like a good plan. Considering that the device already
doesn't allow timestamping of other types of packets, so it doesn't need
to be general purpose.
Am I correct in thinking all I need to do is check the type and if it
matches the currently configured rx timestamp mode, then double check
the bit for whether a timestamp is available, and whether the descriptor
had a timestamp bit enabled?
Thanks
- Jake
^ permalink raw reply
* [PATCH] net: codel: fix build errors
From: Sasha Levin @ 2012-05-14 17:14 UTC (permalink / raw)
To: edumazet, dave.taht, davem; +Cc: linux-kernel, netdev, Sasha Levin
Fix the following build error:
net/sched/sch_fq_codel.c: In function 'fq_codel_dump_stats':
net/sched/sch_fq_codel.c:464:3: error: unknown field 'qdisc_stats' specified in initializer
net/sched/sch_fq_codel.c:464:3: warning: missing braces around initializer
net/sched/sch_fq_codel.c:464:3: warning: (near initialization for 'st.<anonymous>')
net/sched/sch_fq_codel.c:465:3: error: unknown field 'qdisc_stats' specified in initializer
net/sched/sch_fq_codel.c:465:3: warning: excess elements in struct initializer
net/sched/sch_fq_codel.c:465:3: warning: (near initialization for 'st')
net/sched/sch_fq_codel.c:466:3: error: unknown field 'qdisc_stats' specified in initializer
net/sched/sch_fq_codel.c:466:3: warning: excess elements in struct initializer
net/sched/sch_fq_codel.c:466:3: warning: (near initialization for 'st')
net/sched/sch_fq_codel.c:467:3: error: unknown field 'qdisc_stats' specified in initializer
net/sched/sch_fq_codel.c:467:3: warning: excess elements in struct initializer
net/sched/sch_fq_codel.c:467:3: warning: (near initialization for 'st')
make[1]: *** [net/sched/sch_fq_codel.o] Error 1
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
include/linux/pkt_sched.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/pkt_sched.h b/include/linux/pkt_sched.h
index 32aef0a..c304eda 100644
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
@@ -732,7 +732,9 @@ struct tc_fq_codel_xstats {
union {
struct tc_fq_codel_qd_stats qdisc_stats;
struct tc_fq_codel_cl_stats class_stats;
- };
+ } u;
+#define qdisc_stats u.qdisc_stats
+#define class_stats u.class_stats
};
#endif
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Michael S. Tsirkin @ 2012-05-14 17:04 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Joe Perches, Jason Wang, netdev, linux-kernel,
Ian.Campbell, kvm
In-Reply-To: <20120514095446.3ce307d2@nehalam.linuxnetplumber.net>
On Mon, May 14, 2012 at 09:54:46AM -0700, Stephen Hemminger wrote:
> On Sun, 13 May 2012 18:52:06 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > + /* Userspace may produce vectors with count greater than
> > + * MAX_SKB_FRAGS, so we need to linearize parts of the skb
> > + * to let the rest of data to be fit in the frags.
> > + */
> Rather than complex partial code, just go through slow path for
> requests with too many frags (or for really small requests).
> Creating mixed skb's seems too easy to get wrong.
I don't object in principle but macvtap has same code
so seems better to stay consistent.
--
MST
^ permalink raw reply
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Stephen Hemminger @ 2012-05-14 16:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David S. Miller, Joe Perches, Jason Wang, netdev, linux-kernel,
Ian.Campbell, kvm
In-Reply-To: <20120513155206.GA26847@redhat.com>
On Sun, 13 May 2012 18:52:06 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> + /* Userspace may produce vectors with count greater than
> + * MAX_SKB_FRAGS, so we need to linearize parts of the skb
> + * to let the rest of data to be fit in the frags.
> + */
Rather than complex partial code, just go through slow path for
requests with too many frags (or for really small requests).
Creating mixed skb's seems too easy to get wrong.
^ permalink raw reply
* RE: pch_gbe: oops with vlan (resolved)
From: Andy Cress @ 2012-05-14 16:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1336774254.31653.287.camel@edumazet-glaptop>
Eric,
This patch resolved the driver oops (transmit queue timeout) with vlan. It makes a lot of sense that the wrong spin_locks caused this.
Thanks a lot.
Andy
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Eric Dumazet
Sent: Friday, May 11, 2012 6:11 PM
To: Andy Cress
Cc: netdev
Subject: Re: pch_gbe: oops with vlan (new)
On Fri, 2012-05-11 at 23:13 +0200, Eric Dumazet wrote:
> On Fri, 2012-05-11 at 13:48 -0700, Andy Cress wrote:
> > Folks,
> >
> > I am looking for help in debugging a pch_gbe driver oops/abort.
> >
> > Kernel: version 2.6.32-220.el6.i686 (RHEL6.2)
> > Driver: pch_gbe version 0.91-NAPI (source tarball we used is at
> > https://sendfile.kontron.com/message/24tdUi6MXklnUtBLnOsumq until May
> > 16)
> > NIC: 0b:00.1 Ethernet controller [0200]: Intel Corporation Platform
> > Controller Hub EG20T Gigabit Ethernet Controller [8086:8802] (rev 02)
> >
> > Configuration, with VLAN:
> > eth0 (not started)
> > eth0.100 = 192.168.100.1
> > eth0.200 = 192.168.200.1
> > eth0.6 = 192.168.6.1
> >
> > When starting the VLAN configuration, then doing a ping test for >= 5
> > minutes, I get a kernel oop/abort message as shown below. This does not
> > happen without configuring VLAN.
> > Where should I look for possible causes for a transmit queue timeout
> > like this?
> >
> > I have contacted the OKI/LAPIS driver authors, but no response so far.
> > I thought that this group might be able to comment from similar
> > experiences.
> >
> > Andy
>
> typical sign of a buggy driver
>
> A quick look in current Linus tree show a non existent synchronization
> between ndo_start_xmit and TX completion.
>
> tx completion uses a tx_queue_lock spinlock for nothing but false sense
> of correctness.
Please try the following patch : (based on current net-next tree)
Also this driver has a strange RX path : It does a copy of incoming
frames on fixed size skbs, (2048+overhead -> kmalloc-4096 pool) instead
of using skb of the right size...
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 25 ++++------
2 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
index 9f3dbc4..b07311e 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
@@ -584,7 +584,6 @@ struct pch_gbe_hw_stats {
/**
* struct pch_gbe_adapter - board specific private data structure
* @stats_lock: Spinlock structure for status
- * @tx_queue_lock: Spinlock structure for transmit
* @ethtool_lock: Spinlock structure for ethtool
* @irq_sem: Semaphore for interrupt
* @netdev: Pointer of network device structure
@@ -609,7 +608,6 @@ struct pch_gbe_hw_stats {
struct pch_gbe_adapter {
spinlock_t stats_lock;
- spinlock_t tx_queue_lock;
spinlock_t ethtool_lock;
atomic_t irq_sem;
struct net_device *netdev;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 9dc7e50..3787c64 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -645,14 +645,11 @@ static void pch_gbe_mac_set_pause_packet(struct pch_gbe_hw *hw)
*/
static int pch_gbe_alloc_queues(struct pch_gbe_adapter *adapter)
{
- int size;
-
- size = (int)sizeof(struct pch_gbe_tx_ring);
- adapter->tx_ring = kzalloc(size, GFP_KERNEL);
+ adapter->tx_ring = kzalloc(sizeof(*adapter->tx_ring), GFP_KERNEL);
if (!adapter->tx_ring)
return -ENOMEM;
- size = (int)sizeof(struct pch_gbe_rx_ring);
- adapter->rx_ring = kzalloc(size, GFP_KERNEL);
+
+ adapter->rx_ring = kzalloc(sizeof(*adapter->rx_ring), GFP_KERNEL);
if (!adapter->rx_ring) {
kfree(adapter->tx_ring);
return -ENOMEM;
@@ -1169,7 +1166,6 @@ static void pch_gbe_tx_queue(struct pch_gbe_adapter *adapter,
struct sk_buff *tmp_skb;
unsigned int frame_ctrl;
unsigned int ring_num;
- unsigned long flags;
/*-- Set frame control --*/
frame_ctrl = 0;
@@ -1216,14 +1212,14 @@ static void pch_gbe_tx_queue(struct pch_gbe_adapter *adapter,
}
}
}
- spin_lock_irqsave(&tx_ring->tx_lock, flags);
+
ring_num = tx_ring->next_to_use;
if (unlikely((ring_num + 1) == tx_ring->count))
tx_ring->next_to_use = 0;
else
tx_ring->next_to_use = ring_num + 1;
- spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
+
buffer_info = &tx_ring->buffer_info[ring_num];
tmp_skb = buffer_info->skb;
@@ -1525,7 +1521,7 @@ pch_gbe_alloc_rx_buffers_pool(struct pch_gbe_adapter *adapter,
&rx_ring->rx_buff_pool_logic,
GFP_KERNEL);
if (!rx_ring->rx_buff_pool) {
- pr_err("Unable to allocate memory for the receive poll buffer\n");
+ pr_err("Unable to allocate memory for the receive pool buffer\n");
return -ENOMEM;
}
memset(rx_ring->rx_buff_pool, 0, size);
@@ -1644,15 +1640,17 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
pr_debug("called pch_gbe_unmap_and_free_tx_resource() %d count\n",
cleaned_count);
/* Recover from running out of Tx resources in xmit_frame */
+ spin_lock(&tx_ring->tx_lock);
if (unlikely(cleaned && (netif_queue_stopped(adapter->netdev)))) {
netif_wake_queue(adapter->netdev);
adapter->stats.tx_restart_count++;
pr_debug("Tx wake queue\n");
}
- spin_lock(&adapter->tx_queue_lock);
+
tx_ring->next_to_clean = i;
- spin_unlock(&adapter->tx_queue_lock);
+
pr_debug("next_to_clean : %d\n", tx_ring->next_to_clean);
+ spin_unlock(&tx_ring->tx_lock);
return cleaned;
}
@@ -2043,7 +2041,6 @@ static int pch_gbe_sw_init(struct pch_gbe_adapter *adapter)
return -ENOMEM;
}
spin_lock_init(&adapter->hw.miim_lock);
- spin_lock_init(&adapter->tx_queue_lock);
spin_lock_init(&adapter->stats_lock);
spin_lock_init(&adapter->ethtool_lock);
atomic_set(&adapter->irq_sem, 0);
@@ -2148,10 +2145,10 @@ static int pch_gbe_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
tx_ring->next_to_use, tx_ring->next_to_clean);
return NETDEV_TX_BUSY;
}
- spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
/* CRC,ITAG no support */
pch_gbe_tx_queue(adapter, tx_ring, skb);
+ spin_unlock_irqrestore(&tx_ring->tx_lock, flags);
return NETDEV_TX_OK;
}
--
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 related
* [PATCH net-next v4] be2net: Fix to allow get/set of debug levels in the firmware.
From: Somnath Kotur @ 2012-05-14 16:29 UTC (permalink / raw)
To: netdev, bhutchings; +Cc: Somnath Kotur, Suresh Reddy
Fixed missing paranthesis warning
Incorporated review comments by Ben Hutchings.
Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 3 +
drivers/net/ethernet/emulex/benet/be_cmds.c | 56 +++++++++++++++++
drivers/net/ethernet/emulex/benet/be_cmds.h | 57 +++++++++++++++++
drivers/net/ethernet/emulex/benet/be_ethtool.c | 77 ++++++++++++++++++++++++
drivers/net/ethernet/emulex/benet/be_main.c | 37 +++++++++++
5 files changed, 230 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index c3ee910..9817fed 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -415,6 +415,7 @@ struct be_adapter {
bool wol;
u32 max_pmac_cnt; /* Max secondary UC MACs programmable */
u32 uc_macs; /* Count of secondary UC MAC programmed */
+ u32 msg_enable;
};
#define be_physfn(adapter) (!adapter->is_virtfn)
@@ -603,4 +604,6 @@ extern void be_parse_stats(struct be_adapter *adapter);
extern int be_load_fw(struct be_adapter *adapter, u8 *func);
extern bool be_is_wol_supported(struct be_adapter *adapter);
extern bool be_pause_supported(struct be_adapter *adapter);
+extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+
#endif /* BE_H */
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 43167e8..b24623c 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -2589,4 +2589,60 @@ err:
mutex_unlock(&adapter->mbox_lock);
pci_free_consistent(adapter->pdev, cmd.size, cmd.va, cmd.dma);
return status;
+
+}
+int be_cmd_get_ext_fat_capabilites(struct be_adapter *adapter,
+ struct be_dma_mem *cmd)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_req_get_ext_fat_caps *req;
+ int status;
+
+ if (mutex_lock_interruptible(&adapter->mbox_lock))
+ return -1;
+
+ wrb = wrb_from_mbox(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+
+ req = cmd->va;
+ be_wrb_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_GET_EXT_FAT_CAPABILITES,
+ cmd->size, wrb, cmd);
+ req->parameter_type = cpu_to_le32(1);
+
+ status = be_mbox_notify_wait(adapter);
+err:
+ mutex_unlock(&adapter->mbox_lock);
+ return status;
+}
+
+int be_cmd_set_ext_fat_capabilites(struct be_adapter *adapter,
+ struct be_dma_mem *cmd,
+ struct be_fat_conf_params *configs)
+{
+ struct be_mcc_wrb *wrb;
+ struct be_cmd_req_set_ext_fat_caps *req;
+ int status;
+
+ spin_lock_bh(&adapter->mcc_lock);
+
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
+ goto err;
+ }
+
+ req = cmd->va;
+ memcpy(&req->set_params, configs, sizeof(struct be_fat_conf_params));
+ be_wrb_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
+ OPCODE_COMMON_SET_EXT_FAT_CAPABILITES,
+ cmd->size, wrb, cmd);
+
+ status = be_mcc_notify_wait(adapter);
+err:
+ spin_unlock_bh(&adapter->mcc_lock);
+ return status;
}
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 944f031..0b1029b 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -189,6 +189,8 @@ struct be_mcc_mailbox {
#define OPCODE_COMMON_GET_PHY_DETAILS 102
#define OPCODE_COMMON_SET_DRIVER_FUNCTION_CAP 103
#define OPCODE_COMMON_GET_CNTL_ADDITIONAL_ATTRIBUTES 121
+#define OPCODE_COMMON_GET_EXT_FAT_CAPABILITES 125
+#define OPCODE_COMMON_SET_EXT_FAT_CAPABILITES 126
#define OPCODE_COMMON_GET_MAC_LIST 147
#define OPCODE_COMMON_SET_MAC_LIST 148
#define OPCODE_COMMON_GET_HSW_CONFIG 152
@@ -1602,6 +1604,56 @@ static inline void *be_erx_stats_from_cmd(struct be_adapter *adapter)
}
}
+
+/************** get fat capabilites *******************/
+#define MAX_MODULES 27
+#define MAX_MODES 4
+#define MODE_UART 0
+#define FW_LOG_LEVEL_DEFAULT 48
+#define FW_LOG_LEVEL_FATAL 64
+
+struct ext_fat_mode {
+ u8 mode;
+ u8 rsvd0;
+ u16 port_mask;
+ u32 dbg_lvl;
+ u64 fun_mask;
+} __packed;
+
+struct ext_fat_modules {
+ u8 modules_str[32];
+ u32 modules_id;
+ u32 num_modes;
+ struct ext_fat_mode trace_lvl[MAX_MODES];
+} __packed;
+
+struct be_fat_conf_params {
+ u32 max_log_entries;
+ u32 log_entry_size;
+ u8 log_type;
+ u8 max_log_funs;
+ u8 max_log_ports;
+ u8 rsvd0;
+ u32 supp_modes;
+ u32 num_modules;
+ struct ext_fat_modules module[MAX_MODULES];
+} __packed;
+
+struct be_cmd_req_get_ext_fat_caps {
+ struct be_cmd_req_hdr hdr;
+ u32 parameter_type;
+};
+
+struct be_cmd_resp_get_ext_fat_caps {
+ struct be_cmd_resp_hdr hdr;
+ struct be_fat_conf_params get_params;
+};
+
+struct be_cmd_req_set_ext_fat_caps {
+ struct be_cmd_req_hdr hdr;
+ struct be_fat_conf_params set_params;
+};
+
extern int be_pci_fnum_get(struct be_adapter *adapter);
extern int be_cmd_POST(struct be_adapter *adapter);
extern int be_cmd_mac_addr_query(struct be_adapter *adapter, u8 *mac_addr,
@@ -1707,4 +1759,9 @@ extern int be_cmd_set_hsw_config(struct be_adapter *adapter, u16 pvid,
extern int be_cmd_get_hsw_config(struct be_adapter *adapter, u16 *pvid,
u32 domain, u16 intf_id);
extern int be_cmd_get_acpi_wol_cap(struct be_adapter *adapter);
+extern int be_cmd_get_ext_fat_capabilites(struct be_adapter *adapter,
+ struct be_dma_mem *cmd);
+extern int be_cmd_set_ext_fat_capabilites(struct be_adapter *adapter,
+ struct be_dma_mem *cmd,
+ struct be_fat_conf_params *cfgs);
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 747f68f..88f1107 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -878,6 +878,81 @@ be_read_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom,
return status;
}
+static u32 be_get_msg_level(struct net_device *netdev)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+
+ if (lancer_chip(adapter)) {
+ dev_err(&adapter->pdev->dev, "Operation not supported\n");
+ return -EOPNOTSUPP;
+ }
+
+ return adapter->msg_enable;
+}
+
+static void be_set_fw_log_level(struct be_adapter *adapter, u32 level)
+{
+ struct be_dma_mem extfat_cmd;
+ struct be_fat_conf_params *cfgs;
+ int status;
+ int i, j;
+
+ memset(&extfat_cmd, 0, sizeof(struct be_dma_mem));
+ extfat_cmd.size = sizeof(struct be_cmd_resp_get_ext_fat_caps);
+ extfat_cmd.va = pci_alloc_consistent(adapter->pdev, extfat_cmd.size,
+ &extfat_cmd.dma);
+ if (!extfat_cmd.va) {
+ dev_err(&adapter->pdev->dev, "%s: Memory allocation failure\n",
+ __func__);
+ goto err;
+ }
+ status = be_cmd_get_ext_fat_capabilites(adapter, &extfat_cmd);
+ if (!status) {
+ cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
+ sizeof(struct be_cmd_resp_hdr));
+ for (i = 0; i < cfgs->num_modules; i++) {
+ for (j = 0; j < cfgs->module[i].num_modes; j++) {
+ if (cfgs->module[i].trace_lvl[j].mode ==
+ MODE_UART)
+ cfgs->module[i].trace_lvl[j].dbg_lvl =
+ cpu_to_le32(level);
+ }
+ }
+ status = be_cmd_set_ext_fat_capabilites(adapter, &extfat_cmd,
+ cfgs);
+ if (status)
+ dev_err(&adapter->pdev->dev,
+ "Message level set failed\n");
+ } else {
+ dev_err(&adapter->pdev->dev, "Message level get failed\n");
+ }
+
+ pci_free_consistent(adapter->pdev, extfat_cmd.size, extfat_cmd.va,
+ extfat_cmd.dma);
+err:
+ return;
+}
+
+static void be_set_msg_level(struct net_device *netdev, u32 level)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+
+ if (lancer_chip(adapter)) {
+ dev_err(&adapter->pdev->dev, "Operation not supported\n");
+ return;
+ }
+
+ if (adapter->msg_enable == level)
+ return;
+
+ if ((level & NETIF_MSG_HW) != (adapter->msg_enable & NETIF_MSG_HW))
+ be_set_fw_log_level(adapter, level & NETIF_MSG_HW ?
+ FW_LOG_LEVEL_DEFAULT : FW_LOG_LEVEL_FATAL);
+ adapter->msg_enable = level;
+
+ return;
+}
+
const struct ethtool_ops be_ethtool_ops = {
.get_settings = be_get_settings,
.get_drvinfo = be_get_drvinfo,
@@ -893,6 +968,8 @@ const struct ethtool_ops be_ethtool_ops = {
.set_pauseparam = be_set_pauseparam,
.get_strings = be_get_stat_strings,
.set_phys_id = be_set_phys_id,
+ .get_msglevel = be_get_msg_level,
+ .set_msglevel = be_set_msg_level,
.get_sset_count = be_get_sset_count,
.get_ethtool_stats = be_get_ethtool_stats,
.get_regs_len = be_get_reg_len,
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 6d5d30b..c2286a2 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3367,9 +3367,43 @@ bool be_is_wol_supported(struct be_adapter *adapter)
!be_is_wol_excluded(adapter)) ? true : false;
}
+u32 be_get_fw_log_level(struct be_adapter *adapter)
+{
+ struct be_dma_mem extfat_cmd;
+ struct be_fat_conf_params *cfgs;
+ int status;
+ u32 level = 0;
+ int j;
+
+ memset(&extfat_cmd, 0, sizeof(struct be_dma_mem));
+ extfat_cmd.size = sizeof(struct be_cmd_resp_get_ext_fat_caps);
+ extfat_cmd.va = pci_alloc_consistent(adapter->pdev, extfat_cmd.size,
+ &extfat_cmd.dma);
+ if (!extfat_cmd.va) {
+ dev_err(&adapter->pdev->dev, "%s: Memory allocation failure\n",
+ __func__);
+ goto err;
+ }
+
+ status = be_cmd_get_ext_fat_capabilites(adapter, &extfat_cmd);
+ if (!status) {
+ cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
+ sizeof(struct be_cmd_resp_hdr));
+ for (j = 0; j < cfgs->module[0].num_modes; j++) {
+ if (cfgs->module[0].trace_lvl[j].mode == MODE_UART)
+ level = cfgs->module[0].trace_lvl[j].dbg_lvl;
+ }
+ }
+ pci_free_consistent(adapter->pdev, extfat_cmd.size, extfat_cmd.va,
+ extfat_cmd.dma);
+err:
+ return level;
+}
+
static int be_get_config(struct be_adapter *adapter)
{
int status;
+ u32 level;
status = be_cmd_query_fw_cfg(adapter, &adapter->port_num,
&adapter->function_mode, &adapter->function_caps);
@@ -3407,6 +3441,9 @@ static int be_get_config(struct be_adapter *adapter)
if (be_is_wol_supported(adapter))
adapter->wol = true;
+ level = be_get_fw_log_level(adapter);
+ adapter->msg_enable = level <= FW_LOG_LEVEL_DEFAULT ? NETIF_MSG_HW : 0;
+
return 0;
}
--
1.5.6.1
^ permalink raw reply related
* ppp/l2tp doing oversized allocations ?
From: Dave Jones @ 2012-05-14 16:29 UTC (permalink / raw)
To: netdev; +Cc: Fedora Kernel Team
We just got this trace from reported by a Fedora user running 3.3.4
:WARNING: at mm/page_alloc.c:2204 __alloc_pages_nodemask+0x231/0x8f0()
:Call Trace:
: [<ffffffff81057abf>] warn_slowpath_common+0x7f/0xc0
: [<ffffffff81057b1a>] warn_slowpath_null+0x1a/0x20
: [<ffffffff81129671>] __alloc_pages_nodemask+0x231/0x8f0
: [<ffffffff814e84db>] ? dev_queue_xmit+0x1db/0x640
: [<ffffffff8151f210>] ? ip_forward_options+0x1f0/0x1f0
: [<ffffffff814ef7a1>] ? neigh_direct_output+0x11/0x20
: [<ffffffff81520dee>] ? ip_finish_output+0x17e/0x2f0
: [<ffffffff8151f210>] ? ip_forward_options+0x1f0/0x1f0
: [<ffffffff811608d3>] alloc_pages_current+0xa3/0x110
: [<ffffffff811254b4>] __get_free_pages+0x14/0x50
: [<ffffffff8116b99f>] kmalloc_order_trace+0x3f/0xd0
: [<ffffffff8156d137>] ? xfrm4_output_finish+0x27/0x40
: [<ffffffff8116c8c7>] __kmalloc+0x177/0x1a0
: [<ffffffff81521196>] ? ip_queue_xmit+0x156/0x400
: [<ffffffff814dab07>] pskb_expand_head+0x87/0x310
: [<ffffffff8113dbf9>] ? __mod_zone_page_state+0x49/0x50
: [<ffffffffa05e84dd>] pppol2tp_xmit+0x1ed/0x220 [l2tp_ppp]
: [<ffffffffa05d3d5b>] ppp_push+0x15b/0x650 [ppp_generic]
: [<ffffffff814dacc4>] ? pskb_expand_head+0x244/0x310
: [<ffffffff811285ab>] ? free_compound_page+0x1b/0x20
: [<ffffffff8112cff3>] ? __put_compound_page+0x23/0x30
: [<ffffffff8112d175>] ? put_compound_page+0x125/0x1c0
: [<ffffffffa05d489f>] ppp_xmit_process+0x46f/0x660 [ppp_generic]
: [<ffffffffa05d4bc8>] ppp_start_xmit+0x138/0x1d0 [ppp_generic]
: [<ffffffff814e7f62>] dev_hard_start_xmit+0x332/0x6d0
: [<ffffffff81503e2a>] sch_direct_xmit+0xfa/0x1d0
: [<ffffffff81503fa6>] __qdisc_run+0xa6/0x130
: [<ffffffff814e84be>] dev_queue_xmit+0x1be/0x640
: [<ffffffff8151f210>] ? ip_forward_options+0x1f0/0x1f0
: [<ffffffff814ef7a1>] neigh_direct_output+0x11/0x20
: [<ffffffff81520dee>] ip_finish_output+0x17e/0x2f0
: [<ffffffff81521906>] ip_output+0x66/0xa0
: [<ffffffff81521002>] ? __ip_local_out+0xa2/0xb0
: [<ffffffff815792ae>] xfrm_output_resume+0x38e/0x3f0
: [<ffffffff8116c0db>] ? kfree+0x3b/0x150
: [<ffffffff81297a10>] ? cryptd_free+0x60/0x60
: [<ffffffffa04fc110>] esp_output_done+0x30/0x40 [esp4]
: [<ffffffffa05ed774>] authenc_request_complete+0x14/0x20 [authenc]
: [<ffffffffa05ede4e>] crypto_authenc_givencrypt_done+0x2e/0x40 [authenc]
: [<ffffffff8129728c>] cryptd_blkcipher_crypt+0x5c/0x70
: [<ffffffff812972dc>] cryptd_blkcipher_encrypt+0x1c/0x20
: [<ffffffff81297a66>] cryptd_queue_worker+0x56/0x80
: [<ffffffff810747ae>] process_one_work+0x11e/0x470
: [<ffffffff810755bf>] worker_thread+0x15f/0x360
: [<ffffffff81075460>] ? manage_workers+0x230/0x230
: [<ffffffff81079da3>] kthread+0x93/0xa0
: [<ffffffff815fd2a4>] kernel_thread_helper+0x4/0x10
: [<ffffffff81079d10>] ? kthread_freezable_should_stop+0x70/0x70
: [<ffffffff815fd2a0>] ? gs_change+0x13/0x13
That WARN statement is this in the page allocator..
2197 /*
2198 * In the slowpath, we sanity check order to avoid ever trying to
2199 * reclaim >= MAX_ORDER areas which will never succeed. Callers may
2200 * be using allocators in order of preference for an area that is
2201 * too large.
2202 */
2203 if (order >= MAX_ORDER) {
2204 WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
2205 return NULL;
2206 }
Dave
^ 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