* Re: [PATCH net-next 0/5] qlcnic: Fixes and debug support
From: Anirban Chakraborty @ 2011-08-01 15:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20110801.015706.719035744873995476.davem@davemloft.net>
On Aug 1, 2011, at 1:57 AM, David Miller wrote:
> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
> Date: Fri, 29 Jul 2011 16:30:30 -0700
>
>> Please apply the series to net-next. Thanks.
>
> Queued up for net-next
Would it be too much of a trouble to push these to net-2.6, as these are minor bug fixes anyway?
Thanks a lot.
-Anirban
^ permalink raw reply
* Re: [GIT] Networking
From: Ingo Molnar @ 2011-08-01 15:13 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20110722.073339.1236244143490935644.davem@davemloft.net>
* David Miller <davem@davemloft.net> wrote:
> forcedeth: do vlan cleanup
Trying to bring latest -git into latest -tip today i managed to
bisect back to a pretty bad networking breakage on one of my
testboxes back to this commit - where i have discovered that it has
been fixed freshly.
This bug cost me multiple days of debugging so here's a bit of a post
mortem.
The bit that IMO wasnt very optimal was the timing of the merge path:
- AuthorDate: Wed Jul 20 04:54:38 2011 +0000
- CommitDate: Thu Jul 21 13:47:57 2011 -0700
- tree Linus merge CommitDate: Fri Jul 22 14:43:13 2011 -0700
- first lkml bugreport: Sun Jul 24 16:10:59 2011 -0700
- fix CommitDate: Wed Jul 27 22:39:30 2011 -0700
- fix Linus merge CommitDate: Thu Jul 28 05:58:19 2011 -0700
So you can see that the commit was committed to net-next within 24
hours of it being submitted, the (bad) breakage was not discovered
until 4 days down the road.
I submit that *no one* with real forcedeth hardware actually tested
this commit before it hit upstream. It has not touched linux-next
before going to Linus and it took 8 days for the fix to get upstream.
If the latency of common driver bugfixes is on the order of 1 week
then the golden rule is that commits must be tested for at least 1
week as well. One day of testing was *way* too short.
Furthermore, the changelog of the fix:
0891b0e08937: forcedeth: fix vlans
Doesn't contain any reference to the bisection work done by
walt <w41ter@gmail.com> nor by any of the other bugreporters.
So this really sucked all around - could we please improve on it?
Thanks,
Ingo
^ permalink raw reply
* [PATCH 1/1] atm: br2864: sent packets truncated in VC routed mode
From: chas williams - CONTRACTOR @ 2011-08-01 15:03 UTC (permalink / raw)
To: netdev; +Cc: pascal, davem, linux-atm-general
hopefully this could be included for the next kernel release.
From: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
commit 8b5e1c9db2bcd2d13c2db08e6c6dbe66882fa186
Author: chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Date: Mon Aug 1 07:55:07 2011 -0400
atm: br2864: sent packets truncated in VC routed mode
Reported-by: Pascal Hambourg <pascal@plouf.fr.eu.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 2252c20..52cfd0c 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -242,8 +242,6 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
if (brdev->payload == p_bridged) {
skb_push(skb, 2);
memset(skb->data, 0, 2);
- } else { /* p_routed */
- skb_pull(skb, ETH_HLEN);
}
}
skb_debug(skb);
^ permalink raw reply related
* Re: net-next-2.6 [PATCH 0/7] dccp: add support for dynamic parameter updates
From: Gerrit Renker @ 2011-08-01 14:43 UTC (permalink / raw)
To: David Miller; +Cc: dccp, netdev
In-Reply-To: <20110801.001042.6263177526030880.davem@davemloft.net>
Quoting David S. Miller:
| From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
| Date: Mon, 25 Jul 2011 07:36:29 -0600
|
| > I have also placed this in into a fresh (today's) copy of net-next-2.6, on
| >
| > git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
|
| I did a test pull and this URL doesn't work:
|
|
Sorry, I must have clobbered something during a subsequent update last week.
I have just regenerated the whole tree from scratch, including the 'dccp' sub-branch,
using today's net-next-2.6, double-checking it running
git ls-remote git://eden-feed.erg.abdn.ac.uk/net-next-2.6 dccp
and doing a test-pull of the dccp sub-tree.
Can you please consider pulling again, from
git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [sub-tree 'dccp']
The patch listing of this set is at
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=net-next-2.6.git;a=log;h=dccp
Thank you for the update
Gerrit
--
^ permalink raw reply
* Re: [net-next v2 56/71] macb: Move the Atmel driver
From: Nicolas Ferre @ 2011-08-01 14:49 UTC (permalink / raw)
To: Jeff Kirsher, netdev; +Cc: davem, gospo, sassmann, Jamie Iles
In-Reply-To: <1312082850-24914-57-git-send-email-jeffrey.t.kirsher@intel.com>
On 07/31/2011 04:27 AM, Jeff Kirsher wrote:
> Move the Atmel driver into drivers/net/ethernet/cadence/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Nicolas Ferre<nicolas.ferre@atmel.com>
You can add my:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> CC: Jamie Iles<jamie@jamieiles.com>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> ---
> MAINTAINERS | 2 +-
> drivers/net/Kconfig | 16 --------
> drivers/net/Makefile | 3 -
> drivers/net/arm/Kconfig | 12 ------
> drivers/net/arm/Makefile | 6 ---
> drivers/net/ethernet/Kconfig | 1 +
> drivers/net/ethernet/Makefile | 1 +
> drivers/net/ethernet/cadence/Kconfig | 40 ++++++++++++++++++++
> drivers/net/ethernet/cadence/Makefile | 6 +++
> drivers/net/{arm => ethernet/cadence}/at91_ether.c | 0
> drivers/net/{arm => ethernet/cadence}/at91_ether.h | 0
> drivers/net/{ => ethernet/cadence}/macb.c | 0
> drivers/net/{ => ethernet/cadence}/macb.h | 0
> 13 files changed, 49 insertions(+), 38 deletions(-)
> delete mode 100644 drivers/net/arm/Kconfig
> delete mode 100644 drivers/net/arm/Makefile
> create mode 100644 drivers/net/ethernet/cadence/Kconfig
> create mode 100644 drivers/net/ethernet/cadence/Makefile
> rename drivers/net/{arm => ethernet/cadence}/at91_ether.c (100%)
> rename drivers/net/{arm => ethernet/cadence}/at91_ether.h (100%)
> rename drivers/net/{ => ethernet/cadence}/macb.c (100%)
> rename drivers/net/{ => ethernet/cadence}/macb.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 83a51ad..995f504 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1317,7 +1317,7 @@ F: include/video/atmel_lcdc.h
> ATMEL MACB ETHERNET DRIVER
> M: Nicolas Ferre<nicolas.ferre@atmel.com>
> S: Supported
> -F: drivers/net/macb.*
> +F: drivers/net/ethernet/cadence/
>
> ATMEL SPI DRIVER
> M: Nicolas Ferre<nicolas.ferre@atmel.com>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index bb4bc4b..6db322c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2,9 +2,6 @@
> # Network device configuration
> #
>
> -config HAVE_NET_MACB
> - bool
> -
> menuconfig NETDEVICES
> default y if UML
> depends on NET
> @@ -224,19 +221,6 @@ menuconfig NET_ETHERNET
>
> if NET_ETHERNET
>
> -config MACB
> - tristate "Atmel MACB support"
> - depends on HAVE_NET_MACB
> - select PHYLIB
> - help
> - The Atmel MACB ethernet interface is found on many AT32 and AT91
> - parts. Say Y to include support for the MACB chip.
> -
> - To compile this driver as a module, choose M here: the module
> - will be called macb.
> -
> -source "drivers/net/arm/Kconfig"
> -
> config SH_ETH
> tristate "Renesas SuperH Ethernet support"
> depends on SUPERH&& \
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index d249d76..d7873ba 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -63,9 +63,6 @@ obj-$(CONFIG_ETHOC) += ethoc.o
> obj-$(CONFIG_GRETH) += greth.o
>
> obj-$(CONFIG_DNET) += dnet.o
> -obj-$(CONFIG_MACB) += macb.o
> -
> -obj-$(CONFIG_ARM) += arm/
> obj-$(CONFIG_DEV_APPLETALK) += appletalk/
> obj-$(CONFIG_ETHERNET) += ethernet/
> obj-$(CONFIG_TR) += tokenring/
> diff --git a/drivers/net/arm/Kconfig b/drivers/net/arm/Kconfig
> deleted file mode 100644
> index 57d16b9..0000000
> --- a/drivers/net/arm/Kconfig
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -#
> -# Acorn Network device configuration
> -# These are for Acorn's Expansion card network interfaces
> -#
> -
> -config ARM_AT91_ETHER
> - tristate "AT91RM9200 Ethernet support"
> - depends on ARM&& ARCH_AT91RM9200
> - select MII
> - help
> - If you wish to compile a kernel for the AT91RM9200 and enable
> - ethernet support, then you should always answer Y to this.
> diff --git a/drivers/net/arm/Makefile b/drivers/net/arm/Makefile
> deleted file mode 100644
> index fc0f85c..0000000
> --- a/drivers/net/arm/Makefile
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -# File: drivers/net/arm/Makefile
> -#
> -# Makefile for the ARM network device drivers
> -#
> -
> -obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
> index e087337..68a31b9 100644
> --- a/drivers/net/ethernet/Kconfig
> +++ b/drivers/net/ethernet/Kconfig
> @@ -15,6 +15,7 @@ source "drivers/net/ethernet/3com/Kconfig"
> source "drivers/net/ethernet/amd/Kconfig"
> source "drivers/net/ethernet/apple/Kconfig"
> source "drivers/net/ethernet/atheros/Kconfig"
> +source "drivers/net/ethernet/cadence/Kconfig"
> source "drivers/net/ethernet/adi/Kconfig"
> source "drivers/net/ethernet/broadcom/Kconfig"
> source "drivers/net/ethernet/brocade/Kconfig"
> diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
> index 826db27..0e91c4d 100644
> --- a/drivers/net/ethernet/Makefile
> +++ b/drivers/net/ethernet/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_NET_VENDOR_8390) += 8390/
> obj-$(CONFIG_NET_VENDOR_AMD) += amd/
> obj-$(CONFIG_NET_VENDOR_APPLE) += apple/
> obj-$(CONFIG_NET_VENDOR_ATHEROS) += atheros/
> +obj-$(CONFIG_NET_ATMEL) += cadence/
> obj-$(CONFIG_NET_BFIN) += adi/
> obj-$(CONFIG_NET_VENDOR_BROADCOM) += broadcom/
> obj-$(CONFIG_NET_VENDOR_BROCADE) += brocade/
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> new file mode 100644
> index 0000000..4c443da
> --- /dev/null
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -0,0 +1,40 @@
> +#
> +# Atmel device configuration
> +#
> +
> +config HAVE_NET_MACB
> + bool
> +
> +config NET_ATMEL
> + bool "Atmel devices"
> + depends on HAVE_NET_MACB || (ARM&& ARCH_AT91RM9200)
> + ---help---
> + If you have a network (Ethernet) card belonging to this class, say Y.
> + Make sure you know the name of your card. Read the Ethernet-HOWTO,
> + available from<http://www.tldp.org/docs.html#howto>.
> +
> + If unsure, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the remaining Atmel network card questions. If you say Y, you will be
> + asked for your specific card in the following questions.
> +
> +config ARM_AT91_ETHER
> + tristate "AT91RM9200 Ethernet support"
> + depends on NET_ATMEL&& ARM&& ARCH_AT91RM9200
> + select MII
> + ---help---
> + If you wish to compile a kernel for the AT91RM9200 and enable
> + ethernet support, then you should always answer Y to this.
> +
> +config MACB
> + tristate "Atmel MACB support"
> + depends on NET_ATMEL&& HAVE_NET_MACB
> + select PHYLIB
> + ---help---
> + The Atmel MACB ethernet interface is found on many AT32 and AT91
> + parts. Say Y to include support for the MACB chip.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called macb.
> diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
> new file mode 100644
> index 0000000..9068b83
> --- /dev/null
> +++ b/drivers/net/ethernet/cadence/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for the Atmel network device drivers.
> +#
> +
> +obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
> +obj-$(CONFIG_MACB) += macb.o
> diff --git a/drivers/net/arm/at91_ether.c b/drivers/net/ethernet/cadence/at91_ether.c
> similarity index 100%
> rename from drivers/net/arm/at91_ether.c
> rename to drivers/net/ethernet/cadence/at91_ether.c
> diff --git a/drivers/net/arm/at91_ether.h b/drivers/net/ethernet/cadence/at91_ether.h
> similarity index 100%
> rename from drivers/net/arm/at91_ether.h
> rename to drivers/net/ethernet/cadence/at91_ether.h
> diff --git a/drivers/net/macb.c b/drivers/net/ethernet/cadence/macb.c
> similarity index 100%
> rename from drivers/net/macb.c
> rename to drivers/net/ethernet/cadence/macb.c
> diff --git a/drivers/net/macb.h b/drivers/net/ethernet/cadence/macb.h
> similarity index 100%
> rename from drivers/net/macb.h
> rename to drivers/net/ethernet/cadence/macb.h
^ permalink raw reply
* Re: [PATCH] cxgb3i: ref count cdev access to prevent modification while in use
From: Steve Wise @ 2011-08-01 14:42 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Divy Le Ray, Steve Wise, David S. Miller, Karen Xie
In-Reply-To: <20110801111824.GB23131@hmsreliant.think-freely.org>
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>> CC: Divy Le Ray<divy@chelsio.com>
>> CC: Steve Wise<swise@chelsio.com>
>> CC: "David S. Miller"<davem@davemloft.net>
> Divy, Steve, I think Dave is waiting for an ACK from one of you to, since you're
> the listed maintainers.
> Neil
Karen is the cxgb3i maintainer, but I just now reviewed the patch and it looks good. Divy is on vacation for a few
weeks. I think its ok to pull it in since Karen already acked it.
Steve.
^ permalink raw reply
* Re: [net-next v2 56/71] macb: Move the Atmel driver
From: Jamie Iles @ 2011-08-01 14:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann, Nicolas Ferre, Jamie Iles
In-Reply-To: <1312082850-24914-57-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 08:27:15PM -0700, Jeff Kirsher wrote:
> Move the Atmel driver into drivers/net/ethernet/cadence/ and
> make the necessary Kconfig and Makefile changes.
>
> CC: Nicolas Ferre <nicolas.ferre@atmel.com>
> CC: Jamie Iles <jamie@jamieiles.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Looks good to me.
Acked-by: Jamie Iles <jamie@jamieiles.com>
^ permalink raw reply
* [Bug?] Machine hangs, rtl8192se possible cause
From: Jaroslaw Fedewicz @ 2011-08-01 13:26 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ
Hello,
I own a Thinkpad Edge 13 (AMD, machine type 0197) laptop, which is
shipped with a Realtek 8192 SE WLAN card.
The WLAN support with this particular card was never brilliant under
Linux, first with (very) flakey drivers from Realtek which would stop
transmitting packets every so often or panic after a few hours of
usage. The in-tree drivers are better in this respect, but I'm
experiencing mysterious hangups every once in a while. The machine is
effectively dead and has to be power-cycled — no oops, no kernel
panic, no nothing, it just hangs and that's it.
I'm sure this is not a regression because the hangups were right there
from the start.
The last meaningful message which might be helpful was: "wait for
BIT(6) return value X" (I don't remember what X was, it was a while
ago and only once).
I don't know if there are other means to debug (netconsole over eth0?)
those hangs. The only other thing I know for sure that I can get a
week long uptime if I blacklist rtl8192se.ko from loading.
If I can provide any additional information to track the bug (or a
faulty piece of hardware?) down, please tell me. Google tells me
nobody reported this before, or it was just me feeding incorrect
keywords.
Thanks for your kind attention.
P. S. Tried netconsole before, got nothing to pinpoint the error. The
only recurring pattern I could see in it was that almost every time
the machine hanged was after ip6tables initialized, at least it was
the last message in the log.
P. P. S. I don't track netdev@ and linux-wireless@ lists, so please Cc: me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next v2 16/71] mlx4: Move the Mellanox driver
From: Roland Dreier @ 2011-08-01 13:10 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, sassmann
In-Reply-To: <1312082850-24914-17-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Jul 30, 2011 at 8:26 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> Moves the Mellanox driver into drivers/net/ethernet/mellanox/ and
> make the necessary Kconfig and Makefile changes.
Hi,
no objection to this, but if we're going to move this code around,
maybe it makes sense to split the mlx4_core and mlx4_en code
into separate directories at the same time?
- R.
^ permalink raw reply
* Re: [Bugme-new] [Bug 39742] New: 2.6.39.3 crash and hangs in 1-2 minutes. Still have traps.
From: Rustam Afanasyev @ 2011-08-01 11:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, Patrick McHardy
In-Reply-To: <20110722144214.577718f0.akpm@linux-foundation.org>
With applied patch from xeb
(http://www.spinics.net/lists/netdev/msg170766.html)
there isn't hangs any more. Panics is still occurs. They only occur much
less frequently. And seems it's different place.
Here it is.
1 was like:
[ 1582.319303] ------------[ cut here ]------------
[ 1582.323205] kernel BUG at include/linux/skbuff.h:1189!
[ 1582.323205] invalid opcode: 0000 [#1] SMP
[ 1582.323205] last sysfs file: /sys/devices/virtual/net/ppp168/uevent
[ 1582.323205] CPU 0
[ 1582.323205] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2d
[ 1582.323205]
[ 1582.598100] Pid: 0, comm: swapper Not tainted 2.6.39-std-def-alt3 #1
ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 1582.616208] RIP: 0010:[<ffffffff8134a94b>] [<ffffffff8134a94b>]
skb_pull+0x2b/0x30
[ 1582.616208] RSP: 0018:ffff88011fc03b20 EFLAGS: 00010293
[ 1582.616208] RAX: 0000000000000247 RBX: ffff880117ac2880 RCX:
0000000000000027
[ 1582.616208] RDX: 0000000000000027 RSI: 0000000000000002 RDI:
ffff880117ac2880
[ 1582.698595] RBP: ffff88011fc03b20 R08: 0000000000000228 R09:
000000000000000c
[ 1582.698595] R10: 0000000000000240 R11: 0000000000000001 R12:
ffff880118f00800
[ 1582.698595] R13: ffff8801176a086e R14: 000000000000002f R15:
ffff880115346000
[ 1582.698595] FS: 0000000000000000(0000) GS:ffff88011fc00000(0000)
knlGS:0000000000000000
[ 1582.698595] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1582.808009] CR2: 0000000000645f4c CR3: 000000011760b000 CR4:
00000000000006f0
[ 1582.808009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 1582.808009] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 1582.808009] Process swapper (pid: 0, threadinfo ffffffff81800000,
task ffffffff8180b020)
[ 1582.808009] Stack:
[ 1582.808009] ffff88011fc03b50 ffffffffa034663a ffff88011fc03b80
ffff880118f00800
[ 1582.808009] ffff880117ac2880 0000000000000000 ffff88011fc03b90
ffffffff81346ecc
[ 1582.808009] ffff88011fc03bb0 ffffffff8134b4e9 0000000000000001
ffff880117ac2880
[ 1582.808009] Call Trace:
[ 1582.808009] <IRQ>
[ 1582.808009] [<ffffffffa034663a>] pptp_rcv_core+0x21a/0x220 [pptp]
[ 1582.808009] [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 1582.808009] [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 1582.808009] [<ffffffffa0346783>] pptp_rcv+0x143/0x190 [pptp]
[ 1582.808009] [<ffffffffa03250ad>] gre_rcv+0x5d/0x80 [gre]
[ 1582.808009] [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 1582.808009] [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 1582.808009] [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 1582.808009] [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 1582.808009] [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 1582.808009] [<ffffffff8100cf01>] ? do_IRQ+0x61/0xe0
[ 1582.808009] [<ffffffff8140a593>] ? common_interrupt+0x13/0x13
[ 1582.808009] [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 1582.808009] [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 1582.808009] [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 1582.808009] [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 1582.808009] [<ffffffffa01b229b>] igb_poll+0x6fb/0xae0 [igb]
[ 1582.808009] [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 1582.808009] [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 1582.808009] [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 1582.808009] [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 1582.808009] [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 1582.808009] [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 1582.808009] [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 1582.808009] [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 1582.808009] <EOI>
[ 1582.808009] [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 1582.808009] [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 1582.808009] [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 1582.808009] [<ffffffff813f396d>] rest_init+0x6d/0x80
[ 1582.808009] [<ffffffff8187fbe6>] start_kernel+0x392/0x39d
[ 1582.808009] [<ffffffff8187f347>] x86_64_start_reservations+0x132/0x136
[ 1582.808009] [<ffffffff8187f44c>] x86_64_start_kernel+0x101/0x110
[ 1582.808009] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e
[ 1582.808009] RIP [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 1582.808009] RSP <ffff88011fc03b20>
[ 1583.628015] ---[ end trace 6c39f3d0e04ed229 ]---
[ 1583.641960] Kernel panic - not syncing: Fatal exception in interrupt
[ 1583.661088] Pid: 0, comm: swapper Tainted: G D
2.6.39-std-def-alt3 #1
[ 1583.682846] Call Trace:
[ 1583.690254] <IRQ> [<ffffffff81407284>] panic+0x8c/0x197
[ 1583.706576] [<ffffffff8140b4d2>] oops_end+0xe2/0xf0
[ 1583.721540] [<ffffffff8100e876>] die+0x56/0x90
[ 1583.735215] [<ffffffff8140abf4>] do_trap+0xc4/0x170
[ 1583.750191] [<ffffffff8100bf00>] do_invalid_op+0x90/0xb0
[ 1583.766466] [<ffffffff8134a94b>] ? skb_pull+0x2b/0x30
[ 1583.781965] [<ffffffffa01f31d6>] ? ipt_do_table+0x256/0x670 [ip_tables]
other was:
[ 245.268856] ------------[ cut here ]------------
[ 245.272797] kernel BUG at include/linux/skbuff.h:1189!
[ 245.272797] invalid opcode: 0000 [#1] SMP
[ 245.272797] last sysfs file: /sys/devices/virtual/net/ppp100/uevent
[ 245.272797] CPU 3
[ 245.272797] Modules linked in: cls_fw sch_sfq arc4 ecb ppp_mppe
act_mirred act_skbedit cls_u32 sch_ingress l2tp_ppp l2d
[ 245.272797]
[ 245.272797] Pid: 0, comm: kworker/0:1 Not tainted 2.6.39-std-def-alt3
#1 ASUS RS100-E4/PI2/P5M2-M/RS100-E4
[ 245.272797] RIP: 0010:[<ffffffff8134a94b>] [<ffffffff8134a94b>]
skb_pull+0x2b/0x30
[ 245.272797] RSP: 0018:ffff88011fd83b20 EFLAGS: 00010297
[ 245.272797] RAX: 0000000000000518 RBX: ffff880116a0e0c0 RCX:
0000000000000444
[ 245.272797] RDX: 0000000000000444 RSI: 0000000000000010 RDI:
ffff880116a0e0c0
[ 245.272797] RBP: ffff88011fd83b20 R08: 0000000000000500 R09:
000000000000000c
[ 245.272797] R10: 0000000000000240 R11: 0000000000000001 R12:
ffff8801171fb400
[ 245.272797] R13: ffff880116a0cc72 R14: 000000000000002f R15:
ffff8801168de000
[ 245.272797] FS: 0000000000000000(0000) GS:ffff88011fd80000(0000)
knlGS:0000000000000000
[ 245.272797] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 245.272797] CR2: 00000000008faa2c CR3: 00000001151c2000 CR4:
00000000000006e0
[ 245.272797] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 245.272797] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 245.272797] Process kworker/0:1 (pid: 0, threadinfo ffff880118f46000,
task ffff880118f444c0)
[ 245.272797] Stack:
[ 245.272797] ffff88011fd83b50 ffffffffa03374e2 ffff88011fd83b80
ffff8801171fb400
[ 245.272797] ffff880116a0e0c0 0000000000000000 ffff88011fd83b90
ffffffff81346ecc
[ 245.892667] ffff88011fd83bb0 ffffffff8134b4e9 0000000000000001
ffff880116a0e0c0
[ 245.892667] Call Trace:
[ 245.892667] <IRQ>
[ 245.892667] [<ffffffffa03374e2>] pptp_rcv_core+0xc2/0x220 [pptp]
[ 245.892667] [<ffffffff81346ecc>] sk_receive_skb+0x10c/0x140
[ 245.892667] [<ffffffff8134b4e9>] ? __pskb_pull_tail+0x59/0x3e0
[ 245.892667] [<ffffffffa0337783>] pptp_rcv+0x143/0x190 [pptp]
[ 245.892667] [<ffffffffa03160ad>] gre_rcv+0x5d/0x80 [gre]
[ 245.892667] [<ffffffff8138946d>] ip_local_deliver_finish+0xdd/0x2a0
[ 245.892667] [<ffffffff813897f0>] ip_local_deliver+0x80/0x90
[ 245.892667] [<ffffffff81389135>] ip_rcv_finish+0x135/0x390
[ 245.892667] [<ffffffff81389a1c>] ip_rcv+0x21c/0x2e0
[ 245.892667] [<ffffffff81356f5a>] __netif_receive_skb+0x52a/0x690
[ 245.892667] [<ffffffff81137985>] ? __kmalloc_node_track_caller+0x55/0x60
[ 245.892667] [<ffffffff813572d0>] netif_receive_skb+0x60/0x90
[ 245.892667] [<ffffffff8124de9c>] ? is_swiotlb_buffer+0x3c/0x50
[ 245.892667] [<ffffffff81357440>] napi_skb_finish+0x50/0x70
[ 245.892667] [<ffffffff813579bd>] napi_gro_receive+0xbd/0xd0
[ 245.892667] [<ffffffffa01ea29b>] igb_poll+0x6fb/0xae0 [igb]
[ 245.892667] [<ffffffff81356f5a>] ? __netif_receive_skb+0x52a/0x690
[ 245.892667] [<ffffffff81357be5>] net_rx_action+0x135/0x270
[ 245.892667] [<ffffffff81062705>] __do_softirq+0xa5/0x1d0
[ 245.892667] [<ffffffff8141301c>] call_softirq+0x1c/0x30
[ 245.892667] [<ffffffff8100d355>] do_softirq+0x65/0xa0
[ 245.892667] [<ffffffff81062a96>] irq_exit+0x86/0xa0
[ 245.892667] [<ffffffff8100cf01>] do_IRQ+0x61/0xe0
[ 245.892667] [<ffffffff8140a593>] common_interrupt+0x13/0x13
[ 245.892667] <EOI>
[ 245.892667] [<ffffffff81012deb>] ? mwait_idle+0x9b/0x1d0
[ 245.892667] [<ffffffff8140de35>] ? atomic_notifier_call_chain+0x15/0x20
[ 245.892667] [<ffffffff8100a1e6>] cpu_idle+0x56/0xa0
[ 245.892667] [<ffffffff81403729>] start_secondary+0x197/0x19c
[ 245.892667] Code: 8b 47 68 55 48 89 e5 39 c6 77 1c 29 f0 3b 47 6c 89
47 68 72 16 89 f0 48 03 87 e0 00 00 00 48 89 87 e
[ 245.892667] RIP [<ffffffff8134a94b>] skb_pull+0x2b/0x30
[ 245.892667] RSP <ffff88011fd83b20>
[ 246.520989] ---[ end trace ad4c118e9d8ac857 ]---
[ 246.534912] Kernel panic - not syncing: Fatal exception in interrupt
[ 246.534916] Pid: 0, comm: kworker/0:1 Tainted: G D
2.6.39-std-def-alt3 #1
^ permalink raw reply
* Re: [PATCH] cxgb3i: ref count cdev access to prevent modification while in use
From: Neil Horman @ 2011-08-01 11:18 UTC (permalink / raw)
To: netdev; +Cc: Divy Le Ray, Steve Wise, David S. Miller
In-Reply-To: <1311623817-6417-1-git-send-email-nhorman@tuxdriver.com>
On Mon, Jul 25, 2011 at 03:56:57PM -0400, Neil Horman wrote:
> This oops was reported recently:
> d:mon> e
> cpu 0xd: Vector: 300 (Data Access) at [c0000000fd4c7120]
> pc: d00000000076f194: .t3_l2t_get+0x44/0x524 [cxgb3]
> lr: d000000000b02108: .init_act_open+0x150/0x3d4 [cxgb3i]
> sp: c0000000fd4c73a0
> msr: 8000000000009032
> dar: 0
> dsisr: 40000000
> current = 0xc0000000fd640d40
> paca = 0xc00000000054ff80
> pid = 5085, comm = iscsid
> d:mon> t
> [c0000000fd4c7450] d000000000b02108 .init_act_open+0x150/0x3d4 [cxgb3i]
> [c0000000fd4c7500] d000000000e45378 .cxgbi_ep_connect+0x784/0x8e8 [libcxgbi]
> [c0000000fd4c7650] d000000000db33f0 .iscsi_if_rx+0x71c/0xb18
> [scsi_transport_iscsi2]
> [c0000000fd4c7740] c000000000370c9c .netlink_data_ready+0x40/0xa4
> [c0000000fd4c77c0] c00000000036f010 .netlink_sendskb+0x4c/0x9c
> [c0000000fd4c7850] c000000000370c18 .netlink_sendmsg+0x358/0x39c
> [c0000000fd4c7950] c00000000033be24 .sock_sendmsg+0x114/0x1b8
> [c0000000fd4c7b50] c00000000033d208 .sys_sendmsg+0x218/0x2ac
> [c0000000fd4c7d70] c00000000033f55c .sys_socketcall+0x228/0x27c
> [c0000000fd4c7e30] c0000000000086a4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 00000080da560cfc
>
> The root cause was an EEH error, which sent us down the offload_close path in
> the cxgb3 driver, which in turn sets cdev->lldev to NULL, without regard for
> upper layer driver (like the cxgbi drivers) which might have execution contexts
> in the middle of its use. The result is the oops above, when t3_l2t_get attempts
> to dereference cdev->lldev right after the EEH error handler sets it to NULL.
>
> The fix is to reference count the cdev structure. When an EEH error occurs, the
> shutdown path:
> t3_adapter_error->offload_close->cxgb3i_remove_clients->cxgb3i_dev_close
> will now block until such time as the cdev pointer has a use count of zero.
> This coupled with the fact that lookups will now skip finding any registered
> cdev's in cxgbi_device_find_by_[lldev|netdev] with the CXGBI_FLAG_ADAPTER_RESET
> bit set ensures that on an EEH, the setting of lldev to NULL in offload_close
> will only happen after there are no longer any active users of the data
> structure.
>
> This has been tested by the reporter and shown to fix the reproted oops
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Divy Le Ray <divy@chelsio.com>
> CC: Steve Wise <swise@chelsio.com>
> CC: "David S. Miller" <davem@davemloft.net>
Divy, Steve, I think Dave is waiting for an ACK from one of you to, since you're
the listed maintainers.
Neil
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Alan Cox @ 2011-08-01 9:42 UTC (permalink / raw)
To: David Miller
Cc: jeffrey.t.kirsher, netdev, gospo, sassmann, philb, klassert, dave,
jes, becker, craigs, dahinds
In-Reply-To: <20110801.022107.740149515523315115.davem@davemloft.net>
On Mon, 01 Aug 2011 02:21:07 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Alan Cox <alan@linux.intel.com>
> Date: Mon, 1 Aug 2011 10:03:03 +0100
>
> > And even if you wanted to make Kconfig simpler - you don't need to
> > move files around.
>
> The point is to move the files around, so that drivers/net/ isn't
> a turd pond.
>
> I agree with some of your feedback, but I disagree with a wholesale
> rejecting the idea of untangling the mess under drivers/net/ as that's
> the main reason why I want Jeff's work to be done
In which case I think I'd sort by chipset for the non bus distinct
ones. That also has the added advantage that all the annoying weird
crap disappears into its own subdirectories for ancient chipsets !
So my suggestion would be :
Create an i82586 directory
Stick the following into it
3c505 3c507 3c523 3c527 eepro eexpress ni52 sun3_82586 znet
Create an i82596 directory
Stick the following into it
82596 lasi_82596 lib82596 lp486e sni_82596
Create an ns8390 directory
Stick the following into it
3c503 8390 8390p ac3200 apne aax88796 e2100 es3210 hp hp-plus
hydra lib8390 lne390 mac8390 ne ne2 ne2k-pci ne3210 ne-h8300
smc-mca smc-ultra32 smc-ultra stnic wd zorro8390
Create a sonic directory (sadly nobody ever produced a screwdriver card)
Stick the following into it
jazzsonic macsonic sonic xtsonic
Create a lance directory (actually this is 7990 + lance32 etc)
Stick the following into it
7990.c a2065 ariadne atarilance declance hplance lance mvme147
ni65 pcnet32 sun3lance sunlance
Some bits are then sort of bustypeish
Create a parallel directory
Stick the following into it
atp de600 de620 plip
Create a ppp directory
Stick all the ppp bits in
Given x25_asy is in WAN perhaps slip should be there too ?
^ permalink raw reply
* Re: [PATCH 1/6] net: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia
Cc: kernel-janitors, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <1311857165-14780-2-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Thu, 28 Jul 2011 14:46:01 +0200
> From: Julia Lawall <julia@diku.dk>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: eric.dumazet
Cc: kaber, soltys, akpm, netdev, bugme-daemon, hadi, lucas.bocchi,
631945, 00bormoj, fdelawarde
In-Reply-To: <1312003362.2873.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 30 Jul 2011 07:22:42 +0200
> [PATCH] sch_sfq: fix sfq_enqueue()
>
> commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals)
> forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a
> packet (from another flow) was dropped, leading to various problems.
>
> With help from Michal Soltys and Michal Pokrywka, who did a bisection.
>
> Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372
> Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945
>
> Reported-by: Lucas Bocchi <lucas.bocchi@gmail.com>
> Reported-and-bisected-by: Michal Pokrywka <wolfmoon@o2.pl>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Michal Soltys <soltys@ziu.info>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/6] drivers/net/niu.c: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia-dAYI7NvHqcQ
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <1311857165-14780-4-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Date: Thu, 28 Jul 2011 14:46:03 +0200
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Applied.
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Pekka Savola from ipv6.
From: David Miller @ 2011-08-01 9:23 UTC (permalink / raw)
To: netdev; +Cc: pekkas
Signed-off-by: David S. Miller <davem@davemloft.net>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a99fed1..5d4ceba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4443,7 +4443,6 @@ F: include/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
-M: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
--
1.7.6
^ permalink raw reply related
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: David Miller @ 2011-08-01 9:21 UTC (permalink / raw)
To: alan
Cc: jeffrey.t.kirsher, netdev, gospo, sassmann, philb, klassert, dave,
jes, becker, craigs, dahinds
In-Reply-To: <20110801100303.48ed75f7@bob.linux.org.uk>
From: Alan Cox <alan@linux.intel.com>
Date: Mon, 1 Aug 2011 10:03:03 +0100
> And even if you wanted to make Kconfig simpler - you don't need to move
> files around.
The point is to move the files around, so that drivers/net/ isn't
a turd pond.
I agree with some of your feedback, but I disagree with a wholesale
rejecting the idea of untangling the mess under drivers/net/ as that's
the main reason why I want Jeff's work to be done
^ permalink raw reply
* PLEASE REPLY, ITS A BUSINESS PROPOSAL
From: Weixin.Zheng.15 @ 2011-08-01 8:46 UTC (permalink / raw)
This is a business proposal for you, it is an oil exportation proposition
contract for you and this is a highly prospective crude oil sales
venture; This
involves the shipment of over 2.5 Million barrels of Light Crude Oil from Iraq
to Turkey, this project is genuine, legal and highly lucrative. For more
details, please reply to this email address: bahhahfeaz@hotmail.com
Sincerely
Bahhah Faez Saleh
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: Eric Dumazet @ 2011-08-01 9:15 UTC (permalink / raw)
To: synapse; +Cc: David Miller, netdev
In-Reply-To: <4E366A8F.201@hippy.csoma.elte.hu>
Le lundi 01 août 2011 à 10:57 +0200, synapse a écrit :
> Hello
>
> Sorry, I wasn't home on the weekend. Exactly to which tree should I
> apply this?
> It doesn't apply cleanly to 3.0.0. Am I missing something?
>
Could you try latest linux tree ?
We first validate patches on current tree, then backport them if needed
to previous kernels.
Thanks
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Alan Cox @ 2011-08-01 9:03 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Philip Blundell, Steffen Klassert,
David Dillow, Jes Sorensen, Donald Becker, Craig Southeren,
David Hinds
In-Reply-To: <1312082850-24914-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011 20:26:21 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Moves the 3Com drivers into drivers/net/ethernet/3com/ and the
> necessary Kconfig and Makefile changes.
This still seems crazy
The 3c503 is not being moved (as its 8390 based)
But the 3c505/3c523/3c527/3c507 by that logic also shouldn't be moved
as really they all belong with the rest of the Intel devices they are
basically variants of (the 3c527 is weirder, in fact you can probably
run CP/M 86 on it if you were mad enough)
> drivers/net/{pcmcia => ethernet/3com}/3c574_cs.c | 0
> drivers/net/{pcmcia => ethernet/3com}/3c589_cs.c | 0
These are currently sensibly where they belong - with the pcmcia
adapters.
> drivers/net/{ => ethernet/3com}/3c59x.c | 0
> drivers/net/ethernet/3com/Kconfig | 200
> ++++++++++++++++++++++
> drivers/net/ethernet/3com/Makefile | 16 ++
> drivers/net/{ => ethernet/3com}/acenic.c | 0
> drivers/net/{ => ethernet/3com}/acenic.h | 0
And most Acenic devices are probably branded Netgear not 3COM and may
also claim to be from Farallon, SGI, Alteon or DEC. Again not a 3Com
originated part.
So I still think this patch is utter nonsense and just noise.
There isn't any sense in trying to line the network drivers up by
whatever is written on the box that was thrown away years before. The
reality is that most cards do not bear anything relevant to the chipset
vendors name, even by the early 1990s.
Architectually it makes more sense to keep tidy by bus type and by
chipset, not by vendor name
NAK
And even if you wanted to make Kconfig simpler - you don't need to move
files around.
Alan
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: synapse @ 2011-08-01 8:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1312002053.2873.41.camel@edumazet-laptop>
Hello
Sorry, I wasn't home on the weekend. Exactly to which tree should I
apply this?
It doesn't apply cleanly to 3.0.0. Am I missing something?
Gergely Kalman
On 07/30/11 07:00, Eric Dumazet wrote:
> Le vendredi 29 juillet 2011 à 17:43 +0200, Eric Dumazet a écrit :
>
>> Oh well, we already use RCU in neigh_destroy(), so adding rcu would need
>> to change all dst_get_neighbour() callers to be in one rcu_read_lock()
>> section.
>>
>> I'll take a look, I suspect its mostly already done.
>>
>>
> Here is the patch I finally cooked and tested.
>
> Could you please test it as well Gergely ?
>
> Thanks !
>
> [PATCH] net: fix NULL dereferences in check_peer_redir()
>
> Gergely Kalman reported crashes in check_peer_redir().
>
> It appears commit f39925dbde778 (ipv4: Cache learned redirect
> information in inetpeer.) added a race, leading to possible NULL ptr
> dereference.
>
> Since we can now change dst neighbour, we should make sure a reader can
> safely use a neighbour.
>
> Add RCU protection to dst neighbour, and make sure check_peer_redir()
> can be called safely by different cpus in parallel.
>
> As neighbours are already freed after one RCU grace period, this patch
> should not add typical RCU penalty (cache cold effects)
>
> Many thanks to Gergely for providing a pretty report pointing to the
> bug.
>
> Reported-by: Gergely Kalman<synapse@hippy.csoma.elte.hu>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> ---
> include/net/dst.h | 17 +++++++++++++----
> net/ipv4/ip_output.c | 10 ++++++++--
> net/ipv4/route.c | 14 ++++++++------
> net/ipv6/addrconf.c | 2 +-
> net/ipv6/ip6_fib.c | 2 +-
> net/ipv6/ip6_output.c | 13 +++++++++++--
> net/ipv6/route.c | 35 +++++++++++++++++++++++++----------
> 7 files changed, 67 insertions(+), 26 deletions(-)
>
> diff --git a/include/net/dst.h b/include/net/dst.h
> index 29e2557..13d507d 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -37,7 +37,7 @@ struct dst_entry {
> unsigned long _metrics;
> unsigned long expires;
> struct dst_entry *path;
> - struct neighbour *_neighbour;
> + struct neighbour __rcu *_neighbour;
> #ifdef CONFIG_XFRM
> struct xfrm_state *xfrm;
> #else
> @@ -88,12 +88,17 @@ struct dst_entry {
>
> static inline struct neighbour *dst_get_neighbour(struct dst_entry *dst)
> {
> - return dst->_neighbour;
> + return rcu_dereference(dst->_neighbour);
> +}
> +
> +static inline struct neighbour *dst_get_neighbour_raw(struct dst_entry *dst)
> +{
> + return rcu_dereference_raw(dst->_neighbour);
> }
>
> static inline void dst_set_neighbour(struct dst_entry *dst, struct neighbour *neigh)
> {
> - dst->_neighbour = neigh;
> + rcu_assign_pointer(dst->_neighbour, neigh);
> }
>
> extern u32 *dst_cow_metrics_generic(struct dst_entry *dst, unsigned long old);
> @@ -382,8 +387,12 @@ static inline void dst_rcu_free(struct rcu_head *head)
> static inline void dst_confirm(struct dst_entry *dst)
> {
> if (dst) {
> - struct neighbour *n = dst_get_neighbour(dst);
> + struct neighbour *n;
> +
> + rcu_read_lock();
> + n = dst_get_neighbour(dst);
> neigh_confirm(n);
> + rcu_read_unlock();
> }
> }
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index ccaaa85..77d3ede 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -204,9 +204,15 @@ static inline int ip_finish_output2(struct sk_buff *skb)
> skb = skb2;
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
> +
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
>
> if (net_ratelimit())
> printk(KERN_DEBUG "ip_finish_output2: No header cache and no neighbour!\n");
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 1730689..6afc4eb 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1628,16 +1628,18 @@ static int check_peer_redir(struct dst_entry *dst, struct inet_peer *peer)
> {
> struct rtable *rt = (struct rtable *) dst;
> __be32 orig_gw = rt->rt_gateway;
> - struct neighbour *n;
> + struct neighbour *n, *old_n;
>
> dst_confirm(&rt->dst);
>
> - neigh_release(dst_get_neighbour(&rt->dst));
> - dst_set_neighbour(&rt->dst, NULL);
> -
> rt->rt_gateway = peer->redirect_learned.a4;
> - rt_bind_neighbour(rt);
> - n = dst_get_neighbour(&rt->dst);
> +
> + n = ipv4_neigh_lookup(&rt->dst,&rt->rt_gateway);
> + if (IS_ERR(n))
> + return PTR_ERR(n);
> + old_n = xchg(&rt->dst._neighbour, n);
> + if (old_n)
> + neigh_release(old_n);
> if (!n || !(n->nud_state& NUD_VALID)) {
> if (n)
> neigh_event_send(n, NULL);
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a55500c..f012ebd 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -656,7 +656,7 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
> * layer address of our nexhop router
> */
>
> - if (dst_get_neighbour(&rt->dst) == NULL)
> + if (dst_get_neighbour_raw(&rt->dst) == NULL)
> ifa->flags&= ~IFA_F_OPTIMISTIC;
>
> ifa->idev = idev;
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index 54a4678..320d91d 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -1455,7 +1455,7 @@ static int fib6_age(struct rt6_info *rt, void *arg)
> RT6_TRACE("aging clone %p\n", rt);
> return -1;
> } else if ((rt->rt6i_flags& RTF_GATEWAY)&&
> - (!(dst_get_neighbour(&rt->dst)->flags& NTF_ROUTER))) {
> + (!(dst_get_neighbour_raw(&rt->dst)->flags& NTF_ROUTER))) {
> RT6_TRACE("purging route %p via non-router but gateway\n",
> rt);
> return -1;
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 32e5339..4c882cf 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -135,10 +135,15 @@ static int ip6_finish_output2(struct sk_buff *skb)
> skb->len);
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
>
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
> IP6_INC_STATS_BH(dev_net(dst->dev),
> ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
> kfree_skb(skb);
> @@ -975,12 +980,14 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> * dst entry and replace it instead with the
> * dst entry of the nexthop router
> */
> + rcu_read_lock();
> n = dst_get_neighbour(*dst);
> if (n&& !(n->nud_state& NUD_VALID)) {
> struct inet6_ifaddr *ifp;
> struct flowi6 fl_gw6;
> int redirect;
>
> + rcu_read_unlock();
> ifp = ipv6_get_ifaddr(net,&fl6->saddr,
> (*dst)->dev, 1);
>
> @@ -1000,6 +1007,8 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> if ((err = (*dst)->error))
> goto out_err_release;
> }
> + } else {
> + rcu_read_unlock();
> }
> #endif
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index e8987da..9e69eb0 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -364,7 +364,7 @@ out:
> #ifdef CONFIG_IPV6_ROUTER_PREF
> static void rt6_probe(struct rt6_info *rt)
> {
> - struct neighbour *neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> + struct neighbour *neigh;
> /*
> * Okay, this does not seem to be appropriate
> * for now, however, we need to check if it
> @@ -373,8 +373,10 @@ static void rt6_probe(struct rt6_info *rt)
> * Router Reachability Probe MUST be rate-limited
> * to no more than one per minute.
> */
> + rcu_read_lock();
> + neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> if (!neigh || (neigh->nud_state& NUD_VALID))
> - return;
> + goto out;
> read_lock_bh(&neigh->lock);
> if (!(neigh->nud_state& NUD_VALID)&&
> time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
> @@ -387,8 +389,11 @@ static void rt6_probe(struct rt6_info *rt)
> target = (struct in6_addr *)&neigh->primary_key;
> addrconf_addr_solict_mult(target,&mcaddr);
> ndisc_send_ns(rt->rt6i_dev, NULL, target,&mcaddr, NULL);
> - } else
> + } else {
> read_unlock_bh(&neigh->lock);
> + }
> +out:
> + rcu_read_unlock();
> }
> #else
> static inline void rt6_probe(struct rt6_info *rt)
> @@ -412,8 +417,11 @@ static inline int rt6_check_dev(struct rt6_info *rt, int oif)
>
> static inline int rt6_check_neigh(struct rt6_info *rt)
> {
> - struct neighbour *neigh = dst_get_neighbour(&rt->dst);
> + struct neighbour *neigh;
> int m;
> +
> + rcu_read_lock();
> + neigh = dst_get_neighbour(&rt->dst);
> if (rt->rt6i_flags& RTF_NONEXTHOP ||
> !(rt->rt6i_flags& RTF_GATEWAY))
> m = 1;
> @@ -430,6 +438,7 @@ static inline int rt6_check_neigh(struct rt6_info *rt)
> read_unlock_bh(&neigh->lock);
> } else
> m = 0;
> + rcu_read_unlock();
> return m;
> }
>
> @@ -769,7 +778,7 @@ static struct rt6_info *rt6_alloc_clone(struct rt6_info *ort,
> rt->rt6i_dst.plen = 128;
> rt->rt6i_flags |= RTF_CACHE;
> rt->dst.flags |= DST_HOST;
> - dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour(&ort->dst)));
> + dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour_raw(&ort->dst)));
> }
> return rt;
> }
> @@ -803,7 +812,7 @@ restart:
> dst_hold(&rt->dst);
> read_unlock_bh(&table->tb6_lock);
>
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt,&fl6->daddr,&fl6->saddr);
> else if (!(rt->dst.flags& DST_HOST))
> nrt = rt6_alloc_clone(rt,&fl6->daddr);
> @@ -1587,7 +1596,7 @@ void rt6_redirect(const struct in6_addr *dest, const struct in6_addr *src,
> dst_confirm(&rt->dst);
>
> /* Duplicate redirect: silently ignore. */
> - if (neigh == dst_get_neighbour(&rt->dst))
> + if (neigh == dst_get_neighbour_raw(&rt->dst))
> goto out;
>
> nrt = ip6_rt_copy(rt, dest);
> @@ -1682,7 +1691,7 @@ again:
> 1. It is connected route. Action: COW
> 2. It is gatewayed route or NONEXTHOP route. Action: clone it.
> */
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt, daddr, saddr);
> else
> nrt = rt6_alloc_clone(rt, daddr);
> @@ -2326,6 +2335,7 @@ static int rt6_fill_node(struct net *net,
> struct nlmsghdr *nlh;
> long expires;
> u32 table;
> + struct neighbour *n;
>
> if (prefix) { /* user wants prefix routes only */
> if (!(rt->rt6i_flags& RTF_PREFIX_RT)) {
> @@ -2414,8 +2424,11 @@ static int rt6_fill_node(struct net *net,
> if (rtnetlink_put_metrics(skb, dst_metrics_ptr(&rt->dst))< 0)
> goto nla_put_failure;
>
> - if (dst_get_neighbour(&rt->dst))
> - NLA_PUT(skb, RTA_GATEWAY, 16,&dst_get_neighbour(&rt->dst)->primary_key);
> + rcu_read_lock();
> + n = dst_get_neighbour(&rt->dst);
> + if (n)
> + NLA_PUT(skb, RTA_GATEWAY, 16,&n->primary_key);
> + rcu_read_unlock();
>
> if (rt->dst.dev)
> NLA_PUT_U32(skb, RTA_OIF, rt->rt6i_dev->ifindex);
> @@ -2608,12 +2621,14 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
> #else
> seq_puts(m, "00000000000000000000000000000000 00 ");
> #endif
> + rcu_read_lock();
> n = dst_get_neighbour(&rt->dst);
> if (n) {
> seq_printf(m, "%pi6", n->primary_key);
> } else {
> seq_puts(m, "00000000000000000000000000000000");
> }
> + rcu_read_unlock();
> seq_printf(m, " %08x %08x %08x %08x %8s\n",
> rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
> rt->dst.__use, rt->rt6i_flags,
>
^ permalink raw reply
* Re: [PATCH 2/2] ipg: Use const
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <5311ff3fa329c4551cfdec5960162d3d490509f1.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:15 -0700
> Make a couple of declarations const to save some data space.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 2/2] bna: HW Interface Init Update
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-2-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:27 -0700
> Change details:
> - Split the hw interface into common and asic specific to support new asic
> in the future.
> - Fix bfa_ioc_ct_isr_mode_set() to also include the case that we are already
> in the desired msix mode.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] ipg: Use current logging styles
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <2ee87bfccbbb5cf1776df6751b65e4a3110019f4.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:14 -0700
> Add and use pr_fmt, pr_<level> and netdev_<level>.
> Convert printks with %[n].[n]x to %nx to be shorter
> and clearer.
> Consolidate printks to use a single printk rather
> than continued printks without KERN_CONT.
> Removed unnecessary trailing periods.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:26 -0700
> Change details:
> - ioc->cna is always set to 1 for eth functions, remove the check that
> asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
> bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox