* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Eric Dumazet @ 2013-01-04 17:15 UTC (permalink / raw)
To: Mel Gorman
Cc: Eric Wong, linux-mm, netdev, linux-kernel, Rik van Riel,
Minchan Kim, Andrew Morton, Linus Torvalds
In-Reply-To: <20130104160148.GB3885@suse.de>
On Fri, 2013-01-04 at 16:01 +0000, Mel Gorman wrote:
> Implying that it's stuck in compaction somewhere. It could be the case
> that compaction alters timing enough to trigger another bug. You say it
> tests differently depending on whether TCP or unix sockets are used
> which might indicate multiple problems. However, lets try and see if
> compaction is the primary problem or not.
One difference between TCP or unix socket is that :
Unix sockets try hard to limit the order of allocations.
For a 16KB (+ skb overhead) send(), we will probably use one order-2
page and one order-0 page as a frag (data_len being not 0) :
vi +1484 net/unix/af_unix.c
if (len > SKB_MAX_ALLOC)
data_len = min_t(size_t,
len - SKB_MAX_ALLOC,
MAX_SKB_FRAGS * PAGE_SIZE);
skb = sock_alloc_send_pskb(sk, len - data_len, data_len,
msg->msg_flags & MSG_DONTWAIT, &err);
While TCP could use order-3 pages if available
Eric, you could try to change SKB_FRAG_PAGE_ORDER in net/core/sock.c to
lower values (16384, 8192, 4096) and check if the hang can disappear or
not.
Alternatively (no kernel patching needed), you could try to hang AF_UNIX
using buffers of 90KB, to force order-3 allocations as well (one 32KB
allocation plus 16 * 4KB frags)
Thanks
^ permalink raw reply
* Re: [PATCH v2 net-next] softirq: reduce latencies
From: Eric Dumazet @ 2013-01-04 17:00 UTC (permalink / raw)
To: Joe Perches
Cc: Ben Hutchings, David Miller, Andrew Morton, netdev,
linux-kernel@vger.kernel.org, Tom Herbert
In-Reply-To: <1357290721.5452.55.camel@joe-AO722>
On Fri, 2013-01-04 at 01:12 -0800, Joe Perches wrote:
> On Fri, 2013-01-04 at 00:23 -0800, Eric Dumazet wrote:
> > On Fri, 2013-01-04 at 00:15 -0800, Joe Perches wrote:
> > > Perhaps MAX_SOFTIRQ_TIME should be
> > > #define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
> > > though it would be nicer if it were a compile time constant.
> >
> > If you send a patch to convert msecs_to_jiffies() to an inline function
> > when HZ = 1000, I will gladly use it instead of (2*HZ/1000)
> >
> > Right now, max(1, msecs_to_jiffies(2)) uses way too many instructions,
> > while it should be the constant 2, known at compile time.
>
> Something like this might work.
>
> This is incomplete, it just does msecs_to_jiffies,
> and it should convert usecs_to_jiffies and the
> jiffies_to_<foo> types too.
>
> Maybe it's worthwhile.
>
> It does reduce object size by 16 bytes per call site
> (x86-32) when the argument is a constant. There are
> about 800 of these jiffies conversions in kernel sources.
>
> What do you think?
>
I think this is something to discuss in another thread, and definitely
worth to do, at least for msecs_to_jiffies()
We have many HZ references everywhere that could be cleaned up using
this.
^ permalink raw reply
* [PATCH 2/2] sierra_net: keep status interrupt URB active over netdev open/close
From: Dan Williams @ 2013-01-04 16:51 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Elina Pasheva, netdev, linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <1357318096.5370.15.camel@dcbw.foobar.com>
The driver and firmware sync up through SYNC messages, and the
firmware's affirmative reply to these SYNC messages appears to be the
"Reset" indication received via the status interrupt endpoint. Thus the
driver needs the status interrupt endpoint always active so that the
Reset indication can be received even if the netdev is closed, which is
the case right after device insertion.
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 18dd425..e6e2857 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@@ -905,7 +905,7 @@ static struct sk_buff *sierra_net_tx_fixup(struct usbnet *dev,
static const struct driver_info sierra_net_info_direct_ip = {
.description = "Sierra Wireless USB-to-WWAN Modem",
- .flags = FLAG_WWAN | FLAG_SEND_ZLP,
+ .flags = FLAG_WWAN | FLAG_SEND_ZLP | FLAG_INTR_ALWAYS,
.bind = sierra_net_bind,
.unbind = sierra_net_unbind,
.status = sierra_net_status,
^ permalink raw reply related
* [PATCH 1/2] usbnet: allow status interrupt URB to always be active
From: Dan Williams @ 2013-01-04 16:48 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Elina Pasheva, netdev, linux-usb, Rory Filer, Phil Sutter
In-Reply-To: <20110727141246.GC29616@orbit.nwl.cc>
Some drivers (ex sierra_net) need the status interrupt URB
active even when the device is closed, because they receive
custom indications from firmware. Allow sub-drivers to set
a flag that submits the status interrupt URB on probe and
keeps the URB alive over device open/close. The URB is still
killed/re-submitted for suspend/resume, as before.
Signed-off-by: Dan Williams <dcbw@redhat.com>
---
Oliver: alternatively, is there a problem with *always*
submitting the interrupt URB, and then simply not calling
the subdriver's .status function when the netdev is
closed? That would be a much simpler patch.
drivers/net/usb/usbnet.c | 43 +++++++++++++++++++++++++++++++------------
include/linux/usb/usbnet.h | 3 +++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 3d4bf01..081b685 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -206,13 +206,13 @@ static void intr_complete (struct urb *urb)
break;
}
- if (!netif_running (dev->net))
- return;
-
- status = usb_submit_urb (urb, GFP_ATOMIC);
- if (status != 0)
- netif_err(dev, timer, dev->net,
- "intr resubmit --> %d\n", status);
+ if (dev->driver_info->flags & FLAG_INTR_ALWAYS ||
+ netif_running(dev->net)) {
+ status = usb_submit_urb(urb, GFP_ATOMIC);
+ if (status != 0)
+ netif_err(dev, timer, dev->net,
+ "intr resubmit --> %d\n", status);
+ }
}
static int init_status (struct usbnet *dev, struct usb_interface *intf)
@@ -708,7 +708,8 @@ int usbnet_stop (struct net_device *net)
if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
usbnet_terminate_urbs(dev);
- usb_kill_urb(dev->interrupt);
+ if (!(info->flags & FLAG_INTR_ALWAYS))
+ usb_kill_urb(dev->interrupt);
usbnet_purge_paused_rxq(dev);
@@ -769,7 +770,7 @@ int usbnet_open (struct net_device *net)
}
/* start any status interrupt transfer */
- if (dev->interrupt) {
+ if (dev->interrupt && !(info->flags & FLAG_INTR_ALWAYS)) {
retval = usb_submit_urb (dev->interrupt, GFP_KERNEL);
if (retval < 0) {
netif_err(dev, ifup, dev->net,
@@ -1469,6 +1470,15 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
if (status < 0)
goto out3;
+ /* Submit status interrupt URB immediately if sub-driver wants */
+ if (dev->interrupt && (info->flags & FLAG_INTR_ALWAYS)) {
+ status = usb_submit_urb(dev->interrupt, GFP_KERNEL);
+ if (status < 0) {
+ dev_err(&udev->dev, "intr submit %d\n", status);
+ goto out4;
+ }
+ }
+
if (!dev->rx_urb_size)
dev->rx_urb_size = dev->hard_mtu;
dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
@@ -1480,7 +1490,7 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
status = register_netdev (net);
if (status)
- goto out4;
+ goto out5;
netif_info(dev, probe, dev->net,
"register '%s' at usb-%s-%s, %s, %pM\n",
udev->dev.driver->name,
@@ -1498,6 +1508,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
return 0;
+out5:
+ usb_kill_urb(dev->interrupt);
out4:
usb_free_urb(dev->interrupt);
out3:
@@ -1559,8 +1571,15 @@ int usbnet_resume (struct usb_interface *intf)
if (!--dev->suspend_count) {
/* resume interrupt URBs */
- if (dev->interrupt && test_bit(EVENT_DEV_OPEN, &dev->flags))
- usb_submit_urb(dev->interrupt, GFP_NOIO);
+ if (dev->interrupt &&
+ (dev->driver_info->flags & FLAG_INTR_ALWAYS ||
+ test_bit(EVENT_DEV_OPEN, &dev->flags))) {
+ retval = usb_submit_urb(dev->interrupt, GFP_NOIO);
+ if (retval < 0) {
+ netif_err(dev, ifup, dev->net,
+ "intr submit %d\n", retval);
+ }
+ }
spin_lock_irq(&dev->txq.lock);
while ((res = usb_get_from_anchor(&dev->deferred))) {
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index bd45eb7..8503920 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -108,6 +108,9 @@ struct driver_info {
#define FLAG_MULTI_PACKET 0x2000
#define FLAG_RX_ASSEMBLE 0x4000 /* rx packets may span >1 frames */
+/* Indicates that the interrupt URB should not depend on netdev open/close */
+#define FLAG_INTR_ALWAYS 0x8000
+
/* init device ... can sleep, or cause probe() failure */
int (*bind)(struct usbnet *, struct usb_interface *);
--
1.7.11.7
^ permalink raw reply related
* Re: NULL pointer dereference in veth_stats_one
From: Eric Dumazet @ 2013-01-04 16:17 UTC (permalink / raw)
To: Tom Parkin, David Miller; +Cc: netdev
In-Reply-To: <1357314320.1678.1414.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
On Fri, 2013-01-04 at 07:45 -0800, Eric Dumazet wrote:
> On Fri, 2013-01-04 at 10:59 +0000, Tom Parkin wrote:
> > Hi list,
> >
> > I recently tripped over a NULL pointer dereference in the veth driver.
> > I'm running a 3.8.0_rc1 (updated from net-next git tree this morning)
> > on an Athlon 64 X2 machine running a 32 bit kernel. To trigger the
> > oops I simply created a veth interface as follows:
> >
> > ip link add name ve0 type veth peer name ve1
> >
> > I did a little digging in the git history and I note that veth
> > statistics changed a little with commit 2681128f0ced8aa4. I tried
> > reverting that commit in my tree, which made the oops go away again.
> >
> > Thanks,
> > Tom
>
> Thanks Tom, I'll fix this.
>
Oh well, a last minute change again...
I was fooled by veth_get_ethtool_stats() doing the priv->peer->ifindex
deref without checking.
Here is the fix, thanks !
[PATCH net-next] veth: avoid a NULL deref in veth_stats_one
commit 2681128f0ced8a (veth: extend device features) added a NULL deref
in veth_stats_one(), as veth_get_stats64() was not testing if the peer
device was setup or not.
At init time, we call dev_get_stats() before veth pair is fully setup.
[ 178.854758] [<ffffffffa00f5677>] veth_get_stats64+0x47/0x70 [veth]
[ 178.861013] [<ffffffff814f0a2d>] dev_get_stats+0x6d/0x130
[ 178.866486] [<ffffffff81504efc>] rtnl_fill_ifinfo+0x47c/0x930
[ 178.872299] [<ffffffff81505b93>] rtmsg_ifinfo+0x83/0x100
[ 178.877678] [<ffffffff81505cc6>] rtnl_configure_link+0x76/0xa0
[ 178.883580] [<ffffffffa00f52fa>] veth_newlink+0x16a/0x350 [veth]
[ 178.889654] [<ffffffff815061cc>] rtnl_newlink+0x4dc/0x5e0
[ 178.895128] [<ffffffff81505e1e>] ? rtnl_newlink+0x12e/0x5e0
[ 178.900769] [<ffffffff8150587d>] rtnetlink_rcv_msg+0x11d/0x310
[ 178.906669] [<ffffffff81505760>] ? __rtnl_unlock+0x20/0x20
[ 178.912225] [<ffffffff81521f89>] netlink_rcv_skb+0xa9/0xd0
[ 178.917779] [<ffffffff81502d55>] rtnetlink_rcv+0x25/0x40
[ 178.923159] [<ffffffff815218d1>] netlink_unicast+0x1b1/0x230
[ 178.928887] [<ffffffff81521c4e>] netlink_sendmsg+0x2fe/0x3b0
[ 178.934615] [<ffffffff814dbe22>] sock_sendmsg+0xd2/0xf0
So we must check if peer was setup in veth_get_stats64()
Reported-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
drivers/net/veth.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index 8b2e112..bd57213 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -162,15 +162,18 @@ static struct rtnl_link_stats64 *veth_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *tot)
{
struct veth_priv *priv = netdev_priv(dev);
+ struct net_device *peer = priv->peer;
struct pcpu_vstats one;
tot->tx_dropped = veth_stats_one(&one, dev);
tot->tx_bytes = one.bytes;
tot->tx_packets = one.packets;
- tot->rx_dropped = veth_stats_one(&one, priv->peer);
- tot->rx_bytes = one.bytes;
- tot->rx_packets = one.packets;
+ if (peer) {
+ tot->rx_dropped = veth_stats_one(&one, peer);
+ tot->rx_bytes = one.bytes;
+ tot->rx_packets = one.packets;
+ }
return tot;
}
^ permalink raw reply related
* Re: ppoll() stuck on POLLIN while TCP peer is sending
From: Mel Gorman @ 2013-01-04 16:01 UTC (permalink / raw)
To: Eric Wong
Cc: linux-mm, netdev, linux-kernel, Rik van Riel, Minchan Kim,
Andrew Morton, Linus Torvalds
In-Reply-To: <20130102200848.GA4500@dcvr.yhbt.net>
On Wed, Jan 02, 2013 at 08:08:48PM +0000, Eric Wong wrote:
> (changing Cc:)
>
> Eric Wong <normalperson@yhbt.net> wrote:
> > I'm finding ppoll() unexpectedly stuck when waiting for POLLIN on a
> > local TCP socket. The isolated code below can reproduces the issue
> > after many minutes (<1 hour). It might be easier to reproduce on
> > a busy system while disk I/O is happening.
>
> s/might be/is/
>
> Strangely, I've bisected this seemingly networking-related issue down to
> the following commit:
>
> commit 1fb3f8ca0e9222535a39b884cb67a34628411b9f
> Author: Mel Gorman <mgorman@suse.de>
> Date: Mon Oct 8 16:29:12 2012 -0700
>
> mm: compaction: capture a suitable high-order page immediately when it is made available
>
> That commit doesn't revert cleanly on v3.7.1, and I don't feel
> comfortable touching that code myself.
>
That patch introduced an accounting bug that was corrected by ef6c5be6
(fix incorrect NR_FREE_PAGES accounting (appears like memory leak)). In
some cases that could look like a hang and potentially confuses a bisection.
That said, I see that you report that 3.7.1 and 3.8-rc2 are affected that
includes that fix and the finger is pointed at compaction so something
is wrong.
> Instead, I disabled THP+compaction under v3.7.1 and I've been unable to
> reproduce the issue without THP+compaction.
>
Implying that it's stuck in compaction somewhere. It could be the case
that compaction alters timing enough to trigger another bug. You say it
tests differently depending on whether TCP or unix sockets are used
which might indicate multiple problems. However, lets try and see if
compaction is the primary problem or not.
> As I mention in http://mid.gmane.org/20121229113434.GA13336@dcvr.yhbt.net
> I run my below test (`toosleepy') with heavy network and disk activity
> for a long time before hitting this.
>
Using a 3.7.1 or 3.8-rc2 kernel, can you reproduce the problem and then
answer the following questions please?
1. What are the contents of /proc/vmstat at the time it is stuck?
2. What are the contents of /proc/PID/stack for every toosleepy
process when they are stuck?
3. Can you do a sysrq+m and post the resulting dmesg?
What I'm looking for is a throttling bug (if pgscan_direct_throttle is
elevated), an isolated page accounting bug (nr_isolated_* is elevated
and process is stuck in congestion_wait in a too_many_isolated() loop)
or a free page accounting bug (big difference between nr_free_pages and
buddy list figures).
I'll try reproducing this early next week if none of that shows an
obvious candidate.
Thanks.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [PATCH net-next] ndisc: Remove unused space at tail of skb for ndisc messages. (TAKE 3)
From: Eric Dumazet @ 2013-01-04 16:00 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: David Miller, netdev
In-Reply-To: <50E6DFEC.7080603@linux-ipv6.org>
On Fri, 2013-01-04 at 22:58 +0900, YOSHIFUJI Hideaki wrote:
> Currently, the size of skb allocated for NDISC is MAX_HEADER +
> LL_RESERVED_SPACE(dev) + packet length + dev->needed_tailroom,
> but only LL_RESERVED_SPACE(dev) bytes is "reserved" for headers.
> As a result, the skb looks like this (after construction of the
> message):
>
> head data tail end
> +--------------------------------------------------------------+
> + | | | |
> +--------------------------------------------------------------+
> |<-hlen---->|<---ipv6 packet------>|<--tlen-->|<--MAX_HEADER-->|
> =LL_ = dev
> RESERVED_ ->needed_
> SPACE(dev) tailroom
>
> As the name implies, "MAX_HEADER" is used for headers, and should
> be "reserved" in prior to packet construction. Or, if some space
> is really required at the tail of ther skb, it should be
> explicitly documented.
>
> We have several option after construction of NDISC message:
>
> Option 1:
>
> head data tail end
> +---------------------------------------------+
> + | | |
> +---------------------------------------------+
> |<-hlen---->|<---ipv6 packet------>|<--tlen-->|
> =LL_ = dev
> RESERVED_ ->needed_
> SPACE(dev) tailroom
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: NULL pointer dereference in veth_stats_one
From: Eric Dumazet @ 2013-01-04 15:45 UTC (permalink / raw)
To: Tom Parkin; +Cc: netdev
In-Reply-To: <20130104105955.GA3663@raven>
On Fri, 2013-01-04 at 10:59 +0000, Tom Parkin wrote:
> Hi list,
>
> I recently tripped over a NULL pointer dereference in the veth driver.
> I'm running a 3.8.0_rc1 (updated from net-next git tree this morning)
> on an Athlon 64 X2 machine running a 32 bit kernel. To trigger the
> oops I simply created a veth interface as follows:
>
> ip link add name ve0 type veth peer name ve1
>
> I did a little digging in the git history and I note that veth
> statistics changed a little with commit 2681128f0ced8aa4. I tried
> reverting that commit in my tree, which made the oops go away again.
>
> Thanks,
> Tom
Thanks Tom, I'll fix this.
^ permalink raw reply
* Re: load/unload dccp module caused oops
From: Christoph Lameter @ 2013-01-04 15:05 UTC (permalink / raw)
To: CAI Qian
Cc: netdev, Dave Miller, stable, linux-kernel, Pekka Enberg,
Glauber Costa
In-Reply-To: <2084106232.8072575.1357285039431.JavaMail.root@redhat.com>
See the fix available here:
https://patchwork.kernel.org/patch/1909861/
On Fri, 4 Jan 2013, CAI Qian wrote:
> The bisecting pointed out this commit fixed the problem in
> the mainline.
>
> 3c58346525d82625e68e24f071804c2dc057b6f4
> slab: Simplify bootstrap
>
> However, simply back-ported this single commit to the 3.7.1
> stable wasn't enough to fix it. My guess is that there are
> some other slab/slub commits required to fix this. Keep digging...
>
> The kernel config used the SLUB,
> http://people.redhat.com/qcai/stable/.config
>
> CAI Qian
>
> ----- Original Message -----
> > From: "CAI Qian" <caiqian@redhat.com>
> > To: netdev@vger.kernel.org
> > Cc: "Dave Miller" <davem@redhat.com>, stable@vger.kernel.org
> > Sent: Friday, January 4, 2013 9:57:43 AM
> > Subject: Re: load/unload dccp module caused
> >
> > Adding the netdev as Dave suggested.
> >
> > ----- Original Message -----
> > > From: "CAI Qian" <caiqian@redhat.com>
> > > To: stable@vger.kernel.org
> > > Cc: "Dave Miller" <davem@redhat.com>
> > > Sent: Monday, December 31, 2012 5:42:59 PM
> > > Subject: load/unload dccp module caused
> > >
> > > Just a head up that load and then unload the dccp module
> > > caused an oops below using the current stable kernel - v3.7.1.
> > > Some additional data point here: the mainline v3.6 release has
> > > no such problem, so this looks like a regression. The mainline
> > > v3.8-rc1 also has no such problem, so it looks like it has
> > > already been fixed there but looks like yet queued up for the
> > > stable yet (tested a few commits in Greg's stable-queue and
> > > Dave's net-stable queue did not find anything obvious to fix
> > > this). I am in-process to bisect to figure out the one that
> > > need to back-port right now.
> > >
> > > [ 93.809573]
> > > =============================================================================
> > > [ 93.809577] BUG kmalloc-16 (Tainted: G B ): Objects
> > > remaining in kmalloc-16 on kmem_cache_close()
> > > [ 93.809580]
> > > -----------------------------------------------------------------------------
> > > [ 93.809580]
> > > ...
> > > [ 356.336244] INFO: Object 0xc0000000fa1f0aa0 @offset=2720
> > > [ 356.336247] INFO: Object 0xc0000000fa1f0ab0 @offset=2736
> > > [ 356.336249] INFO: Object 0xc0000000fa1f0ac0 @offset=2752
> > > [ 356.336254] INFO: Object 0xc0000000fa1f0ad0 @offset=2768
> > > [ 356.336257] INFO: Object 0xc0000000fa1f0ae0 @offset=2784
> > > [ 356.336259] INFO: Object 0xc0000000fa1f0af0 @offset=2800
> > > [ 356.336262] INFO: Object 0xc0000000fa1f0b80 @offset=2944
> > > [ 356.336264] INFO: Object 0xc0000000fa1f0bd0 @offset=3024
> > > [ 356.336271] INFO: Object 0xc0000000fa1f1870 @offset=6256
> > > [ 356.336274] INFO: Object 0xc0000000fa1f1880 @offset=6272
> > > [ 356.336276] INFO: Object 0xc0000000fa1f1890 @offset=6288
> > > [ 356.346976] INFO: Object 0xc0000000fa1f18a0 @offset=6304
> > > [ 356.346979] INFO: Object 0xc0000000fa1f18b0 @offset=6320
> > > [ 356.346981] INFO: Object 0xc0000000fa1f1950 @offset=6480
> > > [ 356.346986] INFO: Object 0xc0000000fa1f1960 @offset=6496
> > > [ 356.346989] INFO: Object 0xc0000000fa1f1970 @offset=6512
> > > [ 356.346991] INFO: Object 0xc0000000fa1f1980 @offset=6528
> > > [ 356.346994] INFO: Object 0xc0000000fa1f1990 @offset=6544
> > > [ 356.346997] INFO: Object 0xc0000000fa1f19a0 @offset=6560
> > > [ 356.346999] INFO: Object 0xc0000000fa1f19b0 @offset=6576
> > > [ 356.347005] INFO: Object 0xc0000000fa1f19c0 @offset=6592
> > > [ 356.347008] INFO: Object 0xc0000000fa1f19d0 @offset=6608
> > > [ 356.347010] INFO: Object 0xc0000000fa1f19e0 @offset=6624
> > > [ 356.347012] INFO: Object 0xc0000000fa1f19f0 @offset=6640
> > > [ 356.347081] kmem_cache_destroy kmalloc-16: Slab cache still has
> > > objects
> > > ...
> > > [441283.322161] BUG: unable to handle kernel NULL pointer
> > > dereference
> > > at (null)
> > > [441283.331020] IP: [<ffffffff811785f9>]
> > > __kmem_cache_shutdown+0xa9/0x2f0
> > > [441283.338320] PGD 105568f067 PUD 104a086067 PMD 0
> > > [441283.343600] Oops: 0000 [#1] SMP
> > > [441283.347318] Modules linked in: dccp(-) nf_tproxy_core deflate
> > > zlib_deflate lzo nls_koi8_u nls_cp932 ts_kmp sctp libcrc32c
> > > binfmt_misc des_generic md4 nls_utf8 cifs dns_resolver sg iTCO_wdt
> > > kvm_intel igb iTCO_vendor_support coretemp kvm crc32c_intel lpc_ich
> > > i7core_edac edac_core i2c_i801 i2c_core mfd_core pcspkr microcode
> > > ioatdma dca sr_mod cdrom ata_generic sd_mod pata_acpi crc_t10dif
> > > ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
> > > [last unloaded: inet_diag]
> > > [441283.395187] CPU 6
> > > [441283.397337] Pid: 40979, comm: modprobe Tainted: G B
> > > 3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
> > > [441283.407245] RIP: 0010:[<ffffffff811785f9>]
> > > [<ffffffff811785f9>]
> > > __kmem_cache_shutdown+0xa9/0x2f0
> > > [441283.417256] RSP: 0018:ffff88205247de08 EFLAGS: 00010292
> > > [441283.423280] RAX: ffff881059780001 RBX: ffff88085acfa000 RCX:
> > > 00000000001c7d72
> > > [441283.431336] RDX: 00000000001c7d71 RSI: 0000000000000ff0 RDI:
> > > ffff88085f802600
> > > [441283.439394] RBP: ffff88205247de68 R08: 0000000000016940 R09:
> > > ffff88105fd36940
> > > [441283.447451] R10: ffffea004165e000 R11: ffffffff81178721 R12:
> > > ffffffffffffffe0
> > > [441283.455508] R13: ffff88085acf9000 R14: ffff88085f802500 R15:
> > > ffffea00216b3e40
> > > [441283.463565] FS: 00007fd36f206740(0000)
> > > GS:ffff88105fc20000(0000)
> > > knlGS:0000000000000000
> > > [441283.472687] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > [441283.479194] CR2: 00007fd545ae9c74 CR3: 000000104a273000 CR4:
> > > 00000000000007e0
> > > [441283.487251] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > > 0000000000000000
> > > [441283.495308] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> > > 0000000000000400
> > > [441283.503366] Process modprobe (pid: 40979, threadinfo
> > > ffff88205247c000, task ffff8820493fb240)
> > > [441283.512974] Stack:
> > > [441283.515312] ffffffffa0169760 ffff8810597800c0 0000000000000000
> > > 0000000000000000
> > > [441283.523705] ffff88085f8010d0 ffff88085f8010c0 ffff88205247de68
> > > ffff88085f802500
> > > [441283.532104] ffff88085f802568 0000000000000000 00000000011ec578
> > > 0000000000000000
> > > [441283.540499] Call Trace:
> > > [441283.543328] [<ffffffff8114993a>] kmem_cache_destroy+0x3a/0xe0
> > > [441283.549941] [<ffffffffa0164c0a>] tfrc_li_exit+0x1a/0x30 [dccp]
> > > [441283.556649] [<ffffffffa01635e8>] tfrc_lib_exit+0x18/0x20
> > > [dccp]
> > > [441283.563451] [<ffffffffa01583e6>]
> > > ccid_cleanup_builtins+0x26/0x30
> > > [dccp]
> > > [441283.571032] [<ffffffffa0164e33>] dccp_fini+0xe/0x1db [dccp]
> > > [441283.577449] [<ffffffffa0164e25>] ? scaled_div.part.0+0x6/0x6
> > > [dccp]
> > > [441283.584639] [<ffffffff810bc3fe>] sys_delete_module+0x16e/0x2d0
> > > [441283.591342] [<ffffffff810d851c>] ?
> > > __audit_syscall_entry+0xcc/0x300
> > > [441283.598530] [<ffffffff810d8b3c>] ?
> > > __audit_syscall_exit+0x3ec/0x450
> > > [441283.605719] [<ffffffff815d3b99>]
> > > system_call_fastpath+0x16/0x1b
> > > [441283.612516] Code: 48 39 d7 4d 89 ec 75 41 e9 55 01 00 00 0f 1f
> > > 44
> > > 00 00 e8 0b f7 16 00 48 8b 55 c8 4c 89 fe 4c 89 f7 48 83 6a 08 01
> > > e8
> > > 97 c6 ff ff <49> 8b 44 24 20 49 8d 7c 24 20 4d 89 e7 48 83 e8 20 48
> > > 39 7d c0
> > > [441283.634440] RIP [<ffffffff811785f9>]
> > > __kmem_cache_shutdown+0xa9/0x2f0
> > > [441283.641831] RSP <ffff88205247de08>
> > > [441283.645817] CR2: 0000000000000000
> > > [441283.649815] ---[ end trace 8e20d31634421a27 ]---
> > >
> > > CAI Qian
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe stable"
> > > in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> > --
> > To unsubscribe from this list: send the line "unsubscribe stable" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
^ permalink raw reply
* IFF_NOARP behaviour
From: Jiri Pirko @ 2013-01-04 15:02 UTC (permalink / raw)
To: netdev
Hi.
When I set IFF_NOARP on ordinary ethernet device and try for example
ping to some ip withing the configured network, I see that the frames
have the same dst MAC as src MAC (iface MAC). Is this correct?
Is this behaviour documented somewhere?
Thanks a lot.
Jiri
^ permalink raw reply
* Problem with unregister_netdevice
From: Tomas Vasko @ 2013-01-04 14:22 UTC (permalink / raw)
To: netdev
Hi all,
after upgrade from 3.5.7 to 3.6.x I am experiencing problem with
unregistering of network devices like:
kernel:[ 1523.380066] unregister_netdevice: waiting for XX to become free. Usage count = YY
The XX seems to be an interface used for either ipsec transport or
ipsec tunnel and YY seems to be number of recently active ipsec peers.
Problem occurs when multiple routing tables are used.
>From bisecting on .../git/torvalds/linux-2.6.git it seems the culprit is
this commit: 81166dd6fa8eb780b2132d32fbc77eb6ac04e44e
Steps to reproduce:
see setup-81166dd.sh script bellow, on two computers (say nodeA and nodeB)
run it with swapped arguments --
on nodeA run: setup-81166dd.sh eth1 A B
on nodeB run: setup-81166dd.sh eth1 B A
Script assumes you are using 8139cp driver for your device, please change for
any other. I've used this one for one interface in kvm while cutting my system
down for this reproduction.
Finally on node A run: ping6 -n fc00:B::1
and on node B run: ping6 -n fc00:A::1 -f -c 1500 ; modprobe -r 8139cp
This usually triggers the bug immediately, sometimes more pinging or more time
(up to 2 minutes) is needed to trigger it.
Problem is present also in 3.8-rc2 although there is takes longer time to
trigger. I did not hit it on single core computer.
Please let me know if there is anything I can do to help fixing the problem.
thanks,
tomas
-------------- setup-81166dd.sh --------------
#!/bin/bash
#on node A run: $0 eth2 A B
#on node B run: $0 eth2 B A
[ $# -ne 3 ] && { echo usage: $0 dev A B; exit 1; }
dev=$1
A=$2
B=$3
modprobe 8139cp
sleep 1
ip l s $dev up
ip a a fc00:$A::1/128 dev $dev
ip -6 r a fc00::/16 dev $dev table 2
ip -6 r a fe80::/64 dev $dev table 2
ip -6 rule add to fc00::/16 table 2
setkey -c << __END__
flush;
spdflush;
add fc00:$A::1 fc00:$B::1 ah 0x2$A$B -A hmac-md5 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
add fc00:$B::1 fc00:$A::1 ah 0x2$B$A -A hmac-md5 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
add fc00:$A::1 fc00:$B::1 esp 0x1$A$B -E 3des-cbc 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
add fc00:$B::1 fc00:$A::1 esp 0x1$B$A -E 3des-cbc 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
spdadd fc00:$A::1 fc00:$B::1 any -P out ipsec
esp/transport//require
ah/transport//require;
spdadd fc00:$B::1 fc00:$A::1 any -P in ipsec
esp/transport//require
ah/transport//require;
__END__
exit 0
^ permalink raw reply
* [PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown
From: Lubomir Rintel @ 2013-01-04 14:17 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, linux-kernel, Lubomir Rintel
In-Reply-To: <1357308422-19639-1-git-send-email-lkundrak@v3.sk>
=================================
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: G W
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
NetworkManager/337 [HC0[0]:SC0[0]:HE1:SE1] takes:
(_xmit_ETHER#2){+.?...}, at: [<bf07adfc>] txq_reclaim+0x54/0x264 [mv643xx_eth]
{IN-SOFTIRQ-W} state was registered at:
[<c0068480>] __lock_acquire+0x5b4/0x17d0
[<c0069d7c>] lock_acquire+0x160/0x1e0
[<c04f41a0>] _raw_spin_lock+0x50/0x88
[<c0407178>] sch_direct_xmit+0x4c/0x2d4
[<c03ec978>] dev_queue_xmit+0x4b8/0x8d8
[<c0492dc8>] ip6_finish_output2+0x350/0x42c
[<c04b7fd8>] mld_sendpack+0x2d0/0x514
[<c04b8834>] mld_ifc_timer_expire+0x228/0x278
[<c002afe8>] call_timer_fn+0x140/0x33c
[<c002bbf0>] run_timer_softirq+0x278/0x32c
[<c0024288>] __do_softirq+0x16c/0x398
[<c002488c>] irq_exit+0x5c/0xc0
[<c0009c64>] handle_IRQ+0x6c/0x8c
[<c04f5218>] __irq_svc+0x38/0x80
[<c0065684>] lock_is_held+0x4/0x54
[<c004d5a0>] __might_sleep+0x44/0x228
[<c04f25a4>] down_read+0x28/0x88
[<c0263c94>] __copy_to_user_memcpy+0xa8/0x140
[<c01374d0>] seq_read+0x3ac/0x474
[<c011623c>] vfs_read+0xac/0x184
[<c0116354>] sys_read+0x40/0x6c
[<c0008cc0>] ret_fast_syscall+0x0/0x38
irq event stamp: 115119
hardirqs last enabled at (115119): [<c04f4cf0>] _raw_spin_unlock_irqrestore+0x44/0x64
hardirqs last disabled at (115118): [<c04f430c>] _raw_spin_lock_irqsave+0x28/0xa0
softirqs last enabled at (114880): [<c00243d4>] __do_softirq+0x2b8/0x398
softirqs last disabled at (114873): [<c002488c>] irq_exit+0x5c/0xc0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER#2);
<Interrupt>
lock(_xmit_ETHER#2);
*** DEADLOCK ***
1 lock held by NetworkManager/337:
#0: (rtnl_mutex){+.+.+.}, at: [<c03fad04>] rtnetlink_rcv+0x14/0x2c
stack backtrace:
[<c000f5a8>] (unwind_backtrace+0x0/0x124) from [<c04ebea8>] (print_usage_bug.part.29+0x20c/0x26c)
[<c04ebea8>] (print_usage_bug.part.29+0x20c/0x26c) from [<c0067cc4>] (mark_lock+0x404/0x60c)
[<c0067cc4>] (mark_lock+0x404/0x60c) from [<c0068504>] (__lock_acquire+0x638/0x17d0)
[<c0068504>] (__lock_acquire+0x638/0x17d0) from [<c0069d7c>] (lock_acquire+0x160/0x1e0)
[<c0069d7c>] (lock_acquire+0x160/0x1e0) from [<c04f41a0>] (_raw_spin_lock+0x50/0x88)
[<c04f41a0>] (_raw_spin_lock+0x50/0x88) from [<bf07adfc>] (txq_reclaim+0x54/0x264 [mv643xx_eth])
[<bf07adfc>] (txq_reclaim+0x54/0x264 [mv643xx_eth]) from [<bf07b03c>] (txq_deinit+0x30/0xec [mv643xx_eth])
[<bf07b03c>] (txq_deinit+0x30/0xec [mv643xx_eth]) from [<bf07b21c>] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth])
[<bf07b21c>] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth]) from [<c03e8bbc>] (__dev_close_many+0xb0/0xec)
[<c03e8bbc>] (__dev_close_many+0xb0/0xec) from [<c03e8c28>] (__dev_close+0x30/0x44)
[<c03e8c28>] (__dev_close+0x30/0x44) from [<c03ed154>] (__dev_change_flags+0x94/0x120)
[<c03ed154>] (__dev_change_flags+0x94/0x120) from [<c03ed260>] (dev_change_flags+0x18/0x4c)
[<c03ed260>] (dev_change_flags+0x18/0x4c) from [<c03fb174>] (do_setlink+0x2cc/0x7ac)
[<c03fb174>] (do_setlink+0x2cc/0x7ac) from [<c03fc5ec>] (rtnl_newlink+0x26c/0x4a8)
[<c03fc5ec>] (rtnl_newlink+0x26c/0x4a8) from [<c03fc104>] (rtnetlink_rcv_msg+0x280/0x29c)
[<c03fc104>] (rtnetlink_rcv_msg+0x280/0x29c) from [<c041245c>] (netlink_rcv_skb+0x58/0xb4)
[<c041245c>] (netlink_rcv_skb+0x58/0xb4) from [<c03fad10>] (rtnetlink_rcv+0x20/0x2c)
[<c03fad10>] (rtnetlink_rcv+0x20/0x2c) from [<c0411dec>] (netlink_unicast+0x158/0x208)
[<c0411dec>] (netlink_unicast+0x158/0x208) from [<c0412254>] (netlink_sendmsg+0x310/0x3c0)
[<c0412254>] (netlink_sendmsg+0x310/0x3c0) from [<c03d209c>] (sock_sendmsg+0xa8/0xd0)
[<c03d209c>] (sock_sendmsg+0xa8/0xd0) from [<c03d2314>] (__sys_sendmsg+0x1d8/0x280)
[<c03d2314>] (__sys_sendmsg+0x1d8/0x280) from [<c03d4054>] (sys_sendmsg+0x44/0x68)
[<c03d4054>] (sys_sendmsg+0x44/0x68) from [<c0008cc0>] (ret_fast_syscall+0x0/0x38)
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
---
I've sent an incorrect version; resending with a proper signoff and headers
this time; sorry about that.
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..67a3e78 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -943,7 +943,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
struct netdev_queue *nq = netdev_get_tx_queue(mp->dev, txq->index);
int reclaimed;
- __netif_tx_lock(nq, smp_processor_id());
+ __netif_tx_lock_bh(nq);
reclaimed = 0;
while (reclaimed < budget && txq->tx_desc_count > 0) {
@@ -989,7 +989,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
dev_kfree_skb(skb);
}
- __netif_tx_unlock(nq);
+ __netif_tx_unlock_bh(nq);
if (reclaimed < budget)
mp->work_tx &= ~(1 << txq->index);
--
1.7.1
^ permalink raw reply related
* [PATCH] mv643xx_eth: Fix a possible deadlock upon ifdown
From: Lubomir Rintel @ 2013-01-04 14:07 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: netdev, linux-kernel, Lubomir Rintel
From: Lubomir Rintel <lubo.rintel@gooddata.com>
=================================
[ INFO: inconsistent lock state ]
3.7.0-6.luboskovo.fc19.armv5tel.kirkwood #1 Tainted: G W
---------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
NetworkManager/337 [HC0[0]:SC0[0]:HE1:SE1] takes:
(_xmit_ETHER#2){+.?...}, at: [<bf07adfc>] txq_reclaim+0x54/0x264 [mv643xx_eth]
{IN-SOFTIRQ-W} state was registered at:
[<c0068480>] __lock_acquire+0x5b4/0x17d0
[<c0069d7c>] lock_acquire+0x160/0x1e0
[<c04f41a0>] _raw_spin_lock+0x50/0x88
[<c0407178>] sch_direct_xmit+0x4c/0x2d4
[<c03ec978>] dev_queue_xmit+0x4b8/0x8d8
[<c0492dc8>] ip6_finish_output2+0x350/0x42c
[<c04b7fd8>] mld_sendpack+0x2d0/0x514
[<c04b8834>] mld_ifc_timer_expire+0x228/0x278
[<c002afe8>] call_timer_fn+0x140/0x33c
[<c002bbf0>] run_timer_softirq+0x278/0x32c
[<c0024288>] __do_softirq+0x16c/0x398
[<c002488c>] irq_exit+0x5c/0xc0
[<c0009c64>] handle_IRQ+0x6c/0x8c
[<c04f5218>] __irq_svc+0x38/0x80
[<c0065684>] lock_is_held+0x4/0x54
[<c004d5a0>] __might_sleep+0x44/0x228
[<c04f25a4>] down_read+0x28/0x88
[<c0263c94>] __copy_to_user_memcpy+0xa8/0x140
[<c01374d0>] seq_read+0x3ac/0x474
[<c011623c>] vfs_read+0xac/0x184
[<c0116354>] sys_read+0x40/0x6c
[<c0008cc0>] ret_fast_syscall+0x0/0x38
irq event stamp: 115119
hardirqs last enabled at (115119): [<c04f4cf0>] _raw_spin_unlock_irqrestore+0x44/0x64
hardirqs last disabled at (115118): [<c04f430c>] _raw_spin_lock_irqsave+0x28/0xa0
softirqs last enabled at (114880): [<c00243d4>] __do_softirq+0x2b8/0x398
softirqs last disabled at (114873): [<c002488c>] irq_exit+0x5c/0xc0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER#2);
<Interrupt>
lock(_xmit_ETHER#2);
*** DEADLOCK ***
1 lock held by NetworkManager/337:
#0: (rtnl_mutex){+.+.+.}, at: [<c03fad04>] rtnetlink_rcv+0x14/0x2c
stack backtrace:
[<c000f5a8>] (unwind_backtrace+0x0/0x124) from [<c04ebea8>] (print_usage_bug.part.29+0x20c/0x26c)
[<c04ebea8>] (print_usage_bug.part.29+0x20c/0x26c) from [<c0067cc4>] (mark_lock+0x404/0x60c)
[<c0067cc4>] (mark_lock+0x404/0x60c) from [<c0068504>] (__lock_acquire+0x638/0x17d0)
[<c0068504>] (__lock_acquire+0x638/0x17d0) from [<c0069d7c>] (lock_acquire+0x160/0x1e0)
[<c0069d7c>] (lock_acquire+0x160/0x1e0) from [<c04f41a0>] (_raw_spin_lock+0x50/0x88)
[<c04f41a0>] (_raw_spin_lock+0x50/0x88) from [<bf07adfc>] (txq_reclaim+0x54/0x264 [mv643xx_eth])
[<bf07adfc>] (txq_reclaim+0x54/0x264 [mv643xx_eth]) from [<bf07b03c>] (txq_deinit+0x30/0xec [mv643xx_eth])
[<bf07b03c>] (txq_deinit+0x30/0xec [mv643xx_eth]) from [<bf07b21c>] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth])
[<bf07b21c>] (mv643xx_eth_stop+0x124/0x140 [mv643xx_eth]) from [<c03e8bbc>] (__dev_close_many+0xb0/0xec)
[<c03e8bbc>] (__dev_close_many+0xb0/0xec) from [<c03e8c28>] (__dev_close+0x30/0x44)
[<c03e8c28>] (__dev_close+0x30/0x44) from [<c03ed154>] (__dev_change_flags+0x94/0x120)
[<c03ed154>] (__dev_change_flags+0x94/0x120) from [<c03ed260>] (dev_change_flags+0x18/0x4c)
[<c03ed260>] (dev_change_flags+0x18/0x4c) from [<c03fb174>] (do_setlink+0x2cc/0x7ac)
[<c03fb174>] (do_setlink+0x2cc/0x7ac) from [<c03fc5ec>] (rtnl_newlink+0x26c/0x4a8)
[<c03fc5ec>] (rtnl_newlink+0x26c/0x4a8) from [<c03fc104>] (rtnetlink_rcv_msg+0x280/0x29c)
[<c03fc104>] (rtnetlink_rcv_msg+0x280/0x29c) from [<c041245c>] (netlink_rcv_skb+0x58/0xb4)
[<c041245c>] (netlink_rcv_skb+0x58/0xb4) from [<c03fad10>] (rtnetlink_rcv+0x20/0x2c)
[<c03fad10>] (rtnetlink_rcv+0x20/0x2c) from [<c0411dec>] (netlink_unicast+0x158/0x208)
[<c0411dec>] (netlink_unicast+0x158/0x208) from [<c0412254>] (netlink_sendmsg+0x310/0x3c0)
[<c0412254>] (netlink_sendmsg+0x310/0x3c0) from [<c03d209c>] (sock_sendmsg+0xa8/0xd0)
[<c03d209c>] (sock_sendmsg+0xa8/0xd0) from [<c03d2314>] (__sys_sendmsg+0x1d8/0x280)
[<c03d2314>] (__sys_sendmsg+0x1d8/0x280) from [<c03d4054>] (sys_sendmsg+0x44/0x68)
[<c03d4054>] (sys_sendmsg+0x44/0x68) from [<c0008cc0>] (ret_fast_syscall+0x0/0x38)
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 84c1326..67a3e78 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -943,7 +943,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
struct netdev_queue *nq = netdev_get_tx_queue(mp->dev, txq->index);
int reclaimed;
- __netif_tx_lock(nq, smp_processor_id());
+ __netif_tx_lock_bh(nq);
reclaimed = 0;
while (reclaimed < budget && txq->tx_desc_count > 0) {
@@ -989,7 +989,7 @@ static int txq_reclaim(struct tx_queue *txq, int budget, int force)
dev_kfree_skb(skb);
}
- __netif_tx_unlock(nq);
+ __netif_tx_unlock_bh(nq);
if (reclaimed < budget)
mp->work_tx &= ~(1 << txq->index);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] ndisc: Remove unused space at tail of skb for ndisc messages. (TAKE 3)
From: YOSHIFUJI Hideaki @ 2013-01-04 13:58 UTC (permalink / raw)
To: David Miller, Eric Dumazet, netdev, YOSHIFUJI Hideaki
Currently, the size of skb allocated for NDISC is MAX_HEADER +
LL_RESERVED_SPACE(dev) + packet length + dev->needed_tailroom,
but only LL_RESERVED_SPACE(dev) bytes is "reserved" for headers.
As a result, the skb looks like this (after construction of the
message):
head data tail end
+--------------------------------------------------------------+
+ | | | |
+--------------------------------------------------------------+
|<-hlen---->|<---ipv6 packet------>|<--tlen-->|<--MAX_HEADER-->|
=LL_ = dev
RESERVED_ ->needed_
SPACE(dev) tailroom
As the name implies, "MAX_HEADER" is used for headers, and should
be "reserved" in prior to packet construction. Or, if some space
is really required at the tail of ther skb, it should be
explicitly documented.
We have several option after construction of NDISC message:
Option 1:
head data tail end
+---------------------------------------------+
+ | | |
+---------------------------------------------+
|<-hlen---->|<---ipv6 packet------>|<--tlen-->|
=LL_ = dev
RESERVED_ ->needed_
SPACE(dev) tailroom
Option 2:
head data tail end
+--------------------------------------------------+
+ | | |
+--------------------------------------------------+
|<--MAX_HEADER-->|<---ipv6 packet------>|<--tlen-->|
= dev
->needed_
tailroom
Option 3:
head data tail end
+--------------------------------------------------------------+
+ | | | |
+--------------------------------------------------------------+
|<--MAX_HEADER-->|<-hlen---->|<---ipv6 packet------>|<--tlen-->|
=LL_ = dev
RESERVED_ ->needed_
SPACE(dev) tailroom
Our tunnel drivers try expanding headroom and the space for tunnel
encapsulation was not a mandatory space -- so we are not seeing
bugs here --, but just for optimization for performance critial
situations.
Since NDISC messages are not performance critical unlike TCP,
and as we know outgoing device, LL_RESERVED_SPACE(dev) should be
just enough for the device in most (if not all) cases:
LL_RESERVED_SPACE(dev) <= LL_MAX_HEADER <= MAX_HEADER
Note that LL_RESERVED_SPACE(dev) is also enough for NDISC over
SIT (e.g., ISATAP).
So, I think Option 1 is just fine here.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
net/ipv6/ndisc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 6574175..4c4ccf7 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -395,7 +395,7 @@ static struct sk_buff *ndisc_build_skb(struct net_device *dev,
len += ndisc_opt_addr_space(dev);
skb = sock_alloc_send_skb(sk,
- (MAX_HEADER + sizeof(struct ipv6hdr) +
+ (sizeof(struct ipv6hdr) +
len + hlen + tlen),
1, &err);
if (!skb) {
@@ -1439,7 +1439,7 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
hlen = LL_RESERVED_SPACE(dev);
tlen = dev->needed_tailroom;
buff = sock_alloc_send_skb(sk,
- (MAX_HEADER + sizeof(struct ipv6hdr) +
+ (sizeof(struct ipv6hdr) +
len + hlen + tlen),
1, &err);
if (buff == NULL) {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH -v2 19/26] batman-adv: rename random32() to prandom_u32()
From: Akinobu Mita @ 2013-01-04 13:50 UTC (permalink / raw)
To: Antonio Quartulli
Cc: linux-kernel, akpm, Marek Lindner, Simon Wunderlich, b.a.t.m.a.n,
David S. Miller, netdev
In-Reply-To: <20130104021252.GE27589@ritirata.org>
2013/1/4 Antonio Quartulli <ordex@autistici.org>:
> On Thu, Jan 03, 2013 at 09:19:15PM +0900, Akinobu Mita wrote:
>> Use more preferable function name which implies using a pseudo-random
>> number generator.
>>
>> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
>> Acked-by: Antonio Quartulli <ordex@autistici.org>
>> Cc: Marek Lindner <lindner_marek@yahoo.de>
>> Cc: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
>> Cc: Antonio Quartulli <ordex@autistici.org>
>> Cc: b.a.t.m.a.n@lists.open-mesh.org
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: netdev@vger.kernel.org
>> ---
>
> Hello Akinobu,
>
> as you can see in <201301021952.49979.lindner_marek@yahoo.de>, Marek Lindner
> already applied this change onto our tree. You didn't need to resend this patch
> to netdev, it will be sent by us through a future pull request.
Yes. I read Marek's email. But I included it in v2 again in order not
to break the build. Because it doesn't show up the latest linux-next yet
and the last patch 26/26 removes random32() and srandom32().
But I should have mentioned it and trimmed the Cc list.
Sorry for the confusion.
^ permalink raw reply
* Re: [PATCH v3 1/1 net-next] NET: FEC: dynamtic check DMA desc buff type
From: Sascha Hauer @ 2013-01-04 13:09 UTC (permalink / raw)
To: Frank Li; +Cc: lznuaa, davem, linux-arm-kernel, shawn.guo, netdev
In-Reply-To: <1357265063-30528-1-git-send-email-Frank.Li@freescale.com>
On Fri, Jan 04, 2013 at 10:04:23AM +0800, Frank Li wrote:
> MX6 and mx28 support enhanced DMA descriptor buff to support 1588
> ptp. But MX25, MX3x, MX5x can't support enhanced DMA descriptor buff.
> Check fec type and choose correct DMA descriptor buff type.
>
> Remove static config CONFIG_FEC_PTP.
> ptp function will be auto detected.
>
> Signed-off-by: Frank Li <Frank.Li@freescale.com>
Two minor comments, otherwise:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> @@ -1574,6 +1617,8 @@ fec_probe(struct platform_device *pdev)
> fep->pdev = pdev;
> fep->dev_id = dev_id++;
>
> + fep->bufdesc_ex = 0;
> +
fep already is zeroed, so this is unnecessary.
> if (!fep->hwp) {
> ret = -ENOMEM;
> goto failed_ioremap;
> @@ -1628,19 +1673,19 @@ fec_probe(struct platform_device *pdev)
> goto failed_clk;
> }
>
> -#ifdef CONFIG_FEC_PTP
> fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
> + fep->bufdesc_ex =
> + pdev->id_entry->driver_data & FEC_QUIRK_HAS_BUFDESC_EX;
> if (IS_ERR(fep->clk_ptp)) {
> ret = PTR_ERR(fep->clk_ptp);
> - goto failed_clk;
> + fep->bufdesc_ex = 0;
> }
Since you remove the goto you can remove the 'ret =' aswell.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH net-next] softirq: reduce latencies
From: Sedat Dilek @ 2013-01-04 11:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Rick Jones, netdev, LKML
In-Reply-To: <1357274510.21409.27807.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]
On Fri, Jan 4, 2013 at 5:41 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2013-01-03 at 11:41 -0800, Rick Jones wrote:
>
>> In terms of netperf overhead, once you specify P99_LATENCY, you are
>> already in for the pound of cost but only getting the penny of output
>> (so to speak). While it would clutter the output, one could go ahead
>> and ask for the other latency stats and it won't "cost" anything more:
>>
>> ... -- -k
>> RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
>>
>> Additional information about how the omni output selectors work can be
>> found at
>> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Omni-Output-Selection
>>
>> happy benchmarking,
>>
>> rick jones
>>
>> BTW - you will likely see some differences between RT_LATENCY, which is
>> calculated from the average transactions per second, and MEAN_LATENCY,
>> which is calculated from the histogram of individual latencies
>> maintained when any of the _LATENCY outputs other than RT_LATENCY is
>> requested. Kudos to the folks at Google who did the extensions to the
>> then-existing histogram code to enable it to be used for more reasonably
>> accurate statistics.
>>
>
> Yeah ;)
>
> Here are the before/after_patch results, cpu 2 handling the NIC irqs :
>
>
> Before patch :
>
> # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
> RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
> RT_LATENCY=550110.424
> MIN_LATENCY=146858
> MAX_LATENCY=997109
> P50_LATENCY=305000
> P90_LATENCY=550000
> P99_LATENCY=710000
> MEAN_LATENCY=376989.12
> STDDEV_LATENCY=184046.92
>
> After patch :
>
> # netperf -H 7.7.7.84 -t TCP_RR -T2,2 -- -k
> RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind
> RT_LATENCY=40545.492
> MIN_LATENCY=9834
> MAX_LATENCY=78366
> P50_LATENCY=33583
> P90_LATENCY=59000
> P99_LATENCY=69000
> MEAN_LATENCY=38364.67
> STDDEV_LATENCY=12865.26
>
I also wanted to give some numbers.
But with localhost as default (no netserver running on a remote-host)
I am not sure if these numbers give any helpful feedback.
( I have not tested yet w/o your patch. )
- Sedat -
[-- Attachment #2: NETPERF_softirq-experimental.txt --]
[-- Type: text/plain, Size: 2150 bytes --]
# netperf -H localhost -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET : demo : first burst 0 : cpu bind
RT_LATENCY=11.407
MIN_LATENCY=10
MAX_LATENCY=152
P50_LATENCY=11
P90_LATENCY=12
P99_LATENCY=13
MEAN_LATENCY=11.31
STDDEV_LATENCY=0.95
# netperf -H localhost -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET : demo : first burst 0 : cpu bind
RT_LATENCY=11.364
MIN_LATENCY=10
MAX_LATENCY=156
P50_LATENCY=11
P90_LATENCY=12
P99_LATENCY=13
MEAN_LATENCY=11.27
STDDEV_LATENCY=1.06
# netperf -H localhost -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET : demo : first burst 0 : cpu bind
RT_LATENCY=11.408
MIN_LATENCY=10
MAX_LATENCY=156
P50_LATENCY=11
P90_LATENCY=12
P99_LATENCY=13
MEAN_LATENCY=11.31
STDDEV_LATENCY=1.07
# netperf -H localhost -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET : demo : first burst 0 : cpu bind
RT_LATENCY=11.312
MIN_LATENCY=10
MAX_LATENCY=151
P50_LATENCY=11
P90_LATENCY=12
P99_LATENCY=13
MEAN_LATENCY=11.22
STDDEV_LATENCY=0.94
# netperf -H localhost -t TCP_RR -T2,2 -- -k RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET : demo : first burst 0 : cpu bind
RT_LATENCY=11.345
MIN_LATENCY=10
MAX_LATENCY=159
P50_LATENCY=11
P90_LATENCY=12
P99_LATENCY=13
MEAN_LATENCY=11.25
STDDEV_LATENCY=1.03
-dileks // 04-Jan-2013
^ permalink raw reply
* NULL pointer dereference in veth_stats_one
From: Tom Parkin @ 2013-01-04 10:59 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/plain, Size: 670 bytes --]
Hi list,
I recently tripped over a NULL pointer dereference in the veth driver.
I'm running a 3.8.0_rc1 (updated from net-next git tree this morning)
on an Athlon 64 X2 machine running a 32 bit kernel. To trigger the
oops I simply created a veth interface as follows:
ip link add name ve0 type veth peer name ve1
I did a little digging in the git history and I note that veth
statistics changed a little with commit 2681128f0ced8aa4. I tried
reverting that commit in my tree, which made the oops go away again.
Thanks,
Tom
--
Tom Parkin
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
[-- Attachment #1.2: veth-koops.txt --]
[-- Type: text/plain, Size: 4219 bytes --]
[ 266.169346] BUG: unable to handle kernel NULL pointer dereference at 000002c0
[ 266.172053] IP: [<f8177388>] veth_stats_one.isra.5+0x38/0xd0 [veth]
[ 266.172053] *pde = 00000000
[ 266.172053] Oops: 0000 [#1] SMP
[ 266.172053] Modules linked in: veth bridge stp llc l2tp_ip6 l2tp_ip l2tp_ppp pppox l2tp_eth l2tp_netlink l2tp_core radeon k9
[ 266.193196] Pid: 1544, comm: ip Not tainted 3.8.0-rc1-tpdev-23-lockdep+ #29 Gigabyte Technology Co., Ltd. GA-MA69VM-S2/GA-M2
[ 266.193196] EIP: 0060:[<f8177388>] EFLAGS: 00010297 CPU: 1
[ 266.193196] EIP is at veth_stats_one.isra.5+0x38/0xd0 [veth]
[ 266.193196] EAX: 00000000 EBX: f47cd86c ECX: 00000000 EDX: 00000000
[ 266.193196] ESI: f47cd874 EDI: 00000000 EBP: f47cd864 ESP: f47cd840
[ 266.193196] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 266.193196] CR0: 8005003b CR2: 000002c0 CR3: 34456000 CR4: 000007d0
[ 266.193196] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 266.193196] DR6: ffff0ff0 DR7: 00000400
[ 266.193196] Process ip (pid: 1544, ti=f47cc000 task=f732bf00 task.ti=f47cc000)
[ 266.193196] Stack:
[ 266.193196] f47cd86c 00000003 00000000 00000000 00000000 00000000 f47cd8d4 f345e000
[ 266.193196] f47cd98c f47cd888 f817746d 00000000 00000000 00000000 00000000 c13083d2
[ 266.193196] f47cd8d4 f345e000 f47cd8a0 c14fa6ab f8178040 f345f800 ffffffa6 f345f8bc
[ 266.193196] Call Trace:
[ 266.193196] [<f817746d>] veth_get_stats64+0x4d/0x80 [veth]
[ 266.193196] [<c13083d2>] ? __nla_reserve+0x42/0x60
[ 266.193196] [<c14fa6ab>] dev_get_stats+0x5b/0x100
[ 266.193196] [<c15111e9>] rtnl_fill_ifinfo+0x4d9/0xc30
[ 266.193196] [<c109e2e6>] ? mark_held_locks+0x66/0xf0
[ 266.193196] [<c1155572>] ? __kmalloc_track_caller+0xc2/0x1e0
[ 266.193196] [<c14f201e>] ? __alloc_skb+0x5e/0x260
[ 266.193196] [<c14f1f39>] ? __kmalloc_reserve.isra.58+0x29/0x70
[ 266.193196] [<c14f202d>] ? __alloc_skb+0x6d/0x260
[ 266.193196] [<c15128ed>] rtmsg_ifinfo+0x7d/0x100
[ 266.193196] [<c1512a28>] rtnl_configure_link+0x78/0xa0
[ 266.193196] [<f8177633>] veth_newlink+0x143/0x30c [veth]
[ 266.193196] [<c109e2e6>] ? mark_held_locks+0x66/0xf0
[ 266.193196] [<f81774f0>] ? veth_open+0x50/0x50 [veth]
[ 266.193196] [<c1512edc>] rtnl_newlink+0x48c/0x540
[ 266.193196] [<c1512b5f>] ? rtnl_newlink+0x10f/0x540
[ 266.193196] [<c1512a50>] ? rtnl_configure_link+0xa0/0xa0
[ 266.193196] [<c1512693>] rtnetlink_rcv_msg+0x153/0x2a0
[ 266.193196] [<c160cbea>] ? mutex_lock_nested+0x21a/0x2e0
[ 266.193196] [<c150f534>] ? rtnl_lock+0x14/0x20
[ 266.193196] [<c1512540>] ? __rtnl_unlock+0x20/0x20
[ 266.193196] [<c15294be>] netlink_rcv_skb+0x8e/0xb0
[ 266.193196] [<c150f55c>] rtnetlink_rcv+0x1c/0x30
[ 266.193196] [<c1528e7d>] netlink_unicast+0x17d/0x1f0
[ 266.193196] [<c1529114>] netlink_sendmsg+0x224/0x390
[ 266.193196] [<c14e86c1>] sock_sendmsg+0xd1/0xf0
[ 266.193196] [<c1135b89>] ? might_fault+0x89/0x90
[ 266.193196] [<c12fa932>] ? _copy_from_user+0x42/0x60
[ 266.193196] [<c14f5c14>] ? verify_iovec+0x44/0xb0
[ 266.193196] [<c14e95d2>] __sys_sendmsg+0x262/0x270
[ 266.193196] [<c1073e4f>] ? sched_clock_cpu+0xcf/0x150
[ 266.193196] [<c109c02b>] ? trace_hardirqs_off+0xb/0x10
[ 266.193196] [<c1073f35>] ? local_clock+0x65/0x70
[ 266.193196] [<c109c69c>] ? lock_release_holdtime.part.23+0xbc/0xf0
[ 266.193196] [<c10a15ed>] ? lock_release_non_nested+0x29d/0x2e0
[ 266.193196] [<c1073f35>] ? local_clock+0x65/0x70
[ 266.193196] [<c1178ab1>] ? fget_light+0x371/0x450
[ 266.193196] [<c14eaccb>] sys_sendmsg+0x3b/0x60
[ 266.193196] [<c14eb373>] sys_socketcall+0x283/0x2e0
[ 266.193196] [<c16103e0>] ? restore_all+0xf/0xf
[ 266.193196] [<c1613c90>] ? __do_page_fault+0x4e0/0x4e0
[ 266.193196] [<c12fa548>] ? trace_hardirqs_on_thunk+0xc/0x10
[ 266.193196] [<c1617b8d>] sysenter_do_call+0x12/0x38
[ 266.193196] Code: 00 c7 00 00 00 00 00 89 cf 89 c3 c7 40 04 00 00 00 00 89 d6 b9 ff ff ff ff c7 02 00 00 00 00 c7 42 04 00 b
[ 266.193196] EIP: [<f8177388>] veth_stats_one.isra.5+0x38/0xd0 [veth] SS:ESP 0068:f47cd840
[ 266.193196] CR2: 00000000000002c0
[ 266.553774] ---[ end trace fff0ac235458be49 ]---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* MDaemon Notification -- Attachment Removed
From: Postmaster @ 2013-01-04 8:52 UTC (permalink / raw)
To: netdev
-------------------------------------------------------------------
MDaemon has detected restricted attachments within an email message
-------------------------------------------------------------------
>From : netdev@vger.kernel.org
To : vineet.ahuja@igt.in
Subject : Delivery failed
Message-ID:
---------------------
Attachment(s) removed
---------------------
transcript.scr
^ permalink raw reply
* Re: Support for Marvell 88E1510 and 88E1116R
From: Michal Simek @ 2013-01-04 9:40 UTC (permalink / raw)
To: Steven Wang
Cc: Lars-Peter Clausen, netdev@vger.kernel.org, Christian Hohnstaedt,
Srinivas Kandagatla, David Miller, LKML, John Linn, Sam Bobrowicz,
Rick Hoover
In-Reply-To: <BF617F5A412EFC46879ABC89757850DE02692A298149@SERVER.digilent.local>
Hi Steve,
2013/1/2 Steven Wang <steven.wang@digilentinc.com>:
> Hi, Michal,
>
> We do have the Ethernet support for 88E1510 (used on ZedBoard) in our repository. The commit is
> https://github.com/Digilent/linux-digilent/commit/ae635e5fff35e9fe5928b4aca7264a1e5313a6b8
> Or, I can send the patch to you if you need.
I know. Can you please clean this patch and send it to mainline for review?
(Remove comment and that emacps connection).
I will add this patch to our tree to support this patch.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: [PATCH v2 net-next] softirq: reduce latencies
From: Joe Perches @ 2013-01-04 9:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, David Miller, Andrew Morton, netdev,
linux-kernel@vger.kernel.org, Tom Herbert
In-Reply-To: <1357287786.1678.87.camel@edumazet-glaptop>
On Fri, 2013-01-04 at 00:23 -0800, Eric Dumazet wrote:
> On Fri, 2013-01-04 at 00:15 -0800, Joe Perches wrote:
> > Perhaps MAX_SOFTIRQ_TIME should be
> > #define MAX_SOFTIRQ_TIME msecs_to_jiffies(2)
> > though it would be nicer if it were a compile time constant.
>
> If you send a patch to convert msecs_to_jiffies() to an inline function
> when HZ = 1000, I will gladly use it instead of (2*HZ/1000)
>
> Right now, max(1, msecs_to_jiffies(2)) uses way too many instructions,
> while it should be the constant 2, known at compile time.
Something like this might work.
This is incomplete, it just does msecs_to_jiffies,
and it should convert usecs_to_jiffies and the
jiffies_to_<foo> types too.
Maybe it's worthwhile.
It does reduce object size by 16 bytes per call site
(x86-32) when the argument is a constant. There are
about 800 of these jiffies conversions in kernel sources.
What do you think?
include/linux/jiffies.h | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
kernel/time.c | 42 +++---------------------------------------
2 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 82ed068..c67ddcf 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -291,7 +291,54 @@ extern unsigned long preset_lpj;
*/
extern unsigned int jiffies_to_msecs(const unsigned long j);
extern unsigned int jiffies_to_usecs(const unsigned long j);
-extern unsigned long msecs_to_jiffies(const unsigned int m);
+extern unsigned long __msecs_to_jiffies(const unsigned int m);
+
+static inline unsigned long __inline_msecs_to_jiffies(const unsigned int m)
+{
+ /*
+ * Negative value, means infinite timeout:
+ */
+ if ((int)m < 0)
+ return MAX_JIFFY_OFFSET;
+
+#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
+ /*
+ * HZ is equal to or smaller than 1000, and 1000 is a nice
+ * round multiple of HZ, divide with the factor between them,
+ * but round upwards:
+ */
+ return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
+#elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC)
+ /*
+ * HZ is larger than 1000, and HZ is a nice round multiple of
+ * 1000 - simply multiply with the factor between them.
+ *
+ * But first make sure the multiplication result cannot
+ * overflow:
+ */
+ if (m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
+ return MAX_JIFFY_OFFSET;
+
+ return m * (HZ / MSEC_PER_SEC);
+#else
+ /*
+ * Generic case - multiply, round and divide. But first
+ * check that if we are doing a net multiplication, that
+ * we wouldn't overflow:
+ */
+ if (HZ > MSEC_PER_SEC && m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
+ return MAX_JIFFY_OFFSET;
+
+ return (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32)
+ >> MSEC_TO_HZ_SHR32;
+#endif
+}
+
+#define msecs_to_jiffies(x) \
+ (__builtin_constant_p(x) ? \
+ __inline_msecs_to_jiffies(x) : \
+ __msecs_to_jiffies(x))
+
extern unsigned long usecs_to_jiffies(const unsigned int u);
extern unsigned long timespec_to_jiffies(const struct timespec *value);
extern void jiffies_to_timespec(const unsigned long jiffies,
diff --git a/kernel/time.c b/kernel/time.c
index d226c6a..231f2ac 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -425,47 +425,11 @@ EXPORT_SYMBOL(ns_to_timeval);
*
* We must also be careful about 32-bit overflows.
*/
-unsigned long msecs_to_jiffies(const unsigned int m)
+unsigned long __msecs_to_jiffies(const unsigned int m)
{
- /*
- * Negative value, means infinite timeout:
- */
- if ((int)m < 0)
- return MAX_JIFFY_OFFSET;
-
-#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
- /*
- * HZ is equal to or smaller than 1000, and 1000 is a nice
- * round multiple of HZ, divide with the factor between them,
- * but round upwards:
- */
- return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
-#elif HZ > MSEC_PER_SEC && !(HZ % MSEC_PER_SEC)
- /*
- * HZ is larger than 1000, and HZ is a nice round multiple of
- * 1000 - simply multiply with the factor between them.
- *
- * But first make sure the multiplication result cannot
- * overflow:
- */
- if (m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
- return MAX_JIFFY_OFFSET;
-
- return m * (HZ / MSEC_PER_SEC);
-#else
- /*
- * Generic case - multiply, round and divide. But first
- * check that if we are doing a net multiplication, that
- * we wouldn't overflow:
- */
- if (HZ > MSEC_PER_SEC && m > jiffies_to_msecs(MAX_JIFFY_OFFSET))
- return MAX_JIFFY_OFFSET;
-
- return (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32)
- >> MSEC_TO_HZ_SHR32;
-#endif
+ return __inline_msecs_to_jiffies(m);
}
-EXPORT_SYMBOL(msecs_to_jiffies);
+EXPORT_SYMBOL(__msecs_to_jiffies);
unsigned long usecs_to_jiffies(const unsigned int u)
{
^ permalink raw reply related
* [patch net-next V6 08/15] cxgb3: remove usage of dev->master
From: Jiri Pirko @ 2013-01-04 8:48 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, faisal.latif, roland, sean.hefty, hal.rosenstock,
fubar, andy, divy, jitendra.kalsaria, sony.chacko, linux-driver,
kaber, ursula.braun, blaschka, linux390, shemminger, bhutchings,
therbert, xiyou.wangcong, joe, gregory.v.rose, john.r.fastabend,
linux-rdma, linux-kernel, linux-s390, bridge, fbl
In-Reply-To: <1357289343-817-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
index 942dace..3f1f501 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_offload.c
@@ -182,14 +182,17 @@ static struct net_device *get_iff_from_mac(struct adapter *adapter,
struct net_device *dev = adapter->port[i];
if (!memcmp(dev->dev_addr, mac, ETH_ALEN)) {
+ rcu_read_lock();
if (vlan && vlan != VLAN_VID_MASK) {
- rcu_read_lock();
dev = __vlan_find_dev_deep(dev, vlan);
- rcu_read_unlock();
} else if (netif_is_bond_slave(dev)) {
- while (dev->master)
- dev = dev->master;
+ struct net_device *upper_dev;
+
+ while ((upper_dev =
+ netdev_master_upper_dev_get_rcu(dev)))
+ dev = upper_dev;
}
+ rcu_read_unlock();
return dev;
}
}
--
1.8.0
^ permalink raw reply related
* [patch net-next V6 07/15] netpoll: remove usage of dev->master
From: Jiri Pirko @ 2013-01-04 8:48 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, faisal.latif, roland, sean.hefty, hal.rosenstock,
fubar, andy, divy, jitendra.kalsaria, sony.chacko, linux-driver,
kaber, ursula.braun, blaschka, linux390, shemminger, bhutchings,
therbert, xiyou.wangcong, joe, gregory.v.rose, john.r.fastabend,
linux-rdma, linux-kernel, linux-s390, bridge, fbl
In-Reply-To: <1357289343-817-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/core/netpoll.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 3151acf..d2bda8e 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -210,9 +210,12 @@ static void netpoll_poll_dev(struct net_device *dev)
if (dev->flags & IFF_SLAVE) {
if (ni) {
- struct net_device *bond_dev = dev->master;
+ struct net_device *bond_dev;
struct sk_buff *skb;
- struct netpoll_info *bond_ni = rcu_dereference_bh(bond_dev->npinfo);
+ struct netpoll_info *bond_ni;
+
+ bond_dev = netdev_master_upper_dev_get_rcu(dev);
+ bond_ni = rcu_dereference_bh(bond_dev->npinfo);
while ((skb = skb_dequeue(&ni->arp_tx))) {
skb->dev = bond_dev;
skb_queue_tail(&bond_ni->arp_tx, skb);
@@ -815,7 +818,7 @@ int netpoll_setup(struct netpoll *np)
return -ENODEV;
}
- if (ndev->master) {
+ if (netdev_master_upper_dev_get(ndev)) {
np_err(np, "%s is a slave device, aborting\n", np->dev_name);
err = -EBUSY;
goto put;
--
1.8.0
^ permalink raw reply related
* [patch net-next V6 06/15] bridge: remove usage of netdev_set_master()
From: Jiri Pirko @ 2013-01-04 8:48 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, faisal.latif, roland, sean.hefty, hal.rosenstock,
fubar, andy, divy, jitendra.kalsaria, sony.chacko, linux-driver,
kaber, ursula.braun, blaschka, linux390, shemminger, bhutchings,
therbert, xiyou.wangcong, joe, gregory.v.rose, john.r.fastabend,
linux-rdma, linux-kernel, linux-s390, bridge, fbl
In-Reply-To: <1357289343-817-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/bridge/br_if.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index 1edd71d..2148d47 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -148,7 +148,7 @@ static void del_nbp(struct net_bridge_port *p)
netdev_rx_handler_unregister(dev);
synchronize_net();
- netdev_set_master(dev, NULL);
+ netdev_upper_dev_unlink(dev, br->dev);
br_multicast_del_port(p);
@@ -364,7 +364,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
if (br_netpoll_info(br) && ((err = br_netpoll_enable(p, GFP_KERNEL))))
goto err3;
- err = netdev_set_master(dev, br->dev);
+ err = netdev_master_upper_dev_link(dev, br->dev);
if (err)
goto err4;
@@ -403,7 +403,7 @@ int br_add_if(struct net_bridge *br, struct net_device *dev)
return 0;
err5:
- netdev_set_master(dev, NULL);
+ netdev_upper_dev_unlink(dev, br->dev);
err4:
br_netpoll_disable(p);
err3:
--
1.8.0
^ permalink raw reply related
* [patch net-next V6 04/15] rtnetlink: remove usage of dev->master
From: Jiri Pirko @ 2013-01-04 8:48 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, faisal.latif, roland, sean.hefty, hal.rosenstock,
fubar, andy, divy, jitendra.kalsaria, sony.chacko, linux-driver,
kaber, ursula.braun, blaschka, linux390, shemminger, bhutchings,
therbert, xiyou.wangcong, joe, gregory.v.rose, john.r.fastabend,
linux-rdma, linux-kernel, linux-s390, bridge, fbl
In-Reply-To: <1357289343-817-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
net/core/rtnetlink.c | 69 ++++++++++++++++++++++++++++------------------------
1 file changed, 37 insertions(+), 32 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 2ef7a56..ae612f4 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -880,6 +880,7 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
const struct rtnl_link_stats64 *stats;
struct nlattr *attr, *af_spec;
struct rtnl_af_ops *af_ops;
+ struct net_device *upper_dev = netdev_master_upper_dev_get(dev);
ASSERT_RTNL();
nlh = nlmsg_put(skb, pid, seq, type, sizeof(*ifm), flags);
@@ -908,8 +909,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb, struct net_device *dev,
#endif
(dev->ifindex != dev->iflink &&
nla_put_u32(skb, IFLA_LINK, dev->iflink)) ||
- (dev->master &&
- nla_put_u32(skb, IFLA_MASTER, dev->master->ifindex)) ||
+ (upper_dev &&
+ nla_put_u32(skb, IFLA_MASTER, upper_dev->ifindex)) ||
nla_put_u8(skb, IFLA_CARRIER, netif_carrier_ok(dev)) ||
(dev->qdisc &&
nla_put_string(skb, IFLA_QDISC, dev->qdisc->ops->id)) ||
@@ -1273,16 +1274,16 @@ static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
static int do_set_master(struct net_device *dev, int ifindex)
{
- struct net_device *master_dev;
+ struct net_device *upper_dev = netdev_master_upper_dev_get(dev);
const struct net_device_ops *ops;
int err;
- if (dev->master) {
- if (dev->master->ifindex == ifindex)
+ if (upper_dev) {
+ if (upper_dev->ifindex == ifindex)
return 0;
- ops = dev->master->netdev_ops;
+ ops = upper_dev->netdev_ops;
if (ops->ndo_del_slave) {
- err = ops->ndo_del_slave(dev->master, dev);
+ err = ops->ndo_del_slave(upper_dev, dev);
if (err)
return err;
} else {
@@ -1291,12 +1292,12 @@ static int do_set_master(struct net_device *dev, int ifindex)
}
if (ifindex) {
- master_dev = __dev_get_by_index(dev_net(dev), ifindex);
- if (!master_dev)
+ upper_dev = __dev_get_by_index(dev_net(dev), ifindex);
+ if (!upper_dev)
return -EINVAL;
- ops = master_dev->netdev_ops;
+ ops = upper_dev->netdev_ops;
if (ops->ndo_add_slave) {
- err = ops->ndo_add_slave(master_dev, dev);
+ err = ops->ndo_add_slave(upper_dev, dev);
if (err)
return err;
} else {
@@ -2064,7 +2065,6 @@ errout:
static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
{
struct net *net = sock_net(skb->sk);
- struct net_device *master = NULL;
struct ndmsg *ndm;
struct nlattr *tb[NDA_MAX+1];
struct net_device *dev;
@@ -2106,10 +2106,10 @@ static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
/* Support fdb on master device the net/bridge default case */
if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
(dev->priv_flags & IFF_BRIDGE_PORT)) {
- master = dev->master;
- err = master->netdev_ops->ndo_fdb_add(ndm, tb,
- dev, addr,
- nlh->nlmsg_flags);
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
+ const struct net_device_ops *ops = br_dev->netdev_ops;
+
+ err = ops->ndo_fdb_add(ndm, tb, dev, addr, nlh->nlmsg_flags);
if (err)
goto out;
else
@@ -2170,10 +2170,11 @@ static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
/* Support fdb on master device the net/bridge default case */
if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
(dev->priv_flags & IFF_BRIDGE_PORT)) {
- struct net_device *master = dev->master;
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
+ const struct net_device_ops *ops = br_dev->netdev_ops;
- if (master->netdev_ops->ndo_fdb_del)
- err = master->netdev_ops->ndo_fdb_del(ndm, dev, addr);
+ if (ops->ndo_fdb_del)
+ err = ops->ndo_fdb_del(ndm, dev, addr);
if (err)
goto out;
@@ -2257,9 +2258,11 @@ static int rtnl_fdb_dump(struct sk_buff *skb, struct netlink_callback *cb)
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
if (dev->priv_flags & IFF_BRIDGE_PORT) {
- struct net_device *master = dev->master;
- const struct net_device_ops *ops = master->netdev_ops;
+ struct net_device *br_dev;
+ const struct net_device_ops *ops;
+ br_dev = netdev_master_upper_dev_get(dev);
+ ops = br_dev->netdev_ops;
if (ops->ndo_fdb_dump)
idx = ops->ndo_fdb_dump(skb, cb, dev, idx);
}
@@ -2280,6 +2283,7 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
struct ifinfomsg *ifm;
struct nlattr *br_afspec;
u8 operstate = netif_running(dev) ? dev->operstate : IF_OPER_DOWN;
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
nlh = nlmsg_put(skb, pid, seq, RTM_NEWLINK, sizeof(*ifm), NLM_F_MULTI);
if (nlh == NULL)
@@ -2297,8 +2301,8 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
if (nla_put_string(skb, IFLA_IFNAME, dev->name) ||
nla_put_u32(skb, IFLA_MTU, dev->mtu) ||
nla_put_u8(skb, IFLA_OPERSTATE, operstate) ||
- (dev->master &&
- nla_put_u32(skb, IFLA_MASTER, dev->master->ifindex)) ||
+ (br_dev &&
+ nla_put_u32(skb, IFLA_MASTER, br_dev->ifindex)) ||
(dev->addr_len &&
nla_put(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr)) ||
(dev->ifindex != dev->iflink &&
@@ -2334,11 +2338,11 @@ static int rtnl_bridge_getlink(struct sk_buff *skb, struct netlink_callback *cb)
rcu_read_lock();
for_each_netdev_rcu(net, dev) {
const struct net_device_ops *ops = dev->netdev_ops;
- struct net_device *master = dev->master;
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
- if (master && master->netdev_ops->ndo_bridge_getlink) {
+ if (br_dev && br_dev->netdev_ops->ndo_bridge_getlink) {
if (idx >= cb->args[0] &&
- master->netdev_ops->ndo_bridge_getlink(
+ br_dev->netdev_ops->ndo_bridge_getlink(
skb, portid, seq, dev) < 0)
break;
idx++;
@@ -2375,7 +2379,7 @@ static inline size_t bridge_nlmsg_size(void)
static int rtnl_bridge_notify(struct net_device *dev, u16 flags)
{
struct net *net = dev_net(dev);
- struct net_device *master = dev->master;
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
struct sk_buff *skb;
int err = -EOPNOTSUPP;
@@ -2386,8 +2390,8 @@ static int rtnl_bridge_notify(struct net_device *dev, u16 flags)
}
if ((!flags || (flags & BRIDGE_FLAGS_MASTER)) &&
- master && master->netdev_ops->ndo_bridge_getlink) {
- err = master->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
+ br_dev && br_dev->netdev_ops->ndo_bridge_getlink) {
+ err = br_dev->netdev_ops->ndo_bridge_getlink(skb, 0, 0, dev);
if (err < 0)
goto errout;
}
@@ -2446,13 +2450,14 @@ static int rtnl_bridge_setlink(struct sk_buff *skb, struct nlmsghdr *nlh,
oflags = flags;
if (!flags || (flags & BRIDGE_FLAGS_MASTER)) {
- if (!dev->master ||
- !dev->master->netdev_ops->ndo_bridge_setlink) {
+ struct net_device *br_dev = netdev_master_upper_dev_get(dev);
+
+ if (!br_dev || !br_dev->netdev_ops->ndo_bridge_setlink) {
err = -EOPNOTSUPP;
goto out;
}
- err = dev->master->netdev_ops->ndo_bridge_setlink(dev, nlh);
+ err = br_dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
if (err)
goto out;
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox