* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-23 1:41 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, ppc-dev, Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20110823114011.a059aea0138b75bfa7eed1ce@canb.auug.org.au>
Hi Dave,
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Here's what I am applying as a merge fixup to the net tree today so that
> > my ppc64_defconfig builds actually build more or less the same set of
> > drivers as before this rearrangement.
>
> And this today:
And this:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:35:18 +1000
Subject: [PATCH] sparc: update sparc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/configs/sparc64_defconfig | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 3c1e858..5732728 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -37,8 +37,6 @@ CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_NET_IPIP=m
-CONFIG_NET_IPGRE=m
-CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
@@ -95,17 +93,19 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_NETDEVICES=y
-CONFIG_NET_ETHERNET=y
CONFIG_MII=m
+CONFIG_NET_VENDOR_AMD=y
CONFIG_SUNLANCE=m
+CONFIG_NET_VENDOR_BROADCOM=y
+CONFIG_BNX2=m
+CONFIG_TIGON3=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E1000=m
+CONFIG_E1000E=m
+CONFIG_NET_VENDOR_SUN=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_SUNVNET=m
-CONFIG_NET_PCI=y
-CONFIG_E1000=m
-CONFIG_E1000E=m
-CONFIG_TIGON3=m
-CONFIG_BNX2=m
CONFIG_NIU=m
# CONFIG_WLAN is not set
CONFIG_PPP=m
@@ -126,13 +126,13 @@ CONFIG_INPUT_SPARCSPKR=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_RAW=m
+# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_SUNSU=y
CONFIG_SERIAL_SUNSU_CONSOLE=y
CONFIG_SERIAL_SUNSAB=y
CONFIG_SERIAL_SUNSAB_CONSOLE=y
CONFIG_SERIAL_SUNHV=y
-# CONFIG_LEGACY_PTYS is not set
CONFIG_FB=y
CONFIG_FB_TILEBLITTING=y
CONFIG_FB_SBUS=y
@@ -206,10 +206,8 @@ CONFIG_PRINTK_TIME=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KEYS=y
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 2:13 UTC (permalink / raw)
To: sfr
Cc: netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus
In-Reply-To: <20110823114129.ceb18da164bf7df3c145941b@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 23 Aug 2011 11:41:29 +1000
> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> >
>> > Here's what I am applying as a merge fixup to the net tree today so that
>> > my ppc64_defconfig builds actually build more or less the same set of
>> > drivers as before this rearrangement.
>>
>> And this today:
>
> And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig changes
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. Could you prepare a patch which does that?
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Jeff Kirsher @ 2011-08-23 2:26 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
mikey@neuling.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
benh@kernel.crashing.org, paulus@samba.org
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]
On Mon, 2011-08-22 at 19:13 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
> > On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> >
> >> > Here's what I am applying as a merge fixup to the net tree today so that
> >> > my ppc64_defconfig builds actually build more or less the same set of
> >> > drivers as before this rearrangement.
> >>
> >> And this today:
> >
> > And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig changes
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. Could you prepare a patch which does that?
>
I was just finishing up those patches (not including any defconfig
changes) and started looking at a patch to fix/resolve the issues that
Stephen is seeing.
Let me see what I can come up with tonight to resolve this.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* (3.1.0-rc2-git7) include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
From: Dave Jones @ 2011-08-23 2:44 UTC (permalink / raw)
To: netdev
Just hit this..
Is the fix as straight forward as changing that __in_dev_get_rcu to
an in_dev_get() ?
Dave
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
4 locks held by setfiles/2123:
#0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>] walk_component+0x1ef/0x3e8
#1: (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>] inode_doinit_with_dentry+0x3f/0x41f
#2: (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>] run_timer_softirq+0x157/0x372
#3: (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process+0x36/0x103
stack backtrace:
Pid: 2123, comm: setfiles Tainted: G W 3.1.0-0.rc2.git7.2.fc16.x86_64 #1
Call Trace:
<IRQ> [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf
[<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d
[<ffffffff8146a751>] arp_process+0x25/0x4d7
[<ffffffff8146ac11>] parp_redo+0xe/0x10
[<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103
[<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372
[<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372
[<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41
[<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95
[<ffffffff81062bb6>] __do_softirq+0x112/0x25a
[<ffffffff8150d27c>] call_softirq+0x1c/0x30
[<ffffffff81010bf5>] do_softirq+0x4b/0xa2
[<ffffffff81062f65>] irq_exit+0x5d/0xcf
[<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a
[<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80
<EOI> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
[<ffffffff814fc285>] ? __slab_free+0x30/0x24c
[<ffffffff814fc283>] ? __slab_free+0x2e/0x24c
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81130cb0>] kfree+0x108/0x131
[<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e
[<ffffffff81200f4f>] security_d_instantiate+0x21/0x23
[<ffffffff81154625>] d_instantiate+0x5c/0x61
[<ffffffff811563ca>] d_splice_alias+0xbc/0xd2
[<ffffffff811b17ff>] ext4_lookup+0xba/0xeb
[<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b
[<ffffffff8114cbea>] walk_component+0x215/0x3e8
[<ffffffff8114cdf8>] lookup_last+0x3b/0x3d
[<ffffffff8114daf3>] path_lookupat+0x82/0x2af
[<ffffffff8110fc53>] ? might_fault+0xa5/0xac
[<ffffffff8110fc0a>] ? might_fault+0x5c/0xac
[<ffffffff8114c564>] ? getname_flags+0x31/0x1ca
[<ffffffff8114dd48>] do_path_lookup+0x28/0x97
[<ffffffff8114df2c>] user_path_at+0x59/0x96
[<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d
[<ffffffff811469a6>] vfs_fstatat+0x44/0x6e
[<ffffffff811469ee>] vfs_lstat+0x1e/0x20
[<ffffffff81146b3d>] sys_newlstat+0x1a/0x33
[<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
[<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8150af82>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* linux-next: manual merge of the net tree with the unicore32 tree
From: Stephen Rothwell @ 2011-08-23 3:02 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Guan Xuetao, Zhang Shu, Chu Xiaowei,
Su Yonggang, Jeff Kirsher
Hi all,
Today's linux-next merge of the net tree got conflicts in
drivers/net/Kconfig and drivers/net/Makefile between commit e8787de6fa83
("unicore32: add pkunity-v3 mac/net driver (umal)") from the unicore32
tree and the network driver rearrangement from the net tree.
I just added the new driver from the unicore32 tree commit into each file
(see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ef6b6be..df5e990 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -215,6 +215,12 @@ source "drivers/s390/net/Kconfig"
source "drivers/net/caif/Kconfig"
+config MAC_PUV3
+ tristate "PKUnity v3 UMAL Gigabit Network Adapter support"
+ depends on UNICORE32 && ARCH_PUV3
+ select MII
+ select PHYLIB
+
config XEN_NETDEV_FRONTEND
tristate "Xen network device frontend driver"
depends on XEN
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index c33009b..9896ad1 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_RIONET) += rionet.o
obj-$(CONFIG_NET) += Space.o loopback.o
obj-$(CONFIG_NET_SB1000) += sb1000.o
+obj-$(CONFIG_MAC_PUV3) += mac-puv3.o
obj-$(CONFIG_PPP) += ppp_generic.o
obj-$(CONFIG_PPP_ASYNC) += ppp_async.o
obj-$(CONFIG_PPP_SYNC_TTY) += ppp_synctty.o
^ permalink raw reply related
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-08-23 3:49 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110822083613.GA18556@redhat.com>
On Mon, 22 Aug 2011 11:36:13 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> Yes. Or maybe 'WHEN' - since if MSI-X is disabled again, it moves back.
> Let's update the spec to make it clearer?
I left the language as is, but added a footnote at the end of the
sentence:
If MSI-X is enabled for the device, two additional fields immediately
follow this header:
[footnote: ie. once you enable MSI-X on the device, the other
fields move. If you turn it off again, they move back!]
Thanks,
Rusty.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Arnaud Lacombe @ 2011-08-23 3:50 UTC (permalink / raw)
To: David Miller
Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus, linux-kbuild
In-Reply-To: <20110822.191348.2099822249437201579.davem@davemloft.net>
Hi,
[Added linux-kbuild@ to the Cc: list.]
On Mon, Aug 22, 2011 at 10:13 PM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 23 Aug 2011 11:41:29 +1000
>
>> On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> >
>>> > Here's what I am applying as a merge fixup to the net tree today so that
>>> > my ppc64_defconfig builds actually build more or less the same set of
>>> > drivers as before this rearrangement.
>>>
>>> And this today:
>>
>> And this:
>
> I'm starting to get uncomfortable with this whole situation, and I
> feel more and more that these new kconfig guards are not tenable.
>
> Changing defconfig files might fix the "automated test boot with
> defconfig" case but it won't fix the case of someone trying to
> automate a build and boot using a different, existing, config file.
> It ought to work too, and I do know people really do this.
>
> And just the fact that we would have to merge all of these defconfig changes
> through the networking tree is evidence of how it's really not reasonable
> to be doing things this way.
>
> Jeff, I think we need to revert the dependencies back to what they were
> before the drivers/net moves. Could you prepare a patch which does that?
>
Are you implying we need some kind of way to migrate config ?
- Arnaud
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: David Miller @ 2011-08-23 4:02 UTC (permalink / raw)
To: lacombar
Cc: sfr, netdev, linux-next, linux-kernel, jeffrey.t.kirsher, mikey,
torvalds, akpm, linuxppc-dev, benh, paulus, linux-kbuild
In-Reply-To: <CACqU3MW4BnucRt3gxPrKPDvWEjaVuxRF1VOPWk5hTRfneyANkg@mail.gmail.com>
From: Arnaud Lacombe <lacombar@gmail.com>
Date: Mon, 22 Aug 2011 23:50:02 -0400
> Are you implying we need some kind of way to migrate config ?
The issue is that the dependencies for every single ethernet driver
have changed. Some dependencies have been dropped (f.e. NETDEV_10000
and some have been added (f.e. ETHERNET, NET_VENDOR_****)
So right now an automated (non-prompted, default to no on all new
options) run on an existing config results in all ethernet drivers
getting disabled because the new dependencies don't get enabled.
This wouldn't be so bad if it was just one or two drivers, but in
this case it's every single ethernet driver which will have and hit
this problem.
^ permalink raw reply
* Re: [net-next 03/10] ixgbe: Drop the TX work limit and instead just leave it to budget
From: Alexander Duyck @ 2011-08-23 4:04 UTC (permalink / raw)
To: David Miller
Cc: alexander.h.duyck, bhutchings, jeffrey.t.kirsher, netdev, gospo
In-Reply-To: <20110822.164027.1830363266993513959.davem@davemloft.net>
On Mon, Aug 22, 2011 at 4:40 PM, David Miller <davem@davemloft.net> wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Mon, 22 Aug 2011 15:57:51 -0700
>
>> The problem was occurring even without large rings.
>> I was seeing issues with rings just 256 descriptors in size.
>
> And the default in the ixgbe driver is 512 entries which I think
> itself is quite excessive. Something like 128 is more in line with
> what I'd call a sane default.
Are you suggesting I change the the ring size, the TX quota, or both?
> So the only side effect of your change is to decrease the TX quota to
> 64 (the default NAPI quota) from it's current value of 512
> (IXGBE_DEFAULT_TXD).
Yeah, that pretty much sums it up. However as I said in the earlier
email I am counting SKBs freed instead of descriptors. As such we
will probably end up cleaning more like 128 descriptors per TX clean
just due to our context descriptors that are also occupying space in
the ring.
> Talking about the existing code, I can't even see how the current
> driver private TX quota can trigger except in the most extreme cases.
> This is because the quota is set the same as the size you're setting
> the TX ring to.
I'm not sure if it ever met the quota either. I suspect not since
under the routing workloads I would see the RX interrupts get disabled
but the TX interrupts keep going.
>> The problem seemed to be that the TX cleanup being a multiple of
>> budget was allowing one CPU to overwhelm the other and the fact that
>> the TX was essentially unbounded was just allowing the issue to
>> feedback on itself.
>
> I still don't understand what issue you could even be running into.
>
> On each CPU we round robin against all NAPI requestors for that CPU.
>
> In your routing test setup, we should have one cpu doing the RX and
> another different cpu doing TX.
>
> Therefore if the TX cpu simply spins in a loop doing nothing but TX
> reclaim work it should not really matter.
Doing a unidirectional test was fine and everything worked as you
describe. It was doing a bidirectional test with two ports and a
single queue for each port that was the issue. Specifically what
would happen is that one direction would tend to dominate over the
other so I would end up with a 60/40 split with either upstream or
downstream dominating. By using the budget as the quota I found the
results were generally much closer to 50/50 and the overall result of
the two flows combined was higher. I suspect it had to do with TX
work getting backlogged on the ring and acting as a feedback mechanism
to prevent the RX work on that CPU from getting squashed.
> And if you hit the TX budget on the TX cpu, it's just going to come
> right back into the ixgbe NAPI handler and thus the TX reclaim
> processing not even a dozen cycles later.
>
> The only effect is to have us go through the whole function call
> sequence and data structure setup into local variables more than you
> would be doing so before.
I suppose that is possible. It all depends on the type of packets
being sent. For single sends without any offloads we would only be
cleaning 64 descriptors per call to ixgbe_poll, with an offloaded
checksum or VLAN it would be 128 descriptors per call, and with TSO we
probably still wouldn't consume the budget since the sk_buff
consumption rate would be too low.
I can try testing the throughput with pktgen tomorrow to see if it
improves by increasing the TX budget. I suppose there could be a few
factors affecting this since the budget value also determines the
number of buffers we clean before we call netif_wake_queue to
re-enable the transmit path.
>> In addition since the RX and TX workload was balanced it kept both
>> locked into polling while the CPU was saturated instead of allowing
>> the TX to become interrupt driven. In addition since the TX was
>> working on the same budget as the RX the number of SKBs freed up in
>> the TX path would match the number consumed when being reallocated
>> on the RX path.
>
> So the only conclusion I can come to is that what happens is we're now
> executing what are essentially wasted cpu cycles and this takes us
> over the threshold such that we poll more and take interrupts less.
> And this improves performance.
>
> That's pretty unwise if you ask me, we should do something useful with
> cpu cycles instead of wasting them merely to make us poll more.
The thing is we are probably going to be wasting those cycles anyway.
In the case of bidirectional routing I was always locked into RX
polling with this change in place or not. The only difference is that
the TX will likely clean itself completely with each poll versus the
possibility of leaving a few buffers behind when it hits the 64 quota.
>> The problem seemed to be present as long as I allowed the TX budget to
>> be a multiple of the RX budget. The easiest way to keep things
>> balanced and avoid allowing the TX from one CPU to overwhelm the RX on
>> another was just to keep the budgets equal.
>
> You're executing 10 or 20 cpu cycles after every 64 TX reclaims,
> that's the only effect of these changes. That's not even long enough
> for a cache line to transfer between two cpus.
It sounds like I may not have been seeing this due to the type of
workload I was focusing on. I'll try generating some data with pktgen
and netperf tomorrow to see how this holds up under small packet
transmit only traffic since those are the cases most likely to get
into the state you mention.
Also I would appreciate it if you had any suggestions on other
workloads I might need to focus on in order to determine the impact of
this change.
Thanks,
Alex
^ permalink raw reply
* Re: (3.1.0-rc2-git7) include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
From: Eric Dumazet @ 2011-08-23 5:02 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20110823024423.GA23874@redhat.com>
Le lundi 22 août 2011 à 22:44 -0400, Dave Jones a écrit :
> Just hit this..
> Is the fix as straight forward as changing that __in_dev_get_rcu to
> an in_dev_get() ?
>
> Dave
>
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 4 locks held by setfiles/2123:
> #0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>] walk_component+0x1ef/0x3e8
> #1: (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>] inode_doinit_with_dentry+0x3f/0x41f
> #2: (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>] run_timer_softirq+0x157/0x372
> #3: (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process+0x36/0x103
>
> stack backtrace:
> Pid: 2123, comm: setfiles Tainted: G W 3.1.0-0.rc2.git7.2.fc16.x86_64 #1
> Call Trace:
> <IRQ> [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf
> [<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d
> [<ffffffff8146a751>] arp_process+0x25/0x4d7
> [<ffffffff8146ac11>] parp_redo+0xe/0x10
> [<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103
> [<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372
> [<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372
> [<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41
> [<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95
> [<ffffffff81062bb6>] __do_softirq+0x112/0x25a
> [<ffffffff8150d27c>] call_softirq+0x1c/0x30
> [<ffffffff81010bf5>] do_softirq+0x4b/0xa2
> [<ffffffff81062f65>] irq_exit+0x5d/0xcf
> [<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a
> [<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80
> <EOI> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
> [<ffffffff814fc285>] ? __slab_free+0x30/0x24c
> [<ffffffff814fc283>] ? __slab_free+0x2e/0x24c
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81130cb0>] kfree+0x108/0x131
> [<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e
> [<ffffffff81200f4f>] security_d_instantiate+0x21/0x23
> [<ffffffff81154625>] d_instantiate+0x5c/0x61
> [<ffffffff811563ca>] d_splice_alias+0xbc/0xd2
> [<ffffffff811b17ff>] ext4_lookup+0xba/0xeb
> [<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b
> [<ffffffff8114cbea>] walk_component+0x215/0x3e8
> [<ffffffff8114cdf8>] lookup_last+0x3b/0x3d
> [<ffffffff8114daf3>] path_lookupat+0x82/0x2af
> [<ffffffff8110fc53>] ? might_fault+0xa5/0xac
> [<ffffffff8110fc0a>] ? might_fault+0x5c/0xac
> [<ffffffff8114c564>] ? getname_flags+0x31/0x1ca
> [<ffffffff8114dd48>] do_path_lookup+0x28/0x97
> [<ffffffff8114df2c>] user_path_at+0x59/0x96
> [<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d
> [<ffffffff811469a6>] vfs_fstatat+0x44/0x6e
> [<ffffffff811469ee>] vfs_lstat+0x1e/0x20
> [<ffffffff81146b3d>] sys_newlstat+0x1a/0x33
> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
> [<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [<ffffffff8150af82>] system_call_fastpath+0x16/0x1b
Thanks for the report Dave, I am preparing a patch to fix this.
^ permalink raw reply
* Re: (3.1.0-rc2-git7) include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
From: Eric Dumazet @ 2011-08-23 5:32 UTC (permalink / raw)
To: Dave Jones, David Miller; +Cc: netdev
In-Reply-To: <20110823024423.GA23874@redhat.com>
Le lundi 22 août 2011 à 22:44 -0400, Dave Jones a écrit :
> Just hit this..
> Is the fix as straight forward as changing that __in_dev_get_rcu to
> an in_dev_get() ?
>
> Dave
>
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 4 locks held by setfiles/2123:
> #0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>] walk_component+0x1ef/0x3e8
> #1: (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>] inode_doinit_with_dentry+0x3f/0x41f
> #2: (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>] run_timer_softirq+0x157/0x372
> #3: (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process+0x36/0x103
>
> stack backtrace:
> Pid: 2123, comm: setfiles Tainted: G W 3.1.0-0.rc2.git7.2.fc16.x86_64 #1
> Call Trace:
> <IRQ> [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf
> [<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d
> [<ffffffff8146a751>] arp_process+0x25/0x4d7
> [<ffffffff8146ac11>] parp_redo+0xe/0x10
> [<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103
> [<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372
> [<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372
> [<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41
> [<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95
> [<ffffffff81062bb6>] __do_softirq+0x112/0x25a
> [<ffffffff8150d27c>] call_softirq+0x1c/0x30
> [<ffffffff81010bf5>] do_softirq+0x4b/0xa2
> [<ffffffff81062f65>] irq_exit+0x5d/0xcf
> [<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a
> [<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80
> <EOI> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
> [<ffffffff814fc285>] ? __slab_free+0x30/0x24c
> [<ffffffff814fc283>] ? __slab_free+0x2e/0x24c
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81130cb0>] kfree+0x108/0x131
> [<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f
> [<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e
> [<ffffffff81200f4f>] security_d_instantiate+0x21/0x23
> [<ffffffff81154625>] d_instantiate+0x5c/0x61
> [<ffffffff811563ca>] d_splice_alias+0xbc/0xd2
> [<ffffffff811b17ff>] ext4_lookup+0xba/0xeb
> [<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b
> [<ffffffff8114cbea>] walk_component+0x215/0x3e8
> [<ffffffff8114cdf8>] lookup_last+0x3b/0x3d
> [<ffffffff8114daf3>] path_lookupat+0x82/0x2af
> [<ffffffff8110fc53>] ? might_fault+0xa5/0xac
> [<ffffffff8110fc0a>] ? might_fault+0x5c/0xac
> [<ffffffff8114c564>] ? getname_flags+0x31/0x1ca
> [<ffffffff8114dd48>] do_path_lookup+0x28/0x97
> [<ffffffff8114df2c>] user_path_at+0x59/0x96
> [<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d
> [<ffffffff811469a6>] vfs_fstatat+0x44/0x6e
> [<ffffffff811469ee>] vfs_lstat+0x1e/0x20
> [<ffffffff81146b3d>] sys_newlstat+0x1a/0x33
> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
> [<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [<ffffffff8150af82>] system_call_fastpath+0x16/0x1b
>
Dave, thanks again for your report, here the fix I cooked to address
this.
Kernels >= 2.6.36 are affected, probably only RT ones, since
neigh_proxy_process() holds a spinlock before the call to proxy_redo().
David, IPv6 side is affected too only in net-next, but following patch
should take care of both protocols.
Thanks
[PATCH] arp: fix rcu lockdep splat in arp_process()
Dave Jones reported a lockdep splat triggered by an arp_process() call
from parp_redo().
Commit faa9dcf793be (arp: RCU changes) is the origin of the bug, since
it assumed arp_process() was called under rcu_read_lock(), which is not
true in this particular path.
Instead of adding rcu_read_lock() in parp_redo(), I chose to add it in
neigh_proxy_process() to take care of IPv6 side too.
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/linux/inetdevice.h:209 invoked rcu_dereference_check() without
protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
4 locks held by setfiles/2123:
#0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>]
walk_component+0x1ef/0x3e8
#1: (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>]
inode_doinit_with_dentry+0x3f/0x41f
#2: (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>]
run_timer_softirq+0x157/0x372
#3: (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process
+0x36/0x103
stack backtrace:
Pid: 2123, comm: setfiles Tainted: G W
3.1.0-0.rc2.git7.2.fc16.x86_64 #1
Call Trace:
<IRQ> [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf
[<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d
[<ffffffff8146a751>] arp_process+0x25/0x4d7
[<ffffffff8146ac11>] parp_redo+0xe/0x10
[<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103
[<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372
[<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372
[<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41
[<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95
[<ffffffff81062bb6>] __do_softirq+0x112/0x25a
[<ffffffff8150d27c>] call_softirq+0x1c/0x30
[<ffffffff81010bf5>] do_softirq+0x4b/0xa2
[<ffffffff81062f65>] irq_exit+0x5d/0xcf
[<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a
[<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80
<EOI> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
[<ffffffff814fc285>] ? __slab_free+0x30/0x24c
[<ffffffff814fc283>] ? __slab_free+0x2e/0x24c
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81130cb0>] kfree+0x108/0x131
[<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f
[<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e
[<ffffffff81200f4f>] security_d_instantiate+0x21/0x23
[<ffffffff81154625>] d_instantiate+0x5c/0x61
[<ffffffff811563ca>] d_splice_alias+0xbc/0xd2
[<ffffffff811b17ff>] ext4_lookup+0xba/0xeb
[<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b
[<ffffffff8114cbea>] walk_component+0x215/0x3e8
[<ffffffff8114cdf8>] lookup_last+0x3b/0x3d
[<ffffffff8114daf3>] path_lookupat+0x82/0x2af
[<ffffffff8110fc53>] ? might_fault+0xa5/0xac
[<ffffffff8110fc0a>] ? might_fault+0x5c/0xac
[<ffffffff8114c564>] ? getname_flags+0x31/0x1ca
[<ffffffff8114dd48>] do_path_lookup+0x28/0x97
[<ffffffff8114df2c>] user_path_at+0x59/0x96
[<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d
[<ffffffff811469a6>] vfs_fstatat+0x44/0x6e
[<ffffffff811469ee>] vfs_lstat+0x1e/0x20
[<ffffffff81146b3d>] sys_newlstat+0x1a/0x33
[<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
[<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff8150af82>] system_call_fastpath+0x16/0x1b
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/neighbour.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 8fab9b0..1334d7e 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1319,11 +1319,15 @@ static void neigh_proxy_process(unsigned long arg)
if (tdif <= 0) {
struct net_device *dev = skb->dev;
+
__skb_unlink(skb, &tbl->proxy_queue);
- if (tbl->proxy_redo && netif_running(dev))
+ if (tbl->proxy_redo && netif_running(dev)) {
+ rcu_read_lock();
tbl->proxy_redo(skb);
- else
+ rcu_read_unlock();
+ } else {
kfree_skb(skb);
+ }
dev_put(dev);
} else if (!sched_next || tdif < sched_next)
^ permalink raw reply related
* [PATCH net-next 2/5] be2net: get rid of memory mapped pci-cfg space address
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314078115-8121-1-git-send-email-sathya.perla@emulex.com>
Get rid of adapter->pcicfg and its use. Use pci_config_read/write_dword()
instead.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 1 -
drivers/net/ethernet/emulex/benet/be_main.c | 27 ++++++++-------------------
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 12b5b51..868d7f4 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -298,7 +298,6 @@ struct be_adapter {
u8 __iomem *csr;
u8 __iomem *db; /* Door Bell */
- u8 __iomem *pcicfg; /* PCI config space */
struct mutex mbox_lock; /* For serializing mbox cmds to BE card */
struct be_dma_mem mbox_mem;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 09eb699..2375c0c 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -141,13 +141,15 @@ static int be_queue_alloc(struct be_adapter *adapter, struct be_queue_info *q,
static void be_intr_set(struct be_adapter *adapter, bool enable)
{
- u8 __iomem *addr = adapter->pcicfg + PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET;
- u32 reg = ioread32(addr);
- u32 enabled = reg & MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
+ u32 reg, enabled;
if (adapter->eeh_err)
return;
+ pci_read_config_dword(adapter->pdev, PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET,
+ ®);
+ enabled = reg & MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
+
if (!enabled && enable)
reg |= MEMBAR_CTRL_INT_CTRL_HOSTINTR_MASK;
else if (enabled && !enable)
@@ -155,7 +157,8 @@ static void be_intr_set(struct be_adapter *adapter, bool enable)
else
return;
- iowrite32(reg, addr);
+ pci_write_config_dword(adapter->pdev,
+ PCICFG_MEMBAR_CTRL_INT_CTRL_OFFSET, reg);
}
static void be_rxq_notify(struct be_adapter *adapter, u16 qid, u16 posted)
@@ -2951,14 +2954,12 @@ static void be_unmap_pci_bars(struct be_adapter *adapter)
iounmap(adapter->csr);
if (adapter->db)
iounmap(adapter->db);
- if (adapter->pcicfg && be_physfn(adapter))
- iounmap(adapter->pcicfg);
}
static int be_map_pci_bars(struct be_adapter *adapter)
{
u8 __iomem *addr;
- int pcicfg_reg, db_reg;
+ int db_reg;
if (lancer_chip(adapter)) {
addr = ioremap_nocache(pci_resource_start(adapter->pdev, 0),
@@ -2978,10 +2979,8 @@ static int be_map_pci_bars(struct be_adapter *adapter)
}
if (adapter->generation == BE_GEN2) {
- pcicfg_reg = 1;
db_reg = 4;
} else {
- pcicfg_reg = 0;
if (be_physfn(adapter))
db_reg = 4;
else
@@ -2993,16 +2992,6 @@ static int be_map_pci_bars(struct be_adapter *adapter)
goto pci_map_err;
adapter->db = addr;
- if (be_physfn(adapter)) {
- addr = ioremap_nocache(
- pci_resource_start(adapter->pdev, pcicfg_reg),
- pci_resource_len(adapter->pdev, pcicfg_reg));
- if (addr == NULL)
- goto pci_map_err;
- adapter->pcicfg = addr;
- } else
- adapter->pcicfg = adapter->db + SRIOV_VF_PCICFG_OFFSET;
-
return 0;
pci_map_err:
be_unmap_pci_bars(adapter);
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 0/5] be2net fixes v2
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
Incorporated Eric's feedback on [3/5] be2net: fix erx->rx_drops_no_frags wrap around
Pls apply. Thanks.
Sathya Perla (5):
be2net: Fix race in posting rx buffers.
be2net: get rid of memory mapped pci-cfg space address
be2net: fix erx->rx_drops_no_frags wrap around
be2net: increase FW update completion timeout
be2net: remove unused variable
drivers/net/ethernet/emulex/benet/be.h | 2 -
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 51 +++++++++++++++------------
3 files changed, 29 insertions(+), 26 deletions(-)
--
1.7.4
^ permalink raw reply
* [PATCH net-next 1/5] be2net: Fix race in posting rx buffers.
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314078115-8121-1-git-send-email-sathya.perla@emulex.com>
There is a possibility of be_post_rx_frags() being called simultaneously from
both be_worker() (when rx_post_starved) and be_poll_rx() (when rxq->used is 0).
This can be avoided by posting rx buffers only when some completions have been
reaped.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index ef62594..09eb699 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1862,7 +1862,7 @@ loop_continue:
}
/* Refill the queue */
- if (atomic_read(&rxo->q.used) < RX_FRAGS_REFILL_WM)
+ if (work_done && atomic_read(&rxo->q.used) < RX_FRAGS_REFILL_WM)
be_post_rx_frags(rxo, GFP_ATOMIC);
/* All consumed */
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 3/5] be2net: fix erx->rx_drops_no_frags wrap around
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314078115-8121-1-git-send-email-sathya.perla@emulex.com>
The rx_drops_no_frags HW counter for RSS rings is 16bits in HW and can
wraparound often. Maintain a 32-bit accumulator in the driver to prevent
frequent wraparound.
Also, incorporated Eric's feedback to use ACCESS_ONCE() for the accumulator
write.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2375c0c..fb2eda0 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -378,6 +378,18 @@ static void populate_lancer_stats(struct be_adapter *adapter)
pport_stats->rx_drops_too_many_frags_lo;
}
+static void accumulate_16bit_val(u32 *acc, u16 val)
+{
+#define lo(x) (x & 0xFFFF)
+#define hi(x) (x & 0xFFFF0000)
+ bool wrapped = val < lo(*acc);
+ u32 newacc = hi(*acc) + val;
+
+ if (wrapped)
+ newacc += 65536;
+ ACCESS_ONCE(*acc) = newacc;
+}
+
void be_parse_stats(struct be_adapter *adapter)
{
struct be_erx_stats_v1 *erx = be_erx_stats_from_cmd(adapter);
@@ -394,9 +406,13 @@ void be_parse_stats(struct be_adapter *adapter)
}
/* as erx_v1 is longer than v0, ok to use v1 defn for v0 access */
- for_all_rx_queues(adapter, rxo, i)
- rx_stats(rxo)->rx_drops_no_frags =
- erx->rx_drops_no_fragments[rxo->q.id];
+ for_all_rx_queues(adapter, rxo, i) {
+ /* below erx HW counter can actually wrap around after
+ * 65535. Driver accumulates a 32-bit value
+ */
+ accumulate_16bit_val(&rx_stats(rxo)->rx_drops_no_frags,
+ (u16)erx->rx_drops_no_fragments[rxo->q.id]);
+ }
}
static struct rtnl_link_stats64 *be_get_stats64(struct net_device *netdev,
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 4/5] be2net: increase FW update completion timeout
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314078115-8121-1-git-send-email-sathya.perla@emulex.com>
Flashing some of the PHYs can take longer thus increasing the total flash
update time to a max of 40s.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index bec039d..bebeee6 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1939,7 +1939,7 @@ int be_cmd_write_flashrom(struct be_adapter *adapter, struct be_dma_mem *cmd,
spin_unlock_bh(&adapter->mcc_lock);
if (!wait_for_completion_timeout(&adapter->flash_compl,
- msecs_to_jiffies(12000)))
+ msecs_to_jiffies(40000)))
status = -1;
else
status = adapter->flash_status;
--
1.7.4
^ permalink raw reply related
* [PATCH net-next 5/5] be2net: remove unused variable
From: Sathya Perla @ 2011-08-23 5:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1314078115-8121-1-git-send-email-sathya.perla@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 868d7f4..c5f0516 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -347,7 +347,6 @@ struct be_adapter {
u32 beacon_state; /* for set_phys_id */
bool eeh_err;
- bool link_up;
u32 port_num;
bool promiscuous;
bool wol;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: Julian Anastasov @ 2011-08-23 6:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
In-Reply-To: <20110820082048.GA15169@gondor.apana.org.au>
Hello,
On Sat, 20 Aug 2011, Herbert Xu wrote:
> On Fri, Aug 19, 2011 at 03:43:54AM -0700, David Miller wrote:
> > From: Julian Anastasov <ja@ssi.bg>
> > Date: Mon, 15 Aug 2011 19:21:23 +0300 (EEST)
> >
> > >
> > > May be there is one more case that we can avoid using
> > > non-local source for ICMP errors: xfrm_lookup, num_xfrms = 0 when
> > > reverse "Flow passes untransformed". Avoid using the input route
> > > if xfrm_lookup returns same dst.
> > >
> > > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > > ---
> > >
> > > In fact, should we use local IP in all cases when
> > > sending ICMP? I'm asking it for the following case:
> > >
> > > Large packet is forwarded but is rejected with ICMP FRAG
> > > NEEDED. We usually send ICMP with local saddr instead of the
> > > original non-local destination. What is the role of
> > > this reverse check? May be after xfrm_decode_session_reverse
> > > we should use 'fl4_dec.saddr = fl4->saddr;' so that xfrm_lookup
> > > works with ICMP from local IP? What is right thing to do here?
> > > I don't see code that looks in the embedded header...
> >
> > Well.. this relookup behavior is guided by a special transform state
> > XFRM_STATE_ICMP that the user must explicitly create IPSEC rules for.
> >
> > Presumably they are going to add real transforms to such special IPSEC
> > rules, not create NOP ones with no transforms. And if they do create
> > such IPSEC state with no transforms, perhaps the intention is to trigger
> > to use of the non-local source.
> >
> > The whole thing revolves around how Herbert envisions people implementing
> > RFC4301 support using this new XFRM_STATE_ICMP thing.
> >
> > Right?
I see, RFC 4301 prescribes reverse check for ICMP errors
to reuse SA as a fallback mechanism. Even if we send ICMP packet via
some tunnel to the previous secure gateway, shouldn't the ICMP
receiver prefer to see our local IP as ICMP sender?
> The intention of XFRM_STATE_ICMP is to automatically allow inbound
> IPsec-protected ICMP packets (remember that IPsec tunnels are not
> automatically allowed, as that opens room for address spoofing).
>
> Imagine if you have a policy P that allows IPsec packets with inner
> addresses going from S to D. The purpose of this is to ensure that
> ICMP packets from D to S are automatically allowed.
OK, thanks for the information! I don't have setup for
further tests, I hope things still work somehow, even if we
fallback to unprotected ICMP with non-local source which was
the only concern for me. I think, using local IP for ICMP packets
is preferred to help firewalling.
I just notice that if original packet (say TCP) hits
"fwd" policy, for the locally generated ICMP error we call
xfrm_lookup with sk = NULL and it always uses "out" dir
for the flow_cache_lookup call to search for this reverse SA.
So, we must be prepared with rules in "out" dir even for
the forwarding case? icmp flag in "fwd" rules is not considered?
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next 3/5] be2net: fix erx->rx_drops_no_frags wrap around
From: Eric Dumazet @ 2011-08-23 6:41 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <1314078115-8121-4-git-send-email-sathya.perla@emulex.com>
Le mardi 23 août 2011 à 11:11 +0530, Sathya Perla a écrit :
> The rx_drops_no_frags HW counter for RSS rings is 16bits in HW and can
> wraparound often. Maintain a 32-bit accumulator in the driver to prevent
> frequent wraparound.
>
> Also, incorporated Eric's feedback to use ACCESS_ONCE() for the accumulator
> write.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 22 +++++++++++++++++++---
> 1 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 2375c0c..fb2eda0 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -378,6 +378,18 @@ static void populate_lancer_stats(struct be_adapter *adapter)
> pport_stats->rx_drops_too_many_frags_lo;
> }
>
> +static void accumulate_16bit_val(u32 *acc, u16 val)
> +{
> +#define lo(x) (x & 0xFFFF)
> +#define hi(x) (x & 0xFFFF0000)
> + bool wrapped = val < lo(*acc);
> + u32 newacc = hi(*acc) + val;
> +
> + if (wrapped)
> + newacc += 65536;
> + ACCESS_ONCE(*acc) = newacc;
> +}
> +
I still feel something is wrong here :
> void be_parse_stats(struct be_adapter *adapter)
> {
> struct be_erx_stats_v1 *erx = be_erx_stats_from_cmd(adapter);
> @@ -394,9 +406,13 @@ void be_parse_stats(struct be_adapter *adapter)
> }
>
> /* as erx_v1 is longer than v0, ok to use v1 defn for v0 access */
> - for_all_rx_queues(adapter, rxo, i)
> - rx_stats(rxo)->rx_drops_no_frags =
> - erx->rx_drops_no_fragments[rxo->q.id];
previous code was not doing a sum_of_all_queues.
It only gave the final erx->rx_drops_no_fragments[rxo->q.id], not taking
into account previous rx_stats(rxo)->rx_drops_no_frags value.
Your changelog is about wrap around, while the bug might have be
different (No real sum)
Now you say : previous value is meaningfull, and we add to it 16bits
values.
> + for_all_rx_queues(adapter, rxo, i) {
> + /* below erx HW counter can actually wrap around after
> + * 65535. Driver accumulates a 32-bit value
> + */
> + accumulate_16bit_val(&rx_stats(rxo)->rx_drops_no_frags,
> + (u16)erx->rx_drops_no_fragments[rxo->q.id]);
> + }
> }
>
Arent multiple calls to be_parse_stats() will have wrong final
rx_drops_no_frags value ?
Or are the rx_drops_no_fragments[rxo->q.id] cleared when read ?
I am afraid that if HW maintains 16bit values, then the only way is to
also have a 16bit accumulator. You cannot detect wraparounds without
also keeping a copy of previous 16bit samples.
u16 accum = 0;
or_all_rx_queues(adapter, rxo, i) {
accum += erx->rx_drops_no_fragments[rxo->q.id];
}
rx_stats(rxo)->rx_drops_no_frags = accum;
^ permalink raw reply
* Re: [PATCH net-next] ipv4: one more case for non-local saddr in ICMP
From: Herbert Xu @ 2011-08-23 6:46 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David Miller, netdev
In-Reply-To: <alpine.LFD.2.00.1108230845510.1565@ja.ssi.bg>
On Tue, Aug 23, 2011 at 09:34:45AM +0300, Julian Anastasov wrote:
>
> I just notice that if original packet (say TCP) hits
> "fwd" policy, for the locally generated ICMP error we call
> xfrm_lookup with sk = NULL and it always uses "out" dir
> for the flow_cache_lookup call to search for this reverse SA.
> So, we must be prepared with rules in "out" dir even for
> the forwarding case? icmp flag in "fwd" rules is not considered?
This is a common question about our IPsec stack. Both fwd
and in are used for ingress, with the only difference being
whether the packet is locally destined or not. Only out is
used for egress traffic.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] net/phy: fix DP83865 phy interrupt handler
From: Giuseppe CAVALLARO @ 2011-08-23 7:07 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro, Thorsten Schubert
According to the DP83865 datasheet we need to clear
the interrupt status bit by writing a 1 to the
corresponding bit in INT_CLEAR (2:0 are reserved).
Proposed and tested by Thorsten.
Signed-off-by: Thorsten Schubert <tshu@msc-ge.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/phy/national.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/national.c b/drivers/net/phy/national.c
index 0620ba9..04bb8fc 100644
--- a/drivers/net/phy/national.c
+++ b/drivers/net/phy/national.c
@@ -25,8 +25,9 @@
/* DP83865 phy identifier values */
#define DP83865_PHY_ID 0x20005c7a
-#define DP83865_INT_MASK_REG 0x15
-#define DP83865_INT_MASK_STATUS 0x14
+#define DP83865_INT_STATUS 0x14
+#define DP83865_INT_MASK 0x15
+#define DP83865_INT_CLEAR 0x17
#define DP83865_INT_REMOTE_FAULT 0x0008
#define DP83865_INT_ANE_COMPLETED 0x0010
@@ -68,21 +69,25 @@ static int ns_config_intr(struct phy_device *phydev)
int err;
if (phydev->interrupts == PHY_INTERRUPT_ENABLED)
- err = phy_write(phydev, DP83865_INT_MASK_REG,
+ err = phy_write(phydev, DP83865_INT_MASK,
DP83865_INT_MASK_DEFAULT);
else
- err = phy_write(phydev, DP83865_INT_MASK_REG, 0);
+ err = phy_write(phydev, DP83865_INT_MASK, 0);
return err;
}
static int ns_ack_interrupt(struct phy_device *phydev)
{
- int ret = phy_read(phydev, DP83865_INT_MASK_STATUS);
+ int ret = phy_read(phydev, DP83865_INT_STATUS);
if (ret < 0)
return ret;
- return 0;
+ /* Clear the interrupt status bit by writing a “1”
+ * to the corresponding bit in INT_CLEAR (2:0 are reserved) */
+ ret = phy_write(phydev, DP83865_INT_CLEAR, ret & ~0x7);
+
+ return ret;
}
static void ns_giga_speed_fallback(struct phy_device *phydev, int mode)
--
1.7.4.4
^ permalink raw reply related
* RE: [PATCH net-next 3/5] be2net: fix erx->rx_drops_no_frags wrap around
From: Sathya.Perla @ 2011-08-23 7:06 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1314081677.4791.28.camel@edumazet-laptop>
>-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Tuesday, August 23, 2011 12:11 PM
>
>Le mardi 23 août 2011 à 11:11 +0530, Sathya Perla a écrit :
>> The rx_drops_no_frags HW counter for RSS rings is 16bits in HW and can
>> wraparound often. Maintain a 32-bit accumulator in the driver to prevent
>> frequent wraparound.
>>
>> Also, incorporated Eric's feedback to use ACCESS_ONCE() for the
>accumulator
>> write.
<...>
>>
>> +static void accumulate_16bit_val(u32 *acc, u16 val)
>> +{
>> +#define lo(x) (x & 0xFFFF)
>> +#define hi(x) (x & 0xFFFF0000)
>> + bool wrapped = val < lo(*acc);
>> + u32 newacc = hi(*acc) + val;
>> +
>> + if (wrapped)
>> + newacc += 65536;
>> + ACCESS_ONCE(*acc) = newacc;
>> +}
>> +
>
>I still feel something is wrong here :
>
>> void be_parse_stats(struct be_adapter *adapter)
>> {
>> struct be_erx_stats_v1 *erx = be_erx_stats_from_cmd(adapter);
>> @@ -394,9 +406,13 @@ void be_parse_stats(struct be_adapter *adapter)
>> }
>>
>> /* as erx_v1 is longer than v0, ok to use v1 defn for v0 access */
>> - for_all_rx_queues(adapter, rxo, i)
>> - rx_stats(rxo)->rx_drops_no_frags =
>> - erx->rx_drops_no_fragments[rxo->q.id];
>
>previous code was not doing a sum_of_all_queues.
Yes, the new code still *does not* do a sum of all queues. The code just
parses per-queue stats. For each queue, the 16 bit
HW stats value is taken and stored in a 32-bit *per-queue* variable.
The comment that "driver accumulates a 32-bit val" may be misleading. The
code here is not doing a sum of the per-queue stat.
+ for_all_rx_queues(adapter, rxo, i) {
+ /* below erx HW counter can actually wrap around after
+ * 65535. Driver accumulates a 32-bit value
+ */
+ accumulate_16bit_val(&rx_stats(rxo)->rx_drops_no_frags,
+ (u16)erx->rx_drops_no_fragments[rxo->q.id]);
+ }
>
>It only gave the final erx->rx_drops_no_fragments[rxo->q.id], not taking
>into account previous rx_stats(rxo)->rx_drops_no_frags value.
>
>Your changelog is about wrap around, while the bug might have be
>different (No real sum)
>
>Now you say : previous value is meaningfull, and we add to it 16bits
>values.
>
>> + for_all_rx_queues(adapter, rxo, i) {
>> + /* below erx HW counter can actually wrap around after
>> + * 65535. Driver accumulates a 32-bit value
>> + */
>> + accumulate_16bit_val(&rx_stats(rxo)->rx_drops_no_frags,
>> + (u16)erx->rx_drops_no_fragments[rxo->q.id]);
>> + }
>> }
>>
>
>Arent multiple calls to be_parse_stats() will have wrong final
>rx_drops_no_frags value ?
>
>Or are the rx_drops_no_fragments[rxo->q.id] cleared when read ?
The following logic should take care of that:
u32 newacc = hi(*acc) + val;
Only the upper 16 bits of the accumulator are retained and the new-val
of the 16-bit stat is used for the lower 16 bits. So, even if I call this
routine 10 times with the same value for val, the accumulator value will not change.
Say: accumulator is 0x00010001
Say: new 16-bit hw counter value is now 2 (it was previously 1 and had wraped-aroud before that)
accumulate(acc, 2) ==> newacc = 0x00010000 + 2 = 0x00010002
any number of calls to accumulate(acc, 2) will still produce acc = 0x00010002
>
>I am afraid that if HW maintains 16bit values, then the only way is to
>also have a 16bit accumulator. You cannot detect wraparounds without
>also keeping a copy of previous 16bit samples.
I don't agree:
Say: accumulator is 0x0000FFFF
Say: new 16-bit hw counter value is now 0 (after a wrap-aroud)
accumulate(acc, 0) ==> newacc = 0x00000000 + 0 = 0x00000000
After the wraparound check newacc = 0x00010000
>
>u16 accum = 0;
>or_all_rx_queues(adapter, rxo, i) {
> accum += erx->rx_drops_no_fragments[rxo->q.id];
>}
>rx_stats(rxo)->rx_drops_no_frags = accum;
>
^ permalink raw reply
* RE: [PATCH net-next 3/5] be2net: fix erx->rx_drops_no_frags wrap around
From: Eric Dumazet @ 2011-08-23 7:29 UTC (permalink / raw)
To: Sathya.Perla; +Cc: netdev
In-Reply-To: <3367B80B08154D42A3B2BC708B5D41F642D8EDB9C6@EXMAIL.ad.emulex.com>
Le mardi 23 août 2011 à 00:06 -0700, Sathya.Perla@Emulex.Com a écrit :
> >-----Original Message-----
> >From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> >Sent: Tuesday, August 23, 2011 12:11 PM
> >
> >Le mardi 23 août 2011 à 11:11 +0530, Sathya Perla a écrit :
> >> The rx_drops_no_frags HW counter for RSS rings is 16bits in HW and can
> >> wraparound often. Maintain a 32-bit accumulator in the driver to prevent
> >> frequent wraparound.
> >>
> >> Also, incorporated Eric's feedback to use ACCESS_ONCE() for the
> >accumulator
> >> write.
> <...>
> >>
> >> +static void accumulate_16bit_val(u32 *acc, u16 val)
> >> +{
> >> +#define lo(x) (x & 0xFFFF)
> >> +#define hi(x) (x & 0xFFFF0000)
> >> + bool wrapped = val < lo(*acc);
> >> + u32 newacc = hi(*acc) + val;
> >> +
> >> + if (wrapped)
> >> + newacc += 65536;
> >> + ACCESS_ONCE(*acc) = newacc;
> >> +}
> >> +
> >
> >I still feel something is wrong here :
> >
> >> void be_parse_stats(struct be_adapter *adapter)
> >> {
> >> struct be_erx_stats_v1 *erx = be_erx_stats_from_cmd(adapter);
> >> @@ -394,9 +406,13 @@ void be_parse_stats(struct be_adapter *adapter)
> >> }
> >>
> >> /* as erx_v1 is longer than v0, ok to use v1 defn for v0 access */
> >> - for_all_rx_queues(adapter, rxo, i)
> >> - rx_stats(rxo)->rx_drops_no_frags =
> >> - erx->rx_drops_no_fragments[rxo->q.id];
> >
> >previous code was not doing a sum_of_all_queues.
> Yes, the new code still *does not* do a sum of all queues. The code just
> parses per-queue stats. For each queue, the 16 bit
> HW stats value is taken and stored in a 32-bit *per-queue* variable.
> The comment that "driver accumulates a 32-bit val" may be misleading. The
> code here is not doing a sum of the per-queue stat.
Ah ok, I now see the code intent, and everything seems fine now, thanks
for explaining.
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Jeff Kirsher @ 2011-08-23 8:29 UTC (permalink / raw)
To: David Miller
Cc: lacombar@gmail.com, sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
mikey@neuling.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
benh@kernel.crashing.org, paulus@samba.org,
linux-kbuild@vger.kernel.org
In-Reply-To: <20110822.210255.1902105215409964106.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
On Mon, 2011-08-22 at 21:02 -0700, David Miller wrote:
> From: Arnaud Lacombe <lacombar@gmail.com>
> Date: Mon, 22 Aug 2011 23:50:02 -0400
>
> > Are you implying we need some kind of way to migrate config ?
>
> The issue is that the dependencies for every single ethernet driver
> have changed. Some dependencies have been dropped (f.e. NETDEV_10000
> and some have been added (f.e. ETHERNET, NET_VENDOR_****)
>
> So right now an automated (non-prompted, default to no on all new
> options) run on an existing config results in all ethernet drivers
> getting disabled because the new dependencies don't get enabled.
>
> This wouldn't be so bad if it was just one or two drivers, but in
> this case it's every single ethernet driver which will have and hit
> this problem.
>
Ok, I have patch which will resolve the issue. It is the last patch in
the series I am about to send out. What this patch does is set the
"new" Kconfig options to Y, so that current defconfig's can build
driver's that are currently set to build.
This will fix the issue, I have confirmed this with the x86_64
defconfig. It will be nice that eventually all configs get updated so
that not all the NET_VENDOR_* tags have to be enabled, but
understandably this is the best way to ensure that current defconfig's
will compile all expected drivers.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [net-next 1/9] fddi: Move the FDDI drivers
From: Jeff Kirsher @ 2011-08-23 8:45 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, Maciej W. Rozycki, Christoph Goos,
linux
In-Reply-To: <1314089149-27205-1-git-send-email-jeffrey.t.kirsher@intel.com>
Move the FDDI drivers into drivers/net/fddi/ and make the
necessary Kconfig and Makefile changes.
CC: "Maciej W. Rozycki" <macro@linux-mips.org>
CC: Christoph Goos <cgoos@syskonnect.de>
CC: <linux@syskonnect.de>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
MAINTAINERS | 2 +-
drivers/net/Kconfig | 72 +---------------------------
drivers/net/Makefile | 3 +-
drivers/net/fddi/Kconfig | 77 ++++++++++++++++++++++++++++++
drivers/net/fddi/Makefile | 6 ++
drivers/net/{ => fddi}/defxx.c | 0
drivers/net/{ => fddi}/defxx.h | 0
drivers/net/{ => fddi}/skfp/Makefile | 0
drivers/net/{ => fddi}/skfp/cfm.c | 0
drivers/net/{ => fddi}/skfp/drvfbi.c | 0
drivers/net/{ => fddi}/skfp/ecm.c | 0
drivers/net/{ => fddi}/skfp/ess.c | 0
drivers/net/{ => fddi}/skfp/fplustm.c | 0
drivers/net/{ => fddi}/skfp/h/cmtdef.h | 0
drivers/net/{ => fddi}/skfp/h/fddi.h | 0
drivers/net/{ => fddi}/skfp/h/fddimib.h | 0
drivers/net/{ => fddi}/skfp/h/fplustm.h | 0
drivers/net/{ => fddi}/skfp/h/hwmtm.h | 0
drivers/net/{ => fddi}/skfp/h/mbuf.h | 0
drivers/net/{ => fddi}/skfp/h/osdef1st.h | 0
drivers/net/{ => fddi}/skfp/h/sba.h | 0
drivers/net/{ => fddi}/skfp/h/sba_def.h | 0
drivers/net/{ => fddi}/skfp/h/skfbi.h | 0
drivers/net/{ => fddi}/skfp/h/skfbiinc.h | 0
drivers/net/{ => fddi}/skfp/h/smc.h | 0
drivers/net/{ => fddi}/skfp/h/smt.h | 0
drivers/net/{ => fddi}/skfp/h/smt_p.h | 0
drivers/net/{ => fddi}/skfp/h/smtstate.h | 0
drivers/net/{ => fddi}/skfp/h/supern_2.h | 0
drivers/net/{ => fddi}/skfp/h/targethw.h | 0
drivers/net/{ => fddi}/skfp/h/targetos.h | 0
drivers/net/{ => fddi}/skfp/h/types.h | 0
drivers/net/{ => fddi}/skfp/hwmtm.c | 0
drivers/net/{ => fddi}/skfp/hwt.c | 0
drivers/net/{ => fddi}/skfp/pcmplc.c | 0
drivers/net/{ => fddi}/skfp/pmf.c | 0
drivers/net/{ => fddi}/skfp/queue.c | 0
drivers/net/{ => fddi}/skfp/rmt.c | 0
drivers/net/{ => fddi}/skfp/skfddi.c | 0
drivers/net/{ => fddi}/skfp/smt.c | 0
drivers/net/{ => fddi}/skfp/smtdef.c | 0
drivers/net/{ => fddi}/skfp/smtinit.c | 0
drivers/net/{ => fddi}/skfp/smttimer.c | 0
drivers/net/{ => fddi}/skfp/srf.c | 0
44 files changed, 87 insertions(+), 73 deletions(-)
create mode 100644 drivers/net/fddi/Kconfig
create mode 100644 drivers/net/fddi/Makefile
rename drivers/net/{ => fddi}/defxx.c (100%)
rename drivers/net/{ => fddi}/defxx.h (100%)
rename drivers/net/{ => fddi}/skfp/Makefile (100%)
rename drivers/net/{ => fddi}/skfp/cfm.c (100%)
rename drivers/net/{ => fddi}/skfp/drvfbi.c (100%)
rename drivers/net/{ => fddi}/skfp/ecm.c (100%)
rename drivers/net/{ => fddi}/skfp/ess.c (100%)
rename drivers/net/{ => fddi}/skfp/fplustm.c (100%)
rename drivers/net/{ => fddi}/skfp/h/cmtdef.h (100%)
rename drivers/net/{ => fddi}/skfp/h/fddi.h (100%)
rename drivers/net/{ => fddi}/skfp/h/fddimib.h (100%)
rename drivers/net/{ => fddi}/skfp/h/fplustm.h (100%)
rename drivers/net/{ => fddi}/skfp/h/hwmtm.h (100%)
rename drivers/net/{ => fddi}/skfp/h/mbuf.h (100%)
rename drivers/net/{ => fddi}/skfp/h/osdef1st.h (100%)
rename drivers/net/{ => fddi}/skfp/h/sba.h (100%)
rename drivers/net/{ => fddi}/skfp/h/sba_def.h (100%)
rename drivers/net/{ => fddi}/skfp/h/skfbi.h (100%)
rename drivers/net/{ => fddi}/skfp/h/skfbiinc.h (100%)
rename drivers/net/{ => fddi}/skfp/h/smc.h (100%)
rename drivers/net/{ => fddi}/skfp/h/smt.h (100%)
rename drivers/net/{ => fddi}/skfp/h/smt_p.h (100%)
rename drivers/net/{ => fddi}/skfp/h/smtstate.h (100%)
rename drivers/net/{ => fddi}/skfp/h/supern_2.h (100%)
rename drivers/net/{ => fddi}/skfp/h/targethw.h (100%)
rename drivers/net/{ => fddi}/skfp/h/targetos.h (100%)
rename drivers/net/{ => fddi}/skfp/h/types.h (100%)
rename drivers/net/{ => fddi}/skfp/hwmtm.c (100%)
rename drivers/net/{ => fddi}/skfp/hwt.c (100%)
rename drivers/net/{ => fddi}/skfp/pcmplc.c (100%)
rename drivers/net/{ => fddi}/skfp/pmf.c (100%)
rename drivers/net/{ => fddi}/skfp/queue.c (100%)
rename drivers/net/{ => fddi}/skfp/rmt.c (100%)
rename drivers/net/{ => fddi}/skfp/skfddi.c (100%)
rename drivers/net/{ => fddi}/skfp/smt.c (100%)
rename drivers/net/{ => fddi}/skfp/smtdef.c (100%)
rename drivers/net/{ => fddi}/skfp/smtinit.c (100%)
rename drivers/net/{ => fddi}/skfp/smttimer.c (100%)
rename drivers/net/{ => fddi}/skfp/srf.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index d32e1ca..2777088 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2113,7 +2113,7 @@ F: net/decnet/
DEFXX FDDI NETWORK DRIVER
M: "Maciej W. Rozycki" <macro@linux-mips.org>
S: Maintained
-F: drivers/net/defxx.*
+F: drivers/net/fddi/defxx.*
DELL LAPTOP DRIVER
M: Matthew Garrett <mjg59@srcf.ucam.org>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ef6b6be..7bdc22b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -195,6 +195,8 @@ config SUNGEM_PHY
source "drivers/net/ethernet/Kconfig"
+source "drivers/net/fddi/Kconfig"
+
source "drivers/net/tokenring/Kconfig"
source "drivers/net/wireless/Kconfig"
@@ -268,76 +270,6 @@ config RIONET_RX_SIZE
depends on RIONET
default "128"
-config FDDI
- tristate "FDDI driver support"
- depends on (PCI || EISA || TC)
- help
- Fiber Distributed Data Interface is a high speed local area network
- design; essentially a replacement for high speed Ethernet. FDDI can
- run over copper or fiber. If you are connected to such a network and
- want a driver for the FDDI card in your computer, say Y here (and
- then also Y to the driver for your FDDI card, below). Most people
- will say N.
-
-config DEFXX
- tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
- depends on FDDI && (PCI || EISA || TC)
- ---help---
- This is support for the DIGITAL series of TURBOchannel (DEFTA),
- EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
- to a local FDDI network.
-
- To compile this driver as a module, choose M here: the module
- will be called defxx. If unsure, say N.
-
-config DEFXX_MMIO
- bool
- prompt "Use MMIO instead of PIO" if PCI || EISA
- depends on DEFXX
- default n if PCI || EISA
- default y
- ---help---
- This instructs the driver to use EISA or PCI memory-mapped I/O
- (MMIO) as appropriate instead of programmed I/O ports (PIO).
- Enabling this gives an improvement in processing time in parts
- of the driver, but it may cause problems with EISA (DEFEA)
- adapters. TURBOchannel does not have the concept of I/O ports,
- so MMIO is always used for these (DEFTA) adapters.
-
- If unsure, say N.
-
-config SKFP
- tristate "SysKonnect FDDI PCI support"
- depends on FDDI && PCI
- select BITREVERSE
- ---help---
- Say Y here if you have a SysKonnect FDDI PCI adapter.
- The following adapters are supported by this driver:
- - SK-5521 (SK-NET FDDI-UP)
- - SK-5522 (SK-NET FDDI-UP DAS)
- - SK-5541 (SK-NET FDDI-FP)
- - SK-5543 (SK-NET FDDI-LP)
- - SK-5544 (SK-NET FDDI-LP DAS)
- - SK-5821 (SK-NET FDDI-UP64)
- - SK-5822 (SK-NET FDDI-UP64 DAS)
- - SK-5841 (SK-NET FDDI-FP64)
- - SK-5843 (SK-NET FDDI-LP64)
- - SK-5844 (SK-NET FDDI-LP64 DAS)
- - Netelligent 100 FDDI DAS Fibre SC
- - Netelligent 100 FDDI SAS Fibre SC
- - Netelligent 100 FDDI DAS UTP
- - Netelligent 100 FDDI SAS UTP
- - Netelligent 100 FDDI SAS Fibre MIC
-
- Read <file:Documentation/networking/skfp.txt> for information about
- the driver.
-
- Questions concerning this driver can be addressed to:
- <linux@syskonnect.de>
-
- To compile this driver as a module, choose M here: the module
- will be called skfp. This is recommended.
-
config HIPPI
bool "HIPPI driver support (EXPERIMENTAL)"
depends on EXPERIMENTAL && INET && PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index c33009b..3087b27 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_VMXNET3) += vmxnet3/
#
obj-$(CONFIG_PLIP) += plip.o
obj-$(CONFIG_ROADRUNNER) += rrunner.o
-obj-$(CONFIG_SKFP) += skfp/
obj-$(CONFIG_RIONET) += rionet.o
#
@@ -42,13 +41,13 @@ obj-$(CONFIG_DUMMY) += dummy.o
obj-$(CONFIG_IFB) += ifb.o
obj-$(CONFIG_MACVLAN) += macvlan.o
obj-$(CONFIG_MACVTAP) += macvtap.o
-obj-$(CONFIG_DEFXX) += defxx.o
obj-$(CONFIG_EQUALIZER) += eql.o
obj-$(CONFIG_TUN) += tun.o
obj-$(CONFIG_VETH) += veth.o
obj-$(CONFIG_DEV_APPLETALK) += appletalk/
obj-$(CONFIG_ETHERNET) += ethernet/
+obj-$(CONFIG_FDDI) += fddi/
obj-$(CONFIG_TR) += tokenring/
obj-$(CONFIG_WAN) += wan/
obj-$(CONFIG_ARCNET) += arcnet/
diff --git a/drivers/net/fddi/Kconfig b/drivers/net/fddi/Kconfig
new file mode 100644
index 0000000..0cc4cd1
--- /dev/null
+++ b/drivers/net/fddi/Kconfig
@@ -0,0 +1,77 @@
+#
+# FDDI network device configuration
+#
+
+menuconfig FDDI
+ bool "FDDI driver support"
+ depends on PCI || EISA || TC
+ ---help---
+ Fiber Distributed Data Interface is a high speed local area network
+ design; essentially a replacement for high speed Ethernet. FDDI can
+ run over copper or fiber. If you are connected to such a network and
+ want a driver for the FDDI card in your computer, say Y here (and
+ then also Y to the driver for your FDDI card, below). Most people
+ will say N.
+
+if FDDI
+
+config DEFXX
+ tristate "Digital DEFTA/DEFEA/DEFPA adapter support"
+ depends on FDDI && (PCI || EISA || TC)
+ ---help---
+ This is support for the DIGITAL series of TURBOchannel (DEFTA),
+ EISA (DEFEA) and PCI (DEFPA) controllers which can connect you
+ to a local FDDI network.
+
+ To compile this driver as a module, choose M here: the module
+ will be called defxx. If unsure, say N.
+
+config DEFXX_MMIO
+ bool
+ prompt "Use MMIO instead of PIO" if PCI || EISA
+ depends on DEFXX
+ default n if PCI || EISA
+ default y
+ ---help---
+ This instructs the driver to use EISA or PCI memory-mapped I/O
+ (MMIO) as appropriate instead of programmed I/O ports (PIO).
+ Enabling this gives an improvement in processing time in parts
+ of the driver, but it may cause problems with EISA (DEFEA)
+ adapters. TURBOchannel does not have the concept of I/O ports,
+ so MMIO is always used for these (DEFTA) adapters.
+
+ If unsure, say N.
+
+config SKFP
+ tristate "SysKonnect FDDI PCI support"
+ depends on FDDI && PCI
+ select BITREVERSE
+ ---help---
+ Say Y here if you have a SysKonnect FDDI PCI adapter.
+ The following adapters are supported by this driver:
+ - SK-5521 (SK-NET FDDI-UP)
+ - SK-5522 (SK-NET FDDI-UP DAS)
+ - SK-5541 (SK-NET FDDI-FP)
+ - SK-5543 (SK-NET FDDI-LP)
+ - SK-5544 (SK-NET FDDI-LP DAS)
+ - SK-5821 (SK-NET FDDI-UP64)
+ - SK-5822 (SK-NET FDDI-UP64 DAS)
+ - SK-5841 (SK-NET FDDI-FP64)
+ - SK-5843 (SK-NET FDDI-LP64)
+ - SK-5844 (SK-NET FDDI-LP64 DAS)
+ - Netelligent 100 FDDI DAS Fibre SC
+ - Netelligent 100 FDDI SAS Fibre SC
+ - Netelligent 100 FDDI DAS UTP
+ - Netelligent 100 FDDI SAS UTP
+ - Netelligent 100 FDDI SAS Fibre MIC
+
+ Read <file:Documentation/networking/skfp.txt> for information about
+ the driver.
+
+ Questions concerning this driver can be addressed to:
+ <linux@syskonnect.de>
+
+ To compile this driver as a module, choose M here: the module
+ will be called skfp. This is recommended.
+
+endif # FDDI
diff --git a/drivers/net/fddi/Makefile b/drivers/net/fddi/Makefile
new file mode 100644
index 0000000..36da19c
--- /dev/null
+++ b/drivers/net/fddi/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for the Linux FDDI network device drivers.
+#
+
+obj-$(CONFIG_DEFXX) += defxx.o
+obj-$(CONFIG_SKFP) += skfp/
diff --git a/drivers/net/defxx.c b/drivers/net/fddi/defxx.c
similarity index 100%
rename from drivers/net/defxx.c
rename to drivers/net/fddi/defxx.c
diff --git a/drivers/net/defxx.h b/drivers/net/fddi/defxx.h
similarity index 100%
rename from drivers/net/defxx.h
rename to drivers/net/fddi/defxx.h
diff --git a/drivers/net/skfp/Makefile b/drivers/net/fddi/skfp/Makefile
similarity index 100%
rename from drivers/net/skfp/Makefile
rename to drivers/net/fddi/skfp/Makefile
diff --git a/drivers/net/skfp/cfm.c b/drivers/net/fddi/skfp/cfm.c
similarity index 100%
rename from drivers/net/skfp/cfm.c
rename to drivers/net/fddi/skfp/cfm.c
diff --git a/drivers/net/skfp/drvfbi.c b/drivers/net/fddi/skfp/drvfbi.c
similarity index 100%
rename from drivers/net/skfp/drvfbi.c
rename to drivers/net/fddi/skfp/drvfbi.c
diff --git a/drivers/net/skfp/ecm.c b/drivers/net/fddi/skfp/ecm.c
similarity index 100%
rename from drivers/net/skfp/ecm.c
rename to drivers/net/fddi/skfp/ecm.c
diff --git a/drivers/net/skfp/ess.c b/drivers/net/fddi/skfp/ess.c
similarity index 100%
rename from drivers/net/skfp/ess.c
rename to drivers/net/fddi/skfp/ess.c
diff --git a/drivers/net/skfp/fplustm.c b/drivers/net/fddi/skfp/fplustm.c
similarity index 100%
rename from drivers/net/skfp/fplustm.c
rename to drivers/net/fddi/skfp/fplustm.c
diff --git a/drivers/net/skfp/h/cmtdef.h b/drivers/net/fddi/skfp/h/cmtdef.h
similarity index 100%
rename from drivers/net/skfp/h/cmtdef.h
rename to drivers/net/fddi/skfp/h/cmtdef.h
diff --git a/drivers/net/skfp/h/fddi.h b/drivers/net/fddi/skfp/h/fddi.h
similarity index 100%
rename from drivers/net/skfp/h/fddi.h
rename to drivers/net/fddi/skfp/h/fddi.h
diff --git a/drivers/net/skfp/h/fddimib.h b/drivers/net/fddi/skfp/h/fddimib.h
similarity index 100%
rename from drivers/net/skfp/h/fddimib.h
rename to drivers/net/fddi/skfp/h/fddimib.h
diff --git a/drivers/net/skfp/h/fplustm.h b/drivers/net/fddi/skfp/h/fplustm.h
similarity index 100%
rename from drivers/net/skfp/h/fplustm.h
rename to drivers/net/fddi/skfp/h/fplustm.h
diff --git a/drivers/net/skfp/h/hwmtm.h b/drivers/net/fddi/skfp/h/hwmtm.h
similarity index 100%
rename from drivers/net/skfp/h/hwmtm.h
rename to drivers/net/fddi/skfp/h/hwmtm.h
diff --git a/drivers/net/skfp/h/mbuf.h b/drivers/net/fddi/skfp/h/mbuf.h
similarity index 100%
rename from drivers/net/skfp/h/mbuf.h
rename to drivers/net/fddi/skfp/h/mbuf.h
diff --git a/drivers/net/skfp/h/osdef1st.h b/drivers/net/fddi/skfp/h/osdef1st.h
similarity index 100%
rename from drivers/net/skfp/h/osdef1st.h
rename to drivers/net/fddi/skfp/h/osdef1st.h
diff --git a/drivers/net/skfp/h/sba.h b/drivers/net/fddi/skfp/h/sba.h
similarity index 100%
rename from drivers/net/skfp/h/sba.h
rename to drivers/net/fddi/skfp/h/sba.h
diff --git a/drivers/net/skfp/h/sba_def.h b/drivers/net/fddi/skfp/h/sba_def.h
similarity index 100%
rename from drivers/net/skfp/h/sba_def.h
rename to drivers/net/fddi/skfp/h/sba_def.h
diff --git a/drivers/net/skfp/h/skfbi.h b/drivers/net/fddi/skfp/h/skfbi.h
similarity index 100%
rename from drivers/net/skfp/h/skfbi.h
rename to drivers/net/fddi/skfp/h/skfbi.h
diff --git a/drivers/net/skfp/h/skfbiinc.h b/drivers/net/fddi/skfp/h/skfbiinc.h
similarity index 100%
rename from drivers/net/skfp/h/skfbiinc.h
rename to drivers/net/fddi/skfp/h/skfbiinc.h
diff --git a/drivers/net/skfp/h/smc.h b/drivers/net/fddi/skfp/h/smc.h
similarity index 100%
rename from drivers/net/skfp/h/smc.h
rename to drivers/net/fddi/skfp/h/smc.h
diff --git a/drivers/net/skfp/h/smt.h b/drivers/net/fddi/skfp/h/smt.h
similarity index 100%
rename from drivers/net/skfp/h/smt.h
rename to drivers/net/fddi/skfp/h/smt.h
diff --git a/drivers/net/skfp/h/smt_p.h b/drivers/net/fddi/skfp/h/smt_p.h
similarity index 100%
rename from drivers/net/skfp/h/smt_p.h
rename to drivers/net/fddi/skfp/h/smt_p.h
diff --git a/drivers/net/skfp/h/smtstate.h b/drivers/net/fddi/skfp/h/smtstate.h
similarity index 100%
rename from drivers/net/skfp/h/smtstate.h
rename to drivers/net/fddi/skfp/h/smtstate.h
diff --git a/drivers/net/skfp/h/supern_2.h b/drivers/net/fddi/skfp/h/supern_2.h
similarity index 100%
rename from drivers/net/skfp/h/supern_2.h
rename to drivers/net/fddi/skfp/h/supern_2.h
diff --git a/drivers/net/skfp/h/targethw.h b/drivers/net/fddi/skfp/h/targethw.h
similarity index 100%
rename from drivers/net/skfp/h/targethw.h
rename to drivers/net/fddi/skfp/h/targethw.h
diff --git a/drivers/net/skfp/h/targetos.h b/drivers/net/fddi/skfp/h/targetos.h
similarity index 100%
rename from drivers/net/skfp/h/targetos.h
rename to drivers/net/fddi/skfp/h/targetos.h
diff --git a/drivers/net/skfp/h/types.h b/drivers/net/fddi/skfp/h/types.h
similarity index 100%
rename from drivers/net/skfp/h/types.h
rename to drivers/net/fddi/skfp/h/types.h
diff --git a/drivers/net/skfp/hwmtm.c b/drivers/net/fddi/skfp/hwmtm.c
similarity index 100%
rename from drivers/net/skfp/hwmtm.c
rename to drivers/net/fddi/skfp/hwmtm.c
diff --git a/drivers/net/skfp/hwt.c b/drivers/net/fddi/skfp/hwt.c
similarity index 100%
rename from drivers/net/skfp/hwt.c
rename to drivers/net/fddi/skfp/hwt.c
diff --git a/drivers/net/skfp/pcmplc.c b/drivers/net/fddi/skfp/pcmplc.c
similarity index 100%
rename from drivers/net/skfp/pcmplc.c
rename to drivers/net/fddi/skfp/pcmplc.c
diff --git a/drivers/net/skfp/pmf.c b/drivers/net/fddi/skfp/pmf.c
similarity index 100%
rename from drivers/net/skfp/pmf.c
rename to drivers/net/fddi/skfp/pmf.c
diff --git a/drivers/net/skfp/queue.c b/drivers/net/fddi/skfp/queue.c
similarity index 100%
rename from drivers/net/skfp/queue.c
rename to drivers/net/fddi/skfp/queue.c
diff --git a/drivers/net/skfp/rmt.c b/drivers/net/fddi/skfp/rmt.c
similarity index 100%
rename from drivers/net/skfp/rmt.c
rename to drivers/net/fddi/skfp/rmt.c
diff --git a/drivers/net/skfp/skfddi.c b/drivers/net/fddi/skfp/skfddi.c
similarity index 100%
rename from drivers/net/skfp/skfddi.c
rename to drivers/net/fddi/skfp/skfddi.c
diff --git a/drivers/net/skfp/smt.c b/drivers/net/fddi/skfp/smt.c
similarity index 100%
rename from drivers/net/skfp/smt.c
rename to drivers/net/fddi/skfp/smt.c
diff --git a/drivers/net/skfp/smtdef.c b/drivers/net/fddi/skfp/smtdef.c
similarity index 100%
rename from drivers/net/skfp/smtdef.c
rename to drivers/net/fddi/skfp/smtdef.c
diff --git a/drivers/net/skfp/smtinit.c b/drivers/net/fddi/skfp/smtinit.c
similarity index 100%
rename from drivers/net/skfp/smtinit.c
rename to drivers/net/fddi/skfp/smtinit.c
diff --git a/drivers/net/skfp/smttimer.c b/drivers/net/fddi/skfp/smttimer.c
similarity index 100%
rename from drivers/net/skfp/smttimer.c
rename to drivers/net/fddi/skfp/smttimer.c
diff --git a/drivers/net/skfp/srf.c b/drivers/net/fddi/skfp/srf.c
similarity index 100%
rename from drivers/net/skfp/srf.c
rename to drivers/net/fddi/skfp/srf.c
--
1.7.6
^ 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