* [PATCH] skbuff: struct ubuf_info callback type safety
From: Michael S. Tsirkin @ 2012-04-09 10:24 UTC (permalink / raw)
To: linux-kernel, kvm, virtualization, netdev
Cc: Shirley Ma, Stephen Hemminger, David S. Miller, Eric Dumazet,
Ian Campbell
The skb struct ubuf_info callback gets passed struct ubuf_info
itself, not the arg value as the field name and the function signature
seem to imply. Rename the arg field to ctx to match usage,
add documentation and change the callback argument type
to make usage clear and to have compiler check correctness.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/vhost/net.c | 2 +-
drivers/vhost/vhost.c | 5 ++---
drivers/vhost/vhost.h | 2 +-
include/linux/skbuff.h | 7 ++++---
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f0da2c3..1f21d2a 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -238,7 +238,7 @@ static void handle_tx(struct vhost_net *net)
vq->heads[vq->upend_idx].len = len;
ubuf->callback = vhost_zerocopy_callback;
- ubuf->arg = vq->ubufs;
+ ubuf->ctx = vq->ubufs;
ubuf->desc = vq->upend_idx;
msg.msg_control = ubuf;
msg.msg_controllen = sizeof(ubuf);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 947f00d..51e4c1e 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1598,10 +1598,9 @@ void vhost_ubuf_put_and_wait(struct vhost_ubuf_ref *ubufs)
kfree(ubufs);
}
-void vhost_zerocopy_callback(void *arg)
+void vhost_zerocopy_callback(struct ubuf_info *ubuf)
{
- struct ubuf_info *ubuf = arg;
- struct vhost_ubuf_ref *ubufs = ubuf->arg;
+ struct vhost_ubuf_ref *ubufs = ubuf->ctx;
struct vhost_virtqueue *vq = ubufs->vq;
/* set len = 1 to mark this desc buffers done DMA */
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 8dcf4cc..8de1fd5 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -188,7 +188,7 @@ bool vhost_enable_notify(struct vhost_dev *, struct vhost_virtqueue *);
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
unsigned int log_num, u64 len);
-void vhost_zerocopy_callback(void *arg);
+void vhost_zerocopy_callback(struct ubuf_info *);
int vhost_zerocopy_signal_used(struct vhost_virtqueue *vq);
#define vq_err(vq, fmt, ...) do { \
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 3337027..4c3f138 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -238,11 +238,12 @@ enum {
/*
* The callback notifies userspace to release buffers when skb DMA is done in
* lower device, the skb last reference should be 0 when calling this.
- * The desc is used to track userspace buffer index.
+ * The ctx field is used to track device context.
+ * The desc field is used to track userspace buffer index.
*/
struct ubuf_info {
- void (*callback)(void *);
- void *arg;
+ void (*callback)(struct ubuf_info *);
+ void *ctx;
unsigned long desc;
};
--
1.7.9.111.gf3fb0
^ permalink raw reply related
* [PATCH] davinci_emac: Add cpu_freq support
From: Manjunathappa, Prakash @ 2012-04-09 10:49 UTC (permalink / raw)
To: netdev
Cc: davem, linux-kernel, davinci-linux-open-source,
Manjunathappa, Prakash
Reconfigure interrupt coalesce parameter for changed emac bus_freq
due to DVFS.
Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 174a334..11d3bd7 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -50,6 +50,7 @@
#include <linux/ctype.h>
#include <linux/spinlock.h>
#include <linux/dma-mapping.h>
+#include <linux/cpufreq.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/semaphore.h>
@@ -344,6 +345,9 @@ struct emac_priv {
/*platform specific members*/
void (*int_enable) (void);
void (*int_disable) (void);
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
/* clock frequency for EMAC */
@@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
#endif
};
+#ifdef CONFIG_CPU_FREQ
+static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ int ret = 0;
+ struct emac_priv *priv;
+
+ priv = container_of(nb, struct emac_priv, freq_transition);
+ if (priv->coal_intvl != 0) {
+ if (val == CPUFREQ_POSTCHANGE) {
+ if (emac_bus_frequency != clk_get_rate(emac_clk)) {
+ struct ethtool_coalesce coal;
+
+ emac_bus_frequency = clk_get_rate(emac_clk);
+
+ priv->bus_freq_mhz = (u32)(emac_bus_frequency /
+ 1000000);
+ coal.rx_coalesce_usecs = (priv->coal_intvl
+ << 4);
+ ret = emac_set_coalesce(priv->ndev, &coal);
+ }
+ }
+ }
+ return ret;
+}
+
+static inline int davinci_emac_cpufreq_register(struct emac_priv *priv)
+{
+ priv->freq_transition.notifier_call = davinci_emac_cpufreq_transition;
+ return cpufreq_register_notifier(&priv->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void davinci_emac_cpufreq_deregister(struct emac_priv *priv)
+{
+ cpufreq_unregister_notifier(&priv->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#endif
+
/**
* davinci_emac_probe: EMAC device probe
* @pdev: The DaVinci EMAC device that we are removing
@@ -1925,8 +1969,21 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
"(regs: %p, irq: %d)\n",
(void *)priv->emac_base_phys, ndev->irq);
}
+
+#ifdef CONFIG_CPU_FREQ
+ rc = davinci_emac_cpufreq_register(priv);
+ if (rc) {
+ dev_err(&pdev->dev, "error in register_netdev\n");
+ rc = -ENODEV;
+ goto cpufreq_reg_err;
+ }
+#endif
return 0;
+#ifdef CONFIG_CPU_FREQ
+cpufreq_reg_err:
+ unregister_netdev(ndev);
+#endif
netdev_reg_err:
clk_disable(emac_clk);
no_irq_res:
@@ -1973,6 +2030,9 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
release_mem_region(res->start, resource_size(res));
+#ifdef CONFIG_CPU_FREQ
+ davinci_emac_cpufreq_deregister(priv);
+#endif
unregister_netdev(ndev);
iounmap(priv->remap_addr);
free_netdev(ndev);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] davinci_emac: Add cpu_freq support
From: Sergei Shtylyov @ 2012-04-09 11:29 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1333968549-3282-1-git-send-email-prakash.pm-l0cyMroinI0@public.gmane.org>
Hello.
On 09-04-2012 14:49, Manjunathappa, Prakash wrote:
> Reconfigure interrupt coalesce parameter for changed emac bus_freq
> due to DVFS.
> Signed-off-by: Manjunathappa, Prakash<prakash.pm-l0cyMroinI0@public.gmane.org>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
> 1 files changed, 60 insertions(+), 0 deletions(-)
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 174a334..11d3bd7 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
[...]
> @@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_CPU_FREQ
> +static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + int ret = 0;
> + struct emac_priv *priv;
> +
> + priv = container_of(nb, struct emac_priv, freq_transition);
> + if (priv->coal_intvl != 0) {
> + if (val == CPUFREQ_POSTCHANGE) {
> + if (emac_bus_frequency != clk_get_rate(emac_clk)) {
These 3 *if*s could be collapsed into one, and so indentation level
lowered significantly.
> + struct ethtool_coalesce coal;
> +
> + emac_bus_frequency = clk_get_rate(emac_clk);
> +
> + priv->bus_freq_mhz = (u32)(emac_bus_frequency /
> + 1000000);
> + coal.rx_coalesce_usecs = (priv->coal_intvl
> + << 4);
> + ret = emac_set_coalesce(priv->ndev,&coal);
> + }
> + }
> + }
> + return ret;
> +}
> +
> +static inline int davinci_emac_cpufreq_register(struct emac_priv *priv)
> +{
> + priv->freq_transition.notifier_call = davinci_emac_cpufreq_transition;
> + return cpufreq_register_notifier(&priv->freq_transition,
> + CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +
> +static inline void davinci_emac_cpufreq_deregister(struct emac_priv *priv)
> +{
> + cpufreq_unregister_notifier(&priv->freq_transition,
> + CPUFREQ_TRANSITION_NOTIFIER);
> +}
> +#endif
> +
> /**
> * davinci_emac_probe: EMAC device probe
> * @pdev: The DaVinci EMAC device that we are removing
> @@ -1925,8 +1969,21 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
> "(regs: %p, irq: %d)\n",
> (void *)priv->emac_base_phys, ndev->irq);
> }
> +
> +#ifdef CONFIG_CPU_FREQ
> + rc = davinci_emac_cpufreq_register(priv);
> + if (rc) {
> + dev_err(&pdev->dev, "error in register_netdev\n");
Really?
> + rc = -ENODEV;
> + goto cpufreq_reg_err;
> + }
> +#endif
> return 0;
>
> +#ifdef CONFIG_CPU_FREQ
> +cpufreq_reg_err:
> + unregister_netdev(ndev);
> +#endif
> netdev_reg_err:
> clk_disable(emac_clk);
> no_irq_res:
> @@ -1973,6 +2030,9 @@ static int __devexit davinci_emac_remove(struct platform_device *pdev)
>
> release_mem_region(res->start, resource_size(res));
>
> +#ifdef CONFIG_CPU_FREQ
> + davinci_emac_cpufreq_deregister(priv);
> +#endif
This is considered a bad practice to use #ifdef in the body of function.
Define the faunction you call here as empty inline in case CONFIG_CPU_FREQ is
not defined instead. The same about davinci_emac_cpufreq_register().
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 6/6] tilegx network driver: initial support
From: Arnd Bergmann @ 2012-04-09 13:49 UTC (permalink / raw)
To: Chris Metcalf; +Cc: linux-kernel, netdev
In-Reply-To: <201204062101.q36L1uCi011406@farm-0027.internal.tilera.com>
On Friday 06 April 2012, Chris Metcalf wrote:
> This change adds support for the tilegx network driver based on the
> GXIO IORPC support in the tilegx software stack, using the on-chip
> mPIPE packet processing engine.
>
> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
> ---
> drivers/net/ethernet/tile/Kconfig | 1 +
> drivers/net/ethernet/tile/Makefile | 4 +-
> drivers/net/ethernet/tile/tilegx.c | 2045 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 2048 insertions(+), 2 deletions(-)
> create mode 100644 drivers/net/ethernet/tile/tilegx.c
I think the directory name should be the company, not the architecture here, so make
it drivers/net/ethernet/tilera/tilegx.c instead.
> +
> +MODULE_AUTHOR("Tilera");
> +MODULE_LICENSE("GPL");
> +
MODULE_AUTHOR is normally a real person with an email address.
> +/* Statistics counters for a specific cpu and device. */
> +struct tile_net_stats_t {
> + u32 rx_packets;
> + u32 rx_bytes;
> + u32 tx_packets;
> + u32 tx_bytes;
> +};
I think you need to drop the _t postfix here, which presumably comes
from converting it from a typedef.
> +
> +/* The actual devices. */
> +static struct net_device *tile_net_devs[TILE_NET_DEVS];
> +
> +/* The device for a given channel. HACK: We use "32", not
> + * TILE_NET_CHANNELS, because it is fairly subtle that the 5 bit
> + * "idesc.channel" field never exceeds TILE_NET_CHANNELS.
> + */
> +static struct net_device *tile_net_devs_for_channel[32];
When you need to keep a list or array of device structures in a driver, you're
usually doing something very wrong. The convention is to just pass the pointer
around to where you need it.
> +
> +/* Convert a "buffer ptr" into a "buffer cpa". */
> +static inline void *buf_to_cpa(void *buf)
> +{
> + return (void *)__pa(buf);
> +}
> +
> +
> +/* Convert a "buffer cpa" into a "buffer ptr". */
> +static inline void *cpa_to_buf(void *cpa)
> +{
> + return (void *)__va(cpa);
> +}
This is almost certainly wrong: The type returned by __pa is a phys_addr_t,
which cannot be dereferenced like a pointer. On normal drivers, you would
use dma_map_single()/dma_unmap_single() to get a token that can get
passed into a dma engine. From what I can tell, this device is directly mapped,
while your PCI uses an IOMMU, so that would require two different
implementations of dma mapping operations.
> +/* Allocate and push a buffer. */
> +static bool tile_net_provide_buffer(bool small)
> +{
> + int stack = small ? small_buffer_stack : large_buffer_stack;
> +
> + /* Buffers must be aligned. */
> + const unsigned long align = 128;
> +
> + /* Note that "dev_alloc_skb()" adds NET_SKB_PAD more bytes,
> + * and also "reserves" that many bytes.
> + */
> + int len = sizeof(struct sk_buff **) + align + (small ? 128 : 1664);
> +
> + /* Allocate (or fail). */
> + struct sk_buff *skb = dev_alloc_skb(len);
> + if (skb == NULL)
> + return false;
> +
> + /* Make room for a back-pointer to 'skb'. */
> + skb_reserve(skb, sizeof(struct sk_buff **));
> +
> + /* Make sure we are aligned. */
> + skb_reserve(skb, -(long)skb->data & (align - 1));
> +
> + /* Save a back-pointer to 'skb'. */
> + *(struct sk_buff **)(skb->data - sizeof(struct sk_buff **)) = skb;
This looks very wrong: why would you put the pointer to the skb into the
skb itself?
> + /* Make sure "skb" and the back-pointer have been flushed. */
> + __insn_mf();
Try to use archicture independent names for flush operations like this
to make it more readable. I assume this should be smp_wmb()?
> +
> + /* Compute the "ip checksum". */
> + jsum = isum_hack + htons(s_len - eh_len) + htons(id);
> + jsum = __insn_v2sadu(jsum, 0);
> + jsum = __insn_v2sadu(jsum, 0);
> + jsum = (0xFFFF ^ jsum);
> + jh->check = jsum;
> +
> + /* Update the tcp "seq". */
> + uh->seq = htonl(seq);
> +
> + /* Update some flags. */
> + if (!final)
> + uh->fin = uh->psh = 0;
> +
> + /* Compute the tcp pseudo-header checksum. */
> + usum = tsum_hack + htons(s_len);
> + usum = __insn_v2sadu(usum, 0);
> + usum = __insn_v2sadu(usum, 0);
> + uh->check = usum;
Why to you open-code the ip checksum functions here? Normally the stack takes
care of this by calling the functions you already provide in
arch/tile/lib/checksum.c
Arnd
^ permalink raw reply
* [PATCH] net/garp: fix GID rbtree ordering
From: David Ward @ 2012-04-09 14:13 UTC (permalink / raw)
To: netdev; +Cc: Jorge Boncompte [DTI2], David Ward
The comparison operators were backwards in both garp_attr_lookup and
garp_attr_create, so the entire GID rbtree was in reverse order.
(There was no practical side effect to this though, except that PDUs
were sent with attributes listed in reverse order, which is still
valid by the protocol. This change is only for clarity.)
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
net/802/garp.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/802/garp.c b/net/802/garp.c
index a5c2248..8456f5d 100644
--- a/net/802/garp.c
+++ b/net/802/garp.c
@@ -157,9 +157,9 @@ static struct garp_attr *garp_attr_lookup(const struct garp_applicant *app,
while (parent) {
attr = rb_entry(parent, struct garp_attr, node);
d = garp_attr_cmp(attr, data, len, type);
- if (d < 0)
+ if (d > 0)
parent = parent->rb_left;
- else if (d > 0)
+ else if (d < 0)
parent = parent->rb_right;
else
return attr;
@@ -178,9 +178,9 @@ static struct garp_attr *garp_attr_create(struct garp_applicant *app,
parent = *p;
attr = rb_entry(parent, struct garp_attr, node);
d = garp_attr_cmp(attr, data, len, type);
- if (d < 0)
+ if (d > 0)
p = &parent->rb_left;
- else if (d > 0)
+ else if (d < 0)
p = &parent->rb_right;
else {
/* The attribute already exists; re-use it. */
--
1.7.4.1
^ permalink raw reply related
* [PATCH]Fix misplaces parenthesis in virtio_net.c
From: Torsten Kaiser @ 2012-04-09 15:14 UTC (permalink / raw)
To: David Miller, Rick Jones; +Cc: netdev, linux-kernel
Commit 2e57b79ccef1ff1422fdf45a9b28fe60f8f084f7 misplaced its
parenthesis and now tx_fifo_errors will only be incremented if an
ENOMEM error is not written to the syslog.
Correct the parenthesis and indentation to the original goal of
counting all non ENOMEM errors and ratelimiting only the messages.
Signed-of-by: Torsten Kaiser <just.for.lkml@googlemail.com>
--- a/drivers/net/virtio_net.c 2012-04-09 16:55:31.366847092 +0200
+++ b/drivers/net/virtio_net.c 2012-04-09 16:56:31.196847799 +0200
@@ -626,16 +626,15 @@
/* This can happen with OOM and indirect buffers. */
if (unlikely(capacity < 0)) {
if (likely(capacity == -ENOMEM)) {
- if (net_ratelimit()) {
+ if (net_ratelimit())
dev_warn(&dev->dev,
"TX queue failure: out of memory\n");
- } else {
+ } else {
dev->stats.tx_fifo_errors++;
if (net_ratelimit())
dev_warn(&dev->dev,
"Unexpected TX queue failure: %d\n",
capacity);
- }
}
dev->stats.tx_dropped++;
kfree_skb(skb);
^ permalink raw reply
* Re: [PATCH] davinci_emac: Add cpu_freq support
From: Ben Hutchings @ 2012-04-09 15:56 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: netdev, davem, linux-kernel, davinci-linux-open-source
In-Reply-To: <1333968549-3282-1-git-send-email-prakash.pm@ti.com>
On Mon, 2012-04-09 at 16:19 +0530, Manjunathappa, Prakash wrote:
> Reconfigure interrupt coalesce parameter for changed emac bus_freq
> due to DVFS.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 60 ++++++++++++++++++++++++++++++++
> 1 files changed, 60 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 174a334..11d3bd7 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -50,6 +50,7 @@
> #include <linux/ctype.h>
> #include <linux/spinlock.h>
> #include <linux/dma-mapping.h>
> +#include <linux/cpufreq.h>
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/semaphore.h>
> @@ -344,6 +345,9 @@ struct emac_priv {
> /*platform specific members*/
> void (*int_enable) (void);
> void (*int_disable) (void);
> +#ifdef CONFIG_CPU_FREQ
> + struct notifier_block freq_transition;
> +#endif
> };
>
> /* clock frequency for EMAC */
> @@ -1761,6 +1765,46 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_CPU_FREQ
> +static int davinci_emac_cpufreq_transition(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + int ret = 0;
> + struct emac_priv *priv;
> +
> + priv = container_of(nb, struct emac_priv, freq_transition);
> + if (priv->coal_intvl != 0) {
> + if (val == CPUFREQ_POSTCHANGE) {
> + if (emac_bus_frequency != clk_get_rate(emac_clk)) {
> + struct ethtool_coalesce coal;
> +
> + emac_bus_frequency = clk_get_rate(emac_clk);
> +
> + priv->bus_freq_mhz = (u32)(emac_bus_frequency /
> + 1000000);
> + coal.rx_coalesce_usecs = (priv->coal_intvl
> + << 4);
> + ret = emac_set_coalesce(priv->ndev, &coal);
[...]
Ick. Why don't you break up emac_set_coalesce() so that you can push
this one value to the hardware without faking up a struct
ethtool_coalesce? Don't you need to push it on reset/resume anyway?
Ben.
--
Ben Hutchings, Staff 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: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Marc MERLIN @ 2012-04-09 17:20 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-wireless, netdev
In-Reply-To: <1333044575.2656.1.camel@bwh-desktop.uk.solarflarecom.com>
On Thu, Mar 29, 2012 at 07:09:35PM +0100, Ben Hutchings wrote:
> On Thu, 2012-03-29 at 09:38 -0700, Marc MERLIN wrote:
> [...]
> > Below are some sysreq dumps I took (syslog to local disk was still
> > working fine). I know I have Tainted 'G', and I have no idea where that
> > came from, sorry :-/
> [...]
>
> 'G' isn't a taint flag, but the following 'O' is; it means you have one
> or more out-of-tree modules loaded. Care to tell us what they are?
Ok, I just had time to reproduce this without tainting. It was with 3.2.5
though since I'm debugging a battery power use issue too.
I confirmed that the problem only happens when I do NFS copies. Doing the
same copy with rsync over SSH works fine.
I'm not much of a kernel guy, but it looks like there is a memory problem,
which in turn causes the network driver to deadlock waiting on RAM with
interrupts turned off (mouse cursor won't move). Eventually it gets a bit of
the special RAM it seems to need, at that point, my frozen mouse pointer
unfreezes until it locks again soon after.
So there are 2 problems
1) memory issue
2) driver waits for RAM with interrupts turned off
The log below shows offlineimap first getting memory allocation problems
as soon after I start the copy, then firefox, and some:
ieee80211 phy0: failed to reallocate TX buffer
No taint flags this time.
I'll paste a few lines below.
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?
kernel config: http://marc.merlins.org/tmp/config.txt
Thanks,
Marc
09:44:12 offlineimap: page allocation failure: order:1, mode:0x20
09:44:12 Pid: 6269, comm: offlineimap Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:12 Call Trace:
09:44:12 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
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
09:44:12 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:12 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:12 [<ffffffff81065863>] ? timekeeping_get_ns+0xd/0x2a
09:44:12 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:12 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:12 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:12 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:12 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:12 <EOI> [<ffffffff81061e33>] ? hrtimer_cancel+0xc/0x16
09:44:12 [<ffffffff8110629a>] ? select_estimate_accuracy+0xcf/0xed
09:44:12 [<ffffffff8110629a>] ? select_estimate_accuracy+0xcf/0xed
09:44:12 [<ffffffff81106464>] ? do_select+0x13c/0x46a
09:44:12 [<ffffffff81034a8c>] ? walk_tg_tree_from+0x70/0x99
09:44:12 [<ffffffff811060ab>] ? poll_freewait+0x97/0x97
09:44:12 [<ffffffff8103a520>] ? update_curr+0xd0/0xf5
09:44:12 [<ffffffff8100d758>] ? __switch_to+0x1fc/0x20e
09:44:12 [<ffffffff8103ac9c>] ? dequeue_entity+0x13e/0x161
09:44:12 [<ffffffff8103891c>] ? finish_task_switch+0x88/0xb9
09:44:12 [<ffffffff813417fc>] ? __schedule+0x5ac/0x5c3
09:44:12 [<ffffffff8106c902>] ? get_futex_value_locked+0x2d/0x3d
09:44:12 [<ffffffff810349f1>] ? set_task_rq+0x23/0x35
09:44:12 [<ffffffff81035ef0>] ? cpumask_next+0x17/0x1a
09:44:12 [<ffffffff8104073f>] ? select_task_rq_fair+0x435/0x67e
09:44:12 [<ffffffff8101353d>] ? paravirt_read_tsc+0x5/0x8
09:44:12 [<ffffffff81013999>] ? native_sched_clock+0x27/0x2f
09:44:12 [<ffffffff810139a6>] ? sched_clock+0x5/0x8
09:44:12 [<ffffffff810634b0>] ? sched_clock_local+0xd/0x6f
09:44:12 [<ffffffff81026aa4>] ? _flat_send_IPI_mask+0x68/0x78
09:44:12 [<ffffffff8103f175>] ? try_to_wake_up+0x187/0x196
09:44:12 [<ffffffff81106907>] ? core_sys_select+0x175/0x21a
09:44:12 [<ffffffff8106e85a>] ? do_futex+0xab/0x7ed
09:44:12 [<ffffffff8104afef>] ? timespec_add_safe+0x32/0x63
09:44:12 [<ffffffff81028a44>] ? read_hpet+0xd/0x10
09:44:12 [<ffffffff81065863>] ? timekeeping_get_ns+0xd/0x2a
09:44:12 [<ffffffff81106a34>] ? sys_select+0x88/0xad
09:44:12 [<ffffffff81347b52>] ? system_call_fastpath+0x16/0x1b
09:44:12 Mem-Info:
09:44:12 Node 0 DMA per-cpu:
09:44:12 CPU 0: hi: 0, btch: 1 usd: 0
09:44:12 CPU 1: hi: 0, btch: 1 usd: 0
09:44:12 Node 0 DMA32 per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 96
09:44:12 CPU 1: hi: 186, btch: 31 usd: 61
09:44:12 Node 0 Normal per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 178
09:44:12 CPU 1: hi: 186, btch: 31 usd: 37
09:44:12 active_anon:992922 inactive_anon:263416 isolated_anon:0
09:44:12 active_file:59734 inactive_file:529995 isolated_file:0
09:44:12 unevictable:1 dirty:52839 writeback:339893 unstable:7544
09:44:12 free:55501 slab_reclaimable:33311 slab_unreclaimable:30518
09:44:12 mapped:18500 shmem:43519 pagetables:21479 bounce:0
09:44:12 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB 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
09:44:12 lowmem_reserve[]: 0 2960 7947 7947
09:44:12 Node 0 DMA32 free:153280kB min:25128kB low:31408kB high:37692kB active_anon:1579176kB inactive_anon:524080kB active_file:33708kB inactive_file:618072kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:81192kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30268kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 4986 4986
09:44:12 Node 0 Normal free:52816kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529584kB active_file:205228kB inactive_file:1501908kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:130164kB writeback:1037144kB mapped:67296kB shmem:107008kB slab_reclaimable:91836kB slab_unreclaimable:91804kB kernel_stack:4216kB pagetables:61508kB unstable:20128kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 0 0
09:44:12 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:12 Node 0 DMA32: 37156*4kB 0*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 153280kB
09:44:12 Node 0 Normal: 12180*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52816kB
09:44:12 676507 total pagecache pages
09:44:12 43251 pages in swap cache
09:44:12 Swap cache stats: add 803319, delete 760068, find 297792/318561
09:44:12 Free swap = 1763732kB
09:44:12 Total swap = 4106248kB
09:44:12 2080752 pages RAM
09:44:12 57163 pages reserved
09:44:12 988140 pages shared
09:44:12 1496507 pages non-shared
09:44:12 ieee80211 phy0: failed to reallocate TX buffer
09:44:12 kworker/0:1: page allocation failure: order:1, mode:0x20
09:44:12 Pid: 8162, comm: kworker/0:1 Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:12 Call Trace:
09:44:12 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
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
09:44:12 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:12 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:12 [<ffffffff8103a946>] ? check_preempt_wakeup+0x10c/0x18e
09:44:12 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:12 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:12 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:12 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:12 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:12 <EOI> [<ffffffffa0089052>] ? dec128+0x15a/0x80c [aes_x86_64]
09:44:12 [<ffffffff8118f263>] ? crypto_cbc_decrypt_inplace.isra.4+0x84/0xef
09:44:12 [<ffffffffa06bb6ee>] ? decode_attr_time+0x2f/0x5d [nfs]
09:44:12 [<ffffffffa0089704>] ? dec128+0x80c/0x80c [aes_x86_64]
09:44:12 [<ffffffff8118f328>] ? crypto_cbc_decrypt+0x5a/0x10a
09:44:12 [<ffffffff8118756b>] ? async_decrypt+0x37/0x3c
09:44:12 [<ffffffffa0108df7>] ? crypt_convert+0x223/0x2b8 [dm_crypt]
09:44:12 [<ffffffffa0109185>] ? kcryptd_crypt+0x56/0x342 [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:12 [<ffffffff8105ac3d>] ? process_one_work+0x163/0x284
09:44:12 [<ffffffff8105bc05>] ? worker_thread+0xc2/0x145
09:44:12 [<ffffffff8105bb43>] ? manage_workers.isra.23+0x15b/0x15b
09:44:12 [<ffffffff8105ed41>] ? kthread+0x76/0x7e
09:44:12 [<ffffffff81349cb4>] ? kernel_thread_helper+0x4/0x10
09:44:12 [<ffffffff8105eccb>] ? kthread_worker_fn+0x139/0x139
09:44:12 [<ffffffff81349cb0>] ? gs_change+0x13/0x13
09:44:12 Mem-Info:
09:44:12 Node 0 DMA per-cpu:
09:44:12 CPU 0: hi: 0, btch: 1 usd: 0
09:44:12 CPU 1: hi: 0, btch: 1 usd: 0
09:44:12 Node 0 DMA32 per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 77
09:44:12 CPU 1: hi: 186, btch: 31 usd: 53
09:44:12 Node 0 Normal per-cpu:
09:44:12 CPU 0: hi: 186, btch: 31 usd: 165
09:44:12 CPU 1: hi: 186, btch: 31 usd: 64
09:44:12 active_anon:992922 inactive_anon:263441 isolated_anon:0
09:44:12 active_file:59734 inactive_file:530249 isolated_file:0
09:44:12 unevictable:1 dirty:52950 writeback:339764 unstable:7673
09:44:12 free:55214 slab_reclaimable:33311 slab_unreclaimable:30507
09:44:12 mapped:18500 shmem:43519 pagetables:21479 bounce:0
09:44:12 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB 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
09:44:12 lowmem_reserve[]: 0 2960 7947 7947
09:44:12 Node 0 DMA32 free:152124kB min:25128kB low:31408kB high:37692kB active_anon:1579176kB inactive_anon:524180kB active_file:33708kB inactive_file:618972kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:81636kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30456kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 4986 4986
09:44:12 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529584kB active_file:205228kB inactive_file:1502024kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:130164kB writeback:1036628kB mapped:67296kB shmem:107008kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:12 lowmem_reserve[]: 0 0 0 0
09:44:12 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:12 Node 0 DMA32: 36855*4kB 0*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 152124kB
09:44:12 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:12 676809 total pagecache pages
09:44:12 43260 pages in swap cache
09:44:12 Swap cache stats: add 803337, delete 760077, find 297801/318574
09:44:12 Free swap = 1763768kB
09:44:12 Total swap = 4106248kB
09:44:12 2080752 pages RAM
09:44:12 57163 pages reserved
09:44:12 988161 pages shared
09:44:12 1496613 pages non-shared
09:44:12 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 firefox-bin: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 6697, comm: firefox-bin Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:13 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:13 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:13 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:13 [<ffffffff8103a95f>] ? check_preempt_wakeup+0x125/0x18e
09:44:13 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:13 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:13 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:13 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:13 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:13 <EOI> [<ffffffff81347c84>] ? sysret_audit+0x16/0x20
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 78
09:44:13 CPU 1: hi: 186, btch: 31 usd: 66
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 165
09:44:13 CPU 1: hi: 186, btch: 31 usd: 70
09:44:13 active_anon:992947 inactive_anon:263499 isolated_anon:0
09:44:13 active_file:59734 inactive_file:535571 isolated_file:0
09:44:13 unevictable:1 dirty:56763 writeback:339764 unstable:7673
09:44:13 free:49597 slab_reclaimable:33311 slab_unreclaimable:30582
09:44:13 mapped:18500 shmem:43562 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB 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
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:129656kB min:25128kB low:31408kB high:37692kB active_anon:1579276kB inactive_anon:524180kB active_file:33708kB inactive_file:640772kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:92588kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30756kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529816kB active_file:205228kB inactive_file:1501512kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:134464kB writeback:1036628kB mapped:67296kB shmem:107180kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:1703 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 31254*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 129656kB
09:44:13 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:13 682242 total pagecache pages
09:44:13 43259 pages in swap cache
09:44:13 Swap cache stats: add 803338, delete 760079, find 297802/318575
09:44:13 Free swap = 1763768kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 992010 pages shared
09:44:13 1498343 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 firefox-bin: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 6706, comm: firefox-bin Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff81070551>] ? arch_local_irq_save+0x11/0x17
09:44:13 [<ffffffff8129da01>] ? sch_direct_xmit+0x5e/0x12f
09:44:13 [<ffffffff8129dbc9>] ? __qdisc_run+0xf7/0x10f
09:44:13 [<ffffffff81282d56>] ? net_tx_action+0xf1/0x128
09:44:13 [<ffffffff8104bc88>] ? __do_softirq+0xb9/0x177
09:44:13 [<ffffffff8106a67b>] ? clockevents_program_event+0xaa/0xce
09:44:13 [<ffffffff81349dac>] ? call_softirq+0x1c/0x30
09:44:13 [<ffffffff8100f875>] ? do_softirq+0x3c/0x7b
09:44:13 [<ffffffff8104bef0>] ? irq_exit+0x3c/0x9a
09:44:13 [<ffffffff8100f5a5>] ? do_IRQ+0x82/0x98
09:44:13 [<ffffffff81342e2e>] ? common_interrupt+0x6e/0x6e
09:44:13 <EOI> [<ffffffff81347c84>] ? sysret_audit+0x16/0x20
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 69
09:44:13 CPU 1: hi: 186, btch: 31 usd: 35
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 178
09:44:13 CPU 1: hi: 186, btch: 31 usd: 68
09:44:13 active_anon:992947 inactive_anon:263499 isolated_anon:0
09:44:13 active_file:59734 inactive_file:536198 isolated_file:0
09:44:13 unevictable:1 dirty:57182 writeback:339764 unstable:7673
09:44:13 free:49028 slab_reclaimable:33311 slab_unreclaimable:30581
09:44:13 mapped:18500 shmem:43562 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB 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
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:127380kB min:25128kB low:31408kB high:37692kB active_anon:1579276kB inactive_anon:524180kB active_file:33708kB inactive_file:643272kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:93920kB writeback:322428kB mapped:6704kB shmem:67068kB slab_reclaimable:41408kB slab_unreclaimable:30752kB kernel_stack:2216kB pagetables:24408kB unstable:10048kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52824kB min:42324kB low:52904kB high:63484kB active_anon:2392512kB inactive_anon:529816kB active_file:205228kB inactive_file:1501520kB unevictable:4kB isolated(anon):0kB isolated(file):0kB present:5106560kB mlocked:4kB dirty:134808kB writeback:1036628kB mapped:67296kB shmem:107180kB slab_reclaimable:91836kB slab_unreclaimable:91572kB kernel_stack:4216kB pagetables:61508kB unstable:20644kB bounce:0kB writeback_tmp:0kB pages_scanned:112 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 30640*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 127256kB
09:44:13 Node 0 Normal: 12182*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52824kB
09:44:13 682828 total pagecache pages
09:44:13 43261 pages in swap cache
09:44:13 Swap cache stats: add 803340, delete 760079, find 297802/318575
09:44:13 Free swap = 1763760kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 992430 pages shared
09:44:13 1498647 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 kworker/0:0: page allocation failure: order:1, mode:0x20
09:44:13 Pid: 7949, comm: kworker/0:0 Tainted: G O 3.2.5amd64-volpreempt-noide-20120208 #1
09:44:13 Call Trace:
09:44:13 <IRQ> [<ffffffff810b755a>] ? warn_alloc_failed+0x11a/0x12d
09:44:13 [<ffffffff810ba394>] ? __alloc_pages_nodemask+0x6b2/0x726
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810e9081>] ? kmem_getpages+0x4c/0xd9
09:44:13 [<ffffffff810ea421>] ? fallback_alloc+0x123/0x1c2
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffff810ea923>] ? __kmalloc+0xba/0x112
09:44:13 [<ffffffff8127daae>] ? pskb_expand_head+0xe0/0x24a
09:44:13 [<ffffffffa07a81c0>] ? ieee80211_skb_resize+0x64/0x9d [mac80211]
09:44:13 [<ffffffffa07aa087>] ? ieee80211_subif_start_xmit+0x68e/0x80c [mac80211]
09:44:13 [<ffffffffa07922c8>] ? ieee80211_tx_status_irqsafe+0x2e/0x7f [mac80211]
09:44:13 [<ffffffff812877f3>] ? dev_hard_start_xmit+0x3fc/0x543
09:44:13 [<ffffffff8129da01>] ? sch_d9704>] ? dec128+0x80c/0x80c [aes_x86_64]
09:44:13 [<ffffffff810349f1>] ? set_task_rq+0x23/0x35
09:44:13 [<ffffffff8118f328>] ? crypto_cbc_decrypt+0x5a/0x10a
09:44:13 [<ffffffff8118756b>] ? async_decrypt+0x37/0x3c
09:44:13 [<ffffffffa0108df7>] ? crypt_convert+0x223/0x2b8 [dm_crypt]
09:44:13 [<ffffffffa0109185>] ? kcryptd_crypt+0x56/0x342 [dm_crypt]
09:44:13 [<ffffffff810388e2>] ? finish_task_switch+0x4e/0xb9
09:44:13 [<ffffffff811a4021>] ? cfq_init_queue+0x403/0x403
09:44:13 [<ffffffffa010912f>] ? crypt_convert_init.isra.17+0x4f/0x4f [dm_crypt]
09:44:13 [<ffffffff8105ac3d>] ? process_one_work+0x163/0x284
09:44:13 [<ffffffff8105bc05>] ? worker_thread+0xc2/0x145
09:44:13 [<ffffffff8105bb43>] ? manage_workers.isra.23+0x15b/0x15b
09:44:13 [<ffffffff8105ed41>] ? kthread+0x76/0x7e
09:44:13 [<ffffffff81349cb4>] ? kernel_thread_helper+0x4/0x10
09:44:13 [<ffffffff8105eccb>] ? kthread_worker_fn+0x139/0x139
09:44:13 [<ffffffff81349cb0>] ? gs_change+0x13/0x13
09:44:13 Mem-Info:
09:44:13 Node 0 DMA per-cpu:
09:44:13 CPU 0: hi: 0, btch: 1 usd: 0
09:44:13 CPU 1: hi: 0, btch: 1 usd: 0
09:44:13 Node 0 DMA32 per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 17
09:44:13 CPU 1: hi: 186, btch: 31 usd: 0
09:44:13 Node 0 Normal per-cpu:
09:44:13 CPU 0: hi: 186, btch: 31 usd: 69
09:44:13 CPU 1: hi: 186, btch: 31 usd: 125
09:44:13 active_anon:992968 inactive_anon:263499 isolated_anon:1
09:44:13 active_file:59749 inactive_file:538771 isolated_file:12
09:44:13 unevictable:1 dirty:59393 writeback:339244 unstable:8193
09:44:13 free:46512 slab_reclaimable:33220 slab_unreclaimable:30692
09:44:13 mapped:18504 shmem:43598 pagetables:21479 bounce:0
09:44:13 Node 0 DMA free:15908kB min:128kB low:160kB high:192kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB 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
09:44:13 lowmem_reserve[]: 0 2960 7947 7947
09:44:13 Node 0 DMA32 free:117308kB min:25128kB low:31408kB high:37692kB active_anon:1579336kB inactive_anon:524204kB active_file:33764kB inactive_file:653796kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3031688kB mlocked:0kB dirty:99216kB writeback:322356kB mapped:6716kB shmem:67128kB slab_reclaimable:41324kB slab_unreclaimable:30888kB kernel_stack:2216kB pagetables:24408kB unstable:10120kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 4986 4986
09:44:13 Node 0 Normal free:52832kB min:42324kB low:52904kB high:63484kB active_anon:2392536kB inactive_anon:529792kB active_file:205232kB inactive_file:1501288kB unevictable:4kB isolated(anon):4kB isolated(file):48kB present:5106560kB mlocked:4kB dirty:138356kB writeback:1034620kB mapped:67300kB shmem:107264kB slab_reclaimable:91556kB slab_unreclaimable:91880kB kernel_stack:4216kB pagetables:61508kB unstable:22652kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
09:44:13 lowmem_reserve[]: 0 0 0 0
09:44:13 Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15908kB
09:44:13 Node 0 DMA32: 28147*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 1*4096kB = 117308kB
09:44:13 Node 0 Normal: 12094*4kB 5*8kB 12*16kB 4*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 52832kB
09:44:13 685431 total pagecache pages
09:44:13 43261 pages in swap cache
09:44:13 Swap cache stats: add 803341, delete 760080, find 297802/318575
09:44:13 Free swap = 1763756kB
09:44:13 Total swap = 4106248kB
09:44:13 2080752 pages RAM
09:44:13 57163 pages reserved
09:44:13 994159 pages shared
09:44:13 1498949 pages non-shared
09:44:13 ieee80211 phy0: failed to reallocate TX buffer
09:44:13 kworker/0:0: page allocation failure: order:1, mode:0x20
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/
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-09 17:40 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: <1333728250-14248-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
(cc'ing other memcg ppl just in case)
Hello,
I don't think the error handling is correct here.
On Fri, Apr 06, 2012 at 08:04:10PM +0400, Glauber Costa wrote:
> The last man standing justifying the need for populate() is the
> sock memcg initialization functions. Now that we are able to pass
> a struct mem_cgroup instead of a struct cgroup to the socket
> initialization, there is nothing that stops us from initializing
> everything in create().
>
> Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
...
> @@ -5010,7 +5010,9 @@ mem_cgroup_create(struct cgroup *cont)
> memcg->move_charge_at_immigrate = 0;
> mutex_init(&memcg->thresholds_lock);
> spin_lock_init(&memcg->move_lock);
> - return &memcg->css;
> +
> + if (!memcg_init_kmem(memcg, &mem_cgroup_subsys))
> + return &memcg->css;
> free_out:
> __mem_cgroup_free(memcg);
> return ERR_PTR(error);
So, the control is just falling through free_out: on kmem init
failure; however, there seem to be stuff which needs to be undone -
hotcpu_notifier() registration, 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.
It probably would be best to reorganize the function slightly such
that, it's organized as...
1. alloc
2. init stuff w/o other side effects
3. make side effects
and add kmemcg init at the end of the second step.
Also, memcg maintainers, once the patches get updated and acked, I'd
like to route them through cgroup tree so that I can kill ->populate
there. cgroup/for-3.5 is stable branch which can be pulled into other
trees including the memcg one. Would that be okay?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Glauber Costa @ 2012-04-09 17:51 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: <20120409174042.GA7522-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
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.
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] r8169: support RTL8411
From: Francois Romieu @ 2012-04-09 18:02 UTC (permalink / raw)
To: hayeswang; +Cc: netdev
In-Reply-To: <20120405083743.GB32027@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> hayeswang <hayeswang@realtek.com> :
> [...]
> > There is nothing to do for rtl_init_jumbo_ops. It is all right for keeping
> > NULL.
>
> Ok, I'll add it to the commit message for future reference.
>
> > Do I need to resend this patch?
>
> No, I'll give it a short testing and forward to David.
Rx/Tx is ok, WoL + shutdown is ok but runtime power management is not.
I tried net-next + your patches + cff4c16296754888b6fd8c886bc860a888e20257
("r8169: enable napi on resume.", required for RPM or suspend/resume after
regression in da78dbff2e05630921c551dbbc70a4b7981a8fff).
- set a 8402 and a 8411 in the same test box
- ip addr add ...
- ip link set dev ... up
- start ping from remote host
- echo auto > /sys/bus/pci/devices/.../power/control
- unplug cable
- ping stops flowing
- cat /sys/bus/pci/devices/.../power/runtime_status
-> "active"
- plug cable
-> RPM status does not change, no link, no packet, no fun.
I have tried the same with a built-in 8168b (XID 18000000).
-> RPM status changes, link recovers, packets flow.
The 8168b is a bit special, so I swapped the 8411 for a 8102e (XID 04a00000).
It resumed correctly as well.
Any idea ?
--
Ueimor
Will code drivers for food.
^ 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:12 UTC (permalink / raw)
To: marc; +Cc: bhutchings, linux-wireless, netdev
In-Reply-To: <20120409172051.GR32290@merlins.org>
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.
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-09 18:13 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: <4F83218E.7060502-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
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
^ 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 18:36 UTC (permalink / raw)
To: David Miller
Cc: bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120409.141241.1216091936509309354.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Apr 09, 2012 at 02:12:41PM -0400, David Miller wrote:
> From: Marc MERLIN <marc-xnduUnryOU1AfugRpC6u6w@public.gmane.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?
Thanks,
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: 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
* 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: 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: [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: [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 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 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: 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: 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: [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: [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
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