* Re: [PATCH v3] sky2: copy received packets on inefficient unaligned architecture
From: David Miller @ 2012-04-04 22:14 UTC (permalink / raw)
To: shemminger; +Cc: cmetcalf, netdev, linux-kernel
In-Reply-To: <20120404151027.047c183b@s6510.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 4 Apr 2012 15:10:27 -0700
> Modified from original patch from Chris.
>
> The sky2 driver has to have 8 byte alignment of receive buffer
> on some chip versions. On architectures which don't support efficient
> unaligned access this doesn't work very well. The solution is to
> just copy all received packets which is what the driver already
> does for small packets.
>
> This allows the driver to be used on the Tilera TILEmpower-Gx, since
> the tile architecture doesn't currently handle kernel unaligned accesses,
> just userspace.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> Acked-by: Chris Metcalf <cmetcalf@tilera.com>
Applied.
^ permalink raw reply
* Re: [PATCH] scpt: Allow struct sctp_event_subscribe to grow without breaking binaries
From: Thomas Graf @ 2012-04-04 22:13 UTC (permalink / raw)
To: David Miller; +Cc: vladislav.yasevich, linux-sctp, netdev
In-Reply-To: <20120404.180552.936202389292040147.davem@davemloft.net>
On Wed, Apr 04, 2012 at 06:05:52PM -0400, David Miller wrote:
> From: Vladislav Yasevich <vladislav.yasevich@hp.com>
> Date: Wed, 04 Apr 2012 09:52:04 -0400
> >
> > Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
>
> Applied, but I had to fix the Subject to read "sctp: " not "scpt: " :-)
Thanks much Dave :)
^ permalink raw reply
* Re: [PATCH net V1 2/2] net/bonding: correctly proxy slave neigh param setup ndo function
From: David Miller @ 2012-04-04 22:12 UTC (permalink / raw)
To: ogerlitz; +Cc: roland, netdev, fubar, shlomop
In-Reply-To: <1333529780-28421-3-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 4 Apr 2012 11:56:20 +0300
> From: Shlomo Pongratz <shlomop@mellanox.com>
>
> The current implemenation was buggy for slaves who use ndo_neigh_setup,
> since the networking stack invokes the bonding device ndo entry (from
> neigh_params_alloc) before any devices are enslaved, and the bonding
> driver can't further delegate the call at that point in time. As a
> result when bonding IPoIB devices, the neigh_cleanup hasn't been called.
>
> Fix that by deferring the actual call into the slave ndo_neigh_setup
> from the time the bonding neigh_setup is called.
>
> Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V1 1/2] net/bonding: emit address change event also in bond_release
From: David Miller @ 2012-04-04 22:12 UTC (permalink / raw)
To: ogerlitz; +Cc: roland, netdev, fubar, shlomop
In-Reply-To: <1333529780-28421-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 4 Apr 2012 11:56:19 +0300
> From: Shlomo Pongratz <shlomop@mellanox.com>
>
> commit 7d26bb103c4 "bonding: emit event when bonding changes MAC" didn't
> take care to emit the NETDEV_CHANGEADDR event in bond_release, where bonding
> actually changes the mac address (to all zeroes). As a result the neighbours
> aren't deleted by the core networking code (which does so upon getting that
> event).
>
> Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Applied.
^ permalink raw reply
* [PATCH v3] sky2: copy received packets on inefficient unaligned architecture
From: Stephen Hemminger @ 2012-04-04 22:10 UTC (permalink / raw)
To: Chris Metcalf; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4F7CC2AC.5040309@tilera.com>
Modified from original patch from Chris.
The sky2 driver has to have 8 byte alignment of receive buffer
on some chip versions. On architectures which don't support efficient
unaligned access this doesn't work very well. The solution is to
just copy all received packets which is what the driver already
does for small packets.
This allows the driver to be used on the Tilera TILEmpower-Gx, since
the tile architecture doesn't currently handle kernel unaligned accesses,
just userspace.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
--- a/drivers/net/ethernet/marvell/sky2.c 2012-04-04 08:49:05.954853108 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c 2012-04-04 15:03:41.725705876 -0700
@@ -2468,6 +2468,17 @@ static int sky2_change_mtu(struct net_de
return err;
}
+static inline bool needs_copy(const struct rx_ring_info *re,
+ unsigned length)
+{
+#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
+ /* Some architectures need the IP header to be aligned */
+ if (!IS_ALIGNED(re->data_addr + ETH_HLEN, sizeof(u32)))
+ return true;
+#endif
+ return length < copybreak;
+}
+
/* For small just reuse existing skb for next receive */
static struct sk_buff *receive_copy(struct sky2_port *sky2,
const struct rx_ring_info *re,
@@ -2605,7 +2616,7 @@ static struct sk_buff *sky2_receive(stru
goto error;
okay:
- if (length < copybreak)
+ if (needs_copy(re, length))
skb = receive_copy(sky2, re, length);
else
skb = receive_new(sky2, re, length);
^ permalink raw reply
* Re: [PATCH] net: lpc_eth: no need to reserve 8 extra bytes in rx skb
From: David Miller @ 2012-04-04 22:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, stigge
In-Reply-To: <1333490531.18626.336.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 04 Apr 2012 00:02:11 +0200
> Probably a leftover from ancient code...
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Roland Stigge <stigge@antcom.de>
Applied to net-next, thanks Eric.
^ permalink raw reply
* Re: [PATCH] Driver: Atm: Remove 'break' after 'return' statement.
From: David Miller @ 2012-04-04 22:07 UTC (permalink / raw)
To: santoshprasadnayak; +Cc: chas, linux-atm-general, netdev, kernel-janitors
In-Reply-To: <1333453638-6235-1-git-send-email-santoshprasadnayak@gmail.com>
From: santosh nayak <santoshprasadnayak@gmail.com>
Date: Tue, 3 Apr 2012 17:17:18 +0530
> From: Santosh Nayak <santoshprasadnayak@gmail.com>
>
> 'break' is unnecessary after 'return' statement.
> Remove all such 'break' as clean up.
>
> Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: sky2: in free_buffers() do proper checks before call of rx_clean()
From: David Miller @ 2012-04-04 22:07 UTC (permalink / raw)
To: LinoSanfilippo; +Cc: shemminger, mlindner, netdev, linux-kernel
In-Reply-To: <20120403001327.GB10227@Neptun>
From: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Date: Tue, 3 Apr 2012 02:13:27 +0200
> In sky2_open() free_buffers() is called in case that alloc_buffers() failed.
> Here we do the check for sky2->rx_le too late, since we already called
> rx_clean() which accessed rx_le. Furthermore we lack a check for sky2->rx_ring
> which is also accessed by rx_clean().
>
> With this patch both sky2->rx_le and sky2->rx_ring are checked before
> alloc_buffers() is called.
>
> Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Ping?
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update for Marvell Ethernet drivers
From: David Miller @ 2012-04-04 22:06 UTC (permalink / raw)
To: shemminger; +Cc: mlindner, netdev
In-Reply-To: <20120402155947.7167ef2d@s6510.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 2 Apr 2012 15:59:47 -0700
> Marvell has agreed to do maintenance on the sky2 driver.
> * Add the developer to the maintainers file
> * Remove the old reference to the long gone (sk98lin) driver
> * Rearrange to fit current topic organization
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> Please hold this patch until ack'd by Mirko.
Tick... tock... tick... tock...
^ permalink raw reply
* Re: [PATCH] scpt: Allow struct sctp_event_subscribe to grow without breaking binaries
From: David Miller @ 2012-04-04 22:05 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: linux-sctp, netdev
In-Reply-To: <4F7C5204.9040703@hp.com>
From: Vladislav Yasevich <vladislav.yasevich@hp.com>
Date: Wed, 04 Apr 2012 09:52:04 -0400
> On 04/04/2012 04:17 AM, Thomas Graf wrote:
>> getsockopt(..., SCTP_EVENTS, ...) performs a length check and returns
>> an error if the user provides less bytes than the size of struct
>> sctp_event_subscribe.
>>
>> Struct sctp_event_subscribe needs to be extended by an u8 for every
>> new event or notification type that is added.
>>
>> This obviously makes getsockopt fail for binaries that are compiled
>> against an older versions of <net/sctp/user.h> which do not contain
>> all event types.
>>
>> This patch changes getsockopt behaviour to no longer return an error
>> if not enough bytes are being provided by the user. Instead, it
>> returns as much of sctp_event_subscribe as fits into the provided buffer.
>>
>> This leads to the new behavior that users see what they have been aware
>> of at compile time.
>>
>> The setsockopt(..., SCTP_EVENTS, ...) API is already behaving like this.
>>
>> Signed-off-by: Thomas Graf <tgraf@suug.ch>
>
> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied, but I had to fix the Subject to read "sctp: " not "scpt: " :-)
^ permalink raw reply
* 3.3.0, 3.4-rc1 reproducible tun Oops
From: Simon Kirby @ 2012-04-04 22:05 UTC (permalink / raw)
To: netdev
I use an SSH VPN occasionally from home, and since upgrading the remote
kernel to 3.3.0, the it now seems to Oops when I ^C the tunnel with
sockets still active. If I start the tunnel, log in to a box through it
and run "vmstat 1", ^C the tunnel SSH process, and start it up again, I
get an Oops like this:
BUG: unable to handle kernel NULL pointer dereference at 00000000000000ff
IP: [<ffffffff810ed5fa>] __kmalloc_track_caller+0xaa/0x1b0
PGD 12d2bc067 PUD 0
Oops: 0000 [#1] SMP
CPU 1
Modules linked in: nf_conntrack_netlink nfnetlink iptable_mangle ipt_MASQUERADE xt_state xt_conntrack iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack hwmon_vid ppp_async ppp_generic slhc crc_ccitt tun nvidia(PO) uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core e100
Pid: 16156, comm: sshd Tainted: P O 3.3.0 #32 System manufacturer System Product Name/A8N-VM CSM
RIP: 0010:[<ffffffff810ed5fa>] [<ffffffff810ed5fa>] __kmalloc_track_caller+0xaa/0x1b0
RSP: 0000:ffff88012d0b3b58 EFLAGS: 00210206
RAX: 0000000000000000 RBX: ffff8801783f8e00 RCX: 000000000002c11f
RDX: 000000000002c11e RSI: 00000000000000d0 RDI: 0000000000014ac0
RBP: ffff88012d0b3ba8 R08: ffffffff81693c81 R09: ffff88007f546f30
R10: 00000000f80057e0 R11: 0000000000000000 R12: 00000000000000ff
R13: ffff88017b002900 R14: 0000000000000800 R15: 0000000000000800
FS: 0000000000000000(0000) GS:ffff88017fd00000(0063) knlGS:00000000f71ea740
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000000000ff CR3: 000000011906a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process sshd (pid: 16156, threadinfo ffff88012d0b2000, task ffff880100a43a00)
Stack:
dead000000200200 ffff88007fabc0c0 ffffffff816d692c 000000d0000000db
ffff880100000000 ffff8801783f8e00 0000000000000001 00000000000000d0
ffff88017b002780 0000000000000800 ffff88012d0b3be8 ffffffff81693cae
Call Trace:
[<ffffffff816d692c>] ? sk_stream_alloc_skb+0x3c/0x110
[<ffffffff81693cae>] __alloc_skb+0x6e/0x220
[<ffffffff816d692c>] sk_stream_alloc_skb+0x3c/0x110
[<ffffffff816d6c90>] tcp_sendmsg+0x290/0xd90
[<ffffffff81694537>] ? skb_release_data+0xe7/0xf0
[<ffffffffa0032e3a>] ? tun_do_read.isra.24+0x29a/0x420 [tun]
[<ffffffff816f8703>] inet_sendmsg+0x43/0xb0
[<ffffffff8168b78e>] sock_aio_write+0x10e/0x130
[<ffffffff810f04fa>] do_sync_write+0xca/0x110
[<ffffffff8104676a>] ? set_current_blocked+0x3a/0x60
[<ffffffff810467d5>] ? sigprocmask+0x45/0x80
[<ffffffff810f0e15>] vfs_write+0x165/0x180
[<ffffffff810f1085>] sys_write+0x45/0x90
[<ffffffff818098f9>] ia32_do_call+0x13/0x13
Code: 76 bf 49 8b 4d 00 65 48 03 0c 25 b8 cb 00 00 48 8b 51 08 4c 8b 21 4d 85 e4 0f 84 eb 00 00 00 49 63 45 20 49 8b 7d 00 48 8d 4a 01 <49> 8b 1c 04 4c 89 e0 48 8d 37 e8 37 41 28 00 84 c0 74 c4 4d 85
RIP [<ffffffff810ed5fa>] __kmalloc_track_caller+0xaa/0x1b0
RSP <ffff88012d0b3b58>
CR2: 00000000000000ff
---[ end trace 4a40da26b9b3bff5 ]---
Looks like it might need some poisoning there. Sometimes the Oops stops
before it is fully emitted over the serial port. I have verified that
this happens on v3.3 and current Linus head (3.4-rc1+) and not on v3.2.
When I get some more time, I will try to track it down a bit further.
ssh -w any <vpn box> 'ifconfig tun0 x pointopoint y; echo "ifconfig tun0 y pointopoint x && ip route add 10.0.0.0/8 via x"; sleep 1d' | sh -v
Simon-
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: add missing parenthesis to prevent u32 overflow
From: David Miller @ 2012-04-04 22:04 UTC (permalink / raw)
To: yuvalmin; +Cc: netdev, dmitry, eilong
In-Reply-To: <1333542462-22658-1-git-send-email-yuvalmin@broadcom.com>
From: "Yuval Mintz" <yuvalmin@broadcom.com>
Date: Wed, 4 Apr 2012 15:27:42 +0300
> From: Dmitry Kravkov <dmitry@broadcom.com>
>
> Commit b475d78 lacked two pairs of parenthesis, causing an overflow in the
> congestion management.
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next V6 7/8] net/dcb: Add an optional max rate attribute
From: Or Gerlitz @ 2012-04-04 21:56 UTC (permalink / raw)
To: John Fastabend
Cc: Amir Vadai, David S. Miller, netdev, Roland Dreier,
Yevgeny Petrilin, Oren Duer
In-Reply-To: <4F7C6D3C.7070807@intel.com>
On Wed, Apr 4, 2012 at 6:48 PM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> And I think the last comment. We really should have a comment here describing
> what the tc_maxrate field is. Its described in the commit log but its much
> harder for implementers to get it wrong when the struct is annotated.
Okay, John, sure, we can add that, so just to make sure, from your
side the series is okay once this comment is added, correct?
Or.
^ permalink raw reply
* Re: [PATCH v2] marvell sky2 driver: fix so it works without unaligned accesses
From: Chris Metcalf @ 2012-04-04 21:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20120404114253.5f84d4c8@s6510.linuxnetplumber.net>
On 4/4/2012 2:42 PM, Stephen Hemminger wrote:
> On Wed, 4 Apr 2012 10:13:32 -0400
> Chris Metcalf <cmetcalf@tilera.com> wrote:
>
>> The driver uses a receive_new() routine that ends up requiring unaligned
>> accesses in IP header processing. If the architecture doesn't support
>> efficient unaligned accesses, and SKY2_HW_RAM_BUFFER is set,
>> just copy all ingress packets to the bounce buffers instead.
>> Thanks to Eric Dumazet for pointing out the SKY2_HW_RAM_BUFFER issue.
>>
>> This allows the driver to be used on the Tilera TILEmpower-Gx, since
>> the tile architecture doesn't currently handle kernel unaligned accesses,
>> just userspace.
>>
>> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
>> ---
>> drivers/net/ethernet/marvell/sky2.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
> What about the following (compile tested only)
> --- a/drivers/net/ethernet/marvell/sky2.c 2012-04-04 08:49:05.954853108 -0700
> +++ b/drivers/net/ethernet/marvell/sky2.c 2012-04-04 11:30:54.201432707 -0700
> @@ -2468,6 +2468,17 @@ static int sky2_change_mtu(struct net_de
> return err;
> }
>
> +static inline bool needs_copy(const struct rx_ring_info *re,
> + unsigned length)
> +{
> +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> + /* Some architectures need the IP header to be aligned */
> + if (!IS_ALIGNED(re->data_addr + ETH_HLEN, sizeof(u32)))
> + return 1;
> +#endif
> + return length < copybreak;
> +}
> +
> /* For small just reuse existing skb for next receive */
> static struct sk_buff *receive_copy(struct sky2_port *sky2,
> const struct rx_ring_info *re,
> @@ -2605,7 +2616,7 @@ static struct sk_buff *sky2_receive(stru
> goto error;
>
> okay:
> - if (length < copybreak)
> + if (needs_copy(re, length))
> skb = receive_copy(sky2, re, length);
> else
> skb = receive_new(sky2, re, length);
Acked-by: Chris Metcalf <cmetcalf@tilera.com>
This works on our TILEmpower-Gx boxes and seems like it's likely more
efficient. I believe kernel style says you should "return true" rather
than "return 1" from a "bool" routine, though.
Thanks!
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [patch net-next 3/4] team: add binary option type
From: David Miller @ 2012-04-04 21:45 UTC (permalink / raw)
To: jpirko
Cc: netdev, eric.dumazet, bhutchings, shemminger, raise.sail,
nuno.martins, matt
In-Reply-To: <20120404122930.GD2202@minipsycho.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 4 Apr 2012 14:29:31 +0200
> Wed, Apr 04, 2012 at 12:38:16AM CEST, davem@davemloft.net wrote:
>>From: Jiri Pirko <jpirko@redhat.com>
>>Date: Sat, 31 Mar 2012 23:01:21 +0200
>>
>>> For transfering generic binary data (e.g. BPF code), introduce new
>>> binary option type.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>>Several issues:
>>
>>> + struct team_option_binary tbinary;
>>
>>You put this into a netlink attribute, it has a non-fixed
>>type size because it uses pointer. A compat task will do
>>the wrong thing and you won't interpret it's attribute
>>correctly.
>
> I'm not nla_putting struct team_option_binary tbinary. I'm putting only
> the data on what the pointer stored into that points (tbinary.data):
>
> nla_put(skb, TEAM_ATTR_OPTION_DATA, tbinary.data_len, tbinary.data));
Aha, I misread, thanks for explaining.
^ permalink raw reply
* Re: [PATCH] tilepro ethernet driver: fix a few minor issues
From: David Miller @ 2012-04-04 21:44 UTC (permalink / raw)
To: cmetcalf; +Cc: netdev, linux-kernel
In-Reply-To: <4F7C3C00.5020105@tilera.com>
From: Chris Metcalf <cmetcalf@tilera.com>
Date: Wed, 4 Apr 2012 08:18:08 -0400
> It didn't occur to me that you would push it through the net tree; I
> assumed I would push it through the tile tree.
If it's purely changes inside the networking driver, best to push
it through the networking tree(s).
^ permalink raw reply
* Re: [PATCH] m68k/atari: EtherNEC - rewrite to use mainstream ne.c, take two
From: Paul Gortmaker @ 2012-04-04 20:46 UTC (permalink / raw)
To: Michael Schmitz; +Cc: Geert Uytterhoeven, linux-m68k, netdev
In-Reply-To: <4F7816B0.3090802@gmail.com>
On 12-04-01 04:49 AM, Michael Schmitz wrote:
> Hi Paul, Geert,
>> And on re-reading the comments in the other part of the patch, i.e.
>> "...emulates the card interrupt via a timer" --perhaps the driver
>> should be just fixed to support generic netpoll, instead of adding
>> an arch specific thing that amounts to netpoll. Then anyone can
>> attempt to limp along and use one of these ancient relics w/o IRQ.
>>
> Here's take two of my patch to convert the m68k Atari ROM port Ethernet
> driver to use mainstream ne.c, with minimal changes to the core NE2000
> code.
>
> In particular:
>
> Changes to core net code:
> * add a platform specific IRQ flag, so ne.c can share a hardware or
> timer interrupt with some other interrupt source.
>
> Changes to arch/m68k code:
> * register the 8390 platform device on Atari only if the hardware is present
> * retain the old driver (atari_ethernec.c in Geert's tree) under a
> different config option, to be removed soon.
>
> Regarding your suggestion that netpoll be used instead of a dedicated
> timer interrupt: no changes to ne.c or 8390p.c are required to use
> netpoll, it all works out of the box. All that is needed to use the
> driver with netpoll is setting the device interrupt to some source that
> can be registered, and enabling CONFIG_NETPOLL. Interrupt rate and hence
> throughput is lower with netpoll though, which is why I still prefer the
> dedicated timer option.
How much lower? Enough to matter? Implicit in that question is
the assumption that this is largely a hobbyist platform and nobody
is using it in a closet to route gigabytes of traffic.
Also, the only advantage to modifying ne.c is to allow dumping
the old driver. What is the "remove soon" plan? Any reason
for it to not be synchronous? That would eliminate the Kconfig
churn and the introduction of the _OLD option. Modifying ne.c
and then deciding to keep the old driver because it is "faster"
would make this change pointless.
>
> Comments?
Some specific to the non-atari network parts inline below.
P.
>
> Cheers,
>
> Michael Schmitz
>
> Signed-off-by: Michael Schmitz <schmitz@debian.org>
>
> --
> arch/m68k/atari/config.c | 41
> +++++++++++++++++++++++++---
> drivers/net/Space.c | 2 +-
> drivers/net/ethernet/8390/8390.h | 8 +++++
> drivers/net/ethernet/8390/Kconfig | 18 +++++++++++-
> drivers/net/ethernet/8390/Makefile | 3 +-
> drivers/net/ethernet/8390/atari_ethernec.c | 6 ++--
> drivers/net/ethernet/8390/ne.c | 5 ++-
> 7 files changed, 71 insertions(+), 12 deletions(-)
>
[...]
> diff --git a/drivers/net/ethernet/8390/8390.h
> b/drivers/net/ethernet/8390/8390.h
> index ef325ff..9416245 100644
> --- a/drivers/net/ethernet/8390/8390.h
> +++ b/drivers/net/ethernet/8390/8390.h
> @@ -32,6 +32,14 @@ extern void ei_poll(struct net_device *dev);
> extern void eip_poll(struct net_device *dev);
> #endif
>
> +/* Some platforms may need special IRQ flags */
> +#if IS_ENABLED(CONFIG_ATARI_ETHERNEC)
> +# define EI_IRQ_FLAGS IRQF_SHARED
> +#endif
> +
> +#ifndef EI_IRQ_FLAGS
> +# define EI_IRQ_FLAGS 0
> +#endif
This seems more klunky than it needs to be. If we assume that anyone
building ne.c on atari is hence trying to drive an ethernec device
than it can just be
#ifdef CONFIG_ATARI
#define EI_IRQ_FLAGS IRQF_SHARED
#else
#define EI_IRQ_FLAGS 0
#endif
>
> /* Without I/O delay - non ISA or later chips */
> extern void NS8390_init(struct net_device *dev, int startp);
> diff --git a/drivers/net/ethernet/8390/Kconfig
> b/drivers/net/ethernet/8390/Kconfig
> index b801056..75875f2 100644
> --- a/drivers/net/ethernet/8390/Kconfig
> +++ b/drivers/net/ethernet/8390/Kconfig
> @@ -226,11 +226,27 @@ config APNE
> config ATARI_ETHERNEC
> tristate "Atari EtherNEC Ethernet support"
> depends on ATARI_ROM_ISA
> - help
> + select CRC32
> + ---help---
> + Say Y to include support for the EtherNEC network adapter for the
> + ROM port. The driver works by polling instead of interrupts, so it
> + is quite slow.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called ne.
> +
> +config ATARI_ETHERNEC_OLD
> + tristate "Atari EtherNEC Ethernet support - obsolete driver"
> + depends on ATARI_ROM_ISA
> + select CRC32
> + ---help---
> Say Y to include support for the EtherNEC network adapter for the
> ROM port. The driver works by polling instead of interrupts, so it
> is quite slow.
>
> + To compile this driver as a module, choose M here: the module
> + will be called atari_ethernec.
> +
> config NE3210
> tristate "Novell/Eagle/Microdyne NE3210 EISA support (EXPERIMENTAL)"
> depends on PCI && EISA && EXPERIMENTAL
> diff --git a/drivers/net/ethernet/8390/Makefile
> b/drivers/net/ethernet/8390/Makefile
> index d896466..e620355 100644
> --- a/drivers/net/ethernet/8390/Makefile
> +++ b/drivers/net/ethernet/8390/Makefile
> @@ -6,7 +6,8 @@ obj-$(CONFIG_MAC8390) += mac8390.o
> obj-$(CONFIG_AC3200) += ac3200.o 8390.o
> obj-$(CONFIG_APNE) += apne.o 8390.o
> obj-$(CONFIG_ARM_ETHERH) += etherh.o
> -obj-$(CONFIG_ATARI_ETHERNEC) += atari_ethernec.o 8390.o
> +obj-$(CONFIG_ATARI_ETHERNEC_OLD) += atari_ethernec.o 8390.o
> +obj-$(CONFIG_ATARI_ETHERNEC) += ne.o 8390p.o
> obj-$(CONFIG_AX88796) += ax88796.o
> obj-$(CONFIG_E2100) += e2100.o 8390.o
> obj-$(CONFIG_EL2) += 3c503.o 8390p.o
> diff --git a/drivers/net/ethernet/8390/atari_ethernec.c
> b/drivers/net/ethernet/8390/atari_ethernec.c
> index 086d968..5e8fb97 100644
> --- a/drivers/net/ethernet/8390/atari_ethernec.c
> +++ b/drivers/net/ethernet/8390/atari_ethernec.c
> @@ -185,13 +185,13 @@ bad_clone_list[] __initdata = {
> # define DCR_VAL 0x4b
> #elif defined(CONFIG_PLAT_OAKS32R) || \
> defined(CONFIG_TOSHIBA_RBTX4927) || defined(CONFIG_TOSHIBA_RBTX4938)
> || \
> - defined(CONFIG_ATARI_ETHERNEC) || defined(CONFIG_ATARI_ETHERNEC_MODULE)
> + IS_ENABLED(CONFIG_ATARI_ETHERNEC_OLD)
> # define DCR_VAL 0x48 /* 8-bit mode */
> #else
> # define DCR_VAL 0x49
> #endif
>
> -#if defined(CONFIG_ATARI_ETHERNEC) || defined(CONFIG_ATARI_ETHERNEC_MODULE)
> +#if IS_ENABLED(CONFIG_ATARI_ETHERNEC_OLD)
> # define ETHERNEC_RTL_8019_BASE 0x300
> # define ETHERNEC_RTL_8019_IRQ IRQ_MFP_TIMD
> #endif
> @@ -357,7 +357,7 @@ struct net_device * __init atari_ethernec_probe(int
> unit)
> sprintf(dev->name, "eth%d", unit);
> netdev_boot_setup_check(dev);
>
> -#if defined(CONFIG_ATARI_ETHERNEC)
> +#if defined(CONFIG_ATARI_ETHERNEC_OLD)
> dev->base_addr = ETHERNEC_RTL_8019_BASE;
> dev->irq = ETHERNEC_RTL_8019_IRQ;
> #endif
> diff --git a/drivers/net/ethernet/8390/ne.c b/drivers/net/ethernet/8390/ne.c
> index f92ea2a..39678fc 100644
> --- a/drivers/net/ethernet/8390/ne.c
> +++ b/drivers/net/ethernet/8390/ne.c
> @@ -165,7 +165,8 @@ bad_clone_list[] __initdata = {
> #if defined(CONFIG_PLAT_MAPPI)
> # define DCR_VAL 0x4b
> #elif defined(CONFIG_PLAT_OAKS32R) || \
> - defined(CONFIG_MACH_TX49XX)
> + defined(CONFIG_MACH_TX49XX) || \
> + IS_ENABLED(CONFIG_ATARI_ETHERNEC)
Rather than use IS_ENABLED on a driver setting, you can follow
the surrounding context and use defined(CONFIG_ATARI) -- i.e.
work off a platform setting.
Paul.
> # define DCR_VAL 0x48 /* 8-bit mode */
> #else
> # define DCR_VAL 0x49
> @@ -492,7 +493,7 @@ static int __init ne_probe1(struct net_device *dev,
> unsigned long ioaddr)
>
> /* Snarf the interrupt now. There's no point in waiting since we
> cannot
> share and the board will usually be enabled. */
> - ret = request_irq(dev->irq, eip_interrupt, 0, name, dev);
> + ret = request_irq(dev->irq, eip_interrupt, EI_IRQ_FLAGS, name, dev);
> if (ret) {
> printk (" unable to get IRQ %d (errno=%d).\n", dev->irq, ret);
> goto err_out;
>
^ permalink raw reply
* [PATCH v2 0/6] arch/tile: networking support for tilegx
From: Chris Metcalf @ 2012-04-04 20:39 UTC (permalink / raw)
To: Arnd Bergmann, linux-kernel, netdev
In-Reply-To: <4F9C6A0A.5090109@tilera.com>
This patch series addresses the feedback from the community for the
first patch series. Changes include:
- Clean up network driver to not keep two arrays of net_device pointers
- Use explicit tile_io_addr type and conversion functions, not __pa/__va
- Avoid tile-specific __insn_mf() in favor of wmb()
- Clean up checksumming in tilegx.c to use new csum_long() routine
- Use inline assembly for readb/writeb etc to avoid splitting accesses
- Remove fences after mmio writes since they aren't necessary
- Fixed Kconfig options to be appropriately hidden
- Export symbols with EXPORT_SYMBOL_GPL, nestled up against the functions
- Make auto-generated code much terser and more readable
- Avoid typedef'ing structures, and remove "_t" suffix from struct names
- Convert remaining C99 comments to C89
- Fixed driver multiline comment style to match davem's preferred style
arch/tile/Kconfig | 2 +
arch/tile/Makefile | 2 +
arch/tile/gxio/Kconfig | 17 +
arch/tile/gxio/Makefile | 7 +
arch/tile/gxio/dma_queue.c | 230 ++++
arch/tile/gxio/iorpc_globals.c | 89 ++
arch/tile/gxio/iorpc_mpipe.c | 463 +++++++
arch/tile/gxio/iorpc_mpipe_info.c | 85 ++
arch/tile/gxio/kiorpc.c | 61 +
arch/tile/gxio/mpipe.c | 500 ++++++++
arch/tile/include/arch/mpipe.h | 359 ++++++
arch/tile/include/arch/mpipe_constants.h | 42 +
arch/tile/include/arch/mpipe_def.h | 39 +
arch/tile/include/arch/mpipe_shm.h | 509 ++++++++
arch/tile/include/arch/mpipe_shm_def.h | 23 +
arch/tile/include/asm/checksum.h | 18 +
arch/tile/include/asm/io.h | 144 ++-
arch/tile/include/gxio/common.h | 38 +
arch/tile/include/gxio/dma_queue.h | 59 +
arch/tile/include/gxio/iorpc_globals.h | 38 +
arch/tile/include/gxio/iorpc_mpipe.h | 124 ++
arch/tile/include/gxio/iorpc_mpipe_info.h | 46 +
arch/tile/include/gxio/kiorpc.h | 29 +
arch/tile/include/gxio/mpipe.h | 1653 ++++++++++++++++++++++++
arch/tile/include/hv/drv_mpipe_intf.h | 602 +++++++++
arch/tile/include/hv/iorpc.h | 714 +++++++++++
arch/tile/lib/checksum.c | 15 +-
drivers/net/ethernet/tile/Kconfig | 1 +
drivers/net/ethernet/tile/Makefile | 4 +-
drivers/net/ethernet/tile/tilegx.c | 1952 +++++++++++++++++++++++++++++
30 files changed, 7821 insertions(+), 44 deletions(-)
^ permalink raw reply
* [PATCH 0/6] arch/tile: provide tilegx networking support
From: Chris Metcalf @ 2012-04-04 20:39 UTC (permalink / raw)
To: linux-kernel, netdev
This change set provides support for the on-chip networking hardware
on the TILE-Gx chip. The actual network driver is layered on top of
the mPIPE hardware support, which is layered on top of the GXIO IORPC
facility (and its DMA layer). The change set breaks this down into
a series of patches, each progressively adding another component of
functionality. There are also a couple of simple changes to add
support for MMIO memory mappings for readb/writeb, and for installing
MMIO PTEs, which are necessary for this change.
arch/tile/Kconfig | 2 +
arch/tile/Makefile | 1 +
arch/tile/gxio/Kconfig | 25 +
arch/tile/gxio/Makefile | 7 +
arch/tile/gxio/dma_queue.c | 236 ++++
arch/tile/gxio/iorpc_globals.c | 102 ++
arch/tile/gxio/iorpc_mpipe.c | 571 ++++++++
arch/tile/gxio/iorpc_mpipe_info.c | 95 ++
arch/tile/gxio/kiorpc.c | 60 +
arch/tile/gxio/mpipe.c | 631 +++++++++
arch/tile/include/arch/mpipe.h | 321 +++++
arch/tile/include/arch/mpipe_constants.h | 43 +
arch/tile/include/arch/mpipe_def.h | 39 +
arch/tile/include/arch/mpipe_shm.h | 421 ++++++
arch/tile/include/arch/mpipe_shm_def.h | 23 +
arch/tile/include/asm/io.h | 110 ++-
arch/tile/include/gxio/common.h | 40 +
arch/tile/include/gxio/dma_queue.h | 59 +
arch/tile/include/gxio/iorpc_globals.h | 38 +
arch/tile/include/gxio/iorpc_mpipe.h | 124 ++
arch/tile/include/gxio/iorpc_mpipe_info.h | 46 +
arch/tile/include/gxio/kiorpc.h | 29 +
arch/tile/include/gxio/mpipe.h | 1986 ++++++++++++++++++++++++++++
arch/tile/include/hv/drv_mpipe_intf.h | 602 +++++++++
arch/tile/include/hv/iorpc.h | 716 ++++++++++
arch/tile/mm/pgtable.c | 16 +-
drivers/net/ethernet/tile/Kconfig | 1 +
drivers/net/ethernet/tile/Makefile | 4 +-
drivers/net/ethernet/tile/tilegx.c | 2045 +++++++++++++++++++++++++++++
29 files changed, 8359 insertions(+), 34 deletions(-)
^ permalink raw reply
* [RFC] API to modify /proc/sys/net/ipv4/ip_local_reserved_ports
From: Helge Deller @ 2012-04-04 20:24 UTC (permalink / raw)
To: Octavian Purdila, netdev, David Miller, Cong Wang, Andrew Morton,
Eric W. Biederman, Frank Danapfel, Laszlo Ersek, shemminger
In-Reply-To: <4F611835.4080904@gmx.de>
I would like to follow up on my last patch series to be able to modify
the contents of the /proc/sys/net/ipv4/ip_local_reserved_ports port list
from userspace.
My last patch (https://lkml.org/lkml/2012/3/10/187) was based on
modifications to the proc interface, which - based on the feedback here
on the list - seemed to not be the right way to go (although I personally
still like the idea very much :-)).
Anyway, with this RFC I would like to get feedback about a new proposed
API and attached kernel patch.
The idea is to introduce a new <optname> value for get/setsockopt()
named SO_RESERVED_PORTS to get/set the ip_local_reserved_ports
bitmap via standard get/setsockopt() syscalls.
As far as I understand this seems to be similiar to how iptables works.
An untested kernel patch for review and feedback is attached below.
In userspace it then would be possible to write a new tool or to extend
for example the "ip" tool to accept commands like:
$> ip reserved_ports add 100-2000
$> ip reserved_ports remove 50-60
$> ip reserved_ports list (to show current reserved port list)
This userspace tool could then read the port bitmap from kernel via
a) socket(PF_INET, SOCK_RAW, IPPROTO_RAW)
b) getsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS, <bitmaplist>)
and write back the results after modification via
c) setsockopt(3, SOL_SOCKET, SO_RESERVED_PORTS, <bitmaplist>)
Would that be an acceptable solution?
If yes, I will of course write the kernel patch and the userspace
implementation and
post it here for review again...
Thanks,
Helge
diff --git a/include/asm-generic/socket.h b/include/asm-generic/socket.h
--- a/include/asm-generic/socket.h
+++ b/include/asm-generic/socket.h
@@ -67,4 +67,6 @@
#define SO_WIFI_STATUS 41
#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
+#define SO_RESERVED_PORTS 42
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/net/ip.h b/include/net/ip.h
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -214,6 +214,7 @@ extern struct local_ports {
} sysctl_local_ports;
extern void inet_get_local_port_range(int *low, int *high);
+#define SYSCTL_LOCAL_RESERVED_PORTS_BYTES (65536 / 8)
extern unsigned long *sysctl_local_reserved_ports;
static inline int inet_is_reserved_local_port(int port)
{
diff --git a/net/core/sock.c b/net/core/sock.c
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -793,6 +793,13 @@ set_rcvbuf:
sock_valbool_flag(sk, SOCK_WIFI_STATUS, valbool);
break;
+ case SO_RESERVED_PORTS:
+ ret = -EINVAL;
+ if (optlen == SYSCTL_LOCAL_RESERVED_PORTS_BYTES)
+ ret = copy_from_user(sysctl_local_reserved_ports, optval,
optlen);
+ break;
+
+
default:
ret = -ENOPROTOOPT;
break;
@@ -1018,6 +1025,13 @@ int sock_getsockopt(struct socket *sock, int
level, int optname,
v.val = !!sock_flag(sk, SOCK_WIFI_STATUS);
break;
+ case SO_RESERVED_PORTS:
+ if (len != SYSCTL_LOCAL_RESERVED_PORTS_BYTES)
+ return -EINVAL;
+ if (copy_to_user(optval, sysctl_local_reserved_ports, len))
+ return -EFAULT;
+ goto lenout;
+
default:
return -ENOPROTOOPT;
}
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1642,7 +1642,7 @@ static int __init inet_init(void)
BUILD_BUG_ON(sizeof(struct inet_skb_parm) > sizeof(dummy_skb->cb));
- sysctl_local_reserved_ports = kzalloc(65536 / 8, GFP_KERNEL);
+ sysctl_local_reserved_ports =
kzalloc(SYSCTL_LOCAL_RESERVED_PORTS_BYTES, GFP_KERNEL);
if (!sysctl_local_reserved_ports)
goto out;
^ permalink raw reply
* Re: [PATCH] Implement IP_EVIL socket option (RFC 3514)
From: Al Viro @ 2012-04-04 20:18 UTC (permalink / raw)
To: Florian Weimer; +Cc: Martin Lucina, linux-kernel, netdev
In-Reply-To: <87r4w3nw7n.fsf@mid.deneb.enyo.de>
On Wed, Apr 04, 2012 at 09:17:00PM +0200, Florian Weimer wrote:
> * Martin Lucina:
>
> > This patch implements the IP_EVIL socket option, allowing user-space
> > applications to set the Security Flag in the IPv4 Header, aka "evil" bit,
> > as defined in RFC 3514.
>
> I need this to fix a security issue. Could this be merged for real,
> please?
I would suggest switching away from your RFC1149 link - looks like your mail
took 3 days on the way out...
^ permalink raw reply
* [PATCH] mlx4: allocate just enough pages instead of always 4 pages
From: Thadeu Lima de Souza Cascardo @ 2012-04-04 19:40 UTC (permalink / raw)
To: netdev
Cc: davem, roland, ogerlitz, yevgenyp, alexg,
Thadeu Lima de Souza Cascardo, Kleber Sacilotto de Souza
The driver uses a 2-order allocation, which is too much on architectures
like ppc64, which has a 64KiB page. This particular allocation is used
for large packet fragments that may have a size of 512, 1024, 4096 or
fill the whole allocation. So, a minimum size of 16384 is good enough
and will be the same size that is used in architectures of 4KiB sized
pages.
This will avoid allocation failures that we see when the system is under
stress, but still has plenty of memory, like the one below.
This will also allow us to set the interface MTU to higher values like
9000, which was not possible on ppc64 without this patch.
Node 1 DMA: 737*64kB 37*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 51904kB
83137 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 10420096kB
Total swap = 10420096kB
107776 pages RAM
1184 pages reserved
147343 pages shared
28152 pages non-shared
netstat: page allocation failure. order:2, mode:0x4020
Call Trace:
[c0000001a4fa3770] [c000000000012f04] .show_stack+0x74/0x1c0 (unreliable)
[c0000001a4fa3820] [c00000000016af38] .__alloc_pages_nodemask+0x618/0x930
[c0000001a4fa39a0] [c0000000001a71a0] .alloc_pages_current+0xb0/0x170
[c0000001a4fa3a40] [d00000000dcc3e00] .mlx4_en_alloc_frag+0x200/0x240 [mlx4_en]
[c0000001a4fa3b10] [d00000000dcc3f8c] .mlx4_en_complete_rx_desc+0x14c/0x250 [mlx4_en]
[c0000001a4fa3be0] [d00000000dcc4eec] .mlx4_en_process_rx_cq+0x62c/0x850 [mlx4_en]
[c0000001a4fa3d20] [d00000000dcc5150] .mlx4_en_poll_rx_cq+0x40/0x90 [mlx4_en]
[c0000001a4fa3dc0] [c0000000004e2bb8] .net_rx_action+0x178/0x450
[c0000001a4fa3eb0] [c00000000009c9b8] .__do_softirq+0x118/0x290
[c0000001a4fa3f90] [c000000000031df8] .call_do_softirq+0x14/0x24
[c000000184c3b520] [c00000000000e700] .do_softirq+0xf0/0x110
[c000000184c3b5c0] [c00000000009c6d4] .irq_exit+0xb4/0xc0
[c000000184c3b640] [c00000000000e964] .do_IRQ+0x144/0x230
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Tested-by: Kleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
---
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index 9e2b911..d69fee4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -83,8 +83,9 @@
#define MLX4_EN_WATCHDOG_TIMEOUT (15 * HZ)
-#define MLX4_EN_ALLOC_ORDER 2
-#define MLX4_EN_ALLOC_SIZE (PAGE_SIZE << MLX4_EN_ALLOC_ORDER)
+/* Use the maximum between 16384 and a single page */
+#define MLX4_EN_ALLOC_SIZE PAGE_ALIGN(16384)
+#define MLX4_EN_ALLOC_ORDER get_order(MLX4_EN_ALLOC_SIZE)
#define MLX4_EN_MAX_LRO_DESCRIPTORS 32
--
1.7.4.4
^ permalink raw reply related
* Re: Crash in __netif_receive_skb
From: Avleen Vig @ 2012-04-04 19:35 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <CAMjP1KmkS9aBXJm1GEavhcNx75ib7G4m+xYBe3_PcGSo6t5FsQ@mail.gmail.com>
On Thu, Mar 29, 2012 at 4:42 PM, Avleen Vig <avleen@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 10:01 PM, Avleen Vig <avleen@gmail.com> wrote:
>> On Wed, Mar 28, 2012 at 8:31 PM, Avleen Vig <avleen@gmail.com> wrote:
>>> Hi folks, someone in #kernel recommended I email these two lists. Hope
>>> they're the right place.
>>>
>>> We're running 2.6.32-220.4.1.el6.x86_64 on Centos 6.2, and getting a
>>> repeated crash:
>>> https://gist.github.com/2231998
>>>
>>> We can make this happen pretty easily just by passing some network
>>> traffic and waiting a while.
>>> I couldn't find any references to this particular issue.
>>> I have vmcore files and am happy to dig into it if it would help (as
>>> long as someone can tell me what to do :))
>>
>> I hope this debugging is legit, I'm really new to this level of insight.
>>
>> I think the problem is in include/linux/netpoll.h, at the "if"
>> statement at line 86:
>> static inline int netpoll_receive_skb(struct sk_buff *skb)
>> {
>> if (!list_empty(&skb->dev->napi_list))
>> return netpoll_rx(skb);
>> return 0;
>> }
>>
>>
>> This is based on poking around in the crash dump:
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000060
>> IP: [<ffffffff8142bb40>] __netif_receive_skb+0x60/0x6e0
>> crash> dis -rl ffffffff8142bb40
>> ....
>> /usr/src/debug/kernel-2.6.32-220.7.1.el6/linux-2.6.32-220.7.1.el6.x86_64/include/linux/netpoll.h:
>> 86
>> 0xffffffff8142bb33 <__netif_receive_skb+83>: mov 0x20(%rbx),%r12
>> 0xffffffff8142bb37 <__netif_receive_skb+87>: mov %r12,-0x38(%rbp)
>> 0xffffffff8142bb3b <__netif_receive_skb+91>: lea 0x60(%r12),%rax
>> 0xffffffff8142bb40 <__netif_receive_skb+96>: cmp %rax,0x60(%r12)
>>
>>
>>
>> I *think* this means that "&skb->dev->napi_list" is null when we're
>> trying to compare it, rather than being a list.
>>
>> If it matters, this is inside LXC containers.
>
> We've traced this to a problem with machines that have multiple hard
> drives AND have NAPI enabled for the NIC driver.
>
> We recompiled the e1000e driver with NAPI disabled, with:
> make CFLAGS_EXTRA=-DE1000E_NO_NAPI
>
> and everything works great now.
Untrue! This eventually failed too, but after a lot more debugging, we
think we've nailed it:
Multicast
We use ganglia on all of our nodes (and we were setting it up inside
the LXC containers), and ganglia listens / sends on multicast.
When gmond was starting inside the containers, it was giving an error:
Apr 4 17:00:42 hostname /usr/sbin/gmond[551]: Error creating
multicast server mcast_join=239.2.11.110 port=8649 mcast_if=NULL
family='inet4'. Exiting.
It occurred to me that if the kernel is trying to read a multicast
packet from a socket buffer, but the container can't handle multicast
(mcast_if=NULL), that would explain why we got a NULL pointer
dereference in &skb->dev->napi_list.
(at least, this makes sense in my head.)
We disabled gmond in the containers, so nothing should be listening
for multicast packets, and everything is stable again.
Note that this ONLY seems to happen for us when we're using the
onboard 82574L Intel NIC with the e1000e driver.
We have other servers with the 82575 NIC which uses the igb driver and
doesn't exhibit this problem.
Is anyone from Intel here who could look in to this?
^ permalink raw reply
* Re: [PATCH] Implement IP_EVIL socket option (RFC 3514)
From: Florian Weimer @ 2012-04-04 19:17 UTC (permalink / raw)
To: Martin Lucina; +Cc: linux-kernel, netdev
In-Reply-To: <1333284791-5363-1-git-send-email-martin@lucina.net>
* Martin Lucina:
> This patch implements the IP_EVIL socket option, allowing user-space
> applications to set the Security Flag in the IPv4 Header, aka "evil" bit,
> as defined in RFC 3514.
I need this to fix a security issue. Could this be merged for real,
please?
^ permalink raw reply
* Re: [PATCH net-next 23/34] uli526x: fix regions leak in driver probe error path.
From: Grant Grundler @ 2012-04-04 19:10 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, David Miller, Grant Grundler
In-Reply-To: <cc6d6ac73b8297d3eda5ef20a83a1eb0587b52e9.1331814082.git.romieu@fr.zoreil.com>
On Thu, Mar 15, 2012 at 6:57 AM, Francois Romieu <romieu@fr.zoreil.com> wrote:
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Grant Grundler <grundler@parisc-linux.org>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
cheers,
grant
> ---
> drivers/net/ethernet/dec/tulip/uli526x.c | 48 ++++++++++++-----------------
> 1 files changed, 20 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/ethernet/dec/tulip/uli526x.c b/drivers/net/ethernet/dec/tulip/uli526x.c
> index fc4001f..c9b3396 100644
> --- a/drivers/net/ethernet/dec/tulip/uli526x.c
> +++ b/drivers/net/ethernet/dec/tulip/uli526x.c
> @@ -313,9 +313,9 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> goto err_out_disable;
> }
>
> - if (pci_request_regions(pdev, DRV_NAME)) {
> + err = pci_request_regions(pdev, DRV_NAME);
> + if (err < 0) {
> pr_err("Failed to request PCI regions\n");
> - err = -ENODEV;
> goto err_out_disable;
> }
>
> @@ -323,18 +323,15 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> db = netdev_priv(dev);
>
> /* Allocate Tx/Rx descriptor memory */
> + err = -ENOMEM;
> +
> db->desc_pool_ptr = pci_alloc_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20, &db->desc_pool_dma_ptr);
> - if(db->desc_pool_ptr == NULL)
> - {
> - err = -ENOMEM;
> - goto err_out_nomem;
> - }
> + if (!db->desc_pool_ptr)
> + goto err_out_release;
> +
> db->buf_pool_ptr = pci_alloc_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4, &db->buf_pool_dma_ptr);
> - if(db->buf_pool_ptr == NULL)
> - {
> - err = -ENOMEM;
> - goto err_out_nomem;
> - }
> + if (!db->buf_pool_ptr)
> + goto err_out_free_tx_desc;
>
> db->first_tx_desc = (struct tx_desc *) db->desc_pool_ptr;
> db->first_tx_desc_dma = db->desc_pool_dma_ptr;
> @@ -387,7 +384,7 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
> }
> err = register_netdev (dev);
> if (err)
> - goto err_out_res;
> + goto err_out_free_tx_buf;
>
> netdev_info(dev, "ULi M%04lx at pci%s, %pM, irq %d\n",
> ent->driver_data >> 16, pci_name(pdev),
> @@ -397,16 +394,14 @@ static int __devinit uli526x_init_one (struct pci_dev *pdev,
>
> return 0;
>
> -err_out_res:
> +err_out_free_tx_buf:
> + pci_free_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> + db->buf_pool_ptr, db->buf_pool_dma_ptr);
> +err_out_free_tx_desc:
> + pci_free_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20,
> + db->desc_pool_ptr, db->desc_pool_dma_ptr);
> +err_out_release:
> pci_release_regions(pdev);
> -err_out_nomem:
> - if(db->desc_pool_ptr)
> - pci_free_consistent(pdev, sizeof(struct tx_desc) * DESC_ALL_CNT + 0x20,
> - db->desc_pool_ptr, db->desc_pool_dma_ptr);
> -
> - if(db->buf_pool_ptr != NULL)
> - pci_free_consistent(pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> - db->buf_pool_ptr, db->buf_pool_dma_ptr);
> err_out_disable:
> pci_disable_device(pdev);
> err_out_free:
> @@ -422,19 +417,16 @@ static void __devexit uli526x_remove_one (struct pci_dev *pdev)
> struct net_device *dev = pci_get_drvdata(pdev);
> struct uli526x_board_info *db = netdev_priv(dev);
>
> - ULI526X_DBUG(0, "uli526x_remove_one()", 0);
> -
> + unregister_netdev(dev);
> pci_free_consistent(db->pdev, sizeof(struct tx_desc) *
> DESC_ALL_CNT + 0x20, db->desc_pool_ptr,
> db->desc_pool_dma_ptr);
> pci_free_consistent(db->pdev, TX_BUF_ALLOC * TX_DESC_CNT + 4,
> db->buf_pool_ptr, db->buf_pool_dma_ptr);
> - unregister_netdev(dev);
> pci_release_regions(pdev);
> - free_netdev(dev); /* free board information */
> - pci_set_drvdata(pdev, NULL);
> pci_disable_device(pdev);
> - ULI526X_DBUG(0, "uli526x_remove_one() exit", 0);
> + pci_set_drvdata(pdev, NULL);
> + free_netdev(dev);
> }
>
>
> --
> 1.7.7.6
>
^ 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