* [PATCH 10/26] wireless, at76c50x:: Don't needlessly test for NULL before calling release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, linux-wireless, John W. Linville
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
The release_firmware() function deals gracefully with being passed a
NULL pointer, so explicit tests before the call are rather pointless.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/wireless/at76c50x-usb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/at76c50x-usb.c b/drivers/net/wireless/at76c50x-usb.c
index 4045e5a..faa8bcb 100644
--- a/drivers/net/wireless/at76c50x-usb.c
+++ b/drivers/net/wireless/at76c50x-usb.c
@@ -2512,10 +2512,8 @@ static void __exit at76_mod_exit(void)
printk(KERN_INFO DRIVER_DESC " " DRIVER_VERSION " unloading\n");
usb_deregister(&at76_driver);
- for (i = 0; i < ARRAY_SIZE(firmwares); i++) {
- if (firmwares[i].fw)
- release_firmware(firmwares[i].fw);
- }
+ for (i = 0; i < ARRAY_SIZE(firmwares); i++)
+ release_firmware(firmwares[i].fw);
led_trigger_unregister_simple(ledtrig_tx);
}
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 09/26] tehuti: delete redundant NULL check before release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, Andy Gospodarek
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
release_firmware() checks for NULL pointers - no need to test before
the call.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/tehuti/tehuti.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/tehuti/tehuti.c b/drivers/net/ethernet/tehuti/tehuti.c
index ad973ff..a445e77 100644
--- a/drivers/net/ethernet/tehuti/tehuti.c
+++ b/drivers/net/ethernet/tehuti/tehuti.c
@@ -341,8 +341,8 @@ static int bdx_fw_load(struct bdx_priv *priv)
out:
if (master)
WRITE_REG(priv, regINIT_SEMAPHORE, 1);
- if (fw)
- release_firmware(fw);
+
+ release_firmware(fw);
if (rc) {
netdev_err(priv->ndev, "firmware loading failed\n");
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 08/26] qlogic, qlcnic: get rid of redundant test for NULL before a call to release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel
Cc: trivial, netdev, linux-driver, Sony Chacko, Anirban Chakraborty
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
Since release_firmware() deals gracefully with being passed a NULL
pointer there's no reason to test explicitly before calling the
function.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index d32cf0d..799fd40 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1321,8 +1321,7 @@ next:
void
qlcnic_release_firmware(struct qlcnic_adapter *adapter)
{
- if (adapter->fw)
- release_firmware(adapter->fw);
+ release_firmware(adapter->fw);
adapter->fw = NULL;
}
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 07/26] qlogic, netxen: get rid of a redundant test for NULL before call to release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, Rajesh Borundia, Sony Chacko
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
Since release_firmware() deals gracefully with being passed a NULL
pointer there is no reason to test explicitly before calling the
function.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 718b274..1fb149c 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1261,8 +1261,7 @@ next:
void
netxen_release_firmware(struct netxen_adapter *adapter)
{
- if (adapter->fw)
- release_firmware(adapter->fw);
+ release_firmware(adapter->fw);
adapter->fw = NULL;
}
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 06/26] bna: remove redundant NULL test before release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, Rasesh Mody
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
release_firmware() does its own NULL test so explicit test before call
is unneeded.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/brocade/bna/bnad.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index ff78f77..d86390c 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3546,9 +3546,7 @@ static void __exit
bnad_module_exit(void)
{
pci_unregister_driver(&bnad_pci_driver);
-
- if (bfi_fw)
- release_firmware(bfi_fw);
+ release_firmware(bfi_fw);
}
module_init(bnad_module_init);
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 05/26] tg3: remove redundant NULL test before release_firmware() call
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, Michael Chan, Matt Carlson
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
There is no need to test for a NULL pointer before calling
release_firmware - the function does that on its own.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/broadcom/tg3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index 062ac33..9fbf73e 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -15842,8 +15842,7 @@ static void __devexit tg3_remove_one(struct pci_dev *pdev)
if (dev) {
struct tg3 *tp = netdev_priv(dev);
- if (tp->fw)
- release_firmware(tp->fw);
+ release_firmware(tp->fw);
tg3_reset_task_cancel(tp);
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 04/26] typhoon: get rid of redundant conditional before all to release_firmware()
From: Jesper Juhl @ 2012-04-09 20:50 UTC (permalink / raw)
To: linux-kernel; +Cc: trivial, netdev, David Dillow
In-Reply-To: <alpine.LNX.2.00.1204092157340.13925@swampdragon.chaosbits.net>
There's no need to test for a NULL pointer before calling
release_firmware() since the function does that check itself, so
remove the redundant test.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/net/ethernet/3com/typhoon.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
index 1234a14..b153666 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2549,8 +2549,7 @@ typhoon_init(void)
static void __exit
typhoon_cleanup(void)
{
- if (typhoon_fw)
- release_firmware(typhoon_fw);
+ release_firmware(typhoon_fw);
pci_unregister_driver(&typhoon_driver);
}
--
1.7.10
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [PATCH v17 15/15] Documentation: prctl/seccomp_filter
From: Markus Gutschke @ 2012-04-09 20:47 UTC (permalink / raw)
To: Will Drewry
Cc: Andrew Morton, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, indan, pmoore, corbet, eric.dumazet, coreyb,
keescook, jmorris
In-Reply-To: <CABqD9haT5h-7LMkbGSaQbnk8SJj9L21GT61UZCMVWLJCTw9OBg@mail.gmail.com>
No matter what you do, please leave the samples accessible somewhere.
They proved incredibly useful in figuring out how the API works. I am
sure, other developers are going to appreciate them as well.
Alternatively, if you don't want to include the samples with the
kernel sources, figure out how you can include a sample in the
official manual page for prctl().
Markus
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-09 20:39 UTC (permalink / raw)
To: Glauber Costa
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, Li Zefan, Johannes Weiner,
Michal Hocko, Balbir Singh
In-Reply-To: <4F83442C.8040006-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Hello, Glauber.
On Mon, Apr 09, 2012 at 05:18:52PM -0300, Glauber Costa wrote:
> After debugging this a bit, I found most of it not to be a problem.
> Unless I am *very* wrong (and I both read and tested stuff), mount
> operations do not recreate the root cgroup. So stuff like the hotcpu
> notifier, etc, won't be a problem.
Ooh, right, root css is created during subsys init. Please note that
the kernel will panic on subsys init failure (hmm....).
> Now, you are definitely correct in pointing out that we start
> leaking stuff now - my bad.
>
> But I guess I can then bundle it in a new submission, after
> shuffling around stuff a bit. It is really not a bug now, so no
> reason to route it separately.
Sure, just make it a separate patch. As long as memcg ppl are fine
with it, I can route the patches together.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH net-next] rtnetlink: fix spelling errors
From: Stephen Hemminger @ 2012-04-09 20:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Minor spelling mistakes.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/rtnetlink.h 2012-02-27 08:43:02.400935781 -0800
+++ b/include/net/rtnetlink.h 2012-04-09 13:24:02.705034830 -0700
@@ -41,7 +41,7 @@ static inline int rtnl_msg_family(const
* @get_size: Function to calculate required room for dumping device
* specific netlink attributes
* @fill_info: Function to dump device specific netlink attributes
- * @get_xstats_size: Function to calculate required room for dumping devic
+ * @get_xstats_size: Function to calculate required room for dumping device
* specific statistics
* @fill_xstats: Function to dump device specific statistics
*/
@@ -94,7 +94,7 @@ extern void rtnl_link_unregister(struct
* @fill_link_af: Function to fill IFLA_AF_SPEC with address family
* specific netlink attributes.
* @get_link_af_size: Function to calculate size of address family specific
- * netlink attributes exlusive the container attribute.
+ * netlink attributes exclusive the container attribute.
* @validate_link_af: Validate a IFLA_AF_SPEC attribute, must check attr
* for invalid configuration settings.
* @set_link_af: Function to parse a IFLA_AF_SPEC attribute and modify
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Glauber Costa @ 2012-04-09 20:18 UTC (permalink / raw)
To: Tejun Heo
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A, Li Zefan, Johannes Weiner,
Michal Hocko, Balbir Singh
In-Reply-To: <20120409181331.GD7522-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On 04/09/2012 03:13 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 09, 2012 at 02:51:10PM -0300, Glauber Costa wrote:
>> On 04/09/2012 02:40 PM, Tejun Heo wrote:
>>> which BTW seems incorrect even on its
>>> own - unmounting and mounting again would probably make the same
>>> notifier registered multiple times corrupting notification chain, and
>>> ref inc on the parent.
>>
>>
>> For the maintainers: Should I fix those in a new submission, or do
>> you intend to do it yourselves?
>>
>> the refcnt dropping should probably be done in my patch, it is a new
>> leak (sorry). The hotplug notifier, as tejun pointed, was already
>> there.
>>
>> It seems simple enough to fix, so if you guys want, I can bundle it in
>> a new submission.
>
> I think it would be best to create a separate patch which is routed
> through the usual memcg path (I suppose memcg patches go through
> -mm?).
>
> Thanks.
>
Tejun,
After debugging this a bit, I found most of it not to be a problem.
Unless I am *very* wrong (and I both read and tested stuff), mount
operations do not recreate the root cgroup. So stuff like the hotcpu
notifier, etc, won't be a problem.
Now, you are definitely correct in pointing out that we start leaking
stuff now - my bad.
But I guess I can then bundle it in a new submission, after shuffling
around stuff a bit. It is really not a bug now, so no reason to route it
separately.
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Will Drewry @ 2012-04-09 19:59 UTC (permalink / raw)
To: Indan Zupancic
Cc: Andrew Morton, linux-kernel, linux-security-module, linux-arch,
linux-doc, kernel-hardening, netdev, x86, arnd, davem, hpa, mingo,
oleg, peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn,
djm, scarybeasts, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <67e30a0c8655fc53a92e8138bba9de66.squirrel@webmail.greenhost.nl>
On Sun, Apr 8, 2012 at 1:22 PM, Indan Zupancic <indan@nul.nu> wrote:
> On Sat, April 7, 2012 06:23, Andrew Morton wrote:
>> hm, I'm surprised that we don't have a zero-returning implementation of
>> is_compat_task() when CONFIG_COMPAT=n. Seems silly. Blames Arnd.
>
> It's sneakily hidden at the end of compat.h.
>
>>> +/**
>>> + * get_u32 - returns a u32 offset into data
>>> + * @data: a unsigned 64 bit value
>>> + * @index: 0 or 1 to return the first or second 32-bits
>>> + *
>>> + * This inline exists to hide the length of unsigned long.
>>> + * If a 32-bit unsigned long is passed in, it will be extended
>>> + * and the top 32-bits will be 0. If it is a 64-bit unsigned
>>> + * long, then whatever data is resident will be properly returned.
>>> + */
>>> +static inline u32 get_u32(u64 data, int index)
>>> +{
>>> + return ((u32 *)&data)[index];
>>> +}
>>
>> This seems utterly broken on big-endian machines. If so: fix. If not:
>> add comment explaining why?
>
> It's not a bug, it's intentional.
>
> I tried to convince them to have a stable ABI for all archs, but they
> didn't want to make the ABI endianness independent, because it looks
> uglier. The argument being that system call numbers are arch dependent
> anyway.
>
> So a filter for a little endian arch needs to check a different offset
> than one for a big endian archs.
Awkward, but in practice it doesn't seem to matter either way --
especially since properly written filters should check the @arch which
indicates the calling convention, endianness, etc.
>>> +static u32 seccomp_run_filters(int syscall)
>>> +{
>>> + struct seccomp_filter *f;
>>> + u32 ret = SECCOMP_RET_KILL;
>>> + /*
>>> + * All filters are evaluated in order of youngest to oldest. The lowest
>>> + * BPF return value always takes priority.
>>> + */
>>
>> The youngest-first design surprised me. It wasn't mentioned at all in
>> the changelog. Thinking about it, I guess it just doesn't matter. But
>> some description of the reasons for and implications of this decision
>> for the uninitiated would be welcome.
>
> I think it's less confusing to not mention the order at all, exactly
> because it doesn't matter. It has been like this from the start, so
> that's why it's not mentioned in the changelog I guess.
Good call - I will remove that comment. The only relevant information
is that the lowest return value wins. I did add a comment up near
struct seccomp_filter with my attempt at explaining the tree
structure, but I didn't detail evaluation order. In this case, it
only is relevant because our only link to the tree is via our local
pointer which happens to be the "youngest".
> The reason to check the youngest first is because the filters are shared
> between processes: childs inherit it. If later on additional filters are
> added, the only way of adding them without modifying an older filter is
> by adding them to the head of the list. This way no locking is needed,
> because filters are only added and removed single-threadedly, and never
> modified when being shared.
I tried a handful of other strategies, but in practice this seemed to
meet the needs with the least complexity/overhead.
>>> +/**
>>> + * seccomp_attach_filter: Attaches a seccomp filter to current.
>>> + * @fprog: BPF program to install
>>> + *
>>> + * Returns 0 on success or an errno on failure.
>>> + */
>>> +static long seccomp_attach_filter(struct sock_fprog *fprog)
>>> +{
>>> + struct seccomp_filter *filter;
>>> + unsigned long fp_size = fprog->len * sizeof(struct sock_filter);
>>> + unsigned long total_insns = fprog->len;
>>> + long ret;
>>> +
>>> + if (fprog->len == 0 || fprog->len > BPF_MAXINSNS)
>>> + return -EINVAL;
>>> +
>>> + for (filter = current->seccomp.filter; filter; filter = filter->prev)
>>> + total_insns += filter->len + 4; /* include a 4 instr penalty */
>>
>> So tasks don't share filters? We copy them by value at fork? Do we do
>> this at vfork() too?
>
> Yes they do. But shared filters are never modified, except for the refcount.
>
>>
>>> + if (total_insns > MAX_INSNS_PER_PATH)
>>> + return -ENOMEM;
>>> +
>>> + /*
>>> + * Installing a seccomp filter requires that the task have
>>> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
>>> + * This avoids scenarios where unprivileged tasks can affect the
>>> + * behavior of privileged children.
>>> + */
>>> + if (!current->no_new_privs &&
>>> + security_capable_noaudit(current_cred(), current_user_ns(),
>>> + CAP_SYS_ADMIN) != 0)
>>> + return -EACCES;
>>> +
>>> + /* Allocate a new seccomp_filter */
>>> + filter = kzalloc(sizeof(struct seccomp_filter) + fp_size, GFP_KERNEL);
>>
>> I think this gives userspace an easy way of causing page allocation
>> failure warnings, by permitting large kmalloc() attempts. Add
>> __GFP_NOWARN?
>
> Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> it allocates up to 512kb before even checking the length.
>
> What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
It looks like GFP_USER|__GFP_NOWARN would make sense here. I'll change it.
>>> + /* Check and rewrite the fprog via the skb checker */
>>> + ret = sk_chk_filter(filter->insns, filter->len);
>>> + if (ret)
>>> + goto fail;
>>> +
>>> + /* Check and rewrite the fprog for seccomp use */
>>> + ret = seccomp_chk_filter(filter->insns, filter->len);
>>
>> "check" is spelled "check"!
>
> Yes, it is and he did spell "check" as "Check".
>
> seccomp_chk_filter() mirrors sk_chk_filter(). So it refers to
> "chk", not "check".
I can change it to be written out or leave it matching the networking
code. Any preferences?
Thanks!
will
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Marc MERLIN @ 2012-04-09 19:46 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120409.153452.1284163346306246866.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Apr 09, 2012 at 03:34:52PM -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Mon, 09 Apr 2012 21:11:12 +0200
>
> > I think Marc posted stack traces showing problem on transmit side.
> ...
> > I dont really understand how it can happen, with MTU=1500
>
> Depending upon the configuration and the driver, wireless can need
> more headroom. For encryption an extra 8 bytes are necessary, and the
> driver may request a variable amount of extra headroom via
> ->hw.extra_tx_headroom
>
> What wireless device are we dealing with again?
Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
Copyright(c) 2003-2011 Intel Corporation
iwlwifi 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlwifi 0000:03:00.0: setting latency timer to 64
iwlwifi 0000:03:00.0: pci_resource_len = 0x00002000
iwlwifi 0000:03:00.0: pci_resource_base = ffffc900057a4000
iwlwifi 0000:03:00.0: HW Revision ID = 0x0
iwlwifi 0000:03:00.0: irq 47 for MSI/MSI-X
iwlwifi 0000:03:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
iwlwifi 0000:03:00.0: device EEPROM VER=0x11e, CALIB=0x4
iwlwifi 0000:03:00.0: Device SKU: 0Xf0
iwlwifi 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
along with iwlwifi-5000-5.ucode
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.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: [PATCH v17 15/15] Documentation: prctl/seccomp_filter
From: Will Drewry @ 2012-04-09 19:46 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120406142644.223ffff0.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 4:26 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:02:00 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> Documents how system call filtering using Berkeley Packet
>> Filter programs works and how it may be used.
>> Includes an example for x86 and a semi-generic
>> example using a macro-based code generator.
>>
>>
>> ...
>>
>> +Adding architecture support
>> +-----------------------
>> +
>> +See arch/Kconfig for the authoritative requirements. In general, if an
>> +architecture supports both ptrace_event and seccomp, it will be able to
>> +support seccomp filter with minor fixup: SIGSYS support and seccomp return
>> +value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER
>> +to its arch-specific Kconfig.
>> diff --git a/samples/Makefile b/samples/Makefile
>> index 2f75851..5ef08bb 100644
>> --- a/samples/Makefile
>> +++ b/samples/Makefile
>
> Oh good, I was going to ask about that.
>
> Can we get this code into tools/testing/selftests? That way people
> will run it more often and it's more likely to be maintained as the
> code evolves.
I'm currently using a lightweight testsuite in addition to the
samples. It's a little more oriented at pass/fail behavior. Would it
be more appropriate to post those in addition to, or instead of,
samples?
thanks!
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH v17 09/15] seccomp: remove duplicated failure logging
From: Kees Cook @ 2012-04-09 19:39 UTC (permalink / raw)
To: Eric Paris
Cc: kernel-hardening, Andrew Morton, linux-kernel,
linux-security-module, linux-arch, linux-doc, netdev, x86, arnd,
davem, hpa, mingo, oleg, peterz, rdunlap, mcgrathr, tglx, luto,
serge.hallyn, djm, scarybeasts, indan, pmoore, corbet,
eric.dumazet, markus, coreyb, jmorris
In-Reply-To: <1333999988.14260.9.camel@localhost>
On Mon, Apr 9, 2012 at 12:33 PM, Eric Paris <eparis@redhat.com> wrote:
> On Mon, 2012-04-09 at 14:26 -0500, Will Drewry wrote:
>> On Fri, Apr 6, 2012 at 4:14 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> > On Thu, 29 Mar 2012 15:01:54 -0500
>> > Will Drewry <wad@chromium.org> wrote:
>
>> >> -void __audit_seccomp(unsigned long syscall)
>> >> +void __audit_seccomp(unsigned long syscall, long signr, int code)
>> >> {
>> >> struct audit_buffer *ab;
>> >>
>> >> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
>> >> - audit_log_abend(ab, "seccomp", SIGKILL);
>> >> + audit_log_abend(ab, "seccomp", signr);
>> >> audit_log_format(ab, " syscall=%ld", syscall);
>> >> +#ifdef CONFIG_COMPAT
>> >> + audit_log_format(ab, " compat=%d", is_compat_task());
>> >> +#endif
>> >
>> > We don't need the ifdef for compilation reasons now.
>> >
>> > The question is: should we emit the compat= record on
>> > non-compat-capable architectures? Doing so would be safer - making it
>> > conditional invites people to write x86-only usersapce.
>>
>> I'd certainly prefer it always being there for exactly that reason.
>>
>> Kees, Eric, any preferences? Unless I hear one, I'll just drop the
>> ifdefs in the next revision.
>
> I'd just leave it in unconditionally. The audit parse libraries would
> handle it just fine, but that doesn't mean everyone uses that tool to
> parse the text.
Related to this, can we get this patch into a tree as well?
https://lkml.org/lkml/2012/3/23/332
Thanks,
-Kees
--
Kees Cook
ChromeOS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v17 13/15] ptrace,seccomp: Add PTRACE_SECCOMP support
From: Will Drewry @ 2012-04-09 19:38 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120406142423.b2cb2f61.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 4:24 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:58 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP,
>> and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE.
>>
>> When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the
>> tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that
>> results in a BPF program returning SECCOMP_RET_TRACE. The 16-bit
>> SECCOMP_RET_DATA mask of the BPF program return value will be passed as
>> the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG.
>>
>> If the subordinate process is not using seccomp filter, then no
>> system call notifications will occur even if the option is specified.
>>
>> If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE
>> is returned, the system call will not be executed and an -ENOSYS errno
>> will be returned to userspace.
>>
>> This change adds a dependency on the system call slow path. Any future
>> efforts to use the system call fast path for seccomp filter will need to
>> address this restriction.
>>
>>
>> ...
>>
>> @@ -410,6 +411,15 @@ int __secure_computing_int(int this_syscall)
>> /* Let the filter pass back 16 bits of data. */
>> seccomp_send_sigsys(this_syscall, data);
>> goto skip;
>> + case SECCOMP_RET_TRACE:
>> + /* Skip these calls if there is no tracer. */
>> + if (!ptrace_event_enabled(current, PTRACE_EVENT_SECCOMP))
>> + goto skip;
>> + /* Allow the BPF to provide the event message */
>> + ptrace_event(PTRACE_EVENT_SECCOMP, data);
>> + if (fatal_signal_pending(current))
>> + break;
>
> I don't have all the patches applied here so the context is missing.
> Perhaps tht would help me understand what this fatal_signal_pending()
> test is doing here. But an explanatory comment wouldn't hurt.
I'll add a comment along the lines of my answer below!
> What *is* it here for, anyway?
The timely delivery of a fatal signal will silently block tracer event
notification. By immediately terminating if a fatal signal is
pending, we avoid accidentally executing a system call that the tracer
did not approve of.
http://lxr.linux.no/linux+v3.3.1/kernel/signal.c#L1839
I can be more verbose, but hopefully that covers it well enough - thanks!
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: David Miller @ 2012-04-09 19:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: Larry.Finger, marc, bhutchings, linux-wireless, netdev
In-Reply-To: <1333998672.3007.245.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 09 Apr 2012 21:11:12 +0200
> I think Marc posted stack traces showing problem on transmit side.
...
> I dont really understand how it can happen, with MTU=1500
Depending upon the configuration and the driver, wireless can need
more headroom. For encryption an extra 8 bytes are necessary, and the
driver may request a variable amount of extra headroom via
->hw.extra_tx_headroom
What wireless device are we dealing with again?
^ permalink raw reply
* Re: Re: [PATCH v17 09/15] seccomp: remove duplicated failure logging
From: Eric Paris @ 2012-04-09 19:33 UTC (permalink / raw)
To: kernel-hardening
Cc: Andrew Morton, Kees Cook, linux-kernel, linux-security-module,
linux-arch, linux-doc, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
jmorris
In-Reply-To: <CABqD9hZVZQXA5cyufwWirWVUYZwSkjRxHR2CBKW5V62qD-DGtA@mail.gmail.com>
On Mon, 2012-04-09 at 14:26 -0500, Will Drewry wrote:
> On Fri, Apr 6, 2012 at 4:14 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Thu, 29 Mar 2012 15:01:54 -0500
> > Will Drewry <wad@chromium.org> wrote:
> >> -void __audit_seccomp(unsigned long syscall)
> >> +void __audit_seccomp(unsigned long syscall, long signr, int code)
> >> {
> >> struct audit_buffer *ab;
> >>
> >> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
> >> - audit_log_abend(ab, "seccomp", SIGKILL);
> >> + audit_log_abend(ab, "seccomp", signr);
> >> audit_log_format(ab, " syscall=%ld", syscall);
> >> +#ifdef CONFIG_COMPAT
> >> + audit_log_format(ab, " compat=%d", is_compat_task());
> >> +#endif
> >
> > We don't need the ifdef for compilation reasons now.
> >
> > The question is: should we emit the compat= record on
> > non-compat-capable architectures? Doing so would be safer - making it
> > conditional invites people to write x86-only usersapce.
>
> I'd certainly prefer it always being there for exactly that reason.
>
> Kees, Eric, any preferences? Unless I hear one, I'll just drop the
> ifdefs in the next revision.
I'd just leave it in unconditionally. The audit parse libraries would
handle it just fine, but that doesn't mean everyone uses that tool to
parse the text.
-Eric
^ permalink raw reply
* Re: [PATCH v17 09/15] seccomp: remove duplicated failure logging
From: Kees Cook @ 2012-04-09 19:32 UTC (permalink / raw)
To: Will Drewry
Cc: Andrew Morton, Eric Paris, linux-kernel, linux-security-module,
linux-arch, linux-doc, kernel-hardening, netdev, x86, arnd, davem,
hpa, mingo, oleg, peterz, rdunlap, mcgrathr, tglx, luto,
serge.hallyn, djm, scarybeasts, indan, pmoore, corbet,
eric.dumazet, markus, coreyb, jmorris
In-Reply-To: <CABqD9hZVZQXA5cyufwWirWVUYZwSkjRxHR2CBKW5V62qD-DGtA@mail.gmail.com>
On Mon, Apr 9, 2012 at 12:26 PM, Will Drewry <wad@chromium.org> wrote:
> On Fri, Apr 6, 2012 at 4:14 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Thu, 29 Mar 2012 15:01:54 -0500
>> Will Drewry <wad@chromium.org> wrote:
>>
>>> From: Kees Cook <keescook@chromium.org>
>>>
>>> This consolidates the seccomp filter error logging path and adds more
>>> details to the audit log.
>>>
>>> ...
>>>
>>> -void __audit_seccomp(unsigned long syscall)
>>> +void __audit_seccomp(unsigned long syscall, long signr, int code)
>>> {
>>> struct audit_buffer *ab;
>>>
>>> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
>>> - audit_log_abend(ab, "seccomp", SIGKILL);
>>> + audit_log_abend(ab, "seccomp", signr);
>>> audit_log_format(ab, " syscall=%ld", syscall);
>>> +#ifdef CONFIG_COMPAT
>>> + audit_log_format(ab, " compat=%d", is_compat_task());
>>> +#endif
>>
>> We don't need the ifdef for compilation reasons now.
>>
>> The question is: should we emit the compat= record on
>> non-compat-capable architectures? Doing so would be safer - making it
>> conditional invites people to write x86-only usersapce.
>
> I'd certainly prefer it always being there for exactly that reason.
>
> Kees, Eric, any preferences? Unless I hear one, I'll just drop the
> ifdefs in the next revision.
Yeah, I'd prefer the ifdefs dropped too.
-Kees
--
Kees Cook
ChromeOS Security
^ permalink raw reply
* Re: [PATCH v17 09/15] seccomp: remove duplicated failure logging
From: Will Drewry @ 2012-04-09 19:26 UTC (permalink / raw)
To: Andrew Morton, Kees Cook, Eric Paris
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
jmorris
In-Reply-To: <20120406141415.93f46bc6.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 4:14 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:54 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Kees Cook <keescook@chromium.org>
>>
>> This consolidates the seccomp filter error logging path and adds more
>> details to the audit log.
>>
>> ...
>>
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>>
>> ...
>>
>> #define audit_inode(n,d) do { (void)(d); } while (0)
>> #define audit_inode_child(i,p) do { ; } while (0)
>> #define audit_core_dumps(i) do { ; } while (0)
>> -#define audit_seccomp(i) do { ; } while (0)
>> +#define audit_seccomp(i,s,c) do { ; } while (0)
>
> Sigh. Someone please convert all these to C. That way we get
> typechecking and don't need dopey party tricks like that "(void)(d)" to
> squish compilation warnings.
>
>> ...
>> --- a/kernel/auditsc.c
>> +++ b/kernel/auditsc.c
>> @@ -67,6 +67,7 @@
>> #include <linux/syscalls.h>
>> #include <linux/capability.h>
>> #include <linux/fs_struct.h>
>> +#include <linux/compat.h>
>>
>> #include "audit.h"
>>
>> @@ -2710,13 +2711,18 @@ void audit_core_dumps(long signr)
>> audit_log_end(ab);
>> }
>>
>> -void __audit_seccomp(unsigned long syscall)
>> +void __audit_seccomp(unsigned long syscall, long signr, int code)
>> {
>> struct audit_buffer *ab;
>>
>> ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_ANOM_ABEND);
>> - audit_log_abend(ab, "seccomp", SIGKILL);
>> + audit_log_abend(ab, "seccomp", signr);
>> audit_log_format(ab, " syscall=%ld", syscall);
>> +#ifdef CONFIG_COMPAT
>> + audit_log_format(ab, " compat=%d", is_compat_task());
>> +#endif
>
> We don't need the ifdef for compilation reasons now.
>
> The question is: should we emit the compat= record on
> non-compat-capable architectures? Doing so would be safer - making it
> conditional invites people to write x86-only usersapce.
I'd certainly prefer it always being there for exactly that reason.
Kees, Eric, any preferences? Unless I hear one, I'll just drop the
ifdefs in the next revision.
thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v17 07/15] asm/syscall.h: add syscall_get_arch
From: Will Drewry @ 2012-04-09 19:24 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120406130544.3d317192.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 3:05 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:52 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> Adds a stub for a function that will return the AUDIT_ARCH_*
>> value appropriate to the supplied task based on the system
>> call convention.
>>
>> For audit's use, the value can generally be hard-coded at the
>> audit-site. However, for other functionality not inlined into
>> syscall entry/exit, this makes that information available.
>> seccomp_filter is the first planned consumer and, as such,
>> the comment indicates a tie to HAVE_ARCH_SECCOMP_FILTER. That
>
> Should be "CONFIG_HAVE_ARCH_SECCOMP_FILTER", I hope.
yes!
>
>> is probably an unneeded detail.
>>
>> ...
>>
>> --- a/include/asm-generic/syscall.h
>> +++ b/include/asm-generic/syscall.h
>> @@ -142,4 +142,18 @@ void syscall_set_arguments(struct task_struct *task, struct pt_regs *regs,
>> unsigned int i, unsigned int n,
>> const unsigned long *args);
>>
>> +/**
>> + * syscall_get_arch - return the AUDIT_ARCH for the current system call
>> + * @task: task of interest, must be in system call entry tracing
>> + * @regs: task_pt_regs() of @task
>> + *
>> + * Returns the AUDIT_ARCH_* based on the system call convention in use.
>> + *
>> + * It's only valid to call this when @task is stopped on entry to a system
>> + * call, due to %TIF_SYSCALL_TRACE, %TIF_SYSCALL_AUDIT, or %TIF_SECCOMP.
>> + *
>> + * Note, at present this function is only required with
>> + * CONFIG_HAVE_ARCH_SECCOMP_FILTER.
>> + */
>> +int syscall_get_arch(struct task_struct *task, struct pt_regs *regs);
>> #endif /* _ASM_SYSCALL_H */
>
> So architectures which permit CONFIG_HAVE_ARCH_SECCOMP_FILTER must
> provide an implementation of this.
Much better wording.
In practice, many of the existing places that audit arch is needed
already know the calling convention because they happen in asm or have
hardcoded values. It may be that other consumers may want this
information later, like ftrace, but I'm not sure of any that will
immediately benefit from it right now.
^ permalink raw reply
* Re: [PATCH v17 10/15] seccomp: add SECCOMP_RET_ERRNO
From: Will Drewry @ 2012-04-09 19:19 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <20120406141936.25d68860.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 4:19 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:55 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> This change adds the SECCOMP_RET_ERRNO as a valid return value from a
>> seccomp filter. Additionally, it makes the first use of the lower
>> 16-bits for storing a filter-supplied errno. 16-bits is more than
>> enough for the errno-base.h calls.
>>
>> Returning errors instead of immediately terminating processes that
>> violate seccomp policy allow for broader use of this functionality
>> for kernel attack surface reduction. For example, a linux container
>> could maintain a whitelist of pre-existing system calls but drop
>> all new ones with errnos. This would keep a logically static attack
>> surface while providing errnos that may allow for graceful failure
>> without the downside of do_exit() on a bad call.
>>
>>
>> ...
>>
>> @@ -64,11 +65,17 @@ struct seccomp {
>> struct seccomp_filter *filter;
>> };
>>
>> -extern void __secure_computing(int);
>> -static inline void secure_computing(int this_syscall)
>> +/*
>> + * Direct callers to __secure_computing should be updated as
>> + * CONFIG_HAVE_ARCH_SECCOMP_FILTER propagates.
>
> Are there any such callers? There's one I see in arm, but it's called
> from assembly code.
I think just arm, but I was trying to limit the patch growth as much
as I could, practically. ARM support is relevant to my interests, and
I need to have patches out for review quite soon (once this series
settles :).
I hesitate to ask, but should I add a patch to this series for arm?
>> + */
>> +extern void __secure_computing(int) __deprecated;
>> +extern int __secure_computing_int(int);
>> +static inline int secure_computing(int this_syscall)
>> {
>> if (unlikely(test_thread_flag(TIF_SECCOMP)))
>> - __secure_computing(this_syscall);
>> + return __secure_computing_int(this_syscall);
>> + return 0;
>> }
>>
>> ...
>>
>> void __secure_computing(int this_syscall)
>> {
>> + /* Filter calls should never use this function. */
>> + BUG_ON(current->seccomp.mode == SECCOMP_MODE_FILTER);
>> + __secure_computing_int(this_syscall);
>> +}
>> +
>> +int __secure_computing_int(int this_syscall)
>
> What the heck does "_int" mean here? I read it as "integer" but
> perhaps it's shorthand for "internal". Give us a better name, please.
> Or a code comment.
It meant "returns an int", but its unclear. I definitely will add a
comment, but I'm open to better naming. Perhaps it'd make sense to
bring it inline with the other hook call styles:
/* <proper comment here> */
__secure_computing_enter(int this_syscall)
I can keep the other call as 'deprecated', and then remove it once all
the callers are updated.
I'll reply to the rest of the mails shortly - thanks!
will
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Eric Dumazet @ 2012-04-09 19:11 UTC (permalink / raw)
To: Larry Finger; +Cc: marc, David Miller, bhutchings, linux-wireless, netdev
In-Reply-To: <4F83316F.20504@lwfinger.net>
On Mon, 2012-04-09 at 13:58 -0500, Larry Finger wrote:
> As it happens with both iwlwifi and e1000e, it seems to be a problem further up
> the food chain.
>
> I don't know much about iwlwifi, but loading it with the module parameter
> "amsdu_size_8K=0" seems to select 4K rather than 8K buffers. That will hurt
> performance, but it should fix the memory fragmentation. There have also been
> some problems with aggregation that are fixed by setting the option "11n_disable=3".
I think Marc posted stack traces showing problem on transmit side.
09:44:12 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:12 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:12 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:12 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:12 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:12 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:12 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:12 [<ffffffff81070551>] ? arch_local_irq_save+0x11/0x17
09:44:12 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:12 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
I dont really understand how it can happen, with MTU=1500
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Larry Finger @ 2012-04-09 18:58 UTC (permalink / raw)
To: marc; +Cc: David Miller, bhutchings, linux-wireless, netdev
In-Reply-To: <20120409.143710.879746943062854492.davem@davemloft.net>
On 04/09/2012 01:37 PM, David Miller wrote:
> From: Marc MERLIN<marc@merlins.org>
> Date: Mon, 9 Apr 2012 11:36:32 -0700
>
>> On Mon, Apr 09, 2012 at 02:12:41PM -0400, David Miller wrote:
>>> From: Marc MERLIN<marc@merlins.org>
>>> Date: Mon, 9 Apr 2012 10:20:51 -0700
>>>
>>>> Any idea what's going on, what bucket of RAM is an issue for the driver
>>>> (total RAM is more than plenty), and where I should go from there?
>>>
>>> The wireless layer is allocating high-order pages, so it's
>>> not the amount of ram, it's the fragmentation of it leading
>>> to a lack of those high-order pages.
>>
>> I figured it was something of the sort, thanks for the professional
>> confirmation :)
>>
>> What's my next step, file a bug with a specific team?
>
> Wait patiently for a wireless developer to look into your bug.
As it happens with both iwlwifi and e1000e, it seems to be a problem further up
the food chain.
I don't know much about iwlwifi, but loading it with the module parameter
"amsdu_size_8K=0" seems to select 4K rather than 8K buffers. That will hurt
performance, but it should fix the memory fragmentation. There have also been
some problems with aggregation that are fixed by setting the option "11n_disable=3".
Larry
^ permalink raw reply
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: David Miller @ 2012-04-09 18:37 UTC (permalink / raw)
To: marc; +Cc: bhutchings, linux-wireless, netdev
In-Reply-To: <20120409183632.GO29342@merlins.org>
From: Marc MERLIN <marc@merlins.org>
Date: Mon, 9 Apr 2012 11:36:32 -0700
> On Mon, Apr 09, 2012 at 02:12:41PM -0400, David Miller wrote:
>> From: Marc MERLIN <marc@merlins.org>
>> Date: Mon, 9 Apr 2012 10:20:51 -0700
>>
>> > Any idea what's going on, what bucket of RAM is an issue for the driver
>> > (total RAM is more than plenty), and where I should go from there?
>>
>> The wireless layer is allocating high-order pages, so it's
>> not the amount of ram, it's the fragmentation of it leading
>> to a lack of those high-order pages.
>
> I figured it was something of the sort, thanks for the professional
> confirmation :)
>
> What's my next step, file a bug with a specific team?
Wait patiently for a wireless developer to look into your bug.
^ 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