* Re: [PATCH net-next] sfc: make function tables const
From: David Miller @ 2011-04-15 4:55 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, shodgson, linux-net-drivers, netdev
In-Reply-To: <1302799038.2853.5.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 14 Apr 2011 17:37:18 +0100
> On Thu, 2011-04-14 at 08:50 -0700, Stephen Hemminger wrote:
>> The phy, mac, and board information structures should be const.
>
> efx_nic_type actually holds information and function pointers about
> different generations of the controller, not different boards.
>
>> Since tables contain function pointer this improves security
>> (at least theoretically).
>>
>> Compile tested only.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] net-bonding: Fix minor sparse complaints
From: David Miller @ 2011-04-15 5:03 UTC (permalink / raw)
To: decot; +Cc: fubar, andy, netdev, linux-kernel
In-Reply-To: <1302744151-12452-1-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Wed, 13 Apr 2011 18:22:29 -0700
> This gets rid of minor sparse complaints:
> drivers/net/bonding/bond_main.c:4361:4: warning: do-while statement is not a compound statement
> drivers/net/bonding/bond_main.c:243:12: warning: symbol 'bond_mode_name' was not declared. Should it be static?
>
> Signed-off-by: David Decotigny <decot@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] net-bonding: Fix minor/cosmetic type inconsistencies
From: David Miller @ 2011-04-15 5:04 UTC (permalink / raw)
To: decot; +Cc: fubar, andy, netdev, linux-kernel
In-Reply-To: <1302744151-12452-2-git-send-email-decot@google.com>
aFrom: David Decotigny <decot@google.com>
Date: Wed, 13 Apr 2011 18:22:30 -0700
> The __get_link_speed() function returns a u16 value which was stored
> in a u32 local variable. This patch uses the return value directly,
> thus fixing that minor type consistency.
>
> The 'duplex' field in struct slave being encoded on 8 bits, to be more
> consistent we use a u8 integer (instead of u16) whenever we copy it to
> local variables.
>
> Signed-off-by: David Decotigny <decot@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] net-bonding: Adding support for throughputs larger than 65536 Mbps
From: David Miller @ 2011-04-15 5:04 UTC (permalink / raw)
To: decot; +Cc: fubar, andy, netdev, linux-kernel
In-Reply-To: <1302744151-12452-3-git-send-email-decot@google.com>
From: David Decotigny <decot@google.com>
Date: Wed, 13 Apr 2011 18:22:31 -0700
> This updates the bonding driver to support v2.6.27-rc3 enhancements
> (b11f8d8c aka. "ethtool: Expand ethtool_cmd.speed to 32 bits") which
> allow to encode the Mbps link speed on 32-bits (Max 4 Pbps) instead of
> 16 (Max 65536 Mbps).
>
> This patch also attempts to compact struct slave by reordering its
> fields.
>
> Signed-off-by: David Decotigny <decot@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] rndis_host: Quirky devices are still 'point-to-point'
From: David Miller @ 2011-04-15 6:24 UTC (permalink / raw)
To: ben; +Cc: netdev
In-Reply-To: <1302785461.5282.686.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Thu, 14 Apr 2011 13:51:01 +0100
> My changes in commit 4d42d417be75d750b82798922b6e775915e11bce were
> written some time before the introduction of FLAG_POINTTOPOINT, so
> didn't include that flag in the new driver_info. Change the new
> driver_info to be consistent.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied, thanks Ben.
^ permalink raw reply
* Re: [PATCH v2] ip: ip_options_compile() resilient to NULL skb route
From: David Miller @ 2011-04-15 6:26 UTC (permalink / raw)
To: shimoda.hiroaki; +Cc: eric.dumazet, shemminger, lkml, netdev
In-Reply-To: <20110415082022.b5e50f9b.shimoda.hiroaki@gmail.com>
From: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Date: Fri, 15 Apr 2011 08:20:22 +0900
> On Thu, 14 Apr 2011 17:55:37 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Scot Doyle demonstrated ip_options_compile() could be called with an skb
>> without an attached route, using a setup involving a bridge, netfilter,
>> and forged IP packets.
>>
>> Let's make ip_options_compile() and ip_options_rcv_srr() a bit more
>> robust, instead of changing bridge/netfilter code.
>>
>> With help from Hiroaki SHIMODA.
>>
>> Reported-by: Scot Doyle <lkml@scotdoyle.com>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Stephen Hemminger <shemminger@vyatta.com>
>> Cc: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
> Acked-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [RFC] ethtool: remove phys_id from ethtool_ops
From: David Miller @ 2011-04-15 6:46 UTC (permalink / raw)
To: shemminger; +Cc: bhutchings, netdev
In-Reply-To: <20110408170830.3ab079e8@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 8 Apr 2011 17:08:30 -0700
> Hold this patch until after the Intel and Qlogic driver
> changes are merged into net-next. Patches have been submitted
> but still waiting for vendor.
>
> After that all the upstream kernel drivers now use phys_id,
> and the old ethtool_ops interface (phys_id) can be removed.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Since everything is now merged, I've applied this.
Thanks!
^ permalink raw reply
* Re: [RFC] ethtool: remove phys_id from ethtool_ops
From: David Miller @ 2011-04-15 6:57 UTC (permalink / raw)
To: shemminger; +Cc: bhutchings, netdev
In-Reply-To: <20110414.234654.71103337.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 14 Apr 2011 23:46:54 -0700 (PDT)
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Fri, 8 Apr 2011 17:08:30 -0700
>
>> Hold this patch until after the Intel and Qlogic driver
>> changes are merged into net-next. Patches have been submitted
>> but still waiting for vendor.
>>
>> After that all the upstream kernel drivers now use phys_id,
>> and the old ethtool_ops interface (phys_id) can be removed.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Since everything is now merged, I've applied this.
Actually, it seems we're not ready yet, e1000 still refers
to phys_id.
Can someone take care of this?
^ permalink raw reply
* unregister_netdevice: waiting for lo to become free. Usage count = 8
From: Hans Schillstrom @ 2011-04-15 7:01 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Simon Horman, netdev, lvs-devel, Eric W. Biederman
Hello Julian
I'm trying to fix the cleanup process when a namespace get "killed",
which is a new feature for ipvs. However an old problem appears again
When there has been traffic trough ipvs where the destination is unreachable
the usage count on loopback dev increases one for every packet....
I guess thats because of this rule :
# ip route list table all
...
unreachable default dev lo table 0 proto kernel metric 4294967295 error -101 hoplimit 25
...
I made a test just forwarding packets through the same container (ipvs loaded)
to an unreachable destination and that test had a balanced count i.e. it was possible to reboot the container.
Do you have an idea why this happens in the ipvs case ?
Regards
Hans Schillstrom <hans@schillstrom.com>
^ permalink raw reply
* Re: unregister_netdevice: waiting for lo to become free. Usage count = 8
From: Eric W. Biederman @ 2011-04-15 7:27 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: Julian Anastasov, Simon Horman, netdev, lvs-devel
In-Reply-To: <201104150901.47214.hans@schillstrom.com>
Hans Schillstrom <hans@schillstrom.com> writes:
> Hello Julian
>
> I'm trying to fix the cleanup process when a namespace get "killed",
> which is a new feature for ipvs. However an old problem appears again
>
> When there has been traffic trough ipvs where the destination is unreachable
> the usage count on loopback dev increases one for every packet....
> I guess thats because of this rule :
>
> # ip route list table all
> ...
> unreachable default dev lo table 0 proto kernel metric 4294967295 error -101 hoplimit 25
> ...
>
> I made a test just forwarding packets through the same container (ipvs loaded)
> to an unreachable destination and that test had a balanced count i.e. it was possible to reboot the container.
>
> Do you have an idea why this happens in the ipvs case ?
Hans. I do know that most outstanding references when you clean up a
container get moved to the loopback device. So it may not originally
be the loopback device itself where the reference counting is wrong.
Eric
^ permalink raw reply
* Confirmation
From: Western Union Money Transfer @ 2011-04-15 6:27 UTC (permalink / raw)
You have a money transfer of $85,000. Confirm receipt via e-mail:
wudept11@w.cn
________________________________________________________________
Message sent using Telaen Webmail 1.1.3
^ permalink raw reply
* oops during unregister_netdevice interface enslaved to bond - regression
From: Frank Blaschka @ 2011-04-15 8:53 UTC (permalink / raw)
To: netdev, linux-s390, opurdila, davem, fubar
Hi Octavian,
your commit 443457242beb6716b43db4d62fe148eab5515505 introduced this regression.
I have reviewed the net device unregister code but did not understand it very well.
I have seen the problem only in combination with bonding. Can you give me some help
how to go on with this problem. I can reproduced it very easy on a single CPU
machine.
Frank
The test is:
1) enslave netdevice to a bond
2) close the netdevice
3) hot unplug the netdevice
<1>[27649.970474] Unable to handle kernel pointer dereference at virtual kernel address (null)
<4>[27649.970477] Oops: 0004 [#1] SMP
<4>[27649.970479] Modules linked in: bonding sunrpc qeth_l2 qeth_l3 binfmt_misc dm_multipath scsi_dh dm_mod ipv6 lcs qeth c
cwgroup [last unloaded: scsi_wait_scan]
<4>[27649.970488] CPU: 0 Tainted: G W 2.6.39-rc2.48.x.20110407-s390xgit #1
<4>[27649.970490] Process kworker/u:1 (pid: 25, task: 000000007ec4c838, ksp: 000000007ec535a8)
<4>[27649.970493] Krnl PSW : 0704100180000000 000000000055444e (klist_put+0x46/0xd4)
<4>[27649.970498] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
<4>[27649.970501] Krnl GPRS: 0000000000000410 07000000ffffffff 0000000000000000 0000000000000001
<4>[27649.970504] 00000000003e57c6 0000000000000001 000000007bac3d30 000000007bad5005
<4>[27649.970507] 000000007a2bb000 0000000000000000 0000000000000001 0000000000000000
<4>[27649.970509] 000000007d3f2c28 00000000005c1230 000000007ec53a98 000000007ec53a58
<4>[27649.970518] Krnl Code: 0000000000554440: 5710d000 x %r1,0(%r13)
<4>[27649.970521] 0000000000554444: e3b090200004 lg %r11,32(%r9)
<4>[27649.970524] 000000000055444a: a7280000 lhi %r2,0
<4>[27649.970528] >000000000055444e: ba219000 cs %r2,%r1,0(%r9)
<4>[27649.970531] 0000000000554452: 1222 ltr %r2,%r2
<4>[27649.970534] 0000000000554454: a774003c brc 7,5544cc
<4>[27649.970537] 0000000000554458: b90200aa ltgr %r10,%r10
<4>[27649.970540] 000000000055445c: a784000e brc 8,554478
<4>[27649.970542] Call Trace:
<4>[27649.970543] ([<000000000058a848>] bin_vm_ops+0x28/0xe8)
<4>[27649.970548] [<00000000003e57de>] device_del+0x7e/0x1d0
<4>[27649.970551] [<00000000004af858>] rollback_registered_many+0x1ac/0x268
<4>[27649.970554] [<00000000004af9f2>] rollback_registered+0x52/0x74
<4>[27649.970556] [<00000000004afa9e>] unregister_netdevice_queue+0x8a/0xe0
<4>[27649.970559] [<00000000004afc40>] unregister_netdev+0x34/0x40
<4>[27649.970562] [<000003c001a74cfc>] qeth_l2_remove_device+0xf8/0x120 [qeth_l2]
<4>[27649.970566] [<000003c003d87040>] qeth_core_remove_device+0x94/0x180 [qeth]
<4>[27649.970572] [<000003c00124c83e>] ccwgroup_remove+0x66/0x74 [ccwgroup]
<4>[27649.970575] [<00000000003e8d24>] __device_release_driver+0x7c/0xec
<4>[27649.970578] [<00000000003e8dcc>] device_release_driver+0x38/0x48
<4>[27649.970581] [<00000000003e87ee>] bus_remove_device+0xca/0xf4
<4>[27649.970584] [<00000000003e58b0>] device_del+0x150/0x1d0
<4>[27649.970587] [<00000000003e5956>] device_unregister+0x26/0x38
<4>[27649.970589] [<000003c00124c7bc>] ccwgroup_ungroup_callback+0x5c/0x78 [ccwgroup]
<4>[27649.970592] [<00000000002a3ca0>] sysfs_schedule_callback_work+0x38/0xa8
<4>[27649.970595] [<000000000015d1c6>] process_one_work+0x176/0x428
<4>[27649.970598] [<0000000000160ec2>] worker_thread+0x17a/0x398
<4>[27649.970601] [<0000000000166e2a>] kthread+0xa6/0xb0
<4>[27649.970603] [<00000000005614de>] kernel_thread_starter+0x6/0xc
<4>[27649.970606] [<00000000005614d8>] kernel_thread_starter+0x0/0xc
<4>[27649.970609] Last Breaking-Event-Address:
<4>[27649.970610] [<0000000000554538>] klist_del+0x4/0xc
<4>[27649.970613]
<0>[27649.970614] Kernel panic - not syncing: Fatal exception: panic_on_oops
<4>[27649.970617] CPU: 0 Tainted: G D W 2.6.39-rc2.48.x.20110407-s390xgit #1
<4>[27649.970619] Process kworker/u:1 (pid: 25, task: 000000007ec4c838, ksp: 000000007ec535a8)
<4>[27649.970622] 000000007ec53700 000000007ec53680 0000000000000002 0000000000000000
<4>[27649.970625] 000000007ec53720 000000007ec53698 000000007ec53698 000000000055ddae
<4>[27649.970629] 0000000000000001 0000000000000000 000000007bad5005 0000000000100ebe
<4>[27649.970632] 000000000000000d 000000000000000c 000000007ec536e8 0000000000000000
<4>[27649.970636] 0000000000000000 0000000000100a00 000000007ec53680 000000007ec536c0
<4>[27649.970640] Call Trace:
<4>[27649.970641] ([<0000000000882408>] die_lock+0x0/0x4)
I bisect the problem down to 2.6.38 development. Commit introduced the problem is:
commit 443457242beb6716b43db4d62fe148eab5515505
Author: Octavian Purdila <opurdila@ixiacom.com>
Date: Mon Dec 13 12:44:07 2010 +0000
net: factorize sync-rcu call in unregister_netdevice_many
Add dev_close_many and dev_deactivate_many to factorize another
sync-rcu operation on the netdevice unregister path.
$ modprobe dummy numdummies=10000
$ ip link set dev dummy* up
$ time rmmod dummy
Without the patch With the patch
real 0m 24.63s real 0m 5.15s
user 0m 0.00s user 0m 0.00s
sys 0m 6.05s sys 0m 5.14s
I don't know if this commit is bad or if it exposes a problem in the bonding code.
^ permalink raw reply
* Re: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Peter Zijlstra @ 2011-04-15 8:57 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexander Duyck, Wei Gu, netdev, Kirsher, Jeffrey T,
Mike Galbraith, Thomas Gleixner
In-Reply-To: <1302800221.3248.39.camel@edumazet-laptop>
On Thu, 2011-04-14 at 18:57 +0200, Eric Dumazet wrote:
> Le jeudi 14 avril 2011 à 18:56 +0200, Peter Zijlstra a écrit :
> > On Thu, 2011-04-14 at 09:42 -0700, Alexander Duyck wrote:
> >
> > > I'm doing some more digging into this now. One thought that occurred to
> > > me is that if the patch you mention is having some sort of effect this
> > > could be a sign of perhaps a kernel timer or scheduling problem.
> >
> > Right, so the removal of the NO_HZ throttle will allow the CPU to go
> > into C states more often, this could result in longer wake-up times for
> > IRQs.
> >
> > We reverted because:
> > - it caused significant battery drain due to not going into C states
> > often enough, and
> > - its a much better idea to implement these things in the idle
> > governor since it already has the job of guestimating the idle
> > duration.
> >
> > I really can't remember back far enough to even come up with a theory of
> > why kernels prior to merging the NO_HZ throttle would not exhibit this
> > problem.
> >
> >
> >
>
> Normally, Wei Gu already asked to not use C states.
>
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01804533/c01804533.pdf
>
> How can we/he check this ?
Not quite sure, I think powertop has something that measures C-state
usage, but if the BIOS is lying to us (pretty good bet since he's using
HP crap^W) there's nothing much we can do about that.
Another thing that could be causing pain in NO_HZ transitions is if
we're having to switch to timer broadcast mode when we go into NO_HZ,
I'm not sure if HP systems are affected by this, nor am I exactly sure
which DL580 he's got.
^ permalink raw reply
* Re: [RFC] ethtool: remove phys_id from ethtool_ops
From: Jeff Kirsher @ 2011-04-15 9:08 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, bhutchings, netdev
In-Reply-To: <20110414.235736.104051922.davem@davemloft.net>
On Thu, Apr 14, 2011 at 23:57, David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 14 Apr 2011 23:46:54 -0700 (PDT)
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Fri, 8 Apr 2011 17:08:30 -0700
>>
>>> Hold this patch until after the Intel and Qlogic driver
>>> changes are merged into net-next. Patches have been submitted
>>> but still waiting for vendor.
>>>
>>> After that all the upstream kernel drivers now use phys_id,
>>> and the old ethtool_ops interface (phys_id) can be removed.
>>>
>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> Since everything is now merged, I've applied this.
>
> Actually, it seems we're not ready yet, e1000 still refers
> to phys_id.
>
> Can someone take care of this?
I know that most of our drivers still refer to phys_id, with Bruce's
recent patches to ethtool, we can finish up fixing the patches against
the Intel drivers. I will make every effort to have patches to you by
Monday/Tuesday.
--
Cheers,
Jeff
^ permalink raw reply
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Wei Gu @ 2011-04-15 9:14 UTC (permalink / raw)
To: Peter Zijlstra, Eric Dumazet
Cc: Alexander Duyck, netdev, Kirsher, Jeffrey T, Mike Galbraith,
Thomas Gleixner
In-Reply-To: <1302857857.2388.158.camel@twins>
Hi,
Is there something that I can provide in order to identify the problem?
-----Original Message-----
From: Peter Zijlstra [mailto:a.p.zijlstra@chello.nl]
Sent: Friday, April 15, 2011 4:58 PM
To: Eric Dumazet
Cc: Alexander Duyck; Wei Gu; netdev; Kirsher, Jeffrey T; Mike Galbraith; Thomas Gleixner
Subject: Re: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
On Thu, 2011-04-14 at 18:57 +0200, Eric Dumazet wrote:
> Le jeudi 14 avril 2011 à 18:56 +0200, Peter Zijlstra a écrit :
> > On Thu, 2011-04-14 at 09:42 -0700, Alexander Duyck wrote:
> >
> > > I'm doing some more digging into this now. One thought that
> > > occurred to me is that if the patch you mention is having some
> > > sort of effect this could be a sign of perhaps a kernel timer or scheduling problem.
> >
> > Right, so the removal of the NO_HZ throttle will allow the CPU to go
> > into C states more often, this could result in longer wake-up times
> > for IRQs.
> >
> > We reverted because:
> > - it caused significant battery drain due to not going into C states
> > often enough, and
> > - its a much better idea to implement these things in the idle
> > governor since it already has the job of guestimating the idle
> > duration.
> >
> > I really can't remember back far enough to even come up with a
> > theory of why kernels prior to merging the NO_HZ throttle would not
> > exhibit this problem.
> >
> >
> >
>
> Normally, Wei Gu already asked to not use C states.
>
> http://h20000.www2.hp.com/bc/docs/support/SupportManual/c01804533/c018
> 04533.pdf
>
> How can we/he check this ?
Not quite sure, I think powertop has something that measures C-state usage, but if the BIOS is lying to us (pretty good bet since he's using HP crap^W) there's nothing much we can do about that.
Another thing that could be causing pain in NO_HZ transitions is if we're having to switch to timer broadcast mode when we go into NO_HZ, I'm not sure if HP systems are affected by this, nor am I exactly sure which DL580 he's got.
^ permalink raw reply
* Re: [PATCH 08/12] netvm: Allow skb allocation to use PFMEMALLOC reserves
From: Mel Gorman @ 2011-04-15 10:44 UTC (permalink / raw)
To: David Miller; +Cc: linux-mm, netdev, linux-kernel, a.p.zijlstra
In-Reply-To: <20110414.143335.104052252.davem@davemloft.net>
On Thu, Apr 14, 2011 at 02:33:35PM -0700, David Miller wrote:
> From: Mel Gorman <mgorman@suse.de>
> Date: Thu, 14 Apr 2011 11:41:34 +0100
>
> > +extern int memalloc_socks;
> > +static inline int sk_memalloc_socks(void)
> > +{
> > + return memalloc_socks;
> > +}
> > +
> ...
> > +static DEFINE_MUTEX(memalloc_socks_lock);
> > +int memalloc_socks __read_mostly;
>
> Please use an atomic_t, it has to be more efficient than this mutex
> business.
Will fix.
Thanks.
--
Mel Gorman
SUSE Labs
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference at 000002c0 / IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
From: Simon Arlott @ 2011-04-15 11:30 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev
In-Reply-To: <4DA77AE5.9060501@simon.arlott.org.uk>
On Thu, April 14, 2011 23:53, Simon Arlott wrote:
> [19258502.086131] BUG: unable to handle kernel paging request at 676e7543
> [19258502.087007] IP: [<c04d89a7>] icmpv6_send+0x5c3/0x6e2
This happened again in a different part of icmpv6_send:
[31890.810491] BUG: unable to handle kernel NULL pointer dereference at 000002c0
[31890.814522] IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
[31890.814522] *pdpt = 00000000160fb001 *pde = 0000000000000000
[31890.814522] Oops: 0002 [#1] PREEMPT SMP
[31890.814522] last sysfs file: /sys/devices/platform/it87.552/cpu0_vid
[31890.814522] Modules linked in: xt_tcpmss xt_length xt_TCPMSS ppp_synctty sch_sfq xt_u32 xt_CLASSIFY
sch_htb ppp_async bnep nfsd lockd sunrpc rfcomm l2cap crc16 exportfs nf_conntrack_ipv6 xt_state ip6t_LOG ipm
[31890.889345]
[31890.889345] Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.35.4-git+ #git+ GA-MA69VM-S2/GA-MA69VM-S2
[31890.889345] EIP: 0060:[<c04c70f2>] EFLAGS: 00010246 CPU: 0
[31890.917900] EIP is at in6_dev_finish_destroy+0x35/0x8c
[31890.917900] EAX: 00000009 EBX: d6997fa3 ECX: c0513fcd EDX: 00000000
[31890.917900] ESI: 00000000 EDI: f7483bd4 EBP: f7483b40 ESP: f7483b38
[31890.917900] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[31890.917900] Process ksoftirqd/0 (pid: 3, ti=f7482000 task=f74800a0 task.ti=f7482000)
[31890.917900] Stack:
[31890.917900] d6997fa3 00000159 f7483c4c c04d8a8b efb86cc0 c067f614 f7483b58 c067f614
[31890.917900] <0> f7483b68 c0513fe0 0021c090 0021c086 f7483b88 c022e74d 00000046 0101ff2f
[31890.917900] <0> ef87e04c 00000151 f6e1fac0 f6e1fdb4 ef87e05c 00000000 00000040 f6e1faf0
[31890.917900] Call Trace:
[31890.917900] [<c04d8a8b>] ? icmpv6_send+0x6a7/0x6e2
[31890.917900] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
[31890.917900] [<c022e74d>] ? release_console_sem+0x197/0x1c4
[31890.917900] [<fa7ab0b5>] ? reject_tg6+0x70/0x43f [ip6t_REJECT]
[31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
[31890.917900] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
[31890.917900] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
[31890.917900] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
[31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
[31890.917900] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
[31890.917900] [<fa6987c1>] ? ip6t_do_table+0x4c8/0x53e [ip6_tables]
[31890.917900] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
[31890.917900] [<fa6a3018>] ? ip6table_filter_hook+0x18/0x20 [ip6table_filter]
[31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
[31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
[31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31890.917900] [<c04c44d6>] ? ip6_input+0x33/0x47
[31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31890.917900] [<c04c4775>] ? ip6_rcv_finish+0x8b/0x8e
[31890.917900] [<fc22aa3a>] ? nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
[31890.917900] [<fc22a45c>] ? ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
[31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
[31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
[31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31890.917900] [<c04c4aff>] ? ipv6_rcv+0x387/0x47c
[31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31890.917900] [<c0455065>] ? __netif_receive_skb+0x367/0x3b6
[31890.917900] [<c0455142>] ? process_backlog+0x8e/0x146
[31890.917900] [<c0455c3b>] ? net_rx_action+0x62/0x119
[31890.917900] [<c0232750>] ? __do_softirq+0x8b/0x10a
[31890.917900] [<c02327fa>] ? do_softirq+0x2b/0x43
[31890.917900] [<c0232885>] ? run_ksoftirqd+0x73/0x155
[31890.917900] [<c0232812>] ? run_ksoftirqd+0x0/0x155
[31890.917900] [<c023fdbd>] ? kthread+0x61/0x66
[31890.917900] [<c023fd5c>] ? kthread+0x0/0x66
[31890.917900] [<c0202c7a>] ? kernel_thread_helper+0x6/0x1a
[31890.917900] Code: 40 04 39 43 04 74 0f ba 45 01 00 00 b8 7a a1 63 c0 e8 32 70 d6 ff 83 7b 0c 00 74 0f ba
46 01 00 00 b8 7a a1 63 c0 e8 1d 70 d6 ff <f0> ff 8e c0 02 00 00 83 bb e4 00 00 00 00 75 0f 53 68 b5 a
[31890.917900] EIP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c SS:ESP 0068:f7483b38
[31890.917900] CR2: 00000000000002c0
[31891.236446] ---[ end trace 830bf5b3286acea0 ]---
[31891.241375] Kernel panic - not syncing: Fatal exception in interrupt
[31891.248085] Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.35.4-git+ #git+
[31891.255918] Call Trace:
[31891.258474] [<c0511194>] ? printk+0xf/0x13
[31891.262911] [<c0511116>] panic+0x55/0xc4
[31891.267130] [<c02050ed>] oops_end+0x6e/0x7c
[31891.271619] [<c021a514>] no_context+0x13f/0x149
[31891.276496] [<c021a657>] __bad_area_nosemaphore+0x139/0x141
[31891.282461] [<c0207360>] ? native_sched_clock+0x42/0x8d
[31891.288090] [<c024468d>] ? sched_clock_local+0x17/0x104
[31891.293699] [<c021a66c>] bad_area_nosemaphore+0xd/0x10
[31891.299206] [<c021a910>] do_page_fault+0x14e/0x302
[31891.304356] [<c0205311>] ? show_trace+0x10/0x14
[31891.309219] [<c05110b7>] ? dump_stack+0x57/0x61
[31891.314102] [<c021a7c2>] ? do_page_fault+0x0/0x302
[31891.319236] [<c051499b>] error_code+0x6b/0x70
[31891.323934] [<c0513fcd>] ? _raw_spin_unlock_irqrestore+0x2f/0x58
[31891.330370] [<c021a7c2>] ? do_page_fault+0x0/0x302
[31891.335536] [<c04c70f2>] ? in6_dev_finish_destroy+0x35/0x8c
[31891.341512] [<c04d8a8b>] icmpv6_send+0x6a7/0x6e2
[31891.346471] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
[31891.352853] [<c022e74d>] ? release_console_sem+0x197/0x1c4
[31891.358740] [<fa7ab0b5>] reject_tg6+0x70/0x43f [ip6t_REJECT]
[31891.364821] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
[31891.371340] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
[31891.376604] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
[31891.382205] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
[31891.387945] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
[31891.394444] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
[31891.400896] [<fa6987c1>] ip6t_do_table+0x4c8/0x53e [ip6_tables]
[31891.407260] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
[31891.414819] [<fa6a3018>] ip6table_filter_hook+0x18/0x20 [ip6table_filter]
[31891.422118] [<c046ee87>] nf_iterate+0x2f/0x62
[31891.426800] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31891.432267] [<c046f088>] nf_hook_slow+0x63/0xeb
[31891.437147] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31891.442583] [<c04c44d6>] ip6_input+0x33/0x47
[31891.447195] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
[31891.452608] [<c04c4775>] ip6_rcv_finish+0x8b/0x8e
[31891.457655] [<fc22aa3a>] nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
[31891.464929] [<fc22a45c>] ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
[31891.471561] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31891.476693] [<c046ee87>] nf_iterate+0x2f/0x62
[31891.481377] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31891.486501] [<c046f088>] nf_hook_slow+0x63/0xeb
[31891.491383] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31891.496501] [<c04c4aff>] ipv6_rcv+0x387/0x47c
[31891.501227] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
[31891.506394] [<c0455065>] __netif_receive_skb+0x367/0x3b6
[31891.512081] [<c0455142>] process_backlog+0x8e/0x146
[31891.517328] [<c0455c3b>] net_rx_action+0x62/0x119
[31891.522402] [<c0232750>] __do_softirq+0x8b/0x10a
[31891.527386] [<c02327fa>] do_softirq+0x2b/0x43
[31891.532078] [<c0232885>] run_ksoftirqd+0x73/0x155
[31891.537136] [<c0232812>] ? run_ksoftirqd+0x0/0x155
[31891.542294] [<c023fdbd>] kthread+0x61/0x66
[31891.546708] [<c023fd5c>] ? kthread+0x0/0x66
[31891.551211] [<c0202c7a>] kernel_thread_helper+0x6/0x1a
[31891.556747] Rebooting in 10 seconds..
--
Simon Arlott
^ permalink raw reply
* [PATCH] minor cleanup to net_namespace.c.
From: Rob Landley @ 2011-04-15 12:26 UTC (permalink / raw)
To: linux-kernel, netdev, jpirko, eric.dumazet
From: Rob Landley <rlandley@parallels.com>
Inline a small static function that's only ever called from one place.
Signed-off-by: Rob Landley <rlandley@parallels.com>
---
net/core/net_namespace.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 3f86026..1abb508 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -216,11 +216,14 @@ static void net_free(struct net *net)
kmem_cache_free(net_cachep, net);
}
-static struct net *net_create(void)
+struct net *copy_net_ns(unsigned long flags, struct net *old_net)
{
struct net *net;
int rv;
+ if (!(flags & CLONE_NEWNET))
+ return get_net(old_net);
+
net = net_alloc();
if (!net)
return ERR_PTR(-ENOMEM);
@@ -239,13 +242,6 @@ static struct net *net_create(void)
return net;
}
-struct net *copy_net_ns(unsigned long flags, struct net *old_net)
-{
- if (!(flags & CLONE_NEWNET))
- return get_net(old_net);
- return net_create();
-}
-
static DEFINE_SPINLOCK(cleanup_list_lock);
static LIST_HEAD(cleanup_list); /* Must hold cleanup_list_lock to touch */
^ permalink raw reply related
* Re: [PATCH] minor cleanup to net_namespace.c.
From: Jiri Pirko @ 2011-04-15 12:37 UTC (permalink / raw)
To: Rob Landley; +Cc: linux-kernel, netdev, eric.dumazet
In-Reply-To: <4DA83971.7010903@parallels.com>
Fri, Apr 15, 2011 at 02:26:25PM CEST, rlandley@parallels.com wrote:
>From: Rob Landley <rlandley@parallels.com>
>
>Inline a small static function that's only ever called from one place.
>
>Signed-off-by: Rob Landley <rlandley@parallels.com>
>---
>
> net/core/net_namespace.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
>diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>index 3f86026..1abb508 100644
>--- a/net/core/net_namespace.c
>+++ b/net/core/net_namespace.c
>@@ -216,11 +216,14 @@ static void net_free(struct net *net)
> kmem_cache_free(net_cachep, net);
> }
>
>-static struct net *net_create(void)
>+struct net *copy_net_ns(unsigned long flags, struct net *old_net)
> {
> struct net *net;
> int rv;
>
>+ if (!(flags & CLONE_NEWNET))
>+ return get_net(old_net);
>+
> net = net_alloc();
> if (!net)
> return ERR_PTR(-ENOMEM);
>@@ -239,13 +242,6 @@ static struct net *net_create(void)
> return net;
> }
>
>-struct net *copy_net_ns(unsigned long flags, struct net *old_net)
>-{
>- if (!(flags & CLONE_NEWNET))
>- return get_net(old_net);
>- return net_create();
>-}
>-
> static DEFINE_SPINLOCK(cleanup_list_lock);
> static LIST_HEAD(cleanup_list); /* Must hold cleanup_list_lock to touch */
>
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
^ permalink raw reply
* usbnet with NAPI
From: Michael Riesch @ 2011-04-15 13:05 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Habidere,
it looks like the usbnet (on which asix.c bases -> I am still working
on the driver for the Asix AX88172A[1]) does not use NAPI. It
processes the data it receives via netif_rx(). The NAPI way would be
netif_receive_skb in a poll function. Now I would like to check
whether the incoming packets are PTP status frames. My problem is that
skb_defer_rx_timestamp (the PTP check is executed there -
net/core/timestamping.c) is called by netif_receive_skb, but it is not
called by netif_rx(). So the crude hack would be to call
skb_defer_rx_timestamp from the netif_rx() in usbnet.
(It caused the whole system to hang after a few minutes of operation,
so I declared it crude. Haven't found the exact reason for this
behaviour, though...)
The nicer way would probably be enabling usbnet to use NAPI. Now:
- Is or was there some thinking about usbnet going NAPI? In case of
the latter, what was the reason that it was not done? (I could not
find any discussion about that topic)
- Do you see problems doing so? I have read some documentation about
NAPI [2], the requirements seem to be a DMA ring and the ability to
turn off interrupts/events that send packets up the stack.
- Who is going to maintain usbnet in the future?
Looking forward to your comments/ideas,
Michael
[1] http://marc.info/?l=linux-netdev&m=130167000017199&w=2
[2] http://www.linuxfoundation.org/collaborate/workgroups/networking/napi
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 000002c0 / IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
From: Eric Dumazet @ 2011-04-15 13:09 UTC (permalink / raw)
To: Simon Arlott
Cc: Linux Kernel Mailing List, netdev,
Netfilter Development Mailinglist
In-Reply-To: <0b5f315dd0f6e8eefabbd8b38b1d43e181fdd728@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid>
Le vendredi 15 avril 2011 à 12:30 +0100, Simon Arlott a écrit :
> On Thu, April 14, 2011 23:53, Simon Arlott wrote:
> > [19258502.086131] BUG: unable to handle kernel paging request at 676e7543
> > [19258502.087007] IP: [<c04d89a7>] icmpv6_send+0x5c3/0x6e2
>
CC netfilter-devel
> This happened again in a different part of icmpv6_send:
>
> [31890.810491] BUG: unable to handle kernel NULL pointer dereference at 000002c0
> [31890.814522] IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
> [31890.814522] *pdpt = 00000000160fb001 *pde = 0000000000000000
> [31890.814522] Oops: 0002 [#1] PREEMPT SMP
> [31890.814522] last sysfs file: /sys/devices/platform/it87.552/cpu0_vid
> [31890.814522] Modules linked in: xt_tcpmss xt_length xt_TCPMSS ppp_synctty sch_sfq xt_u32 xt_CLASSIFY
> sch_htb ppp_async bnep nfsd lockd sunrpc rfcomm l2cap crc16 exportfs nf_conntrack_ipv6 xt_state ip6t_LOG ipm
> [31890.889345]
> [31890.889345] Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.35.4-git+ #git+ GA-MA69VM-S2/GA-MA69VM-S2
> [31890.889345] EIP: 0060:[<c04c70f2>] EFLAGS: 00010246 CPU: 0
> [31890.917900] EIP is at in6_dev_finish_destroy+0x35/0x8c
> [31890.917900] EAX: 00000009 EBX: d6997fa3 ECX: c0513fcd EDX: 00000000
> [31890.917900] ESI: 00000000 EDI: f7483bd4 EBP: f7483b40 ESP: f7483b38
> [31890.917900] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> [31890.917900] Process ksoftirqd/0 (pid: 3, ti=f7482000 task=f74800a0 task.ti=f7482000)
> [31890.917900] Stack:
> [31890.917900] d6997fa3 00000159 f7483c4c c04d8a8b efb86cc0 c067f614 f7483b58 c067f614
> [31890.917900] <0> f7483b68 c0513fe0 0021c090 0021c086 f7483b88 c022e74d 00000046 0101ff2f
> [31890.917900] <0> ef87e04c 00000151 f6e1fac0 f6e1fdb4 ef87e05c 00000000 00000040 f6e1faf0
> [31890.917900] Call Trace:
> [31890.917900] [<c04d8a8b>] ? icmpv6_send+0x6a7/0x6e2
> [31890.917900] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
> [31890.917900] [<c022e74d>] ? release_console_sem+0x197/0x1c4
> [31890.917900] [<fa7ab0b5>] ? reject_tg6+0x70/0x43f [ip6t_REJECT]
> [31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> [31890.917900] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
> [31890.917900] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
> [31890.917900] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
> [31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> [31890.917900] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
> [31890.917900] [<fa6987c1>] ? ip6t_do_table+0x4c8/0x53e [ip6_tables]
> [31890.917900] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
> [31890.917900] [<fa6a3018>] ? ip6table_filter_hook+0x18/0x20 [ip6table_filter]
> [31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
> [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
> [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31890.917900] [<c04c44d6>] ? ip6_input+0x33/0x47
> [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31890.917900] [<c04c4775>] ? ip6_rcv_finish+0x8b/0x8e
> [31890.917900] [<fc22aa3a>] ? nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
> [31890.917900] [<fc22a45c>] ? ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
> [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
> [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
> [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31890.917900] [<c04c4aff>] ? ipv6_rcv+0x387/0x47c
> [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31890.917900] [<c0455065>] ? __netif_receive_skb+0x367/0x3b6
> [31890.917900] [<c0455142>] ? process_backlog+0x8e/0x146
> [31890.917900] [<c0455c3b>] ? net_rx_action+0x62/0x119
> [31890.917900] [<c0232750>] ? __do_softirq+0x8b/0x10a
> [31890.917900] [<c02327fa>] ? do_softirq+0x2b/0x43
> [31890.917900] [<c0232885>] ? run_ksoftirqd+0x73/0x155
> [31890.917900] [<c0232812>] ? run_ksoftirqd+0x0/0x155
> [31890.917900] [<c023fdbd>] ? kthread+0x61/0x66
> [31890.917900] [<c023fd5c>] ? kthread+0x0/0x66
> [31890.917900] [<c0202c7a>] ? kernel_thread_helper+0x6/0x1a
> [31890.917900] Code: 40 04 39 43 04 74 0f ba 45 01 00 00 b8 7a a1 63 c0 e8 32 70 d6 ff 83 7b 0c 00 74 0f ba
> 46 01 00 00 b8 7a a1 63 c0 e8 1d 70 d6 ff <f0> ff 8e c0 02 00 00 83 bb e4 00 00 00 00 75 0f 53 68 b5 a
> [31890.917900] EIP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c SS:ESP 0068:f7483b38
> [31890.917900] CR2: 00000000000002c0
> [31891.236446] ---[ end trace 830bf5b3286acea0 ]---
> [31891.241375] Kernel panic - not syncing: Fatal exception in interrupt
> [31891.248085] Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.35.4-git+ #git+
> [31891.255918] Call Trace:
> [31891.258474] [<c0511194>] ? printk+0xf/0x13
> [31891.262911] [<c0511116>] panic+0x55/0xc4
> [31891.267130] [<c02050ed>] oops_end+0x6e/0x7c
> [31891.271619] [<c021a514>] no_context+0x13f/0x149
> [31891.276496] [<c021a657>] __bad_area_nosemaphore+0x139/0x141
> [31891.282461] [<c0207360>] ? native_sched_clock+0x42/0x8d
> [31891.288090] [<c024468d>] ? sched_clock_local+0x17/0x104
> [31891.293699] [<c021a66c>] bad_area_nosemaphore+0xd/0x10
> [31891.299206] [<c021a910>] do_page_fault+0x14e/0x302
> [31891.304356] [<c0205311>] ? show_trace+0x10/0x14
> [31891.309219] [<c05110b7>] ? dump_stack+0x57/0x61
> [31891.314102] [<c021a7c2>] ? do_page_fault+0x0/0x302
> [31891.319236] [<c051499b>] error_code+0x6b/0x70
> [31891.323934] [<c0513fcd>] ? _raw_spin_unlock_irqrestore+0x2f/0x58
> [31891.330370] [<c021a7c2>] ? do_page_fault+0x0/0x302
> [31891.335536] [<c04c70f2>] ? in6_dev_finish_destroy+0x35/0x8c
> [31891.341512] [<c04d8a8b>] icmpv6_send+0x6a7/0x6e2
> [31891.346471] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
> [31891.352853] [<c022e74d>] ? release_console_sem+0x197/0x1c4
> [31891.358740] [<fa7ab0b5>] reject_tg6+0x70/0x43f [ip6t_REJECT]
> [31891.364821] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> [31891.371340] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
> [31891.376604] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
> [31891.382205] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
> [31891.387945] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> [31891.394444] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
> [31891.400896] [<fa6987c1>] ip6t_do_table+0x4c8/0x53e [ip6_tables]
> [31891.407260] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
> [31891.414819] [<fa6a3018>] ip6table_filter_hook+0x18/0x20 [ip6table_filter]
> [31891.422118] [<c046ee87>] nf_iterate+0x2f/0x62
> [31891.426800] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31891.432267] [<c046f088>] nf_hook_slow+0x63/0xeb
> [31891.437147] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31891.442583] [<c04c44d6>] ip6_input+0x33/0x47
> [31891.447195] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> [31891.452608] [<c04c4775>] ip6_rcv_finish+0x8b/0x8e
> [31891.457655] [<fc22aa3a>] nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
> [31891.464929] [<fc22a45c>] ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
> [31891.471561] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31891.476693] [<c046ee87>] nf_iterate+0x2f/0x62
> [31891.481377] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31891.486501] [<c046f088>] nf_hook_slow+0x63/0xeb
> [31891.491383] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31891.496501] [<c04c4aff>] ipv6_rcv+0x387/0x47c
> [31891.501227] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> [31891.506394] [<c0455065>] __netif_receive_skb+0x367/0x3b6
> [31891.512081] [<c0455142>] process_backlog+0x8e/0x146
> [31891.517328] [<c0455c3b>] net_rx_action+0x62/0x119
> [31891.522402] [<c0232750>] __do_softirq+0x8b/0x10a
> [31891.527386] [<c02327fa>] do_softirq+0x2b/0x43
> [31891.532078] [<c0232885>] run_ksoftirqd+0x73/0x155
> [31891.537136] [<c0232812>] ? run_ksoftirqd+0x0/0x155
> [31891.542294] [<c023fdbd>] kthread+0x61/0x66
> [31891.546708] [<c023fd5c>] ? kthread+0x0/0x66
> [31891.551211] [<c0202c7a>] kernel_thread_helper+0x6/0x1a
> [31891.556747] Rebooting in 10 seconds..
>
Hmm... net/ipv6/netfilter/nf_conntrack_reasm.c happily keep references
to devices, on queued skb (so can escape RCU read side section)
Maybe try following patch ?
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 0857272..57f158e 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -582,6 +582,7 @@ struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb, u32 user)
spin_unlock_bh(&fq->q.lock);
fq_put(fq);
+ ret_skb->dev = dev;
return ret_skb;
ret_orig:
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: BUG: unable to handle kernel NULL pointer dereference at 000002c0 / IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
From: Eric Dumazet @ 2011-04-15 13:24 UTC (permalink / raw)
To: Simon Arlott
Cc: Linux Kernel Mailing List, netdev,
Netfilter Development Mailinglist
In-Reply-To: <1302872983.3613.10.camel@edumazet-laptop>
Le vendredi 15 avril 2011 à 15:09 +0200, Eric Dumazet a écrit :
> Le vendredi 15 avril 2011 à 12:30 +0100, Simon Arlott a écrit :
> > On Thu, April 14, 2011 23:53, Simon Arlott wrote:
> > > [19258502.086131] BUG: unable to handle kernel paging request at 676e7543
> > > [19258502.087007] IP: [<c04d89a7>] icmpv6_send+0x5c3/0x6e2
> >
>
> CC netfilter-devel
>
> > This happened again in a different part of icmpv6_send:
> >
> > [31890.810491] BUG: unable to handle kernel NULL pointer dereference at 000002c0
> > [31890.814522] IP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c
> > [31890.814522] *pdpt = 00000000160fb001 *pde = 0000000000000000
> > [31890.814522] Oops: 0002 [#1] PREEMPT SMP
> > [31890.814522] last sysfs file: /sys/devices/platform/it87.552/cpu0_vid
> > [31890.814522] Modules linked in: xt_tcpmss xt_length xt_TCPMSS ppp_synctty sch_sfq xt_u32 xt_CLASSIFY
> > sch_htb ppp_async bnep nfsd lockd sunrpc rfcomm l2cap crc16 exportfs nf_conntrack_ipv6 xt_state ip6t_LOG ipm
> > [31890.889345]
> > [31890.889345] Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.35.4-git+ #git+ GA-MA69VM-S2/GA-MA69VM-S2
> > [31890.889345] EIP: 0060:[<c04c70f2>] EFLAGS: 00010246 CPU: 0
> > [31890.917900] EIP is at in6_dev_finish_destroy+0x35/0x8c
> > [31890.917900] EAX: 00000009 EBX: d6997fa3 ECX: c0513fcd EDX: 00000000
> > [31890.917900] ESI: 00000000 EDI: f7483bd4 EBP: f7483b40 ESP: f7483b38
> > [31890.917900] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> > [31890.917900] Process ksoftirqd/0 (pid: 3, ti=f7482000 task=f74800a0 task.ti=f7482000)
> > [31890.917900] Stack:
> > [31890.917900] d6997fa3 00000159 f7483c4c c04d8a8b efb86cc0 c067f614 f7483b58 c067f614
> > [31890.917900] <0> f7483b68 c0513fe0 0021c090 0021c086 f7483b88 c022e74d 00000046 0101ff2f
> > [31890.917900] <0> ef87e04c 00000151 f6e1fac0 f6e1fdb4 ef87e05c 00000000 00000040 f6e1faf0
> > [31890.917900] Call Trace:
> > [31890.917900] [<c04d8a8b>] ? icmpv6_send+0x6a7/0x6e2
> > [31890.917900] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
> > [31890.917900] [<c022e74d>] ? release_console_sem+0x197/0x1c4
> > [31890.917900] [<fa7ab0b5>] ? reject_tg6+0x70/0x43f [ip6t_REJECT]
> > [31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> > [31890.917900] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
> > [31890.917900] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
> > [31890.917900] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
> > [31890.917900] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> > [31890.917900] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
> > [31890.917900] [<fa6987c1>] ? ip6t_do_table+0x4c8/0x53e [ip6_tables]
> > [31890.917900] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
> > [31890.917900] [<fa6a3018>] ? ip6table_filter_hook+0x18/0x20 [ip6table_filter]
> > [31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
> > [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
> > [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31890.917900] [<c04c44d6>] ? ip6_input+0x33/0x47
> > [31890.917900] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31890.917900] [<c04c4775>] ? ip6_rcv_finish+0x8b/0x8e
> > [31890.917900] [<fc22aa3a>] ? nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
> > [31890.917900] [<fc22a45c>] ? ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
> > [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31890.917900] [<c046ee87>] ? nf_iterate+0x2f/0x62
> > [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31890.917900] [<c046f088>] ? nf_hook_slow+0x63/0xeb
> > [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31890.917900] [<c04c4aff>] ? ipv6_rcv+0x387/0x47c
> > [31890.917900] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31890.917900] [<c0455065>] ? __netif_receive_skb+0x367/0x3b6
> > [31890.917900] [<c0455142>] ? process_backlog+0x8e/0x146
> > [31890.917900] [<c0455c3b>] ? net_rx_action+0x62/0x119
> > [31890.917900] [<c0232750>] ? __do_softirq+0x8b/0x10a
> > [31890.917900] [<c02327fa>] ? do_softirq+0x2b/0x43
> > [31890.917900] [<c0232885>] ? run_ksoftirqd+0x73/0x155
> > [31890.917900] [<c0232812>] ? run_ksoftirqd+0x0/0x155
> > [31890.917900] [<c023fdbd>] ? kthread+0x61/0x66
> > [31890.917900] [<c023fd5c>] ? kthread+0x0/0x66
> > [31890.917900] [<c0202c7a>] ? kernel_thread_helper+0x6/0x1a
> > [31890.917900] Code: 40 04 39 43 04 74 0f ba 45 01 00 00 b8 7a a1 63 c0 e8 32 70 d6 ff 83 7b 0c 00 74 0f ba
> > 46 01 00 00 b8 7a a1 63 c0 e8 1d 70 d6 ff <f0> ff 8e c0 02 00 00 83 bb e4 00 00 00 00 75 0f 53 68 b5 a
> > [31890.917900] EIP: [<c04c70f2>] in6_dev_finish_destroy+0x35/0x8c SS:ESP 0068:f7483b38
> > [31890.917900] CR2: 00000000000002c0
> > [31891.236446] ---[ end trace 830bf5b3286acea0 ]---
> > [31891.241375] Kernel panic - not syncing: Fatal exception in interrupt
> > [31891.248085] Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.35.4-git+ #git+
> > [31891.255918] Call Trace:
> > [31891.258474] [<c0511194>] ? printk+0xf/0x13
> > [31891.262911] [<c0511116>] panic+0x55/0xc4
> > [31891.267130] [<c02050ed>] oops_end+0x6e/0x7c
> > [31891.271619] [<c021a514>] no_context+0x13f/0x149
> > [31891.276496] [<c021a657>] __bad_area_nosemaphore+0x139/0x141
> > [31891.282461] [<c0207360>] ? native_sched_clock+0x42/0x8d
> > [31891.288090] [<c024468d>] ? sched_clock_local+0x17/0x104
> > [31891.293699] [<c021a66c>] bad_area_nosemaphore+0xd/0x10
> > [31891.299206] [<c021a910>] do_page_fault+0x14e/0x302
> > [31891.304356] [<c0205311>] ? show_trace+0x10/0x14
> > [31891.309219] [<c05110b7>] ? dump_stack+0x57/0x61
> > [31891.314102] [<c021a7c2>] ? do_page_fault+0x0/0x302
> > [31891.319236] [<c051499b>] error_code+0x6b/0x70
> > [31891.323934] [<c0513fcd>] ? _raw_spin_unlock_irqrestore+0x2f/0x58
> > [31891.330370] [<c021a7c2>] ? do_page_fault+0x0/0x302
> > [31891.335536] [<c04c70f2>] ? in6_dev_finish_destroy+0x35/0x8c
> > [31891.341512] [<c04d8a8b>] icmpv6_send+0x6a7/0x6e2
> > [31891.346471] [<c0513fe0>] ? _raw_spin_unlock_irqrestore+0x42/0x58
> > [31891.352853] [<c022e74d>] ? release_console_sem+0x197/0x1c4
> > [31891.358740] [<fa7ab0b5>] reject_tg6+0x70/0x43f [ip6t_REJECT]
> > [31891.364821] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> > [31891.371340] [<c024e201>] ? trace_hardirqs_on+0xb/0xd
> > [31891.376604] [<c0232a72>] ? local_bh_enable_ip+0x97/0xad
> > [31891.382205] [<c0513f59>] ? _raw_spin_unlock_bh+0x2f/0x32
> > [31891.387945] [<fa7d09b1>] ? ip6t_log_packet+0x15d/0x167 [ip6t_LOG]
> > [31891.394444] [<fa6981a0>] ? ipv6_find_hdr+0xf8/0x164 [ip6_tables]
> > [31891.400896] [<fa6987c1>] ip6t_do_table+0x4c8/0x53e [ip6_tables]
> > [31891.407260] [<fa73e0f0>] ? ip6table_mangle_hook+0xf0/0x100 [ip6table_mangle]
> > [31891.414819] [<fa6a3018>] ip6table_filter_hook+0x18/0x20 [ip6table_filter]
> > [31891.422118] [<c046ee87>] nf_iterate+0x2f/0x62
> > [31891.426800] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31891.432267] [<c046f088>] nf_hook_slow+0x63/0xeb
> > [31891.437147] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31891.442583] [<c04c44d6>] ip6_input+0x33/0x47
> > [31891.447195] [<c04c40c8>] ? ip6_input_finish+0x0/0x3db
> > [31891.452608] [<c04c4775>] ip6_rcv_finish+0x8b/0x8e
> > [31891.457655] [<fc22aa3a>] nf_ct_frag6_output+0x7c/0x95 [nf_conntrack_ipv6]
> > [31891.464929] [<fc22a45c>] ipv6_defrag+0x87/0x9f [nf_conntrack_ipv6]
> > [31891.471561] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31891.476693] [<c046ee87>] nf_iterate+0x2f/0x62
> > [31891.481377] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31891.486501] [<c046f088>] nf_hook_slow+0x63/0xeb
> > [31891.491383] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31891.496501] [<c04c4aff>] ipv6_rcv+0x387/0x47c
> > [31891.501227] [<c04c46ea>] ? ip6_rcv_finish+0x0/0x8e
> > [31891.506394] [<c0455065>] __netif_receive_skb+0x367/0x3b6
> > [31891.512081] [<c0455142>] process_backlog+0x8e/0x146
> > [31891.517328] [<c0455c3b>] net_rx_action+0x62/0x119
> > [31891.522402] [<c0232750>] __do_softirq+0x8b/0x10a
> > [31891.527386] [<c02327fa>] do_softirq+0x2b/0x43
> > [31891.532078] [<c0232885>] run_ksoftirqd+0x73/0x155
> > [31891.537136] [<c0232812>] ? run_ksoftirqd+0x0/0x155
> > [31891.542294] [<c023fdbd>] kthread+0x61/0x66
> > [31891.546708] [<c023fd5c>] ? kthread+0x0/0x66
> > [31891.551211] [<c0202c7a>] kernel_thread_helper+0x6/0x1a
> > [31891.556747] Rebooting in 10 seconds..
> >
>
>
> Hmm... net/ipv6/netfilter/nf_conntrack_reasm.c happily keep references
> to devices, on queued skb (so can escape RCU read side section)
>
> Maybe try following patch ?
>
>
> diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
> index 0857272..57f158e 100644
> --- a/net/ipv6/netfilter/nf_conntrack_reasm.c
> +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
> @@ -582,6 +582,7 @@ struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb, u32 user)
> spin_unlock_bh(&fq->q.lock);
>
> fq_put(fq);
> + ret_skb->dev = dev;
> return ret_skb;
>
> ret_orig:
Hmm.. a more complete patch :
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 0857272..6f0bed0 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -582,6 +582,7 @@ struct sk_buff *nf_ct_frag6_gather(struct sk_buff *skb, u32 user)
spin_unlock_bh(&fq->q.lock);
fq_put(fq);
+ ret_skb->dev = dev;
return ret_skb;
ret_orig:
@@ -602,7 +603,7 @@ void nf_ct_frag6_output(unsigned int hooknum, struct sk_buff *skb,
s2 = s->next;
s->next = NULL;
-
+ s->dev = in;
NF_HOOK_THRESH(NFPROTO_IPV6, hooknum, s, in, out, okfn,
NF_IP6_PRI_CONNTRACK_DEFRAG + 1);
s = s2;
^ permalink raw reply related
* [PATCH] net: spider_net: convert to hw_features
From: Michał Mirosław @ 2011-04-15 14:50 UTC (permalink / raw)
To: netdev; +Cc: Ishizaki Kou, Jens Osterkamp
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/spider_net.c | 15 +++++++--------
drivers/net/spider_net.h | 7 -------
drivers/net/spider_net_ethtool.c | 21 ---------------------
3 files changed, 7 insertions(+), 36 deletions(-)
diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
index cb6bcca..949f124 100644
--- a/drivers/net/spider_net.c
+++ b/drivers/net/spider_net.c
@@ -994,15 +994,13 @@ spider_net_pass_skb_up(struct spider_net_descr *descr,
skb->protocol = eth_type_trans(skb, netdev);
/* checksum offload */
- if (card->options.rx_csum) {
+ skb_checksum_none_assert(skb);
+ if (netdev->features & NETIF_F_RXCSUM) {
if ( ( (data_status & SPIDER_NET_DATA_STATUS_CKSUM_MASK) ==
SPIDER_NET_DATA_STATUS_CKSUM_MASK) &&
!(data_error & SPIDER_NET_DATA_ERR_CKSUM_MASK))
skb->ip_summed = CHECKSUM_UNNECESSARY;
- else
- skb_checksum_none_assert(skb);
- } else
- skb_checksum_none_assert(skb);
+ }
if (data_status & SPIDER_NET_VLAN_PACKET) {
/* further enhancements: HW-accel VLAN
@@ -2322,14 +2320,15 @@ spider_net_setup_netdev(struct spider_net_card *card)
card->aneg_timer.function = spider_net_link_phy;
card->aneg_timer.data = (unsigned long) card;
- card->options.rx_csum = SPIDER_NET_RX_CSUM_DEFAULT;
-
netif_napi_add(netdev, &card->napi,
spider_net_poll, SPIDER_NET_NAPI_WEIGHT);
spider_net_setup_netdev_ops(netdev);
- netdev->features = NETIF_F_IP_CSUM | NETIF_F_LLTX;
+ netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM;
+ if (SPIDER_NET_RX_CSUM_DEFAULT)
+ netdev->features |= NETIF_F_RXCSUM;
+ netdev->features |= NETIF_F_IP_CSUM | NETIF_F_LLTX;
/* some time: NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
* NETIF_F_HW_VLAN_FILTER */
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index 05f74cb..020f64a 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -429,12 +429,6 @@ struct spider_net_descr_chain {
* 701b8000 would be correct, but every packets gets that flag */
#define SPIDER_NET_DESTROY_RX_FLAGS 0x700b8000
-/* this will be bigger some time */
-struct spider_net_options {
- int rx_csum; /* for rx: if 0 ip_summed=NONE,
- if 1 and hw has verified, ip_summed=UNNECESSARY */
-};
-
#define SPIDER_NET_DEFAULT_MSG ( NETIF_MSG_DRV | \
NETIF_MSG_PROBE | \
NETIF_MSG_LINK | \
@@ -487,7 +481,6 @@ struct spider_net_card {
/* for ethtool */
int msg_enable;
struct spider_net_extra_stats spider_stats;
- struct spider_net_options options;
/* Must be last item in struct */
struct spider_net_descr darray[0];
diff --git a/drivers/net/spider_net_ethtool.c b/drivers/net/spider_net_ethtool.c
index 5bae728..d723fca 100644
--- a/drivers/net/spider_net_ethtool.c
+++ b/drivers/net/spider_net_ethtool.c
@@ -115,24 +115,6 @@ spider_net_ethtool_nway_reset(struct net_device *netdev)
return 0;
}
-static u32
-spider_net_ethtool_get_rx_csum(struct net_device *netdev)
-{
- struct spider_net_card *card = netdev_priv(netdev);
-
- return card->options.rx_csum;
-}
-
-static int
-spider_net_ethtool_set_rx_csum(struct net_device *netdev, u32 n)
-{
- struct spider_net_card *card = netdev_priv(netdev);
-
- card->options.rx_csum = n;
- return 0;
-}
-
-
static void
spider_net_ethtool_get_ringparam(struct net_device *netdev,
struct ethtool_ringparam *ering)
@@ -189,9 +171,6 @@ const struct ethtool_ops spider_net_ethtool_ops = {
.set_msglevel = spider_net_ethtool_set_msglevel,
.get_link = ethtool_op_get_link,
.nway_reset = spider_net_ethtool_nway_reset,
- .get_rx_csum = spider_net_ethtool_get_rx_csum,
- .set_rx_csum = spider_net_ethtool_set_rx_csum,
- .set_tx_csum = ethtool_op_set_tx_csum,
.get_ringparam = spider_net_ethtool_get_ringparam,
.get_strings = spider_net_get_strings,
.get_sset_count = spider_net_get_sset_count,
--
1.7.2.5
^ permalink raw reply related
* [PATCH] net: mlx4: convert to hw_features
From: Michał Mirosław @ 2011-04-15 14:50 UTC (permalink / raw)
To: netdev; +Cc: Yevgeny Petrilin, Eli Cohen
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
BTW, MAINTAINERS entry for this driver is missing.
drivers/net/mlx4/en_ethtool.c | 42 -----------------------------------------
drivers/net/mlx4/en_netdev.c | 26 +++++++++---------------
drivers/net/mlx4/en_rx.c | 2 +-
drivers/net/mlx4/mlx4_en.h | 1 -
4 files changed, 11 insertions(+), 60 deletions(-)
diff --git a/drivers/net/mlx4/en_ethtool.c b/drivers/net/mlx4/en_ethtool.c
index d54b7ab..da1b64d 100644
--- a/drivers/net/mlx4/en_ethtool.c
+++ b/drivers/net/mlx4/en_ethtool.c
@@ -57,37 +57,6 @@ mlx4_en_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *drvinfo)
drvinfo->eedump_len = 0;
}
-static u32 mlx4_en_get_tso(struct net_device *dev)
-{
- return (dev->features & NETIF_F_TSO) != 0;
-}
-
-static int mlx4_en_set_tso(struct net_device *dev, u32 data)
-{
- struct mlx4_en_priv *priv = netdev_priv(dev);
-
- if (data) {
- if (!priv->mdev->LSO_support)
- return -EPERM;
- dev->features |= (NETIF_F_TSO | NETIF_F_TSO6);
- } else
- dev->features &= ~(NETIF_F_TSO | NETIF_F_TSO6);
- return 0;
-}
-
-static u32 mlx4_en_get_rx_csum(struct net_device *dev)
-{
- struct mlx4_en_priv *priv = netdev_priv(dev);
- return priv->rx_csum;
-}
-
-static int mlx4_en_set_rx_csum(struct net_device *dev, u32 data)
-{
- struct mlx4_en_priv *priv = netdev_priv(dev);
- priv->rx_csum = (data != 0);
- return 0;
-}
-
static const char main_strings[][ETH_GSTRING_LEN] = {
"rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors",
"tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions",
@@ -483,17 +452,7 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
.get_drvinfo = mlx4_en_get_drvinfo,
.get_settings = mlx4_en_get_settings,
.set_settings = mlx4_en_set_settings,
-#ifdef NETIF_F_TSO
- .get_tso = mlx4_en_get_tso,
- .set_tso = mlx4_en_set_tso,
-#endif
- .get_sg = ethtool_op_get_sg,
- .set_sg = ethtool_op_set_sg,
.get_link = ethtool_op_get_link,
- .get_rx_csum = mlx4_en_get_rx_csum,
- .set_rx_csum = mlx4_en_set_rx_csum,
- .get_tx_csum = ethtool_op_get_tx_csum,
- .set_tx_csum = ethtool_op_set_tx_ipv6_csum,
.get_strings = mlx4_en_get_strings,
.get_sset_count = mlx4_en_get_sset_count,
.get_ethtool_stats = mlx4_en_get_ethtool_stats,
@@ -508,7 +467,6 @@ const struct ethtool_ops mlx4_en_ethtool_ops = {
.set_pauseparam = mlx4_en_set_pauseparam,
.get_ringparam = mlx4_en_get_ringparam,
.set_ringparam = mlx4_en_set_ringparam,
- .get_flags = ethtool_op_get_flags,
};
diff --git a/drivers/net/mlx4/en_netdev.c b/drivers/net/mlx4/en_netdev.c
index 77063f9..61850ad 100644
--- a/drivers/net/mlx4/en_netdev.c
+++ b/drivers/net/mlx4/en_netdev.c
@@ -1083,7 +1083,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
priv->prof = prof;
priv->port = port;
priv->port_up = false;
- priv->rx_csum = 1;
priv->flags = prof->flags;
priv->tx_ring_num = prof->tx_ring_num;
priv->rx_ring_num = prof->rx_ring_num;
@@ -1141,21 +1140,16 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int port,
/*
* Set driver features
*/
- dev->features |= NETIF_F_SG;
- dev->vlan_features |= NETIF_F_SG;
- dev->features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
- dev->vlan_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
- dev->features |= NETIF_F_HIGHDMA;
- dev->features |= NETIF_F_HW_VLAN_TX |
- NETIF_F_HW_VLAN_RX |
- NETIF_F_HW_VLAN_FILTER;
- dev->features |= NETIF_F_GRO;
- if (mdev->LSO_support) {
- dev->features |= NETIF_F_TSO;
- dev->features |= NETIF_F_TSO6;
- dev->vlan_features |= NETIF_F_TSO;
- dev->vlan_features |= NETIF_F_TSO6;
- }
+ dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
+ if (mdev->LSO_support)
+ dev->hw_features |= NETIF_F_TSO | NETIF_F_TSO6;
+
+ dev->vlan_features = dev->hw_features;
+
+ dev->hw_features |= NETIF_F_RXCSUM;
+ dev->features = dev->hw_features | NETIF_F_HIGHDMA |
+ NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX |
+ NETIF_F_HW_VLAN_FILTER;
mdev->pndev[port] = dev;
diff --git a/drivers/net/mlx4/en_rx.c b/drivers/net/mlx4/en_rx.c
index 62dd21b..277215f 100644
--- a/drivers/net/mlx4/en_rx.c
+++ b/drivers/net/mlx4/en_rx.c
@@ -584,7 +584,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
ring->bytes += length;
ring->packets++;
- if (likely(priv->rx_csum)) {
+ if (likely(dev->features & NETIF_F_RXCSUM)) {
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
priv->port_stats.rx_chksum_good++;
diff --git a/drivers/net/mlx4/mlx4_en.h b/drivers/net/mlx4/mlx4_en.h
index e30f609..0b5150d 100644
--- a/drivers/net/mlx4/mlx4_en.h
+++ b/drivers/net/mlx4/mlx4_en.h
@@ -451,7 +451,6 @@ struct mlx4_en_priv {
int registered;
int allocated;
int stride;
- int rx_csum;
u64 mac;
int mac_index;
unsigned max_mtu;
--
1.7.2.5
^ permalink raw reply related
* [PATCH] net: myri10ge: convert to hw_features
From: Michał Mirosław @ 2011-04-15 14:50 UTC (permalink / raw)
To: netdev; +Cc: Andrew Gallatin, Brice Goglin
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/myri10ge/myri10ge.c | 66 +++++++-------------------------------
1 files changed, 12 insertions(+), 54 deletions(-)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 1446de5..a48eb92 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -205,7 +205,6 @@ struct myri10ge_priv {
int tx_boundary; /* boundary transmits cannot cross */
int num_slices;
int running; /* running? */
- int csum_flag; /* rx_csums? */
int small_bytes;
int big_bytes;
int max_intr_slots;
@@ -1386,7 +1385,7 @@ myri10ge_rx_done(struct myri10ge_slice_state *ss, int len, __wsum csum,
skb->protocol = eth_type_trans(skb, dev);
skb_record_rx_queue(skb, ss - &mgp->ss[0]);
- if (mgp->csum_flag) {
+ if (dev->features & NETIF_F_RXCSUM) {
if ((skb->protocol == htons(ETH_P_IP)) ||
(skb->protocol == htons(ETH_P_IPV6))) {
skb->csum = csum;
@@ -1757,43 +1756,6 @@ myri10ge_get_ringparam(struct net_device *netdev,
ring->tx_pending = ring->tx_max_pending;
}
-static u32 myri10ge_get_rx_csum(struct net_device *netdev)
-{
- struct myri10ge_priv *mgp = netdev_priv(netdev);
-
- if (mgp->csum_flag)
- return 1;
- else
- return 0;
-}
-
-static int myri10ge_set_rx_csum(struct net_device *netdev, u32 csum_enabled)
-{
- struct myri10ge_priv *mgp = netdev_priv(netdev);
- int err = 0;
-
- if (csum_enabled)
- mgp->csum_flag = MXGEFW_FLAGS_CKSUM;
- else {
- netdev->features &= ~NETIF_F_LRO;
- mgp->csum_flag = 0;
-
- }
- return err;
-}
-
-static int myri10ge_set_tso(struct net_device *netdev, u32 tso_enabled)
-{
- struct myri10ge_priv *mgp = netdev_priv(netdev);
- u32 flags = mgp->features & (NETIF_F_TSO6 | NETIF_F_TSO);
-
- if (tso_enabled)
- netdev->features |= flags;
- else
- netdev->features &= ~flags;
- return 0;
-}
-
static const char myri10ge_gstrings_main_stats[][ETH_GSTRING_LEN] = {
"rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors",
"tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions",
@@ -1944,11 +1906,6 @@ static u32 myri10ge_get_msglevel(struct net_device *netdev)
return mgp->msg_enable;
}
-static int myri10ge_set_flags(struct net_device *netdev, u32 value)
-{
- return ethtool_op_set_flags(netdev, value, ETH_FLAG_LRO);
-}
-
static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_settings = myri10ge_get_settings,
.get_drvinfo = myri10ge_get_drvinfo,
@@ -1957,19 +1914,12 @@ static const struct ethtool_ops myri10ge_ethtool_ops = {
.get_pauseparam = myri10ge_get_pauseparam,
.set_pauseparam = myri10ge_set_pauseparam,
.get_ringparam = myri10ge_get_ringparam,
- .get_rx_csum = myri10ge_get_rx_csum,
- .set_rx_csum = myri10ge_set_rx_csum,
- .set_tx_csum = ethtool_op_set_tx_hw_csum,
- .set_sg = ethtool_op_set_sg,
- .set_tso = myri10ge_set_tso,
.get_link = ethtool_op_get_link,
.get_strings = myri10ge_get_strings,
.get_sset_count = myri10ge_get_sset_count,
.get_ethtool_stats = myri10ge_get_ethtool_stats,
.set_msglevel = myri10ge_set_msglevel,
.get_msglevel = myri10ge_get_msglevel,
- .get_flags = ethtool_op_get_flags,
- .set_flags = myri10ge_set_flags
};
static int myri10ge_allocate_rings(struct myri10ge_slice_state *ss)
@@ -3136,6 +3086,14 @@ static int myri10ge_set_mac_address(struct net_device *dev, void *addr)
return 0;
}
+static u32 myri10ge_fix_features(struct net_device *dev, u32 features)
+{
+ if (!(features & NETIF_F_RXCSUM))
+ features &= ~NETIF_F_LRO;
+
+ return features;
+}
+
static int myri10ge_change_mtu(struct net_device *dev, int new_mtu)
{
struct myri10ge_priv *mgp = netdev_priv(dev);
@@ -3834,6 +3792,7 @@ static const struct net_device_ops myri10ge_netdev_ops = {
.ndo_get_stats = myri10ge_get_stats,
.ndo_validate_addr = eth_validate_addr,
.ndo_change_mtu = myri10ge_change_mtu,
+ .ndo_fix_features = myri10ge_fix_features,
.ndo_set_multicast_list = myri10ge_set_multicast_list,
.ndo_set_mac_address = myri10ge_set_mac_address,
};
@@ -3860,7 +3819,6 @@ static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
mgp = netdev_priv(netdev);
mgp->dev = netdev;
mgp->pdev = pdev;
- mgp->csum_flag = MXGEFW_FLAGS_CKSUM;
mgp->pause = myri10ge_flow_control;
mgp->intr_coal_delay = myri10ge_intr_coal_delay;
mgp->msg_enable = netif_msg_init(myri10ge_debug, MYRI10GE_MSG_DEFAULT);
@@ -3976,11 +3934,11 @@ static int myri10ge_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->netdev_ops = &myri10ge_netdev_ops;
netdev->mtu = myri10ge_initial_mtu;
netdev->base_addr = mgp->iomem_base;
- netdev->features = mgp->features;
+ netdev->hw_features = mgp->features | NETIF_F_LRO | NETIF_F_RXCSUM;
+ netdev->features = netdev->hw_features;
if (dac_enabled)
netdev->features |= NETIF_F_HIGHDMA;
- netdev->features |= NETIF_F_LRO;
netdev->vlan_features |= mgp->features;
if (mgp->fw_ver_tiny < 37)
--
1.7.2.5
^ 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