* [PATCH v3 0/2] Fix uevent race in register_netdevice()
From: Kalle Valo @ 2011-05-16 14:46 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, linux-kernel
I'm trying to fix a race in register_netdevice(). The problem is that
there's a uevent to userspace before the netdevice is ready for use. The
problem is described here:
https://bugzilla.kernel.org/show_bug.cgi?id=15606
I have sent few different ways to fix this, but none of them have been
really usable. Now I came up with a way which changes the driver core
to make it possible send the uevent in a separate call. This is a clean
and safe way to fix the race. Downside is that two new functions are
added to the driver core interface.
Please comment.
---
Kalle Valo (2):
driver core: add device_add_noevent() and device_uevent()
net: postpone net device uevent to fix a race
drivers/base/core.c | 76 +++++++++++++++++++++++++++++++++++++-----------
include/linux/device.h | 2 +
net/core/dev.c | 3 ++
net/core/net-sysfs.c | 2 +
4 files changed, 65 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: [RFC] ethernet: avoid pre-assigned OUI values in random_ether_addr
From: Rick Jones @ 2011-05-16 14:29 UTC (permalink / raw)
To: Bill Fink; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20110514022825.bcd09e14.billfink@mindspring.com>
On Sat, 2011-05-14 at 02:28 -0400, Bill Fink wrote:
> On Fri, 13 May 2011, Rick Jones wrote:
>
> > > Well, then by a quick glance at
> > > http://standards.ieee.org/develop/regauth/oui/oui.txt it looks like
> > > there are more to add... (some overlap with your list, I've not checked
> > > the entire thing, how the name conflicts should be resolved I've no
> > > idea)
> > >
> > > raj@tardy:~$ grep ^02- oui.txt
> > > 02-07-01 (hex) RACAL-DATACOM
> > > 02-1C-7C (hex) PERQ SYSTEMS CORPORATION
> > > 02-60-86 (hex) LOGIC REPLACEMENT TECH. LTD.
> > > 02-60-8C (hex) 3COM CORPORATION
> > > 02-70-01 (hex) RACAL-DATACOM
> > > 02-70-B0 (hex) M/A-COM INC. COMPANIES
> > > 02-70-B3 (hex) DATA RECALL LTD
> > > 02-9D-8E (hex) CARDIAC RECORDERS INC.
> > > 02-AA-3C (hex) OLIVETTI TELECOMM SPA (OLTECO)
> > > 02-BB-01 (hex) OCTOTHORPE CORP.
> > > 02-C0-8C (hex) 3COM CORPORATION
> > > 02-CF-1C (hex) COMMUNICATION MACHINERY CORP.
> > > 02-E6-D3 (hex) NIXDORF COMPUTER CORPORATION
> > >
> > > The ieee's list doesn't have any 52's though.
> >
> > It does have some A's though:
> > ~$ grep ^.[26AE]- oui.txt
> > [the aforementioned 02's]
> > AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION
> > AA-00-01 (hex) DIGITAL EQUIPMENT CORPORATION
> > AA-00-02 (hex) DIGITAL EQUIPMENT CORPORATION
> > AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION
> > AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION
> >
> > which if I've not botched my bits has the locally administered bit set.
>
> The AA addresses are used by DECNET and related protocols.
Um, ok, I was figuring something along those lines - but regardless, in
the context of Stephen's RFC, they are pre-assigned OUIs with the
locally administered bit set and presumably as such ones that should not
be assigned by the random ethernet address generator. Assuming that
checking for such things is indeed necessary in the first place.
rick jones
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Michał Mirosław @ 2011-05-16 14:23 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller
In-Reply-To: <1305553066.19966.32.camel@localhost>
On Mon, May 16, 2011 at 02:37:46PM +0100, Ben Hutchings wrote:
> On Mon, 2011-05-16 at 15:28 +0200, Michał Mirosław wrote:
> > Remove NETIF_F_COMPAT since it's redundant and will be unused after
> > all drivers are converted to fix/set_features.
> >
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > ---
> >
> > For net as we don't want to have ETHTOOL_F_COMPAT hit stable release.
> [...]
> ETHTOOL_F_WISH means that the requested features could not all be
> enabled, *but are remembered*. ETHTOOL_F_COMPAT means they were not
> remembered.
Hmm. So, lets just revert 39fc0ce5710c53bad14aaba1a789eec810c556f9
(net: Implement SFEATURES compatibility for not updated drivers).
Best Regards,
Michał Mirosław
^ permalink raw reply
* stateless nat *please* tell me how I'm supposed to use it
From: Erik Slagter @ 2011-05-16 13:55 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]
Hello devs,
Normally I wouldn't dare to ask my question here, but really there is
nothing to be found that explains how to do this.
For a high availability router-cluster I need to do static nat. The only
thing it needs to do is replace a dst ipv4 address or a src ipv4
address, depending on src/dst host ip. It does not need to keep any
state / connection tracking etc. Actually I'd prefer to not have it
tracked. Both routers need to be able to take over routing from the
other at any given moment and therefore cannot transfer state
information to the other one.
These are the approaches I've tried and/or considered:
- use iptables stateful NAT in combination with a NOTRACK target:
doesn't work, as soon as a packet is marked NOTRACK, it doesn't get
NATted at all
- use iptables stateful NAT anyway and hope for the best: this kind of
works, but I am not happy with it
- use stateless nat from "ip route": abandoned because "deprecated"
- use "mangle" from iptables: doesn't work because you can't "mangle"
the addresses (which is kind of stupid imho)
- use conntrackd: that will probably work, but it's way too complex for
something simple I want to do.
- finally: use tc action nat as seem to be recommended of late.
Attempt 1: using "tc filter ... action nat ..." syntax.
# tc filter add dev eth0 parent root protocol ip prio 10 u32 match u32 0
0 action nat ingress 1.2.3.4 4.5.6.7
RTNETLINK answers: Invalid argument
This suggests that the construct is recognised by tc but the kernel
doesn't (fully) understand this. That's weird because devs said earlier
it should work from somewhere 2.6.29 onwards. I've added some printk's
to the act_nat.c file and that learns that this code isn't called at
all, so probably something else (rtnetlink?) already bails out. So...
this doesn't work.
Attempt 2: using "tc action" syntax
This syntax is not described anywere other than in the help, so I'm just
try-and-error-ing.
# tc action add nat egress 1.2.3.4 4.5.6.7
Now this works, well, it doesn't throw errors. It doesn't do anything
either. I guess this action needs to be called from a filter, other than
incorporating it INTO the filter (which doesn't work). There is no
syntax (described) that allows a filter to call an action indirectly.
So my question is, how am I supposed to do something that simple as
replacing a few bytes in an ip header with the effect of a stateless nat.
Thanks very much.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5110 bytes --]
^ permalink raw reply
* Re: [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Ben Hutchings @ 2011-05-16 13:37 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, David Miller
In-Reply-To: <20110516132807.1A89F13A6A@rere.qmqm.pl>
On Mon, 2011-05-16 at 15:28 +0200, Michał Mirosław wrote:
> Remove NETIF_F_COMPAT since it's redundant and will be unused after
> all drivers are converted to fix/set_features.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
>
> For net as we don't want to have ETHTOOL_F_COMPAT hit stable release.
[...]
ETHTOOL_F_WISH means that the requested features could not all be
enabled, *but are remembered*. ETHTOOL_F_COMPAT means they were not
remembered.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: several packets in a single buffer in Rx
From: Emmanuel Grumbach @ 2011-05-16 13:36 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, Guy, Wey-Yi,
guy.cohen-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <BANLkTi=xJbL-26Hzg0Pp5zKPUi35bV6VmA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011/5/16 Michał Mirosław <mirqus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> W dniu 16 maja 2011 14:59 użytkownik Emmanuel Grumbach
> <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> napisał:
>> 2011/5/16 Michał Mirosław <mirqus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> 2011/5/16 Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>> I would like to be able to deliver the same page several times to the
>>>> stack without having the stack consume it before the last time I
>>>> deliver it.
>>>> Of course I would like to avoid cloning it.
>>>
>>> Just do get_page() on the page having another packet in it before
>>> passing skb up.
>>>
>>
>> I can see the path:
>> __kfree_skb -> skb_release_all -> skb_release_data -> put_page
>> put_page will free the page iff the _count variable reaches 0. Of course,
>> _count is incremented by get_page.
>>
>> I will give it try.
>>
>> I understand that this will work regardless the order given to
>> alloc_pages right ?
>
> Yes. Remember that if you put a lot of packets in a big-order page
> then the memory will be freed only after all packets are freed.
Sure. Thanks for the help.
>
> Best Regards,
> Michał Mirosław
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ethtool: ETHTOOL_SFEATURES: remove NETIF_F_COMPAT return
From: Michał Mirosław @ 2011-05-16 13:28 UTC (permalink / raw)
To: netdev; +Cc: Ben Hutchings, David Miller
In-Reply-To: <20110516121339.GA1094@rere.qmqm.pl>
Remove NETIF_F_COMPAT since it's redundant and will be unused after
all drivers are converted to fix/set_features.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
For net as we don't want to have ETHTOOL_F_COMPAT hit stable release.
include/linux/ethtool.h | 5 -----
net/core/ethtool.c | 2 +-
2 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index dc80d82..5fb916c 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -625,9 +625,6 @@ struct ethtool_sfeatures {
* Probably there are other device-specific constraints on some features
* in the set. When %ETHTOOL_F_UNSUPPORTED is set, .valid is considered
* here as though ignored bits were cleared.
- * %ETHTOOL_F_COMPAT - some or all changes requested were made by calling
- * compatibility functions. Requested offload state cannot be properly
- * managed by kernel.
*
* Meaning of bits in the masks are obtained by %ETHTOOL_GSSET_INFO (number of
* bits in the arrays - always multiple of 32) and %ETHTOOL_GSTRINGS commands
@@ -637,12 +634,10 @@ struct ethtool_sfeatures {
enum ethtool_sfeatures_retval_bits {
ETHTOOL_F_UNSUPPORTED__BIT,
ETHTOOL_F_WISH__BIT,
- ETHTOOL_F_COMPAT__BIT,
};
#define ETHTOOL_F_UNSUPPORTED (1 << ETHTOOL_F_UNSUPPORTED__BIT)
#define ETHTOOL_F_WISH (1 << ETHTOOL_F_WISH__BIT)
-#define ETHTOOL_F_COMPAT (1 << ETHTOOL_F_COMPAT__BIT)
#ifdef __KERNEL__
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 74ead9e..dc07569 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -308,7 +308,7 @@ static int ethtool_set_features(struct net_device *dev, void __user *useraddr)
return -EINVAL;
if (ethtool_set_features_compat(dev, features))
- ret |= ETHTOOL_F_COMPAT;
+ ret |= ETHTOOL_F_WISH;
if (features[0].valid & ~dev->hw_features) {
features[0].valid &= dev->hw_features;
^ permalink raw reply related
* [PATCH] net: Change netdev_fix_features messages loglevel
From: Michał Mirosław @ 2011-05-16 13:17 UTC (permalink / raw)
To: netdev; +Cc: Michael S. Tsirkin, Herbert Xu, Ben Hutchings
Those reduced to DEBUG can possibly be triggered by unprivileged processes
and are nothing exceptional. Illegal checksum combinations can only be
caused by driver bug, so promote those messages to WARN.
Since GSO without SG will now only cause DEBUG message from
netdev_fix_features(), remove the workaround from register_netdevice().
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
This is for net tree, not net-next.
net/core/dev.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 9200944..b624fe4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5186,27 +5186,27 @@ u32 netdev_fix_features(struct net_device *dev, u32 features)
/* Fix illegal checksum combinations */
if ((features & NETIF_F_HW_CSUM) &&
(features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
- netdev_info(dev, "mixed HW and IP checksum settings.\n");
+ netdev_warn(dev, "mixed HW and IP checksum settings.\n");
features &= ~(NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM);
}
if ((features & NETIF_F_NO_CSUM) &&
(features & (NETIF_F_HW_CSUM|NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
- netdev_info(dev, "mixed no checksumming and other settings.\n");
+ netdev_warn(dev, "mixed no checksumming and other settings.\n");
features &= ~(NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM|NETIF_F_HW_CSUM);
}
/* Fix illegal SG+CSUM combinations. */
if ((features & NETIF_F_SG) &&
!(features & NETIF_F_ALL_CSUM)) {
- netdev_info(dev,
- "Dropping NETIF_F_SG since no checksum feature.\n");
+ netdev_dbg(dev,
+ "Dropping NETIF_F_SG since no checksum feature.\n");
features &= ~NETIF_F_SG;
}
/* TSO requires that SG is present as well. */
if ((features & NETIF_F_ALL_TSO) && !(features & NETIF_F_SG)) {
- netdev_info(dev, "Dropping TSO features since no SG feature.\n");
+ netdev_dbg(dev, "Dropping TSO features since no SG feature.\n");
features &= ~NETIF_F_ALL_TSO;
}
@@ -5216,7 +5216,7 @@ u32 netdev_fix_features(struct net_device *dev, u32 features)
/* Software GSO depends on SG. */
if ((features & NETIF_F_GSO) && !(features & NETIF_F_SG)) {
- netdev_info(dev, "Dropping NETIF_F_GSO since no SG feature.\n");
+ netdev_dbg(dev, "Dropping NETIF_F_GSO since no SG feature.\n");
features &= ~NETIF_F_GSO;
}
@@ -5226,13 +5226,13 @@ u32 netdev_fix_features(struct net_device *dev, u32 features)
if (!((features & NETIF_F_GEN_CSUM) ||
(features & (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))
== (NETIF_F_IP_CSUM|NETIF_F_IPV6_CSUM))) {
- netdev_info(dev,
+ netdev_dbg(dev,
"Dropping NETIF_F_UFO since no checksum offload features.\n");
features &= ~NETIF_F_UFO;
}
if (!(features & NETIF_F_SG)) {
- netdev_info(dev,
+ netdev_dbg(dev,
"Dropping NETIF_F_UFO since no NETIF_F_SG feature.\n");
features &= ~NETIF_F_UFO;
}
@@ -5414,12 +5414,6 @@ int register_netdevice(struct net_device *dev)
dev->features |= NETIF_F_SOFT_FEATURES;
dev->wanted_features = dev->features & dev->hw_features;
- /* Avoid warning from netdev_fix_features() for GSO without SG */
- if (!(dev->wanted_features & NETIF_F_SG)) {
- dev->wanted_features &= ~NETIF_F_GSO;
- dev->features &= ~NETIF_F_GSO;
- }
-
/* Enable GRO and NETIF_F_HIGHDMA for vlans by default,
* vlan_dev_init() will do the dev->features check, so these features
* are enabled only if supported by underlying device.
^ permalink raw reply related
* Re: several packets in a single buffer in Rx
From: Michał Mirosław @ 2011-05-16 13:13 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: netdev, linux-wireless, Johannes Berg, Guy, Wey-Yi, guy.cohen
In-Reply-To: <BANLkTi=aBLPX7OMKi=sMhT81x-2f6Ci6sQ@mail.gmail.com>
W dniu 16 maja 2011 14:59 użytkownik Emmanuel Grumbach
<egrumbach@gmail.com> napisał:
> 2011/5/16 Michał Mirosław <mirqus@gmail.com>:
>> 2011/5/16 Emmanuel Grumbach <egrumbach@gmail.com>:
>>> I would like to be able to deliver the same page several times to the
>>> stack without having the stack consume it before the last time I
>>> deliver it.
>>> Of course I would like to avoid cloning it.
>>
>> Just do get_page() on the page having another packet in it before
>> passing skb up.
>>
>
> I can see the path:
> __kfree_skb -> skb_release_all -> skb_release_data -> put_page
> put_page will free the page iff the _count variable reaches 0. Of course,
> _count is incremented by get_page.
>
> I will give it try.
>
> I understand that this will work regardless the order given to
> alloc_pages right ?
Yes. Remember that if you put a lot of packets in a big-order page
then the memory will be freed only after all packets are freed.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: several packets in a single buffer in Rx
From: Emmanuel Grumbach @ 2011-05-16 12:59 UTC (permalink / raw)
To: Michał Mirosław
Cc: netdev, linux-wireless, Johannes Berg, Guy, Wey-Yi, guy.cohen
In-Reply-To: <BANLkTinb3kaK7_b=47AL+Mb6Zmt9twEM9g@mail.gmail.com>
2011/5/16 Michał Mirosław <mirqus@gmail.com>:
> 2011/5/16 Emmanuel Grumbach <egrumbach@gmail.com>:
>> I would like to be able to deliver the same page several times to the
>> stack without having the stack consume it before the last time I
>> deliver it.
>> Of course I would like to avoid cloning it.
>
> Just do get_page() on the page having another packet in it before
> passing skb up.
>
I can see the path:
__kfree_skb -> skb_release_all -> skb_release_data -> put_page
put_page will free the page iff the _count variable reaches 0. Of course,
_count is incremented by get_page.
I will give it try.
I understand that this will work regardless the order given to
alloc_pages right ?
Thanks
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
From: Vasiliy Kulikov @ 2011-05-16 12:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, solar, linux-kernel, netdev, peak, kees.cook,
dan.j.rosenberg, eugene, nelhage, kuznet, pekkas, jmorris,
yoshfuji, kaber
In-Reply-To: <1305530791.3120.217.camel@edumazet-laptop>
On Mon, May 16, 2011 at 09:26 +0200, Eric Dumazet wrote:
> Le dimanche 15 mai 2011 à 17:44 -0400, David Miller a écrit :
>
> > Just get rid of ping_ioctl() entirely, as that is the effect of
> > this change since inet_ioctl() returns -ENOIOCTLCMD when
> > sk_prot->ioctl is NULL.
> >
> > Also get rid of asm/ioctls.h since that will be no longer needed.
>
> Sure, here is updated version, thanks.
>
> [PATCH net-next-2.6 v2] net: ping: dont call udp_ioctl()
>
> udp_ioctl() really handles UDP and UDPLite protocols.
>
> 1) It can increment UDP_MIB_INERRORS in case first_packet_length() finds
> a frame with bad checksum.
>
> 2) It has a dependency on sizeof(struct udphdr), not applicable to
> ICMP/PING
>
> If ping sockets need to handle SIOCINQ/SIOCOUTQ ioctl, this should be
> done differently.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Vasiliy Kulikov <segoon@openwall.com>
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-16 12:24 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael S. Tsirkin, Shan Wei, Michał Mirosław, netdev,
Ben Hutchings
In-Reply-To: <20110516121857.GA4495@gondor.apana.org.au>
2011/5/16 Herbert Xu <herbert@gondor.apana.org.au>:
> On Mon, May 16, 2011 at 02:21:33PM +0300, Michael S. Tsirkin wrote:
>> Yes, but then we get annoying info messages every time.
>> Change them all to debug or remove completely?
> If you are getting warning messages then it probably means that
> your driver is doing something wrong.
In this case - no. Those messages inform that driver supports more
feature combinations than network core and the feature set is reduced
because of that.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 12:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516112133.GA11274@redhat.com>
On Mon, May 16, 2011 at 02:21:33PM +0300, Michael S. Tsirkin wrote:
>
> Yes, but then we get annoying info messages every time.
> Change them all to debug or remove completely?
If you are getting warning messages then it probably means that
your driver is doing something wrong.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Remove fallback to old ethtool operations for ETHTOOL_SFEATURES
From: Michał Mirosław @ 2011-05-16 12:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1305513923.19966.20.camel@localhost>
On Mon, May 16, 2011 at 03:45:23AM +0100, Ben Hutchings wrote:
> On Sat, 2011-05-14 at 12:35 +0200, Michał Mirosław wrote:
> > On Sat, May 14, 2011 at 02:05:42AM +0100, Ben Hutchings wrote:
> > > ethtool_set_feature_compat() squashes the feature mask into a boolean,
> > > which is not correct for ethtool_ops::set_flags.
> > >
> > > We could fix this, but the fallback code for ETHTOOL_SFEATURES actually
> > > makes things more complicated for the ethtool utility and any other
> > > application using the ethtool API. They will still need to fall back to
> > > the old offload control commands in order to support older kernel
> > > versions. The fallback code in the kernel adds a third possibility for
> > > them to handle. So make ETHTOOL_SFEATURES fail when the driver
> > > implements the old offload control operations, and let userland do the
> > > fallback.
> > BTW, the idea behind the compat code is that if ETHTOOL_[GS]FEATURES is
> > available, then there should be no need to fallback to old ops. For
> > a userspace tool that targets only kernels >= 2.6.39 there's no need
> > to care about old ops at all.
> Well that's not true, because those tools still have to deal with
> ETHTOOL_F_COMPAT. And we're supposed to have all drivers converted for
> 2.6.40, so the hypothetical new tool only has to wait one more release.
I think that handling ETHTOOL_F_COMPAT is like ETHTOOL_F_WISH - the tool
needs to reread features and check what was changed. So we can get rid
of the former by replacing it with the latter.
Changing some feature state may change others that were not requested
to be changed (not present in .valid). This probably should be signalled
as well. Extend ETHTOOL_F_WISH meaning (I prefer this one) or introduce
new bit?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 11:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516104309.GA3534@gondor.apana.org.au>
On Mon, May 16, 2011 at 08:43:10PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 12:48:21PM +0300, Michael S. Tsirkin wrote:
> >
> > Both bridge and tun trigger the messages ATM. I note that
> > dev.c takes pains to avoid these messages:
> > Avoid warning from netdev_fix_features() for GSO without SG
> >
> > Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> > If we start doing this, this spills info about flag dependencies out to drivers.
>
> Drivers don't need to do this at all since the network stack
> will automatically clear SG and related features if checksum
> is disabled.
>
> Cheers,
Yes, but then we get annoying info messages every time.
Change them all to debug or remove completely?
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: several packets in a single buffer in Rx
From: Michał Mirosław @ 2011-05-16 11:06 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Johannes Berg, Guy, Wey-Yi,
guy.cohen-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <BANLkTimkgtQL1A2A3iAP-UYK2KdDvPmY3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011/5/16 Emmanuel Grumbach <egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> I would like to be able to deliver the same page several times to the
> stack without having the stack consume it before the last time I
> deliver it.
> Of course I would like to avoid cloning it.
Just do get_page() on the page having another packet in it before
passing skb up.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michał Mirosław @ 2011-05-16 10:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Herbert Xu, Shan Wei, Michał Mirosław, netdev,
Ben Hutchings
In-Reply-To: <20110516094821.GA9427@redhat.com>
2011/5/16 Michael S. Tsirkin <mst@redhat.com>:
> On Mon, May 16, 2011 at 07:38:22PM +1000, Herbert Xu wrote:
>> On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
>> >
>> > There's no interface for userspace to enable it: userspace
>> > only has an ioctl to enable/disable checksum offloading.
>> > SG is an implementation detail.
>> Yes there is: ethtool -K
> Ok. You are right of course, I was confused.
>
> So it's just an info message: in the end if userspace DTRT features
> get enabled properly. Functionally, there is no regression.
I proposed changing those messages to DEBUG level some time ago.Those
dependencies are constant, so they could be moved to
Documentation/networking/.
> Both bridge and tun trigger the messages ATM. I note that
> dev.c takes pains to avoid these messages:
> Avoid warning from netdev_fix_features() for GSO without SG
>
> Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> If we start doing this, this spills info about flag dependencies out to drivers.
Drivers should not care about those dependencies.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [Patch net-next-2.6] rfkill: remove CONFIG_RFKILL_INPUT
From: Américo Wang @ 2011-05-16 10:44 UTC (permalink / raw)
To: Linux Kernel Network Developers, linux-wireless
Cc: David S. Miller, Johannes Berg, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
This is scheduled to be removed in 2.6.33, now we are at 2.6.39-rc2.
So I think it is safe to remove it completely.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
---
[-- Attachment #2: net-rfkill-remove-rfkill-input.diff --]
[-- Type: text/x-patch, Size: 18654 bytes --]
Documentation/feature-removal-schedule.txt | 7 -
arch/mips/configs/bcm47xx_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 1 -
net/rfkill/Kconfig | 6 -
net/rfkill/Makefile | 1 -
net/rfkill/core.c | 202 ----------------
net/rfkill/input.c | 350 ----------------------------
7 files changed, 0 insertions(+), 568 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 46679e4..ebf2db4 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -345,13 +345,6 @@ Who: Alex Chiang <achiang@hp.com>
---------------------------
-What: CONFIG_RFKILL_INPUT
-When: 2.6.33
-Why: Should be implemented in userspace, policy daemon.
-Who: Johannes Berg <johannes@sipsolutions.net>
-
-----------------------------
-
What: sound-slot/service-* module aliases and related clutters in
sound/sound_core.c
When: August 2010
diff --git a/arch/mips/configs/bcm47xx_defconfig b/arch/mips/configs/bcm47xx_defconfig
index 22fdf2f..3d724ef 100644
--- a/arch/mips/configs/bcm47xx_defconfig
+++ b/arch/mips/configs/bcm47xx_defconfig
@@ -268,7 +268,6 @@ CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_MESH=y
CONFIG_RFKILL=m
-CONFIG_RFKILL_INPUT=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_FW_LOADER=m
CONFIG_CONNECTOR=m
diff --git a/arch/mips/configs/lemote2f_defconfig b/arch/mips/configs/lemote2f_defconfig
index 167c1d0..3ffb909 100644
--- a/arch/mips/configs/lemote2f_defconfig
+++ b/arch/mips/configs/lemote2f_defconfig
@@ -103,7 +103,6 @@ CONFIG_LIB80211_DEBUG=y
CONFIG_MAC80211=m
CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL=m
-CONFIG_RFKILL_INPUT=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=m
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 48464ca..c192603 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -17,12 +17,6 @@ config RFKILL_LEDS
depends on LEDS_TRIGGERS = y || RFKILL = LEDS_TRIGGERS
default y
-config RFKILL_INPUT
- bool "RF switch input support" if EXPERT
- depends on RFKILL
- depends on INPUT = y || RFKILL = INPUT
- default y if !EXPERT
-
config RFKILL_REGULATOR
tristate "Generic rfkill regulator driver"
depends on RFKILL || !RFKILL
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index d9a5a58..0d5e3e1 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -3,6 +3,5 @@
#
rfkill-y += core.o
-rfkill-$(CONFIG_RFKILL_INPUT) += input.o
obj-$(CONFIG_RFKILL) += rfkill.o
obj-$(CONFIG_RFKILL_REGULATOR) += rfkill-regulator.o
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 0198191..47ab44e 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -304,153 +304,6 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
rfkill_event(rfkill);
}
-#ifdef CONFIG_RFKILL_INPUT
-static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
-
-/**
- * __rfkill_switch_all - Toggle state of all switches of given type
- * @type: type of interfaces to be affected
- * @state: the new state
- *
- * This function sets the state of all switches of given type,
- * unless a specific switch is claimed by userspace (in which case,
- * that switch is left alone) or suspended.
- *
- * Caller must have acquired rfkill_global_mutex.
- */
-static void __rfkill_switch_all(const enum rfkill_type type, bool blocked)
-{
- struct rfkill *rfkill;
-
- rfkill_global_states[type].cur = blocked;
- list_for_each_entry(rfkill, &rfkill_list, node) {
- if (rfkill->type != type)
- continue;
-
- rfkill_set_block(rfkill, blocked);
- }
-}
-
-/**
- * rfkill_switch_all - Toggle state of all switches of given type
- * @type: type of interfaces to be affected
- * @state: the new state
- *
- * Acquires rfkill_global_mutex and calls __rfkill_switch_all(@type, @state).
- * Please refer to __rfkill_switch_all() for details.
- *
- * Does nothing if the EPO lock is active.
- */
-void rfkill_switch_all(enum rfkill_type type, bool blocked)
-{
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- if (!rfkill_epo_lock_active)
- __rfkill_switch_all(type, blocked);
-
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_epo - emergency power off all transmitters
- *
- * This kicks all non-suspended rfkill devices to RFKILL_STATE_SOFT_BLOCKED,
- * ignoring everything in its path but rfkill_global_mutex and rfkill->mutex.
- *
- * The global state before the EPO is saved and can be restored later
- * using rfkill_restore_states().
- */
-void rfkill_epo(void)
-{
- struct rfkill *rfkill;
- int i;
-
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- rfkill_epo_lock_active = true;
- list_for_each_entry(rfkill, &rfkill_list, node)
- rfkill_set_block(rfkill, true);
-
- for (i = 0; i < NUM_RFKILL_TYPES; i++) {
- rfkill_global_states[i].sav = rfkill_global_states[i].cur;
- rfkill_global_states[i].cur = true;
- }
-
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_restore_states - restore global states
- *
- * Restore (and sync switches to) the global state from the
- * states in rfkill_default_states. This can undo the effects of
- * a call to rfkill_epo().
- */
-void rfkill_restore_states(void)
-{
- int i;
-
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
-
- rfkill_epo_lock_active = false;
- for (i = 0; i < NUM_RFKILL_TYPES; i++)
- __rfkill_switch_all(i, rfkill_global_states[i].sav);
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_remove_epo_lock - unlock state changes
- *
- * Used by rfkill-input manually unlock state changes, when
- * the EPO switch is deactivated.
- */
-void rfkill_remove_epo_lock(void)
-{
- if (atomic_read(&rfkill_input_disabled))
- return;
-
- mutex_lock(&rfkill_global_mutex);
- rfkill_epo_lock_active = false;
- mutex_unlock(&rfkill_global_mutex);
-}
-
-/**
- * rfkill_is_epo_lock_active - returns true EPO is active
- *
- * Returns 0 (false) if there is NOT an active EPO contidion,
- * and 1 (true) if there is an active EPO contition, which
- * locks all radios in one of the BLOCKED states.
- *
- * Can be called in atomic context.
- */
-bool rfkill_is_epo_lock_active(void)
-{
- return rfkill_epo_lock_active;
-}
-
-/**
- * rfkill_get_global_sw_state - returns global state for a type
- * @type: the type to get the global state of
- *
- * Returns the current global state for a given wireless
- * device type.
- */
-bool rfkill_get_global_sw_state(const enum rfkill_type type)
-{
- return rfkill_global_states[type].cur;
-}
-#endif
-
-
bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
{
bool ret, change;
@@ -950,13 +803,6 @@ int __must_check rfkill_register(struct rfkill *rfkill)
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
- } else {
-#ifdef CONFIG_RFKILL_INPUT
- bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
-
- if (!atomic_read(&rfkill_input_disabled))
- __rfkill_switch_all(rfkill->type, soft_blocked);
-#endif
}
rfkill_send_events(rfkill, RFKILL_OP_ADD);
@@ -1179,43 +1025,11 @@ static int rfkill_fop_release(struct inode *inode, struct file *file)
list_for_each_entry_safe(ev, tmp, &data->events, list)
kfree(ev);
-#ifdef CONFIG_RFKILL_INPUT
- if (data->input_handler)
- if (atomic_dec_return(&rfkill_input_disabled) == 0)
- printk(KERN_DEBUG "rfkill: input handler enabled\n");
-#endif
-
kfree(data);
return 0;
}
-#ifdef CONFIG_RFKILL_INPUT
-static long rfkill_fop_ioctl(struct file *file, unsigned int cmd,
- unsigned long arg)
-{
- struct rfkill_data *data = file->private_data;
-
- if (_IOC_TYPE(cmd) != RFKILL_IOC_MAGIC)
- return -ENOSYS;
-
- if (_IOC_NR(cmd) != RFKILL_IOC_NOINPUT)
- return -ENOSYS;
-
- mutex_lock(&data->mtx);
-
- if (!data->input_handler) {
- if (atomic_inc_return(&rfkill_input_disabled) == 1)
- printk(KERN_DEBUG "rfkill: input handler disabled\n");
- data->input_handler = true;
- }
-
- mutex_unlock(&data->mtx);
-
- return 0;
-}
-#endif
-
static const struct file_operations rfkill_fops = {
.owner = THIS_MODULE,
.open = rfkill_fop_open,
@@ -1223,10 +1037,6 @@ static const struct file_operations rfkill_fops = {
.write = rfkill_fop_write,
.poll = rfkill_fop_poll,
.release = rfkill_fop_release,
-#ifdef CONFIG_RFKILL_INPUT
- .unlocked_ioctl = rfkill_fop_ioctl,
- .compat_ioctl = rfkill_fop_ioctl,
-#endif
.llseek = no_llseek,
};
@@ -1254,15 +1064,6 @@ static int __init rfkill_init(void)
goto out;
}
-#ifdef CONFIG_RFKILL_INPUT
- error = rfkill_handler_init();
- if (error) {
- misc_deregister(&rfkill_miscdev);
- class_unregister(&rfkill_class);
- goto out;
- }
-#endif
-
out:
return error;
}
@@ -1270,9 +1071,6 @@ subsys_initcall(rfkill_init);
static void __exit rfkill_exit(void)
{
-#ifdef CONFIG_RFKILL_INPUT
- rfkill_handler_exit();
-#endif
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
}
diff --git a/net/rfkill/input.c b/net/rfkill/input.c
deleted file mode 100644
index 1bca6d4..0000000
--- a/net/rfkill/input.c
+++ /dev/null
@@ -1,350 +0,0 @@
-/*
- * Input layer to RF Kill interface connector
- *
- * Copyright (c) 2007 Dmitry Torokhov
- * Copyright 2009 Johannes Berg <johannes@sipsolutions.net>
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published
- * by the Free Software Foundation.
- *
- * If you ever run into a situation in which you have a SW_ type rfkill
- * input device, then you can revive code that was removed in the patch
- * "rfkill-input: remove unused code".
- */
-
-#include <linux/input.h>
-#include <linux/slab.h>
-#include <linux/workqueue.h>
-#include <linux/init.h>
-#include <linux/rfkill.h>
-#include <linux/sched.h>
-
-#include "rfkill.h"
-
-enum rfkill_input_master_mode {
- RFKILL_INPUT_MASTER_UNLOCK = 0,
- RFKILL_INPUT_MASTER_RESTORE = 1,
- RFKILL_INPUT_MASTER_UNBLOCKALL = 2,
- NUM_RFKILL_INPUT_MASTER_MODES
-};
-
-/* Delay (in ms) between consecutive switch ops */
-#define RFKILL_OPS_DELAY 200
-
-static enum rfkill_input_master_mode rfkill_master_switch_mode =
- RFKILL_INPUT_MASTER_UNBLOCKALL;
-module_param_named(master_switch_mode, rfkill_master_switch_mode, uint, 0);
-MODULE_PARM_DESC(master_switch_mode,
- "SW_RFKILL_ALL ON should: 0=do nothing (only unlock); 1=restore; 2=unblock all");
-
-static spinlock_t rfkill_op_lock;
-static bool rfkill_op_pending;
-static unsigned long rfkill_sw_pending[BITS_TO_LONGS(NUM_RFKILL_TYPES)];
-static unsigned long rfkill_sw_state[BITS_TO_LONGS(NUM_RFKILL_TYPES)];
-
-enum rfkill_sched_op {
- RFKILL_GLOBAL_OP_EPO = 0,
- RFKILL_GLOBAL_OP_RESTORE,
- RFKILL_GLOBAL_OP_UNLOCK,
- RFKILL_GLOBAL_OP_UNBLOCK,
-};
-
-static enum rfkill_sched_op rfkill_master_switch_op;
-static enum rfkill_sched_op rfkill_op;
-
-static void __rfkill_handle_global_op(enum rfkill_sched_op op)
-{
- unsigned int i;
-
- switch (op) {
- case RFKILL_GLOBAL_OP_EPO:
- rfkill_epo();
- break;
- case RFKILL_GLOBAL_OP_RESTORE:
- rfkill_restore_states();
- break;
- case RFKILL_GLOBAL_OP_UNLOCK:
- rfkill_remove_epo_lock();
- break;
- case RFKILL_GLOBAL_OP_UNBLOCK:
- rfkill_remove_epo_lock();
- for (i = 0; i < NUM_RFKILL_TYPES; i++)
- rfkill_switch_all(i, false);
- break;
- default:
- /* memory corruption or bug, fail safely */
- rfkill_epo();
- WARN(1, "Unknown requested operation %d! "
- "rfkill Emergency Power Off activated\n",
- op);
- }
-}
-
-static void __rfkill_handle_normal_op(const enum rfkill_type type,
- const bool complement)
-{
- bool blocked;
-
- blocked = rfkill_get_global_sw_state(type);
- if (complement)
- blocked = !blocked;
-
- rfkill_switch_all(type, blocked);
-}
-
-static void rfkill_op_handler(struct work_struct *work)
-{
- unsigned int i;
- bool c;
-
- spin_lock_irq(&rfkill_op_lock);
- do {
- if (rfkill_op_pending) {
- enum rfkill_sched_op op = rfkill_op;
- rfkill_op_pending = false;
- memset(rfkill_sw_pending, 0,
- sizeof(rfkill_sw_pending));
- spin_unlock_irq(&rfkill_op_lock);
-
- __rfkill_handle_global_op(op);
-
- spin_lock_irq(&rfkill_op_lock);
-
- /*
- * handle global ops first -- during unlocked period
- * we might have gotten a new global op.
- */
- if (rfkill_op_pending)
- continue;
- }
-
- if (rfkill_is_epo_lock_active())
- continue;
-
- for (i = 0; i < NUM_RFKILL_TYPES; i++) {
- if (__test_and_clear_bit(i, rfkill_sw_pending)) {
- c = __test_and_clear_bit(i, rfkill_sw_state);
- spin_unlock_irq(&rfkill_op_lock);
-
- __rfkill_handle_normal_op(i, c);
-
- spin_lock_irq(&rfkill_op_lock);
- }
- }
- } while (rfkill_op_pending);
- spin_unlock_irq(&rfkill_op_lock);
-}
-
-static DECLARE_DELAYED_WORK(rfkill_op_work, rfkill_op_handler);
-static unsigned long rfkill_last_scheduled;
-
-static unsigned long rfkill_ratelimit(const unsigned long last)
-{
- const unsigned long delay = msecs_to_jiffies(RFKILL_OPS_DELAY);
- return time_after(jiffies, last + delay) ? 0 : delay;
-}
-
-static void rfkill_schedule_ratelimited(void)
-{
- if (delayed_work_pending(&rfkill_op_work))
- return;
- schedule_delayed_work(&rfkill_op_work,
- rfkill_ratelimit(rfkill_last_scheduled));
- rfkill_last_scheduled = jiffies;
-}
-
-static void rfkill_schedule_global_op(enum rfkill_sched_op op)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&rfkill_op_lock, flags);
- rfkill_op = op;
- rfkill_op_pending = true;
- if (op == RFKILL_GLOBAL_OP_EPO && !rfkill_is_epo_lock_active()) {
- /* bypass the limiter for EPO */
- cancel_delayed_work(&rfkill_op_work);
- schedule_delayed_work(&rfkill_op_work, 0);
- rfkill_last_scheduled = jiffies;
- } else
- rfkill_schedule_ratelimited();
- spin_unlock_irqrestore(&rfkill_op_lock, flags);
-}
-
-static void rfkill_schedule_toggle(enum rfkill_type type)
-{
- unsigned long flags;
-
- if (rfkill_is_epo_lock_active())
- return;
-
- spin_lock_irqsave(&rfkill_op_lock, flags);
- if (!rfkill_op_pending) {
- __set_bit(type, rfkill_sw_pending);
- __change_bit(type, rfkill_sw_state);
- rfkill_schedule_ratelimited();
- }
- spin_unlock_irqrestore(&rfkill_op_lock, flags);
-}
-
-static void rfkill_schedule_evsw_rfkillall(int state)
-{
- if (state)
- rfkill_schedule_global_op(rfkill_master_switch_op);
- else
- rfkill_schedule_global_op(RFKILL_GLOBAL_OP_EPO);
-}
-
-static void rfkill_event(struct input_handle *handle, unsigned int type,
- unsigned int code, int data)
-{
- if (type == EV_KEY && data == 1) {
- switch (code) {
- case KEY_WLAN:
- rfkill_schedule_toggle(RFKILL_TYPE_WLAN);
- break;
- case KEY_BLUETOOTH:
- rfkill_schedule_toggle(RFKILL_TYPE_BLUETOOTH);
- break;
- case KEY_UWB:
- rfkill_schedule_toggle(RFKILL_TYPE_UWB);
- break;
- case KEY_WIMAX:
- rfkill_schedule_toggle(RFKILL_TYPE_WIMAX);
- break;
- case KEY_RFKILL:
- rfkill_schedule_toggle(RFKILL_TYPE_ALL);
- break;
- }
- } else if (type == EV_SW && code == SW_RFKILL_ALL)
- rfkill_schedule_evsw_rfkillall(data);
-}
-
-static int rfkill_connect(struct input_handler *handler, struct input_dev *dev,
- const struct input_device_id *id)
-{
- struct input_handle *handle;
- int error;
-
- handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
- if (!handle)
- return -ENOMEM;
-
- handle->dev = dev;
- handle->handler = handler;
- handle->name = "rfkill";
-
- /* causes rfkill_start() to be called */
- error = input_register_handle(handle);
- if (error)
- goto err_free_handle;
-
- error = input_open_device(handle);
- if (error)
- goto err_unregister_handle;
-
- return 0;
-
- err_unregister_handle:
- input_unregister_handle(handle);
- err_free_handle:
- kfree(handle);
- return error;
-}
-
-static void rfkill_start(struct input_handle *handle)
-{
- /*
- * Take event_lock to guard against configuration changes, we
- * should be able to deal with concurrency with rfkill_event()
- * just fine (which event_lock will also avoid).
- */
- spin_lock_irq(&handle->dev->event_lock);
-
- if (test_bit(EV_SW, handle->dev->evbit) &&
- test_bit(SW_RFKILL_ALL, handle->dev->swbit))
- rfkill_schedule_evsw_rfkillall(test_bit(SW_RFKILL_ALL,
- handle->dev->sw));
-
- spin_unlock_irq(&handle->dev->event_lock);
-}
-
-static void rfkill_disconnect(struct input_handle *handle)
-{
- input_close_device(handle);
- input_unregister_handle(handle);
- kfree(handle);
-}
-
-static const struct input_device_id rfkill_ids[] = {
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_WLAN)] = BIT_MASK(KEY_WLAN) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_BLUETOOTH)] = BIT_MASK(KEY_BLUETOOTH) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_UWB)] = BIT_MASK(KEY_UWB) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_WIMAX)] = BIT_MASK(KEY_WIMAX) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_KEYBIT,
- .evbit = { BIT_MASK(EV_KEY) },
- .keybit = { [BIT_WORD(KEY_RFKILL)] = BIT_MASK(KEY_RFKILL) },
- },
- {
- .flags = INPUT_DEVICE_ID_MATCH_EVBIT | INPUT_DEVICE_ID_MATCH_SWBIT,
- .evbit = { BIT(EV_SW) },
- .swbit = { [BIT_WORD(SW_RFKILL_ALL)] = BIT_MASK(SW_RFKILL_ALL) },
- },
- { }
-};
-
-static struct input_handler rfkill_handler = {
- .name = "rfkill",
- .event = rfkill_event,
- .connect = rfkill_connect,
- .start = rfkill_start,
- .disconnect = rfkill_disconnect,
- .id_table = rfkill_ids,
-};
-
-int __init rfkill_handler_init(void)
-{
- switch (rfkill_master_switch_mode) {
- case RFKILL_INPUT_MASTER_UNBLOCKALL:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_UNBLOCK;
- break;
- case RFKILL_INPUT_MASTER_RESTORE:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_RESTORE;
- break;
- case RFKILL_INPUT_MASTER_UNLOCK:
- rfkill_master_switch_op = RFKILL_GLOBAL_OP_UNLOCK;
- break;
- default:
- return -EINVAL;
- }
-
- spin_lock_init(&rfkill_op_lock);
-
- /* Avoid delay at first schedule */
- rfkill_last_scheduled =
- jiffies - msecs_to_jiffies(RFKILL_OPS_DELAY) - 1;
- return input_register_handler(&rfkill_handler);
-}
-
-void __exit rfkill_handler_exit(void)
-{
- input_unregister_handler(&rfkill_handler);
- cancel_delayed_work_sync(&rfkill_op_work);
-}
^ permalink raw reply related
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 10:43 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516094821.GA9427@redhat.com>
On Mon, May 16, 2011 at 12:48:21PM +0300, Michael S. Tsirkin wrote:
>
> Both bridge and tun trigger the messages ATM. I note that
> dev.c takes pains to avoid these messages:
> Avoid warning from netdev_fix_features() for GSO without SG
>
> Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
> If we start doing this, this spills info about flag dependencies out to drivers.
Drivers don't need to do this at all since the network stack
will automatically clear SG and related features if checksum
is disabled.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 9:48 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516093822.GA2779@gondor.apana.org.au>
On Mon, May 16, 2011 at 07:38:22PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
> >
> > There's no interface for userspace to enable it: userspace
> > only has an ioctl to enable/disable checksum offloading.
> > SG is an implementation detail.
>
> Yes there is: ethtool -K
>
> Cheers,
Ok. You are right of course, I was confused.
So it's just an info message: in the end if userspace DTRT features
get enabled properly. Functionally, there is no regression.
Both bridge and tun trigger the messages ATM. I note that
dev.c takes pains to avoid these messages:
Avoid warning from netdev_fix_features() for GSO without SG
Should all drivers do this: clear _SG if they clear checksum? What about _GSO?
If we start doing this, this spills info about flag dependencies out to drivers.
--
MST
^ permalink raw reply
* several packets in a single buffer in Rx
From: Emmanuel Grumbach @ 2011-05-16 9:41 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Johannes Berg, Guy, Wey-Yi, guy.cohen-ral2JQCrhuEAvxtiuMwx3w
Hi,
I am trying to enable a HW feature on a wireless NIC that allows the
HW to put several packets in the same Rx buffer coming from the NIC.
This can save interrupts and traffic on the bus.
Today, the driver allocates pages in which the PCI-e device puts its
data. Then we create an skb and add a fragment that points to the
beginning of the page. The offset of the fragment is set to the offset
of the first byte of the mac header within the buffer. There is only
one packet per page / buffer.
I would like to be able to deliver the same page several times to the
stack without having the stack consume it before the last time I
deliver it.
Of course I would like to avoid cloning it.
I tried to look at shinfo->nr_frags but this looks more like a sgl
related variable
GRO doesn't seem to be related either since as far as I understood, it
is relevant for packets after 802.11 to 802.3 translation.
FWIW: I am talking about Intel's wireless device although I don't
think this fact matters
Thanks
Emmanuel Grumbach
egrumbach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Herbert Xu @ 2011-05-16 9:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516081841.GA8073@redhat.com>
On Mon, May 16, 2011 at 11:18:41AM +0300, Michael S. Tsirkin wrote:
>
> There's no interface for userspace to enable it: userspace
> only has an ioctl to enable/disable checksum offloading.
> SG is an implementation detail.
Yes there is: ethtool -K
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Kernel 2.6.38.6 page allocation failure (ixgbe)
From: Stefan Majer @ 2011-05-16 8:28 UTC (permalink / raw)
To: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel
In-Reply-To: <F169D4F5E1F1974DBFAFABF47F60C10AF23DC8FF@orsmsx507.amr.corp.intel.com>
Hi,
after enlarging vm.min_free_kbytes to 524288 we survived almost a
week, but today i got this again:
May 16 09:18:13 os03 kernel: [331036.332001] kworker/0:1: page
allocation failure. order:2, mode:0x4020
May 16 09:18:13 os03 kernel: [331036.332005] Pid: 0, comm: kworker/0:1
Tainted: P W 2.6.38.6-1.fits.3.el6.x86_64 #1
May 16 09:18:13 os03 kernel: [331036.332009] Call Trace:
May 16 09:18:13 os03 kernel: [331036.332011] <IRQ>
[<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
May 16 09:18:13 os03 kernel: [331036.332024] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 16 09:18:13 os03 kernel: [331036.332028] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 16 09:18:13 os03 kernel: [331036.332033] [<ffffffff814b06ed>] ?
ip_rcv+0x23d/0x310
May 16 09:18:13 os03 kernel: [331036.332038] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 16 09:18:13 os03 kernel: [331036.332042] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 16 09:18:13 os03 kernel: [331036.332045] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 16 09:18:13 os03 kernel: [331036.332054] [<ffffffffa0170217>] ?
ixgbe_alloc_rx_buffers+0x2b7/0x370 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332059] [<ffffffff8108d29d>] ?
sched_clock_cpu+0xcd/0x110
May 16 09:18:13 os03 kernel: [331036.332063] [<ffffffff81474840>] ?
napi_skb_finish+0x50/0x70
May 16 09:18:13 os03 kernel: [331036.332069] [<ffffffffa0172678>] ?
ixgbe_clean_rx_irq+0x828/0x890 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332076] [<ffffffffa01747cf>] ?
ixgbe_clean_rxtx_many+0x10f/0x220 [ixgbe]
May 16 09:18:13 os03 kernel: [331036.332080] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 16 09:18:13 os03 kernel: [331036.332084] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 16 09:18:13 os03 kernel: [331036.332089] [<ffffffff810c7ca4>] ?
handle_IRQ_event+0x54/0x180
May 16 09:18:13 os03 kernel: [331036.332094] [<ffffffff8100cf3c>] ?
call_softirq+0x1c/0x30
May 16 09:18:13 os03 kernel: [331036.332097] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 16 09:18:13 os03 kernel: [331036.332100] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 16 09:18:13 os03 kernel: [331036.332105] [<ffffffff8154a276>] ?
do_IRQ+0x66/0xe0
May 16 09:18:13 os03 kernel: [331036.332108] [<ffffffff81542a53>] ?
ret_from_intr+0x0/0x15
May 16 09:18:13 os03 kernel: [331036.332110] <EOI>
[<ffffffff812db311>] ? intel_idle+0xc1/0x120
May 16 09:18:13 os03 kernel: [331036.332116] [<ffffffff812db2f4>] ?
intel_idle+0xa4/0x120
May 16 09:18:13 os03 kernel: [331036.332121] [<ffffffff8143bca5>] ?
cpuidle_idle_call+0xb5/0x240
May 16 09:18:13 os03 kernel: [331036.332125] [<ffffffff8100aa87>] ?
cpu_idle+0xb7/0x110
May 16 09:18:13 os03 kernel: [331036.332129] [<ffffffff81538ffe>] ?
start_secondary+0x21f/0x221
May 16 09:18:13 os03 kernel: [331036.332131] Mem-Info:
May 16 09:18:13 os03 kernel: [331036.332132] Node 0 DMA per-cpu:
May 16 09:18:13 os03 kernel: [331036.332135] CPU 0: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332137] CPU 1: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332140] CPU 2: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332142] CPU 3: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332144] CPU 4: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332146] CPU 5: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332148] CPU 6: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332150] CPU 7: hi: 0, btch:
1 usd: 0
May 16 09:18:13 os03 kernel: [331036.332152] Node 0 DMA32 per-cpu:
May 16 09:18:13 os03 kernel: [331036.332155] CPU 0: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332157] CPU 1: hi: 186, btch:
31 usd: 31
May 16 09:18:13 os03 kernel: [331036.332159] CPU 2: hi: 186, btch:
31 usd: 182
May 16 09:18:13 os03 kernel: [331036.332162] CPU 3: hi: 186, btch:
31 usd: 37
May 16 09:18:13 os03 kernel: [331036.332164] CPU 4: hi: 186, btch:
31 usd: 13
May 16 09:18:13 os03 kernel: [331036.332166] CPU 5: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332168] CPU 6: hi: 186, btch:
31 usd: 159
May 16 09:18:13 os03 kernel: [331036.332170] CPU 7: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332172] Node 0 Normal per-cpu:
May 16 09:18:13 os03 kernel: [331036.332174] CPU 0: hi: 186, btch:
31 usd: 156
May 16 09:18:13 os03 kernel: [331036.332177] CPU 1: hi: 186, btch:
31 usd: 160
May 16 09:18:13 os03 kernel: [331036.332179] CPU 2: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332181] CPU 3: hi: 186, btch:
31 usd: 168
May 16 09:18:13 os03 kernel: [331036.332183] CPU 4: hi: 186, btch:
31 usd: 163
May 16 09:18:13 os03 kernel: [331036.332185] CPU 5: hi: 186, btch:
31 usd: 180
May 16 09:18:13 os03 kernel: [331036.332187] CPU 6: hi: 186, btch:
31 usd: 156
May 16 09:18:13 os03 kernel: [331036.332189] CPU 7: hi: 186, btch:
31 usd: 182
May 16 09:18:13 os03 kernel: [331036.332195] active_anon:389538
inactive_anon:91572 isolated_anon:0
May 16 09:18:13 os03 kernel: [331036.332196] active_file:2597361
inactive_file:2476894 isolated_file:0
May 16 09:18:13 os03 kernel: [331036.332198] unevictable:123699
dirty:66164 writeback:11426 unstable:0
May 16 09:18:13 os03 kernel: [331036.332199] free:254614
slab_reclaimable:53393 slab_unreclaimable:15304
May 16 09:18:13 os03 kernel: [331036.332201] mapped:1251 shmem:91580
pagetables:1404 bounce:0
May 16 09:18:13 os03 kernel: [331036.332203] Node 0 DMA free:15852kB
min:328kB low:408kB high:492kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15660kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 16 09:18:13 os03 kernel: [331036.332214] lowmem_reserve[]: 0 2991
24201 24201
May 16 09:18:13 os03 kernel: [331036.332217] Node 0 DMA32
free:426948kB min:64764kB low:80952kB high:97144kB
active_anon:135484kB inactive_anon:0kB active_file:1133516kB
inactive_file:1093352kB unevictable:49788kB isolated(anon):0kB
isolated(file):0kB present:3063392kB mlocked:0kB dirty:110436kB
writeback:284kB mapped:432kB shmem:0kB slab_reclaimable:46680kB
slab_unreclaimable:5268kB kernel_stack:152kB pagetables:324kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
May 16 09:18:13 os03 kernel: [331036.332229] lowmem_reserve[]: 0 0 21210 21210
May 16 09:18:13 os03 kernel: [331036.332232] Node 0 Normal
free:575656kB min:459188kB low:573984kB high:688780kB
active_anon:1422668kB inactive_anon:366288kB active_file:9255928kB
inactive_file:8814224kB unevictable:445008kB isolated(anon):0kB
isolated(file):0kB present:21719040kB mlocked:0kB dirty:154220kB
writeback:45420kB mapped:4572kB shmem:366320kB
slab_reclaimable:166892kB slab_unreclaimable:55948kB
kernel_stack:3928kB pagetables:5292kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
May 16 09:18:13 os03 kernel: [331036.332245] lowmem_reserve[]: 0 0 0 0
May 16 09:18:13 os03 kernel: [331036.332248] Node 0 DMA: 1*4kB 1*8kB
0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB
3*4096kB = 15852kB
May 16 09:18:13 os03 kernel: [331036.332256] Node 0 DMA32: 55808*4kB
24890*8kB 3*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 1*4096kB = 426496kB
May 16 09:18:13 os03 kernel: [331036.332264] Node 0 Normal: 142372*4kB
49*8kB 67*16kB 48*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB
0*2048kB 1*4096kB = 576648kB
May 16 09:18:13 os03 kernel: [331036.332272] 5289868 total pagecache pages
May 16 09:18:13 os03 kernel: [331036.332274] 0 pages in swap cache
Is there any way to further identify which is causing this bug? Any
help appreciated.
Greetings Stefan
On Tue, May 10, 2011 at 9:06 PM, Brandeburg, Jesse
<jesse.brandeburg@intel.com> wrote:
> Adding e1000-devel, our list for the out-of-tree ixgbe driver (the issue is reported below to be in both upstream and out-of-tree)
>
> do you have jumbo frames enabled?
>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Stefan Majer
> Sent: Tuesday, May 10, 2011 9:03 AM
> To: netdev@vger.kernel.org
> Subject: Kernel 2.6.38.6 page allocation failure (ixgbe)
>
> Hi,
>
> im running 4 nodes with ceph on top of btrfs with a dualport Intel
> X520 10Gb Ethernet Card with the latest 3.3.9 ixgbe driver.
> during benchmarks i get the following stack.
> I can easily reproduce this by simply running rados bench from a fast
> machine using this 4 nodes as ceph cluster.
> We saw this with stock ixgbe driver from 2.6.38.6 and with the latest
> 3.3.9 ixgbe.
> This kernel is tainted because we use fusion-io iodrives as journal
> devices for btrfs.
>
> Any hints to nail this down are welcome.
>
> Greetings Stefan Majer
>
> May 10 15:26:40 os02 kernel: [ 3652.485219] cosd: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485223] kswapd0: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485228] Pid: 57, comm: kswapd0
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.485230] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.485232] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.485247] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485250] cosd: page allocation
> failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.485256] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.485259] Pid: 1849, comm: cosd
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.485261] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.485264] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.485266] <IRQ>
> [<ffffffff81466f74>] ? __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485274] [<ffffffff81108ce7>] ?
> __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.485277] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485281] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485283] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485287] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.485297] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485300] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.485305] [<ffffffff812b79e0>] ?
> swiotlb_map_page+0x0/0x110
> May 10 15:26:40 os02 kernel: [ 3652.485308] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485315] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485318] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485323] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485326] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.485330] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.485336] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485341] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485344] [<ffffffff81474840>] ?
> napi_skb_finish+0x50/0x70
> May 10 15:26:40 os02 kernel: [ 3652.485348] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3652.485354] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.485357] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485360] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485364] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485367] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.485369] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485372] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485375] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485379] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3652.485383] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3652.485386] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3652.485389] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3652.485391] <EOI>
> [<ffffffff8100cf3c>] ? call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485397] [<ffffffff81110a54>] ?
> shrink_inactive_list+0x164/0x460
> May 10 15:26:40 os02 kernel: [ 3652.485400] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485404] [<ffffffff8153facc>] ?
> schedule+0x44c/0xa10
> May 10 15:26:40 os02 kernel: [ 3652.485407] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485412] [<ffffffff81109b1a>] ?
> determine_dirtyable_memory+0x1a/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485416] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3652.485419] [<ffffffff81111453>] ?
> shrink_zone+0x3d3/0x530
> May 10 15:26:40 os02 kernel: [ 3652.485422] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3652.485423] <EOI>
> [<ffffffff81074a4a>] ? del_timer_sync+0x3a/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485430] [<ffffffff812a774d>] ?
> copy_user_generic_string+0x2d/0x40
> May 10 15:26:40 os02 kernel: [ 3652.485435] [<ffffffff811054a5>] ?
> zone_watermark_ok_safe+0xb5/0xd0
> May 10 15:26:40 os02 kernel: [ 3652.485439] [<ffffffff810ff351>] ?
> iov_iter_copy_from_user_atomic+0x101/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485442] [<ffffffff81112a69>] ?
> kswapd+0x889/0xb20
> May 10 15:26:40 os02 kernel: [ 3652.485457] [<ffffffffa026c91d>] ?
> btrfs_copy_from_user+0xcd/0x130 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485460] [<ffffffff811121e0>] ?
> kswapd+0x0/0xb20
> May 10 15:26:40 os02 kernel: [ 3652.485472] [<ffffffffa026d844>] ?
> __btrfs_buffered_write+0x1a4/0x330 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485476] [<ffffffff810862b6>] ?
> kthread+0x96/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485479] [<ffffffff8117151f>] ?
> file_update_time+0x5f/0x170
> May 10 15:26:40 os02 kernel: [ 3652.485482] [<ffffffff8100ce44>] ?
> kernel_thread_helper+0x4/0x10
> May 10 15:26:40 os02 kernel: [ 3652.485493] [<ffffffffa026dc08>] ?
> btrfs_file_aio_write+0x238/0x4e0 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485496] [<ffffffff81086220>] ?
> kthread+0x0/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.485507] [<ffffffffa026d9d0>] ?
> btrfs_file_aio_write+0x0/0x4e0 [btrfs]
> May 10 15:26:40 os02 kernel: [ 3652.485511] [<ffffffff8100ce40>] ?
> kernel_thread_helper+0x0/0x10
> May 10 15:26:40 os02 kernel: [ 3652.485515] [<ffffffff81158ff3>] ?
> do_sync_readv_writev+0xd3/0x110
> May 10 15:26:40 os02 kernel: [ 3652.485516] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.485519] [<ffffffff81163d42>] ?
> path_put+0x22/0x30
> May 10 15:26:40 os02 kernel: [ 3652.485521] Node 0 DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485525] [<ffffffff812584a3>] ?
> selinux_file_permission+0xf3/0x150
> May 10 15:26:40 os02 kernel: [ 3652.485528] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485530] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485534] [<ffffffff81251583>] ?
> security_file_permission+0x23/0x90
> May 10 15:26:40 os02 kernel: [ 3652.485535] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485538] CPU 3: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485542] [<ffffffff81159f14>] ?
> do_readv_writev+0xd4/0x1e0
> May 10 15:26:40 os02 kernel: [ 3652.485544] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485547] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485550] [<ffffffff81540d91>] ?
> mutex_lock+0x31/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485552] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485554] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485557] [<ffffffff8115a066>] ?
> vfs_writev+0x46/0x60
> May 10 15:26:40 os02 kernel: [ 3652.485558] Node 0 DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485562] [<ffffffff8115a1a1>] ?
> sys_writev+0x51/0xc0
> May 10 15:26:40 os02 kernel: [ 3652.485564] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.485567] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.485571] [<ffffffff8100c002>] ?
> system_call_fastpath+0x16/0x1b
> May 10 15:26:40 os02 kernel: [ 3652.485573] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485574] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.485576] CPU 3: hi: 186, btch:
> 31 usd: 171
> May 10 15:26:40 os02 kernel: [ 3652.485578] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.485581] DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485582] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.485585] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485587] CPU 6: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485589] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485591] CPU 7: hi: 186, btch:
> 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.485593] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485594] Node 0 CPU 3: hi: 0,
> btch: 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485597] Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485598] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485600] CPU 0: hi: 186, btch:
> 31 usd: 100
> May 10 15:26:40 os02 kernel: [ 3652.485602] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485604] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.485606] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485608] CPU 2: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485610] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.485612] CPU 3: hi: 186, btch:
> 31 usd: 140
> May 10 15:26:40 os02 kernel: [ 3652.485614] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.485617] DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485618] CPU 5: hi: 186, btch:
> 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.485621] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.485623] CPU 6: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485625] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.485627] CPU 7: hi: 186, btch:
> 31 usd: 68
> May 10 15:26:40 os02 kernel: [ 3652.485629] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485634] active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.485636] active_file:420093
> inactive_file:5180559 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.485637] unevictable:50582
> dirty:314034 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.485639] free:30074
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.485641] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.485643] CPU 3: hi: 186, btch:
> 31 usd: 171
> May 10 15:26:40 os02 kernel: [ 3652.485644] Node 0 CPU 4: hi: 186,
> btch: 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.485652] DMA free:15852kB min:12kB
> low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB
> inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB present:15660kB mlocked:0kB dirty:0kB writeback:0kB
> mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
> kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB
> writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> May 10 15:26:40 os02 kernel: [ 3652.485659] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.485661] lowmem_reserve[]:CPU 6:
> hi: 186, btch: 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.485663] 0CPU 7: hi: 186,
> btch: 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.485665] 2991Node 0 24201Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.485668] 24201CPU 0: hi: 186,
> btch: 31 usd: 100
> May 10 15:26:40 os02 kernel: [ 3652.485671]
> May 10 15:26:40 os02 kernel: [ 3652.485672] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.485674] Node 0 CPU 2: hi: 186,
> btch: 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485682] DMA32 free:85748kB
> min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485690] CPU 3: hi: 186, btch:
> 31 usd: 140
> May 10 15:26:40 os02 kernel: [ 3652.485691] lowmem_reserve[]:CPU 4:
> hi: 186, btch: 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.485693] 0CPU 5: hi: 186,
> btch: 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.485696] 0CPU 6: hi: 186,
> btch: 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.485698] 21210CPU 7: hi: 186,
> btch: 31 usd: 68
> May 10 15:26:40 os02 kernel: [ 3652.485701] 21210active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.485705] active_file:420093
> inactive_file:5180559 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.485706] unevictable:50582
> dirty:314034 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.485707] free:30074
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.485708] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.485709]
> May 10 15:26:40 os02 kernel: [ 3652.485710] Node 0 Node 0 DMA
> free:15852kB min:12kB low:12kB high:16kB active_anon:0kB
> inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
> isolated(anon):0kB isolated(file):0kB present:15660kB mlocked:0kB
> dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
> slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
> bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> May 10 15:26:40 os02 kernel: [ 3652.485724] Normal free:18696kB
> min:17440kB low:21800kB high:26160kB active_anon:1002744kB
> inactive_anon:72548kB active_file:1528784kB inactive_file:18077048kB
> unevictable:202256kB isolated(anon):0kB isolated(file):0kB
> present:21719040kB mlocked:0kB dirty:1045316kB writeback:33936kB
> mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485731]
> lowmem_reserve[]:lowmem_reserve[]: 0 0 2991 0 24201 0 24201 0
> May 10 15:26:40 os02 kernel: [ 3652.485737]
> May 10 15:26:40 os02 kernel: [ 3652.485738] Node 0 Node 0 DMA32
> free:85748kB min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485747] DMA:
> lowmem_reserve[]:1*4kB 01*8kB 00*16kB 212101*32kB 212101*64kB
> May 10 15:26:40 os02 kernel: [ 3652.485754] 1*128kB Node 0 1*256kB
> Normal free:18696kB min:17440kB low:21800kB high:26160kB
> active_anon:1002744kB inactive_anon:72548kB active_file:1528784kB
> inactive_file:18077048kB unevictable:202256kB isolated(anon):0kB
> isolated(file):0kB present:21719040kB mlocked:0kB dirty:1045316kB
> writeback:33936kB mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.485764] 0*512kB
> lowmem_reserve[]:1*1024kB 01*2048kB 03*4096kB 0= 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.485771] 0Node 0
> May 10 15:26:40 os02 kernel: [ 3652.485773] DMA32: Node 0 59*4kB DMA:
> 125*8kB 1*4kB 66*16kB 1*8kB 80*32kB 0*16kB 188*64kB 1*32kB 51*128kB
> 1*64kB 15*256kB 1*128kB 40*512kB 1*256kB 31*1024kB 0*512kB 1*2048kB
> 1*1024kB 1*4096kB 1*2048kB = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.485789] 3*4096kB Node 0 = 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.485791] Normal: Node 0 3930*4kB
> DMA32: 0*8kB 59*4kB 1*16kB 125*8kB 0*32kB 66*16kB 0*64kB 80*32kB
> 0*128kB 188*64kB 1*256kB 51*128kB 1*512kB 15*256kB 0*1024kB 40*512kB
> 1*2048kB 31*1024kB 0*4096kB 1*2048kB = 18552kB
> May 10 15:26:40 os02 kernel: [ 3652.485807] 1*4096kB 5651289 total
> pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.485809] = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.485810] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.485811] Node 0 Swap cache stats:
> add 0, delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.485814] Normal: Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485815] 3930*4kB Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485817] 0*8kB 1*16kB 0*32kB 0*64kB
> 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 18552kB
> May 10 15:26:40 os02 kernel: [ 3652.485822] 5651289 total pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.485823] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.485824] Swap cache stats: add 0,
> delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.485825] Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.485826] Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.486439] kworker/0:1: page
> allocation failure. order:2, mode:0x4020
> May 10 15:26:40 os02 kernel: [ 3652.486443] Pid: 0, comm: kworker/0:1
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3652.486446] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3652.486448] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3652.486459] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3652.486464] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3652.486468] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3652.486473] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.486476] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3652.486479] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3652.486489] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.486494] [<ffffffff81474840>] ?
> napi_skb_finish+0x50/0x70
> May 10 15:26:40 os02 kernel: [ 3652.486501] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3652.486506] [<ffffffff81013379>] ?
> sched_clock+0x9/0x10
> May 10 15:26:40 os02 kernel: [ 3652.486510] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3652.486514] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3652.486520] [<ffffffff8108aec4>] ?
> hrtimer_interrupt+0x134/0x240
> May 10 15:26:40 os02 kernel: [ 3652.486523] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3652.486526] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.486529] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3652.486533] [<ffffffff8154a360>] ?
> smp_apic_timer_interrupt+0x70/0x9b
> May 10 15:26:40 os02 kernel: [ 3652.486536] [<ffffffff8100c9f3>] ?
> apic_timer_interrupt+0x13/0x20
> May 10 15:26:40 os02 kernel: [ 3652.486538] <EOI>
> [<ffffffff812db311>] ? intel_idle+0xc1/0x120
> May 10 15:26:40 os02 kernel: [ 3652.486544] [<ffffffff812db2f4>] ?
> intel_idle+0xa4/0x120
> May 10 15:26:40 os02 kernel: [ 3652.486549] [<ffffffff8143bca5>] ?
> cpuidle_idle_call+0xb5/0x240
> May 10 15:26:40 os02 kernel: [ 3652.486554] [<ffffffff8100aa87>] ?
> cpu_idle+0xb7/0x110
> May 10 15:26:40 os02 kernel: [ 3652.486558] [<ffffffff81538ffe>] ?
> start_secondary+0x21f/0x221
> May 10 15:26:40 os02 kernel: [ 3652.486561] Mem-Info:
> May 10 15:26:40 os02 kernel: [ 3652.486562] Node 0 DMA per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486564] CPU 0: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486567] CPU 1: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486569] CPU 2: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486571] CPU 3: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486573] CPU 4: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486575] CPU 5: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486578] CPU 6: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486580] CPU 7: hi: 0, btch:
> 1 usd: 0
> May 10 15:26:40 os02 kernel: [ 3652.486581] Node 0 DMA32 per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486584] CPU 0: hi: 186, btch:
> 31 usd: 144
> May 10 15:26:40 os02 kernel: [ 3652.486586] CPU 1: hi: 186, btch:
> 31 usd: 198
> May 10 15:26:40 os02 kernel: [ 3652.486588] CPU 2: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.486590] CPU 3: hi: 186, btch:
> 31 usd: 172
> May 10 15:26:40 os02 kernel: [ 3652.486593] CPU 4: hi: 186, btch:
> 31 usd: 159
> May 10 15:26:40 os02 kernel: [ 3652.486595] CPU 5: hi: 186, btch:
> 31 usd: 69
> May 10 15:26:40 os02 kernel: [ 3652.486597] CPU 6: hi: 186, btch:
> 31 usd: 180
> May 10 15:26:40 os02 kernel: [ 3652.486599] CPU 7: hi: 186, btch:
> 31 usd: 184
> May 10 15:26:40 os02 kernel: [ 3652.486601] Node 0 Normal per-cpu:
> May 10 15:26:40 os02 kernel: [ 3652.486603] CPU 0: hi: 186, btch:
> 31 usd: 162
> May 10 15:26:40 os02 kernel: [ 3652.486605] CPU 1: hi: 186, btch:
> 31 usd: 47
> May 10 15:26:40 os02 kernel: [ 3652.486608] CPU 2: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.486610] CPU 3: hi: 186, btch:
> 31 usd: 141
> May 10 15:26:40 os02 kernel: [ 3652.486612] CPU 4: hi: 186, btch:
> 31 usd: 177
> May 10 15:26:40 os02 kernel: [ 3652.486614] CPU 5: hi: 186, btch:
> 31 usd: 77
> May 10 15:26:40 os02 kernel: [ 3652.486616] CPU 6: hi: 186, btch:
> 31 usd: 168
> May 10 15:26:40 os02 kernel: [ 3652.486618] CPU 7: hi: 186, btch:
> 31 usd: 174
> May 10 15:26:40 os02 kernel: [ 3652.486624] active_anon:255806
> inactive_anon:19454 isolated_anon:0
> May 10 15:26:40 os02 kernel: [ 3652.486625] active_file:420093
> inactive_file:5180745 isolated_file:0
> May 10 15:26:40 os02 kernel: [ 3652.486627] unevictable:50582
> dirty:314470 writeback:8484 unstable:0
> May 10 15:26:40 os02 kernel: [ 3652.486628] free:29795
> slab_reclaimable:35739 slab_unreclaimable:13526
> May 10 15:26:40 os02 kernel: [ 3652.486629] mapped:3440 shmem:51
> pagetables:1342 bounce:0
> May 10 15:26:40 os02 kernel: [ 3652.486631] Node 0 DMA free:15852kB
> min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB
> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> isolated(file):0kB present:15660kB mlocked:0kB dirty:0kB writeback:0kB
> mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
> kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB
> writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
> May 10 15:26:40 os02 kernel: [ 3652.486642] lowmem_reserve[]: 0 2991 24201 24201
> May 10 15:26:40 os02 kernel: [ 3652.486645] Node 0 DMA32 free:85748kB
> min:2460kB low:3072kB high:3688kB active_anon:20480kB
> inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
> unevictable:72kB isolated(anon):0kB isolated(file):0kB
> present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
> mapped:648kB shmem:0kB slab_reclaimable:28400kB
> slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.486657] lowmem_reserve[]: 0 0 21210 21210
> May 10 15:26:40 os02 kernel: [ 3652.486660] Node 0 Normal free:17580kB
> min:17440kB low:21800kB high:26160kB active_anon:1002744kB
> inactive_anon:72548kB active_file:1528784kB inactive_file:18077792kB
> unevictable:202256kB isolated(anon):0kB isolated(file):0kB
> present:21719040kB mlocked:0kB dirty:1047060kB writeback:33936kB
> mapped:13112kB shmem:204kB slab_reclaimable:114556kB
> slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
> unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:64
> all_unreclaimable? no
> May 10 15:26:40 os02 kernel: [ 3652.486673] lowmem_reserve[]: 0 0 0 0
> May 10 15:26:40 os02 kernel: [ 3652.486675] Node 0 DMA: 1*4kB 1*8kB
> 0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB
> 3*4096kB = 15852kB
> May 10 15:26:40 os02 kernel: [ 3652.486684] Node 0 DMA32: 59*4kB
> 125*8kB 66*16kB 80*32kB 188*64kB 51*128kB 15*256kB 40*512kB 31*1024kB
> 1*2048kB 1*4096kB = 85620kB
> May 10 15:26:40 os02 kernel: [ 3652.486692] Node 0 Normal: 3705*4kB
> 12*8kB 16*16kB 4*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB
> 0*4096kB = 18180kB
> May 10 15:26:40 os02 kernel: [ 3652.486700] 5651289 total pagecache pages
> May 10 15:26:40 os02 kernel: [ 3652.486702] 0 pages in swap cache
> May 10 15:26:40 os02 kernel: [ 3652.486704] Swap cache stats: add 0,
> delete 0, find 0/0
> May 10 15:26:40 os02 kernel: [ 3652.486705] Free swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.486707] Total swap = 1048572kB
> May 10 15:26:40 os02 kernel: [ 3652.562795] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.562798] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.562799] 5429575 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.562801] 783596 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3652.651570] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.651572] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.651573] 5430055 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.651575] 782974 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3652.721553] 6291440 pages RAM
> May 10 15:26:40 os02 kernel: [ 3652.721555] 108688 pages reserved
> May 10 15:26:40 os02 kernel: [ 3652.721556] 5430961 pages shared
> May 10 15:26:40 os02 kernel: [ 3652.721557] 781496 pages non-shared
> May 10 15:26:40 os02 kernel: [ 3654.349865] Pid: 1846, comm: cosd
> Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
> May 10 15:26:40 os02 kernel: [ 3654.358792] Call Trace:
> May 10 15:26:40 os02 kernel: [ 3654.361519] <IRQ>
> [<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
> May 10 15:26:40 os02 kernel: [ 3654.369495] [<ffffffff814b0ad0>] ?
> ip_local_deliver+0x80/0x90
> May 10 15:26:40 os02 kernel: [ 3654.376005] [<ffffffff81146cd2>] ?
> kmalloc_large_node+0x62/0xb0
> May 10 15:26:40 os02 kernel: [ 3654.382703] [<ffffffff8114becb>] ?
> __kmalloc_node_track_caller+0x15b/0x1d0
> May 10 15:26:40 os02 kernel: [ 3654.390464] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3654.397163] [<ffffffff81466713>] ?
> __alloc_skb+0x83/0x170
> May 10 15:26:40 os02 kernel: [ 3654.403277] [<ffffffff81466f74>] ?
> __netdev_alloc_skb+0x24/0x50
> May 10 15:26:40 os02 kernel: [ 3654.409970] [<ffffffffa005d9aa>] ?
> ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3654.417926] [<ffffffff812b79e0>] ?
> swiotlb_map_page+0x0/0x110
> May 10 15:26:40 os02 kernel: [ 3654.424432] [<ffffffffa0060930>] ?
> ixgbe_poll+0x1140/0x1670 [ixgbe]
> May 10 15:26:40 os02 kernel: [ 3654.431518] [<ffffffff810f33eb>] ?
> perf_pmu_enable+0x2b/0x40
> May 10 15:26:40 os02 kernel: [ 3654.437924] [<ffffffff81474eb2>] ?
> net_rx_action+0x102/0x2a0
> May 10 15:26:40 os02 kernel: [ 3654.444329] [<ffffffff8106b745>] ?
> __do_softirq+0xb5/0x210
> May 10 15:26:40 os02 kernel: [ 3654.450541] [<ffffffff810c7ca4>] ?
> handle_IRQ_event+0x54/0x180
> May 10 15:26:40 os02 kernel: [ 3654.457138] [<ffffffff8106b7bd>] ?
> __do_softirq+0x12d/0x210
> May 10 15:26:40 os02 kernel: [ 3654.463446] [<ffffffff8100cf3c>] ?
> call_softirq+0x1c/0x30
> May 10 15:26:40 os02 kernel: [ 3654.469562] [<ffffffff8100e975>] ?
> do_softirq+0x65/0xa0
> May 10 15:26:40 os02 kernel: [ 3654.475484] [<ffffffff8106b605>] ?
> irq_exit+0x95/0xa0
> May 10 15:26:40 os02 kernel: [ 3654.481218] [<ffffffff8154a276>] ?
> do_IRQ+0x66/0xe0
> May 10 15:26:40 os02 kernel: [ 3654.486754] [<ffffffff81542a53>] ?
> ret_from_intr+0x0/0x15
> May 10 15:26:40 os02 kernel: [ 3654.492867] <EOI>
> [<ffffffff81286919>] ? __make_request+0x149/0x4c0
> May 10 15:26:40 os02 kernel: [ 3654.500061] [<ffffffff812868e4>] ?
> __make_request+0x114/0x4c0
> May 10 15:26:41 os02 kernel: [ 3654.506565] [<ffffffff812841bd>] ?
> generic_make_request+0x2fd/0x5e0
> May 10 15:26:41 os02 kernel: [ 3654.513649] [<ffffffff8142742b>] ?
> dm_get_live_table+0x4b/0x60
> May 10 15:26:41 os02 kernel: [ 3654.520248] [<ffffffff81427bc1>] ?
> dm_merge_bvec+0xc1/0x140
> May 10 15:26:41 os02 kernel: [ 3654.526555] [<ffffffff81284526>] ?
> submit_bio+0x86/0x110
> May 10 15:26:41 os02 kernel: [ 3654.532574] [<ffffffff8118deac>] ?
> dio_bio_submit+0xbc/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.538881] [<ffffffff8118df40>] ?
> dio_send_cur_page+0x90/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.545478] [<ffffffff8118dfd5>] ?
> submit_page_section+0x65/0x180
> May 10 15:26:41 os02 kernel: [ 3654.552370] [<ffffffff8118e918>] ?
> __blockdev_direct_IO+0x678/0xb30
> May 10 15:26:41 os02 kernel: [ 3654.559454] [<ffffffff81250eaf>] ?
> security_inode_getsecurity+0x1f/0x30
> May 10 15:26:41 os02 kernel: [ 3654.566924] [<ffffffff8118c627>] ?
> blkdev_direct_IO+0x57/0x60
> May 10 15:26:41 os02 kernel: [ 3654.573414] [<ffffffff8118b760>] ?
> blkdev_get_blocks+0x0/0xc0
> May 10 15:26:41 os02 kernel: [ 3654.579954] [<ffffffff811008f2>] ?
> generic_file_direct_write+0xc2/0x190
> May 10 15:26:41 os02 kernel: [ 3654.587424] [<ffffffff811715b6>] ?
> file_update_time+0xf6/0x170
> May 10 15:26:41 os02 kernel: [ 3654.594025] [<ffffffff811023eb>] ?
> __generic_file_aio_write+0x32b/0x460
> May 10 15:26:41 os02 kernel: [ 3654.601494] [<ffffffff8105c9e0>] ?
> wake_up_state+0x10/0x20
>
>
>
> and so on.
>
> --
> Stefan Majer
>
>
>
> --
> Stefan Majer
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Stefan Majer
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 8:28 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516080702.GA1857@gondor.apana.org.au>
On Mon, May 16, 2011 at 06:07:02PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
> >
> > So how is NETIF_F_SG supposed to be enabled then?
>
> It should either be enabled at device creation time, or whatever
> user-space entity managing the device creation should enable it
> along with checksumming and anything else applicable.
>
> > In upstream kernels userspace can disable checksum offloading then
> > re-enable and get SG set back. userspace came to depend on this
> > behaviour so I think changing this is a regression.
>
> Can you point me to the relevant code in the upstream kernel?
> I'm not aware of any automatic SG enabling for network devices
> in general when you enable checksum offloading.
>
> Cheers,
By the way with kvm we let an unpriveledged application
control netdev flags through and ioctl. It's probably
not a good idea to print out stuff on flag change
unconditionally as that will let that application
fill up the system log.
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG
From: Michael S. Tsirkin @ 2011-05-16 8:18 UTC (permalink / raw)
To: Herbert Xu; +Cc: Shan Wei, Michał Mirosław, netdev, Ben Hutchings
In-Reply-To: <20110516080702.GA1857@gondor.apana.org.au>
On Mon, May 16, 2011 at 06:07:02PM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 10:32:10AM +0300, Michael S. Tsirkin wrote:
> >
> > So how is NETIF_F_SG supposed to be enabled then?
>
> It should either be enabled at device creation time, or whatever
> user-space entity managing the device creation should enable it
> along with checksumming and anything else applicable.
There's no interface for userspace to enable it: userspace
only has an ioctl to enable/disable checksum offloading.
SG is an implementation detail.
> > In upstream kernels userspace can disable checksum offloading then
> > re-enable and get SG set back. userspace came to depend on this
> > behaviour so I think changing this is a regression.
>
> Can you point me to the relevant code in the upstream kernel?
> I'm not aware of any automatic SG enabling for network devices
> in general when you enable checksum offloading.
>
> Cheers,
I think what happens _SG is enabled at device creation time and
then upstream just keeps it on always, even when user clears
CSUM. With net-next code changed so that _SG gets cleared when CSUM
'gets cleared. But then it does not get reenabled when CSUM
gets reenabled.
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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