* [PATCH net] ipv4: avoid passing NULL to inet_putpeer() in icmpv4_xrlim_allow()
From: Neal Cardwell @ 2012-11-25 4:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell
inet_getpeer_v4() can return NULL under OOM conditions, and while
inet_peer_xrlim_allow() is OK with a NULL peer, inet_putpeer() will
crash.
This code path now uses the same idiom as the others from:
1d861aa4b3fb08822055345f480850205ffe6170 ("inet: Minimize use of
cached route inetpeer.").
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/icmp.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index f2eccd5..17ff9fd 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -257,7 +257,8 @@ static inline bool icmpv4_xrlim_allow(struct net *net, struct rtable *rt,
struct inet_peer *peer = inet_getpeer_v4(net->ipv4.peers, fl4->daddr, 1);
rc = inet_peer_xrlim_allow(peer,
net->ipv4.sysctl_icmp_ratelimit);
- inet_putpeer(peer);
+ if (peer)
+ inet_putpeer(peer);
}
out:
return rc;
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH RFC 3/5] printk: modify printk interface for syslog_namespace
From: Serge E. Hallyn @ 2012-11-25 4:28 UTC (permalink / raw)
To: Libo Chen
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Eric W. Biederman
In-Reply-To: <50B0ADDB.4000303-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Quoting Libo Chen (chenlibo.3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On 2012/11/22 1:49, Serge E. Hallyn wrote:
>
> > I notice that you haven't made any changes to the struct cont. I
> > suspect this means that to-be-continued msgs from one ns can be
> > erroneously mixed with another ns.
> >
> Yes, I confirmed this problem. There will be erroneously mixed with another ns.
> Thank you very much.
>
> > You said you don't mind putting the syslogns into the userns. If
> > there's no reason not to do that, then we should do so as it will
> > remove a bunch of code (plus the use of a new CLONE flag) from your
> > patch, and the new syslog(NEW_NS) command from mine.
> >
> I agree with you, both are removable.
>
> > Now IMO the ideal place for syslog_ns would be in the devices ns,
> > but that does not yet exist, and may never. The bonus to that would
> > be that the consoles sort of belong there. I avoid this by not
> > having consoles in child syslog namespaces. You put the console in
> > the ns. I haven't looked closely enough to see if what you do is
> > ok (will do so soon).
> >
> > WOuld you mind looking through my patch to see if it suffices for
> > your needs? Where it does not, patches would be greatly appreciated
> > if simple enough.
>
> follow your patch, I can see inject message by "dmesg call" in container, is right?
If I understand you right, yes.
> I am worry that I debug or see messages from serial ports console in some embedded system,
> since console belongs to init_syslog, so the message in container can`t be printed.
Sorry, I don't understand which way you're going with that. Could you
rephrase? You want to prevent console messages from going to a
container? (That should definately not happen) Or something else?
> > Note I'm not at all wedded to my patchset. I'm happy to go with
> > something else entirely. My set was just a proof of concept.
thanks,
-serge
^ permalink raw reply
* [Feature request] ip rule replace
From: Damjan @ 2012-11-25 3:22 UTC (permalink / raw)
To: netdev
similar to "ip route replace" there should be an "ip rule replace"
command. Using "del" and then "add" is more fragile.
--
дамјан
^ permalink raw reply
* Re: [RFC net-next PATCH V1 0/9] net: fragmentation performance scalability on NUMA/SMP systems
From: Eric Dumazet @ 2012-11-25 2:31 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David S. Miller, Florian Westphal, netdev, Pablo Neira Ayuso,
Thomas Graf, Cong Wang, Patrick McHardy, Paul E. McKenney,
Herbert Xu
In-Reply-To: <20121123130749.18764.25962.stgit@dragon>
On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
> This patchset implements significant performance improvements for
> fragmentation handling in the kernel, with a focus on NUMA and SMP
> based systems.
>
> Review:
>
> Please review these patches. I have on purpose added comments in the
> code with the "//" comments style. These comments are to be removed
> before applying. They serve as a questions to, you, the reviewer.
>
> The fragmentation code today:
>
> The fragmentation code "protects" kernel resources, by implementing
> some memory resource limitation code. This is centered around a
> global readers-writer lock, and (per network namespace) an atomic mem
> counter and a LRU (Least-Recently-Used) list. (Although separate
> global variables and namespace resources, are kept for IPv4, IPv6
> and Netfilter reassembly.)
>
> The code tries to keep the memory usage between a high and low
> threshold (see: /proc/sys/net/ipv4/ipfrag_{high,low}_thresh). The
> "evictor" code cleans up fragments, when the high threshold is
> exceeded, and stops only, when the low threshold is reached.
>
> The scalability problem:
>
> Having a global/central variable for a resource limit is obviously a
> scalability issue on SMP systems, and even amplified on a NUMA based
> system.
>
But ... , what practical workload even use fragments ?
Sure, netperf -t UDP_STREAM uses frags, but its a benchmark.
The only heavy user was NFS in the days it was using UDP, a very long
time ago.
A single lost fragment means the whole packet is lost.
Another problem with fragments is the lack of 4-tuple hashing, as only
the first frag contains the dst/src ports.
Also there is the sysctl_ipfrag_max_dist issue...
Hint : many NIC provide TSO (TCP offload), but none provide UFO,
probably because there is no demand for it.
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Eric Dumazet @ 2012-11-24 23:43 UTC (permalink / raw)
To: Tino Keitel; +Cc: netdev
In-Reply-To: <loom.20121124T213422-650@post.gmane.org>
On Sat, 2012-11-24 at 20:42 +0000, Tino Keitel wrote:
> Paul Gortmaker <paul.gortmaker <at> windriver.com> writes:
>
> >
> > On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> > > Hi,
> > >
> > > commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
> > > trace on a Freescale RDB8313 board:
> >
> > Thanks for the report.
> >
> > >
> > > NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> > > ------------[ cut here ]------------
> > > WARNING:
> > > at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
> > > Modules linked in:
> > > NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
> > > REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
> > ^^^^^^^^^^^^^^^
> > I almost overlooked the above. It would have been nice to
> > see more explicit information on what kernel you are running.
> > I say that because the above concerns me. For several reasons.
> >
> > 1) it looks to be not mainline, but preempt_rt
> > 2) There is no RT on 3.7 yet, so I'm assuming this is a custom
> > forward port of the 250 odd RT patches. (The RT is 3.6.7-rt18,
> > i.e. based on the 3.6 gregKH stable tree.)
>
> Sorry for the confusion. This was a 3.7.0-rc6 tree, and I forgot git clean after
> trying the rt-patches and git reset --hard v3.7.0-rc6, so the localversion file
> for -rt was still present, and the kernel was named 3.7.0-rc6-rt18. If I got
> this right, this should be a normal kernel with just the version file modified.
>
> I tried kernel 3.3, which doesnt have the issue. I tried 3.4, 3.6.7 and 3.7-rc6,
> which all show the kernel trace and ptp client misbehaviour. I tried 3.4, 3.6.7,
> 3.7-rc6 and 3.6.5-rt18 with the patch I posted, and they were ok.
>
> The patch I posted is for 3.7-rc6.
>
Hmm, I wonder if BQL makes a particular bug showing more often.
I see gianfar uses a very small watchdog_timeo of 1 second, while many
drivers use 5 seconds.
What happens if you change this to 5 seconds ?
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 19ac096..3a994f9 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -101,7 +101,7 @@
#include "gianfar.h"
-#define TX_TIMEOUT (1*HZ)
+#define TX_TIMEOUT (5*HZ)
const char gfar_driver_version[] = "1.3";
^ permalink raw reply related
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Woodhouse @ 2012-11-24 23:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124225855.GA17340@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 379 bytes --]
On Sat, 2012-11-24 at 23:58 +0100, Francois Romieu wrote:
> While you are at it, do you see what would prevent the watchdog
> timer and the rx napi handler to race on two different CPUs
Hm, good point. Is it sufficient just to stick napi_disable() and
napi_enable() in there? And should we try to reset the TX state machine
without stomping on RX at all?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: Francois Romieu @ 2012-11-24 22:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <1353795081.26346.287.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> :
> Recovery doesn't work too well if we leave interrupts disabled...
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
While you are at it, do you see what would prevent the watchdog
timer and the rx napi handler to race on two different CPUs
("using a Geode" could be an answer :o) ) ?
> ---
> For stable too, I suppose.
Yes. Watch for http://patchwork.ozlabs.org/bundle/davem/stable/
--
Ueimor
^ permalink raw reply
* [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Woodhouse @ 2012-11-24 22:11 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124213348.GA8313@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 735 bytes --]
Recovery doesn't work too well if we leave interrupts disabled...
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
For stable too, I suppose.
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index 1c81825..ad6afc3 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1192,6 +1192,7 @@ static void cp_tx_timeout(struct net_device *dev)
cp_clean_rings(cp);
rc = cp_init_rings(cp);
cp_start_hw(cp);
+ cp_enable_irq(cp);
netif_wake_queue(dev);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* Re: 8139cp TX stall, timeout, failed recovery
From: Francois Romieu @ 2012-11-24 21:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <1353782365.26346.266.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> :
[...]
> To reproduce this, I send a *large* flood of packets (ping -l 1000) from
> inside my network to the ADSL router. Its internal-facing interface is
> an 8139cp. It seems to work best if the packets are destined for the
> outside world over the ADSL lines, rather than the router itself. But
> it's hard to tell. I need between 10 and 30 runs of 'ping -l 1000
> $outside' before it happens. Or sometimes more...
Did you try pktgen as well ?
[...]
> Looking at it now... do we wrap around the Rx ring buffer at 28498.055
> and process some of the packets more than once? Or is the hardware
> genuinely keeping up with us as we suck out, descriptors 51-63, 0-63,
> and 0-39 again all off the same interrupt? Perhaps there lies the root
> of the problem?
Rx slots are always spaced by ~50 us, i.e. more than needed to get a 98 bytes
packets. I do not like the lack of barrier wrt opts2 and opts1 writes for rx
descriptors but it does nprobably not matter for your problem.
If the r8169 experience is any guide, cp_tx_timeout is too light. It should
imho match the init sequence more closely, especially wrt descriptor rings
addresses and CpCmd.
--
Ueimor
^ permalink raw reply
* Re: 8139cp TX stall, timeout, failed recovery
From: David Woodhouse @ 2012-11-24 21:39 UTC (permalink / raw)
To: netdev; +Cc: romieu, jasowang, gilboad, jgarzik, nathan
In-Reply-To: <1353782365.26346.266.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]
On Sat, 2012-11-24 at 18:39 +0000, David Woodhouse wrote:
> This seems to be a consistent pattern — when we get that 0x0080
> interrupt and it dies, it's *very* soon after queueing a new tx:
Once I realise that the 'tx queued' message actually prints the number
of the *next* slot that'll be used, not the slot that was just filled,
that becomes obvious. The hardware takes only 30µs or so to consume the
descriptor that was just submitted. It isn't just coincidence that one
packet completes just as the *next* one is being submitted, as I
originally thought.
The hardware seems to asserts the 0x80 'Tx Descriptor Unavailable'
interrupt first, and the other bits (0x404) come later. I *often* get
into cp_tx() with only 0x80 in the IntrStatus bits, and the other bits
are often set before my heavily-debug-laden cp_tx() has even finished
running).
Register 0x82 indicates the low bits of the address of the most recently
consumed Tx descriptor, and always seems to agree with the driver's
processing of the ring. When we get a 0x80 interrupt, the most recently
consumed descriptor is always the one before tx_head, as you'd expect.
And tx_head always looks sane and (as long as you read it quickly) still
has the 'Own' bit set, as it should.
Eventually I get a 0x80 interrupt which *isn't* immediately followed by
the other 0x404 bits. And then the hardware has crapped itself and is no
longer eating descriptors. We submit more to the queue and we bang on
the TxPoll register *every* time, but that doesn't wake it.
Adding a cp_enable_irq() into the cp_tx_timeout() function at least
makes it recover *eventually*.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] batman-adv: Move soft-interface initialization to ndo_init
From: Sven Eckelmann @ 2012-11-24 21:23 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20121124.155902.1261596975089040930.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 145 bytes --]
On Saturday 24 November 2012 15:59:02 David Miller wrote:
> No pull request?
They didn't apply it yet. (sry for Cc'ing you)
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Q: patchwork entries for net/ and drivers/net/
From: Joe Perches @ 2012-11-24 21:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Add the netdev patchwork entries for networking drivers.
Change the W: entry to Q:for networking.
Signed-off-by: Joe Perches <joe@perches.com>
---
MAINTAINERS | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a9c794c..7549075 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5056,7 +5056,7 @@ NETWORKING [GENERAL]
M: "David S. Miller" <davem@davemloft.net>
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
-W: http://patchwork.ozlabs.org/project/netdev/list/
+Q: http://patchwork.ozlabs.org/project/netdev/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S: Maintained
@@ -5116,6 +5116,7 @@ F: drivers/net/wireless/
NETWORKING DRIVERS
L: netdev@vger.kernel.org
W: http://www.linuxfoundation.org/en/Net
+Q: http://patchwork.ozlabs.org/project/netdev/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
S: Odd Fixes
^ permalink raw reply related
* Re: [PATCH 1/7] batman-adv: Move soft-interface initialization to ndo_init
From: David Miller @ 2012-11-24 20:59 UTC (permalink / raw)
To: sven; +Cc: b.a.t.m.a.n, netdev
In-Reply-To: <1353715332-4284-1-git-send-email-sven@narfation.org>
No pull request?
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Tino Keitel @ 2012-11-24 20:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <50AFA599.9040108@windriver.com>
Paul Gortmaker <paul.gortmaker <at> windriver.com> writes:
>
> On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> > Hi,
> >
> > commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
> > trace on a Freescale RDB8313 board:
>
> Thanks for the report.
>
> >
> > NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> > ------------[ cut here ]------------
> > WARNING:
> > at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
> > Modules linked in:
> > NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
> > REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
> ^^^^^^^^^^^^^^^
> I almost overlooked the above. It would have been nice to
> see more explicit information on what kernel you are running.
> I say that because the above concerns me. For several reasons.
>
> 1) it looks to be not mainline, but preempt_rt
> 2) There is no RT on 3.7 yet, so I'm assuming this is a custom
> forward port of the 250 odd RT patches. (The RT is 3.6.7-rt18,
> i.e. based on the 3.6 gregKH stable tree.)
Sorry for the confusion. This was a 3.7.0-rc6 tree, and I forgot git clean after
trying the rt-patches and git reset --hard v3.7.0-rc6, so the localversion file
for -rt was still present, and the kernel was named 3.7.0-rc6-rt18. If I got
this right, this should be a normal kernel with just the version file modified.
I tried kernel 3.3, which doesnt have the issue. I tried 3.4, 3.6.7 and 3.7-rc6,
which all show the kernel trace and ptp client misbehaviour. I tried 3.4, 3.6.7,
3.7-rc6 and 3.6.5-rt18 with the patch I posted, and they were ok.
The patch I posted is for 3.7-rc6.
Regards,
Tino
^ permalink raw reply
* 8139cp TX stall, timeout, failed recovery
From: David Woodhouse @ 2012-11-24 18:39 UTC (permalink / raw)
To: netdev; +Cc: romieu, jasowang, gilboad, jgarzik
[-- Attachment #1: Type: text/plain, Size: 33253 bytes --]
When I stress it hard, I see a Tx timeout that it doesn't recover from.
This is 3.6.7, with or without my recent init path patch (and with or
without my BQL patch).
To reproduce this, I send a *large* flood of packets (ping -l 1000) from
inside my network to the ADSL router. Its internal-facing interface is
an 8139cp. It seems to work best if the packets are destined for the
outside world over the ADSL lines, rather than the router itself. But
it's hard to tell. I need between 10 and 30 runs of 'ping -l 1000
$outside' before it happens. Or sometimes more...
Log shows it all running fine, followed by a flood of incoming packets
starting at around 28498.05. At 28498.060901 we queue a new tx, and
*immediately* afterwards (28498.060936) we get an interrupt with status
0x0080 (Tx Descriptor Unavailable, but no Tx Done). That's the last
tx-related interrupt we ever get.
This seems to be a consistent pattern — when we get that 0x0080
interrupt and it dies, it's *very* soon after queueing a new tx:
8139dead2.cap-[27538.841952] 8139cp 0000:00:0b.0: eth1: tx queued, slot 54, skblen 98
8139dead2.cap:[27538.841985] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead3a.cap-[28498.060901] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 98
8139dead3a.cap:[28498.060936] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead4.cap-[30230.248780] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 98
8139dead4.cap:[30230.248816] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
--
8139dead.cap-[ 228.119159] 8139cp 0000:00:0b.0: eth1: tx queued, slot 63, skblen 98
8139dead.cap:[ 228.119195] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
Here's a full log of one of those, showing the failure to recover too...
Looking at it now... do we wrap around the Rx ring buffer at 28498.055
and process some of the packets more than once? Or is the hardware
genuinely keeping up with us as we suck out, descriptors 51-63, 0-63,
and 0-39 again all off the same interrupt? Perhaps there lies the root
of the problem?
[28497.924957] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x320141d8 len 468
[28498.032253] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.032300] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32022062 len 94
[28498.040770] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 110
[28498.040816] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.040836] 8139cp 0000:00:0b.0: eth1: tx done, slot 6
[28498.041048] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 1514
[28498.041090] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041108] 8139cp 0000:00:0b.0: eth1: tx done, slot 7
[28498.041177] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 1514
[28498.041218] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041236] 8139cp 0000:00:0b.0: eth1: tx done, slot 8
[28498.041677] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.041709] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x3200e04e len 74
[28498.041846] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 533
[28498.041882] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.041901] 8139cp 0000:00:0b.0: eth1: tx done, slot 9
[28498.043028] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043056] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x3200e04e len 74
[28498.043264] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043291] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x3200e04e len 74
[28498.043456] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.043483] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x3200e04e len 74
[28498.043905] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 245
[28498.043941] 8139cp 0000:00:0b.0: eth1: intr, status 0484 cmd 0c cpcmd 002b
[28498.043960] 8139cp 0000:00:0b.0: eth1: tx done, slot 10
[28498.051129] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.051165] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.051333] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.051394] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.051451] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.051523] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.051575] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.051623] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.051672] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.051720] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.051771] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.051821] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.051871] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.051962] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.051989] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.052041] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.052089] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.052139] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.052189] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.052238] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.052287] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.052370] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.052396] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.052446] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.052496] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.052562] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.052612] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.052661] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.052711] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.052760] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.052810] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.052860] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.052975] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.053001] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.053053] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.053103] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.053151] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.053201] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.053249] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.053299] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.053348] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.053397] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.053446] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.053495] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.053561] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.053611] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.053661] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.053711] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.053760] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.053810] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.053860] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.053947] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.053973] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.054025] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.054074] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.054123] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.054173] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.054222] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.054272] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.054320] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x32036066 len 98
[28498.054405] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.054432] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x32036066 len 98
[28498.054482] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036066 len 98
[28498.054548] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036066 len 98
[28498.054597] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036066 len 98
[28498.054648] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32036066 len 98
[28498.054697] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32036066 len 98
[28498.054747] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x32036066 len 98
[28498.054796] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x32036066 len 98
[28498.054846] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x32036066 len 98
[28498.054895] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.055030] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.055057] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.055109] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.055158] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.055206] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.055256] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.055305] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.055355] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.055403] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.055453] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.055519] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.055568] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.055617] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.055666] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.055715] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.055763] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.055812] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.055861] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.055910] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.055958] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.056007] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.056056] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.056105] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.056154] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.056202] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.056251] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.056300] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.056349] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.056398] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.056447] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.056495] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.056544] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.056593] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.056678] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.056728] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.056777] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.056826] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.056875] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.056923] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.056972] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.057020] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.057069] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.057117] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.057166] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.057214] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.057263] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.057312] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.057362] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.057410] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.057459] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.057508] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.057557] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.057606] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.057654] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.057703] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x32036066 len 98
[28498.057752] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x32036066 len 98
[28498.057800] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036066 len 98
[28498.057848] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036066 len 98
[28498.057897] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036066 len 98
[28498.057946] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x32036066 len 98
[28498.057994] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32036066 len 98
[28498.058043] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x32036066 len 98
[28498.058091] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x32036066 len 98
[28498.058141] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x32036066 len 98
[28498.058190] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x32036066 len 98
[28498.058238] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x32036066 len 98
[28498.058287] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x32036066 len 98
[28498.058337] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32036066 len 98
[28498.058385] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x32036066 len 98
[28498.058434] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x32036066 len 98
[28498.058482] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32036066 len 98
[28498.058531] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32036066 len 98
[28498.058579] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x32036066 len 98
[28498.058629] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x32036066 len 98
[28498.058678] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x32036066 len 98
[28498.058727] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x32036066 len 98
[28498.058775] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x32036066 len 98
[28498.058824] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x72036066 len 98
[28498.058872] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x32036066 len 98
[28498.058921] 8139cp 0000:00:0b.0: eth1: rx slot 1 status 0x32036066 len 98
[28498.058969] 8139cp 0000:00:0b.0: eth1: rx slot 2 status 0x32036066 len 98
[28498.059018] 8139cp 0000:00:0b.0: eth1: rx slot 3 status 0x32036066 len 98
[28498.059066] 8139cp 0000:00:0b.0: eth1: rx slot 4 status 0x32036066 len 98
[28498.059115] 8139cp 0000:00:0b.0: eth1: rx slot 5 status 0x32036066 len 98
[28498.059164] 8139cp 0000:00:0b.0: eth1: rx slot 6 status 0x32036066 len 98
[28498.059212] 8139cp 0000:00:0b.0: eth1: rx slot 7 status 0x32036066 len 98
[28498.059261] 8139cp 0000:00:0b.0: eth1: rx slot 8 status 0x32036066 len 98
[28498.059309] 8139cp 0000:00:0b.0: eth1: rx slot 9 status 0x32036066 len 98
[28498.059358] 8139cp 0000:00:0b.0: eth1: rx slot 10 status 0x32036066 len 98
[28498.059407] 8139cp 0000:00:0b.0: eth1: rx slot 11 status 0x32036066 len 98
[28498.059455] 8139cp 0000:00:0b.0: eth1: rx slot 12 status 0x32036066 len 98
[28498.059504] 8139cp 0000:00:0b.0: eth1: rx slot 13 status 0x32036066 len 98
[28498.059553] 8139cp 0000:00:0b.0: eth1: rx slot 14 status 0x32036066 len 98
[28498.059602] 8139cp 0000:00:0b.0: eth1: rx slot 15 status 0x32036066 len 98
[28498.059651] 8139cp 0000:00:0b.0: eth1: rx slot 16 status 0x32036066 len 98
[28498.059700] 8139cp 0000:00:0b.0: eth1: rx slot 17 status 0x32036066 len 98
[28498.059748] 8139cp 0000:00:0b.0: eth1: rx slot 18 status 0x32036066 len 98
[28498.059814] 8139cp 0000:00:0b.0: eth1: rx slot 19 status 0x32036066 len 98
[28498.059863] 8139cp 0000:00:0b.0: eth1: rx slot 20 status 0x32036066 len 98
[28498.059913] 8139cp 0000:00:0b.0: eth1: rx slot 21 status 0x32036066 len 98
[28498.059961] 8139cp 0000:00:0b.0: eth1: rx slot 22 status 0x32036066 len 98
[28498.060011] 8139cp 0000:00:0b.0: eth1: rx slot 23 status 0x32036066 len 98
[28498.060059] 8139cp 0000:00:0b.0: eth1: rx slot 24 status 0x32036066 len 98
[28498.060108] 8139cp 0000:00:0b.0: eth1: rx slot 25 status 0x32036066 len 98
[28498.060156] 8139cp 0000:00:0b.0: eth1: rx slot 26 status 0x32036066 len 98
[28498.060205] 8139cp 0000:00:0b.0: eth1: rx slot 27 status 0x32036066 len 98
[28498.060253] 8139cp 0000:00:0b.0: eth1: rx slot 28 status 0x32036066 len 98
[28498.060302] 8139cp 0000:00:0b.0: eth1: rx slot 29 status 0x32036066 len 98
[28498.060350] 8139cp 0000:00:0b.0: eth1: rx slot 30 status 0x32036066 len 98
[28498.060399] 8139cp 0000:00:0b.0: eth1: rx slot 31 status 0x32036066 len 98
[28498.060447] 8139cp 0000:00:0b.0: eth1: rx slot 32 status 0x32036066 len 98
[28498.060496] 8139cp 0000:00:0b.0: eth1: rx slot 33 status 0x32036066 len 98
[28498.060544] 8139cp 0000:00:0b.0: eth1: rx slot 34 status 0x32036066 len 98
[28498.060594] 8139cp 0000:00:0b.0: eth1: rx slot 35 status 0x32036066 len 98
[28498.060642] 8139cp 0000:00:0b.0: eth1: rx slot 36 status 0x32036066 len 98
[28498.060691] 8139cp 0000:00:0b.0: eth1: rx slot 37 status 0x32036066 len 98
[28498.060740] 8139cp 0000:00:0b.0: eth1: rx slot 38 status 0x32036066 len 98
[28498.060789] 8139cp 0000:00:0b.0: eth1: rx slot 39 status 0x32036066 len 98
[28498.060901] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 98
[28498.060936] 8139cp 0000:00:0b.0: eth1: intr, status 0080 cmd 0c cpcmd 002b
[28498.061814] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 98
[28498.064007] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 98
[28498.065750] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 98
[28498.067472] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 98
[28498.068062] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 79
[28498.068221] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 74
[28498.070711] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 98
[28498.072137] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 98
[28498.074369] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 98
[28498.075829] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 98
[28498.078074] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 98
[28498.079772] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 98
[28498.082254] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 98
[28498.120915] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.120946] 8139cp 0000:00:0b.0: eth1: rx slot 40 status 0x3201404e len 74
[28498.140144] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 74
[28498.182530] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 66
[28498.276742] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 79
[28498.421426] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.421454] 8139cp 0000:00:0b.0: eth1: rx slot 41 status 0x320141d8 len 468
[28498.485291] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 74
[28498.578432] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 66
[28498.646429] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 118
[28498.649979] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.650008] 8139cp 0000:00:0b.0: eth1: rx slot 42 status 0x32036094 len 144
[28498.650098] 8139cp 0000:00:0b.0: eth1: rx slot 43 status 0x32036096 len 146
[28498.650165] 8139cp 0000:00:0b.0: eth1: rx slot 44 status 0x32036094 len 144
[28498.696744] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 79
[28498.804309] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28498.804338] 8139cp 0000:00:0b.0: eth1: rx slot 45 status 0x320140a0 len 156
[28498.885404] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 125
[28499.086435] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 74
[28499.098211] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.098239] 8139cp 0000:00:0b.0: eth1: rx slot 46 status 0x32014046 len 66
[28499.108839] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 66
[28499.121567] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.121596] 8139cp 0000:00:0b.0: eth1: rx slot 47 status 0x3201404e len 74
[28499.121992] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.122018] 8139cp 0000:00:0b.0: eth1: rx slot 48 status 0x3200e0a0 len 156
[28499.139903] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 74
[28499.401749] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.401777] 8139cp 0000:00:0b.0: eth1: rx slot 49 status 0x320141d8 len 468
[28499.558938] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 66
[28499.775920] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28499.775948] 8139cp 0000:00:0b.0: eth1: rx slot 50 status 0x3203605e len 90
[28499.888841] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 116
[28500.286470] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 74
[28500.353205] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 66
[28501.125519] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28501.125553] 8139cp 0000:00:0b.0: eth1: rx slot 51 status 0x3201404e len 74
[28501.143803] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 74
[28501.373644] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28501.373673] 8139cp 0000:00:0b.0: eth1: rx slot 52 status 0x320141d8 len 468
[28501.530366] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 66
[28501.648615] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 112
[28501.888561] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 121
[28502.094862] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28502.094891] 8139cp 0000:00:0b.0: eth1: rx slot 53 status 0x32014046 len 66
[28502.105856] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 66
[28502.113535] 8139cp 0000:00:0b.0: eth1: tx queued, slot 46, skblen 94
[28502.221163] 8139cp 0000:00:0b.0: eth1: tx queued, slot 47, skblen 58
[28502.507301] SysRq : Changing Loglevel
[28502.511000] Loglevel set to 9
[28502.690951] 8139cp 0000:00:0b.0: eth1: tx queued, slot 48, skblen 74
[28502.725709] 8139cp 0000:00:0b.0: eth1: tx queued, slot 49, skblen 62
[28502.891993] 8139cp 0000:00:0b.0: eth1: tx queued, slot 50, skblen 116
[28502.997597] 8139cp 0000:00:0b.0: eth1: tx queued, slot 51, skblen 102
[28504.652076] 8139cp 0000:00:0b.0: eth1: tx queued, slot 52, skblen 118
[28504.886623] 8139cp 0000:00:0b.0: eth1: tx queued, slot 53, skblen 147
[28504.894552] 8139cp 0000:00:0b.0: eth1: tx queued, slot 54, skblen 123
[28505.133020] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28505.140825] 8139cp 0000:00:0b.0: eth1: rx slot 54 status 0x3201404e len 74
[28505.149255] 8139cp 0000:00:0b.0: eth1: tx queued, slot 55, skblen 147
[28505.167408] 8139cp 0000:00:0b.0: eth1: tx queued, slot 56, skblen 74
[28505.317183] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28505.325489] 8139cp 0000:00:0b.0: eth1: rx slot 55 status 0x320141d8 len 468
[28508.094647] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28508.101681] 8139cp 0000:00:0b.0: eth1: rx slot 56 status 0x32014046 len 66
[28508.913790] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28508.921135] 8139cp 0000:00:0b.0: eth1: rx slot 57 status 0x32022040 len 60
[28510.009002] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.016533] 8139cp 0000:00:0b.0: eth1: rx slot 58 status 0x3201406b len 103
[28510.239735] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.246717] 8139cp 0000:00:0b.0: eth1: rx slot 59 status 0x3201406b len 103
[28510.702856] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28510.709886] 8139cp 0000:00:0b.0: eth1: rx slot 60 status 0x3201406b len 103
[28511.098502] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.105396] 8139cp 0000:00:0b.0: eth1: rx slot 61 status 0x3202205d len 89
[28511.629295] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.636190] 8139cp 0000:00:0b.0: eth1: rx slot 62 status 0x3201406b len 103
[28511.898925] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28511.905833] 8139cp 0000:00:0b.0: eth1: rx slot 63 status 0x7202205d len 89
[28512.011147] 8139cp 0000:00:0b.0: eth1: intr, status 0001 cmd 0c cpcmd 002b
[28512.018063] 8139cp 0000:00:0b.0: eth1: rx slot 0 status 0x3202206b len 103
[28513.017313] 8139cp 0000:00:0b.0: eth1: Transmit timeout, status c 2b 0 80ff
[28513.025121] 8139cp 0000:00:0b.0: eth1: tx queued, slot 1, skblen 66
[28513.031420] 8139cp 0000:00:0b.0: eth1: tx queued, slot 2, skblen 111
[28513.037801] 8139cp 0000:00:0b.0: eth1: tx queued, slot 3, skblen 116
[28513.044164] 8139cp 0000:00:0b.0: eth1: tx queued, slot 4, skblen 109
[28513.050549] 8139cp 0000:00:0b.0: eth1: tx queued, slot 5, skblen 118
[28513.056912] 8139cp 0000:00:0b.0: eth1: tx queued, slot 6, skblen 111
[28513.063300] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 114
[28513.069685] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 125
[28513.076049] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 147
[28513.082426] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 66
[28513.088804] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 147
[28513.095254] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 74
[28513.101631] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 66
[28513.108009] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 147
[28513.114461] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 66
[28513.120846] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 66
[28513.127210] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 94
[28513.133595] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 66
[28513.139973] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 108
[28513.146425] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 110
[28513.152897] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 62
[28513.159273] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 66
[28513.165639] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 110
[28513.172111] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 147
[28513.178575] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 135
[28513.185027] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 70
[28513.191411] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 70
[28513.661282] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 110
[28513.902182] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 114
[28514.152998] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 62
[28514.904881] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 109
[28515.996046] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 70
[28516.664680] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 125
[28516.904608] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 126
[28517.916878] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 115
[28518.352300] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 66
[28519.028318] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 102
[28519.339446] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 141
[28519.668103] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 112
[28519.756759] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 141
[28519.907770] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 109
[28520.188635] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 62
[28520.596861] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 141
[28520.635544] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 147
[28520.911469] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 125
[28531.018105] 8139cp 0000:00:0b.0: eth1: Transmit timeout, status c 2b 485 0
[28531.025915] 8139cp 0000:00:0b.0: eth1: tx queued, slot 1, skblen 141
[28531.032305] 8139cp 0000:00:0b.0: eth1: tx queued, slot 2, skblen 117
[28531.038685] 8139cp 0000:00:0b.0: eth1: tx queued, slot 3, skblen 115
[28531.045049] 8139cp 0000:00:0b.0: eth1: tx queued, slot 4, skblen 117
[28531.051433] 8139cp 0000:00:0b.0: eth1: tx queued, slot 5, skblen 126
[28531.057797] 8139cp 0000:00:0b.0: eth1: tx queued, slot 6, skblen 112
[28531.064184] 8139cp 0000:00:0b.0: eth1: tx queued, slot 7, skblen 121
[28531.070559] 8139cp 0000:00:0b.0: eth1: tx queued, slot 8, skblen 118
[28531.076925] 8139cp 0000:00:0b.0: eth1: tx queued, slot 9, skblen 118
[28531.083310] 8139cp 0000:00:0b.0: eth1: tx queued, slot 10, skblen 115
[28531.089779] 8139cp 0000:00:0b.0: eth1: tx queued, slot 11, skblen 79
[28531.096148] 8139cp 0000:00:0b.0: eth1: tx queued, slot 12, skblen 141
[28531.102613] 8139cp 0000:00:0b.0: eth1: tx queued, slot 13, skblen 94
[28531.108990] 8139cp 0000:00:0b.0: eth1: tx queued, slot 14, skblen 42
[28531.115354] 8139cp 0000:00:0b.0: eth1: tx queued, slot 15, skblen 42
[28531.121738] 8139cp 0000:00:0b.0: eth1: tx queued, slot 16, skblen 42
[28531.128116] 8139cp 0000:00:0b.0: eth1: tx queued, slot 17, skblen 42
[28531.858156] 8139cp 0000:00:0b.0: eth1: tx queued, slot 18, skblen 42
[28532.256232] 8139cp 0000:00:0b.0: eth1: tx queued, slot 19, skblen 141
[28532.858193] 8139cp 0000:00:0b.0: eth1: tx queued, slot 20, skblen 42
[28533.862354] 8139cp 0000:00:0b.0: eth1: tx queued, slot 21, skblen 42
[28534.858290] 8139cp 0000:00:0b.0: eth1: tx queued, slot 22, skblen 42
[28535.858336] 8139cp 0000:00:0b.0: eth1: tx queued, slot 23, skblen 42
[28536.634367] 8139cp 0000:00:0b.0: eth1: tx queued, slot 24, skblen 147
[28537.684826] 8139cp 0000:00:0b.0: eth1: tx queued, slot 25, skblen 42
[28538.678444] 8139cp 0000:00:0b.0: eth1: tx queued, slot 26, skblen 42
[28539.678487] 8139cp 0000:00:0b.0: eth1: tx queued, slot 27, skblen 42
[28540.688218] 8139cp 0000:00:0b.0: eth1: tx queued, slot 28, skblen 42
[28541.678581] 8139cp 0000:00:0b.0: eth1: tx queued, slot 29, skblen 42
[28542.678622] 8139cp 0000:00:0b.0: eth1: tx queued, slot 30, skblen 42
[28543.690661] 8139cp 0000:00:0b.0: eth1: tx queued, slot 31, skblen 42
[28544.688708] 8139cp 0000:00:0b.0: eth1: tx queued, slot 32, skblen 42
[28545.575351] 8139cp 0000:00:0b.0: eth1: tx queued, slot 33, skblen 141
[28545.688766] 8139cp 0000:00:0b.0: eth1: tx queued, slot 34, skblen 42
[28546.694068] 8139cp 0000:00:0b.0: eth1: tx queued, slot 35, skblen 42
[28547.688840] 8139cp 0000:00:0b.0: eth1: tx queued, slot 36, skblen 42
[28548.688882] 8139cp 0000:00:0b.0: eth1: tx queued, slot 37, skblen 42
[28549.697713] 8139cp 0000:00:0b.0: eth1: tx queued, slot 38, skblen 42
[28550.579007] 8139cp 0000:00:0b.0: eth1: tx queued, slot 39, skblen 86
[28550.688971] 8139cp 0000:00:0b.0: eth1: tx queued, slot 40, skblen 42
[28550.811035] SysRq : Changing Loglevel
[28550.814730] Loglevel set to 1
[28551.579045] 8139cp 0000:00:0b.0: eth1: tx queued, slot 41, skblen 86
[28551.689016] 8139cp 0000:00:0b.0: eth1: tx queued, slot 42, skblen 42
[28551.719077] 8139cp 0000:00:0b.0: eth1: tx queued, slot 43, skblen 79
[28552.579071] 8139cp 0000:00:0b.0: eth1: tx queued, slot 44, skblen 86
[28552.701599] 8139cp 0000:00:0b.0: eth1: tx queued, slot 45, skblen 42
[28555.116322] 8139cp 0000:00:0b.0: eth1: disabling interface
[28555.116663] br-lan: port 2(eth1) entered disabled state
[28555.120239] device eth1 left promiscuous mode
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* [PATCH v6 6/6] USB: forbid memory allocation with I/O during bus reset
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
If one storage interface or usb network interface(iSCSI case)
exists in current configuration, memory allocation with
GFP_KERNEL during usb_device_reset() might trigger I/O transfer
on the storage interface itself and cause deadlock because
the 'us->dev_mutex' is held in .pre_reset() and the storage
interface can't do I/O transfer when the reset is triggered
by other interface, or the error handling can't be completed
if the reset is triggered by the storage itself(error handling path).
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v5:
- use inline memalloc_noio_save()
v4:
- mark current memalloc_noio for every usb device reset
---
drivers/usb/core/hub.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 90accde..2d5cc1c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5040,6 +5040,7 @@ int usb_reset_device(struct usb_device *udev)
{
int ret;
int i;
+ unsigned int noio_flag;
struct usb_host_config *config = udev->actconfig;
if (udev->state == USB_STATE_NOTATTACHED ||
@@ -5049,6 +5050,17 @@ int usb_reset_device(struct usb_device *udev)
return -EINVAL;
}
+ /*
+ * Don't allocate memory with GFP_KERNEL in current
+ * context to avoid possible deadlock if usb mass
+ * storage interface or usbnet interface(iSCSI case)
+ * is included in current configuration. The easist
+ * approach is to do it for every device reset,
+ * because the device 'memalloc_noio' flag may have
+ * not been set before reseting the usb device.
+ */
+ noio_flag = memalloc_noio_save();
+
/* Prevent autosuspend during the reset */
usb_autoresume_device(udev);
@@ -5093,6 +5105,7 @@ int usb_reset_device(struct usb_device *udev)
}
usb_autosuspend_device(udev);
+ memalloc_noio_restore(noio_flag);
return ret;
}
EXPORT_SYMBOL_GPL(usb_reset_device);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v6 5/6] PM / Runtime: force memory allocation with no I/O during Runtime PM callbcack
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume/runtime_suspend callback on device with
the flag of 'memalloc_noio' set.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v5:
- use inline memalloc_noio_save()
v4:
- runtime_suspend need this too because rpm_resume may wait for
completion of concurrent runtime_suspend, so deadlock still may
be triggered in runtime_suspend path.
---
drivers/base/power/runtime.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3e198a0..96d99ea 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -371,6 +371,7 @@ static int rpm_suspend(struct device *dev, int rpmflags)
int (*callback)(struct device *);
struct device *parent = NULL;
int retval;
+ unsigned int noio_flag;
trace_rpm_suspend(dev, rpmflags);
@@ -480,7 +481,20 @@ static int rpm_suspend(struct device *dev, int rpmflags)
if (!callback && dev->driver && dev->driver->pm)
callback = dev->driver->pm->runtime_suspend;
- retval = rpm_callback(callback, dev);
+ /*
+ * Deadlock might be caused if memory allocation with GFP_KERNEL
+ * happens inside runtime_suspend callback of one block device's
+ * ancestor or the block device itself. Network device might be
+ * thought as part of iSCSI block device, so network device and
+ * its ancestor should be marked as memalloc_noio.
+ */
+ if (dev->power.memalloc_noio) {
+ noio_flag = memalloc_noio_save();
+ retval = rpm_callback(callback, dev);
+ memalloc_noio_restore(noio_flag);
+ } else {
+ retval = rpm_callback(callback, dev);
+ }
if (retval)
goto fail;
@@ -563,6 +577,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
int (*callback)(struct device *);
struct device *parent = NULL;
int retval = 0;
+ unsigned int noio_flag;
trace_rpm_resume(dev, rpmflags);
@@ -712,7 +727,20 @@ static int rpm_resume(struct device *dev, int rpmflags)
if (!callback && dev->driver && dev->driver->pm)
callback = dev->driver->pm->runtime_resume;
- retval = rpm_callback(callback, dev);
+ /*
+ * Deadlock might be caused if memory allocation with GFP_KERNEL
+ * happens inside runtime_resume callback of one block device's
+ * ancestor or the block device itself. Network device might be
+ * thought as part of iSCSI block device, so network device and
+ * its ancestor should be marked as memalloc_noio.
+ */
+ if (dev->power.memalloc_noio) {
+ noio_flag = memalloc_noio_save();
+ retval = rpm_callback(callback, dev);
+ memalloc_noio_restore(noio_flag);
+ } else {
+ retval = rpm_callback(callback, dev);
+ }
if (retval) {
__update_runtime_status(dev, RPM_SUSPENDED);
pm_runtime_cancel_pending(dev);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v6 4/6] net/core: apply pm_runtime_set_memalloc_noio on network devices
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Eric Dumazet,
David Decotigny, Tom Herbert, Ingo Molnar
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
Deadlock might be caused by allocating memory with GFP_KERNEL in
runtime_resume and runtime_suspend callback of network devices in
iSCSI situation, so mark network devices and its ancestor as
'memalloc_noio' with the introduced pm_runtime_set_memalloc_noio().
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Decotigny <david.decotigny@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v4:
- call pm_runtime_set_memalloc_noio(ddev, true) after
device_add
---
net/core/net-sysfs.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index bcf02f6..a55d255 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -22,6 +22,7 @@
#include <linux/vmalloc.h>
#include <linux/export.h>
#include <linux/jiffies.h>
+#include <linux/pm_runtime.h>
#include <net/wext.h>
#include "net-sysfs.h"
@@ -1386,6 +1387,8 @@ void netdev_unregister_kobject(struct net_device * net)
remove_queue_kobjects(net);
+ pm_runtime_set_memalloc_noio(dev, false);
+
device_del(dev);
}
@@ -1421,6 +1424,8 @@ int netdev_register_kobject(struct net_device *net)
return error;
}
+ pm_runtime_set_memalloc_noio(dev, true);
+
return error;
}
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v6 3/6] block/genhd.c: apply pm_runtime_set_memalloc_noio on block devices
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
This patch applyes the introduced pm_runtime_set_memalloc_noio on
block device so that PM core will teach mm to not allocate memory with
GFP_IOFS when calling the runtime_resume and runtime_suspend callback
for block devices and its ancestors.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v5:
- fix code style and one typo
v4:
- call pm_runtime_set_memalloc_noio(ddev, true) after device_add
---
block/genhd.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/block/genhd.c b/block/genhd.c
index 9a289d7..1905966 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -18,6 +18,7 @@
#include <linux/mutex.h>
#include <linux/idr.h>
#include <linux/log2.h>
+#include <linux/pm_runtime.h>
#include "blk.h"
@@ -532,6 +533,14 @@ static void register_disk(struct gendisk *disk)
return;
}
}
+
+ /*
+ * avoid probable deadlock caused by allocating memory with
+ * GFP_KERNEL in runtime_resume callback of its all ancestor
+ * devices
+ */
+ pm_runtime_set_memalloc_noio(ddev, true);
+
disk->part0.holder_dir = kobject_create_and_add("holders", &ddev->kobj);
disk->slave_dir = kobject_create_and_add("slaves", &ddev->kobj);
@@ -661,6 +670,7 @@ void del_gendisk(struct gendisk *disk)
disk->driverfs_dev = NULL;
if (!sysfs_deprecated)
sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk)));
+ pm_runtime_set_memalloc_noio(disk_to_dev(disk), false);
device_del(disk_to_dev(disk));
}
EXPORT_SYMBOL(del_gendisk);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v6 2/6] PM / Runtime: introduce pm_runtime_set_memalloc_noio()
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
The patch introduces the flag of memalloc_noio in 'struct dev_pm_info'
to help PM core to teach mm not allocating memory with GFP_KERNEL
flag for avoiding probable deadlock.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume() or runtime_suspend() on any one of device in
the path from one block or network device to the root device
in the device tree may cause deadlock, the introduced
pm_runtime_set_memalloc_noio() sets or clears the flag on
device in the path recursively.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v5:
- fix code style error
- add comment on clear the device memalloc_noio flag
v4:
- rename memalloc_noio_resume as memalloc_noio
- remove pm_runtime_get_memalloc_noio()
- add comments on pm_runtime_set_memalloc_noio
v3:
- introduce pm_runtime_get_memalloc_noio()
- hold one global lock on pm_runtime_set_memalloc_noio
- hold device power lock when accessing memalloc_noio_resume
flag suggested by Alan Stern
- implement pm_runtime_set_memalloc_noio without recursion
suggested by Alan Stern
v2:
- introduce pm_runtime_set_memalloc_noio()
---
drivers/base/power/runtime.c | 60 ++++++++++++++++++++++++++++++++++++++++++
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 3 +++
3 files changed, 64 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3148b10..3e198a0 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -124,6 +124,66 @@ unsigned long pm_runtime_autosuspend_expiration(struct device *dev)
}
EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
+static int dev_memalloc_noio(struct device *dev, void *data)
+{
+ return dev->power.memalloc_noio;
+}
+
+/*
+ * pm_runtime_set_memalloc_noio - Set a device's memalloc_noio flag.
+ * @dev: Device to handle.
+ * @enable: True for setting the flag and False for clearing the flag.
+ *
+ * Set the flag for all devices in the path from the device to the
+ * root device in the device tree if @enable is true, otherwise clear
+ * the flag for devices in the path whose siblings don't set the flag.
+ *
+ * The function should only be called by block device, or network
+ * device driver for solving the deadlock problem during runtime
+ * resume/suspend:
+ *
+ * If memory allocation with GFP_KERNEL is called inside runtime
+ * resume/suspend callback of any one of its ancestors(or the
+ * block device itself), the deadlock may be triggered inside the
+ * memory allocation since it might not complete until the block
+ * device becomes active and the involed page I/O finishes. The
+ * situation is pointed out first by Alan Stern. Network device
+ * are involved in iSCSI kind of situation.
+ *
+ * The lock of dev_hotplug_mutex is held in the function for handling
+ * hotplug race because pm_runtime_set_memalloc_noio() may be called
+ * in async probe().
+ *
+ * The function should be called between device_add() and device_del()
+ * on the affected device(block/network device).
+ */
+void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
+{
+ static DEFINE_MUTEX(dev_hotplug_mutex);
+
+ mutex_lock(&dev_hotplug_mutex);
+ for (;;) {
+ /* hold power lock since bitfield is not SMP-safe. */
+ spin_lock_irq(&dev->power.lock);
+ dev->power.memalloc_noio = enable;
+ spin_unlock_irq(&dev->power.lock);
+
+ dev = dev->parent;
+
+ /*
+ * clear flag of the parent device only if all the
+ * children don't set the flag because ancestor's
+ * flag was set by any one of the descendants.
+ */
+ if (!dev || (!enable &&
+ device_for_each_child(dev, NULL,
+ dev_memalloc_noio)))
+ break;
+ }
+ mutex_unlock(&dev_hotplug_mutex);
+}
+EXPORT_SYMBOL_GPL(pm_runtime_set_memalloc_noio);
+
/**
* rpm_check_suspend_allowed - Test whether a device may be suspended.
* @dev: Device to test.
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 03d7bb1..1a8a69d 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -538,6 +538,7 @@ struct dev_pm_info {
unsigned int irq_safe:1;
unsigned int use_autosuspend:1;
unsigned int timer_autosuspends:1;
+ unsigned int memalloc_noio:1;
enum rpm_request request;
enum rpm_status runtime_status;
int runtime_error;
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index f271860..775e063 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -47,6 +47,7 @@ extern void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
extern unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
extern void pm_runtime_update_max_time_suspended(struct device *dev,
s64 delta_ns);
+extern void pm_runtime_set_memalloc_noio(struct device *dev, bool enable);
static inline bool pm_children_suspended(struct device *dev)
{
@@ -149,6 +150,8 @@ static inline void pm_runtime_set_autosuspend_delay(struct device *dev,
int delay) {}
static inline unsigned long pm_runtime_autosuspend_expiration(
struct device *dev) { return 0; }
+static inline void pm_runtime_set_memalloc_noio(struct device *dev,
+ bool enable){}
#endif /* !CONFIG_PM_RUNTIME */
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v6 1/6] mm: teach mm by current context info to not do I/O during memory allocation
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Jiri Kosina,
Mel Gorman, KAMEZAWA Hiroyuki, Michal Hocko, Ingo Molnar,
Peter Zijlstra
In-Reply-To: <1353761958-12810-1-git-send-email-ming.lei@canonical.com>
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task
to avoid doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device,
and the problem may happen at least in the below situations:
- during block device runtime resume, if memory allocation with
GFP_KERNEL is called inside runtime resume callback of any one
of its ancestors(or the block device itself), the deadlock may be
triggered inside the memory allocation since it might not complete
until the block device becomes active and the involed page I/O finishes.
The situation is pointed out first by Alan Stern. It is not a good
approach to convert all GFP_KERNEL[1] in the path into GFP_NOIO because
several subsystems may be involved(for example, PCI, USB and SCSI may
be involved for usb mass stoarage device, network devices involved too
in the iSCSI case)
- during block device runtime suspend, because runtime resume need
to wait for completion of concurrent runtime suspend.
- during error handling of usb mass storage deivce, USB bus reset
will be put on the device, so there shouldn't have any
memory allocation with GFP_KERNEL during USB bus reset, otherwise
the deadlock similar with above may be triggered. Unfortunately, any
usb device may include one mass storage interface in theory, so it
requires all usb interface drivers to handle the situation. In fact,
most usb drivers don't know how to handle bus reset on the device
and don't provide .pre_set() and .post_reset() callback at all, so
USB core has to unbind and bind driver for these devices. So it
is still not practical to resort to GFP_NOIO for solving the problem.
Also the introduced solution can be used by block subsystem or block
drivers too, for example, set the PF_MEMALLOC_NOIO flag before doing
actual I/O transfer.
It is not a good idea to convert all these GFP_KERNEL in the
affected path into GFP_NOIO because these functions doing that may be
implemented as library and will be called in many other contexts.
In fact, memalloc_noio_flags() can convert some of current static GFP_NOIO
allocation into GFP_KERNEL back in other non-affected contexts, at least
almost all GFP_NOIO in USB subsystem can be converted into GFP_KERNEL
after applying the approach and make allocation with GFP_NOIO
only happen in runtime resume/bus reset/block I/O transfer contexts
generally.
[1], several GFP_KERNEL allocation examples in runtime resume path
- pci subsystem
acpi_os_allocate
<-acpi_ut_allocate
<-ACPI_ALLOCATE_ZEROED
<-acpi_evaluate_object
<-__acpi_bus_set_power
<-acpi_bus_set_power
<-acpi_pci_set_power_state
<-platform_pci_set_power_state
<-pci_platform_power_transition
<-__pci_complete_power_transition
<-pci_set_power_state
<-pci_restore_standard_config
<-pci_pm_runtime_resume
- usb subsystem
usb_get_status
<-finish_port_resume
<-usb_port_resume
<-generic_resume
<-usb_resume_device
<-usb_resume_both
<-usb_runtime_resume
- some individual usb drivers
usblp, uvc, gspca, most of dvb-usb-v2 media drivers, cpia2, az6007, ....
That is just what I have found. Unfortunately, this allocation can
only be found by human being now, and there should be many not found
since any function in the resume path(call tree) may allocate memory
with GFP_KERNEL.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Jiri Kosina <jiri.kosina@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v6:
- replace GFP_IO with __GFP_IO to fix compile failure
v5:
- use inline instead of macro to define memalloc_noio_*
- replace memalloc_noio() with memalloc_noio_flags() to
make code neater
- don't clear GFP_FS because no GFP_IO means
that allocation won't enter device driver as pointed by
Andrew Morton
v4:
- fix comment
v3:
- no change
v2:
- remove changes on 'may_writepage' and 'may_swap' because that
isn't related with the patchset, and can't introduce I/O in
allocation path if GFP_IOFS is unset, so handing 'may_swap'
and may_writepage on GFP_NOIO or GFP_NOFS should be a
mm internal thing, and let mm guys deal with that, :-).
Looks clearing the two may_XXX flag only excludes dirty pages
and anon pages for relaiming, and the behaviour should be decided
by GFP FLAG, IMO.
- unset GFP_IOFS in try_to_free_pages() path since
alloc_page_buffers()
and dma_alloc_from_contiguous may drop into the path, as
pointed by KAMEZAWA Hiroyuki
v1:
- take Minchan's change to avoid the check in alloc_page hot
path
- change the helpers' style into save/restore as suggested by
Alan Stern
---
include/linux/sched.h | 22 ++++++++++++++++++++++
mm/page_alloc.c | 9 ++++++++-
mm/vmscan.c | 4 ++--
3 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 85d14e1..c9bb377 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -51,6 +51,7 @@ struct sched_param {
#include <linux/cred.h>
#include <linux/llist.h>
#include <linux/uidgid.h>
+#include <linux/gfp.h>
#include <asm/processor.h>
@@ -1810,6 +1811,7 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define PF_FROZEN 0x00010000 /* frozen for system suspend */
#define PF_FSTRANS 0x00020000 /* inside a filesystem transaction */
#define PF_KSWAPD 0x00040000 /* I am kswapd */
+#define PF_MEMALLOC_NOIO 0x00080000 /* Allocating memory without IO involved */
#define PF_LESS_THROTTLE 0x00100000 /* Throttle me less: I clean memory */
#define PF_KTHREAD 0x00200000 /* I am a kernel thread */
#define PF_RANDOMIZE 0x00400000 /* randomize virtual address space */
@@ -1847,6 +1849,26 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
#define used_math() tsk_used_math(current)
+/* __GFP_IO isn't allowed if PF_MEMALLOC_NOIO is set in current->flags */
+static inline gfp_t memalloc_noio_flags(gfp_t flags)
+{
+ if (unlikely(current->flags & PF_MEMALLOC_NOIO))
+ flags &= ~__GFP_IO;
+ return flags;
+}
+
+static inline gfp_t memalloc_noio_save(void)
+{
+ gfp_t flags = current->flags & PF_MEMALLOC_NOIO;
+ current->flags |= PF_MEMALLOC_NOIO;
+ return flags;
+}
+
+static inline void memalloc_noio_restore(gfp_t flags)
+{
+ current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flags;
+}
+
/*
* task->jobctl flags
*/
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4d077f0..4e485b1 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2644,10 +2644,17 @@ retry_cpuset:
page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
zonelist, high_zoneidx, alloc_flags,
preferred_zone, migratetype);
- if (unlikely(!page))
+ if (unlikely(!page)) {
+ /*
+ * Runtime PM, block IO and its error handling path
+ * can deadlock because I/O on the device might not
+ * complete.
+ */
+ gfp_mask = memalloc_noio_flags(gfp_mask);
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
+ }
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9ca84e2..b1296c4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2270,7 +2270,7 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
{
unsigned long nr_reclaimed;
struct scan_control sc = {
- .gfp_mask = gfp_mask,
+ .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
.may_writepage = !laptop_mode,
.nr_to_reclaim = SWAP_CLUSTER_MAX,
.may_unmap = 1,
@@ -3277,7 +3277,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
.may_swap = 1,
.nr_to_reclaim = max_t(unsigned long, nr_pages,
SWAP_CLUSTER_MAX),
- .gfp_mask = gfp_mask,
+ .gfp_mask = (gfp_mask = memalloc_noio_flags(gfp_mask)),
.order = order,
.priority = ZONE_RECLAIM_PRIORITY,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v6 0/6] solve deadlock caused by memory allocation with I/O
From: Ming Lei @ 2012-11-24 12:59 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
Hi,
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime PM and block device
error handling path. Traditionly, the problem is addressed by passing
GFP_NOIO statically to mm, but that is not a effective solution, see
detailed description in patch 1's commit log.
This patch set introduces one process flag and trys to fix the deadlock
problem on block device/network device during runtime PM or usb bus reset.
The 1st one is the change on include/sched.h and mm.
The 2nd patch introduces the flag of memalloc_noio on 'dev_pm_info',
and pm_runtime_set_memalloc_noio(), so that PM Core can teach mm to not
allocate mm with GFP_IO during the runtime_resume callback only on
device with the flag set.
The following 2 patches apply the introduced pm_runtime_set_memalloc_noio()
to mark all devices as memalloc_noio_resume in the path from the block or
network device to the root device in device tree.
The last 2 patches are applied again PM and USB subsystem to demonstrate
how to use the introduced mechanism to fix the deadlock problem.
Andrew, could you queue these patches into your tree since V6 fixes all
your concerns and looks no one objects these patches?
Change logs:
V6:
- fix one compile failure(1/6), and only one line change
V5:
- don't clear GFP_FS
- coding style fix
- add comments
- see details in individual change logs
V4:
- patches from the 2nd to the 6th changed
- call pm_runtime_set_memalloc_noio() after device_add() as pointed
by Alan
- set PF_MEMALLOC_NOIO during runtime_suspend()
V3:
- patch 2/6 and 5/6 changed, see their commit log
- remove RFC from title since several guys have expressed that
it is a reasonable solution
V2:
- remove changes on 'may_writepage' and 'may_swap'(1/6)
- unset GFP_IOFS in try_to_free_pages() path(1/6)
- introduce pm_runtime_set_memalloc_noio()
- only apply the meachnism on block/network device and its ancestors
for runtime resume context
V1:
- take Minchan's change to avoid the check in alloc_page hot path
- change the helpers' style into save/restore as suggested by Alan
- memory allocation with no io in usb bus reset path for all devices
as suggested by Greg and Oliver
block/genhd.c | 10 +++++
drivers/base/power/runtime.c | 92 +++++++++++++++++++++++++++++++++++++++++-
drivers/usb/core/hub.c | 13 ++++++
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 3 ++
include/linux/sched.h | 22 ++++++++++
mm/page_alloc.c | 9 ++++-
mm/vmscan.c | 4 +-
net/core/net-sysfs.c | 5 +++
9 files changed, 154 insertions(+), 5 deletions(-)
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] bonding: make arp_ip_target parameter checks consistent with sysfs
From: Nikolay Aleksandrov @ 2012-11-24 12:21 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, davem
The module can be loaded with arp_ip_target="255.255.255.255" which makes it
impossible to remove as the function in sysfs checks for that value, so we make
the parameter checks consistent with sysfs.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5f5b69f..940eac8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4706,12 +4706,14 @@ static int bond_check_params(struct bond_params *params)
arp_ip_count++) {
/* not complete check, but should be good enough to
catch mistakes */
- if (!isdigit(arp_ip_target[arp_ip_count][0])) {
+ __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
+ if (!isdigit(arp_ip_target[arp_ip_count][0])
+ || ip == 0
+ || ip == htonl(INADDR_BROADCAST)) {
pr_warning("Warning: bad arp_ip_target module parameter (%s), ARP monitoring will not be performed\n",
arp_ip_target[arp_ip_count]);
arp_interval = 0;
} else {
- __be32 ip = in_aton(arp_ip_target[arp_ip_count]);
arp_target[arp_ip_count] = ip;
}
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] net: sched: enable CAN Identifier to be build into kernel
From: Marc Kleine-Budde @ 2012-11-24 12:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-can
In-Reply-To: <20121123.142258.816355331172102352.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
On 11/23/2012 08:22 PM, David Miller wrote:
> From: Marc Kleine-Budde <mkl@pengutronix.de>
> Date: Fri, 23 Nov 2012 11:44:57 +0100
>
>> This patch makes it possible to build the CAN Identifier into the kernel, even
>> if the CAN support is build as a module.
>>
>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> Why is this so critical that you're asking me to merge this into
> the 'net' tree mere days before Linus makes a release?
Sorry my fault. I intended post that patch against net-next.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]
^ permalink raw reply
* [PATCH] bonding: fix race condition in bonding_store_slaves_active
From: Nikolay Aleksandrov @ 2012-11-24 12:19 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, davem
Race between bonding_store_slaves_active() and slave manipulation functions
The bond_for_each_slave use in bonding_store_slaves_active() is not protected
by any synchronization mechanism. NULL pointer dereference is easy to reach.
Fixed by acquiring the bond->lock for the slave walk.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_sysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index ef8d2a0..ba4f95b 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -1582,6 +1582,7 @@ static ssize_t bonding_store_slaves_active(struct device *d,
goto out;
}
+ read_lock(&bond->lock);
bond_for_each_slave(bond, slave, i) {
if (!bond_is_active_slave(slave)) {
if (new_value)
@@ -1590,6 +1591,7 @@ static ssize_t bonding_store_slaves_active(struct device *d,
slave->inactive = 1;
}
}
+ read_unlock(&bond->lock);
out:
return ret;
}
--
1.7.11.7
^ 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