* Re: [PATCH net-next-2.6] net_sched: RCU conversion of stab
From: David Miller @ 2011-01-21 0:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber, hawk, jarkao2, hadi
In-Reply-To: <1295531299.2825.175.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Jan 2011 14:48:19 +0100
> This patch converts stab qdisc management to RCU, so that we can perform
> the qdisc_calculate_pkt_len() call before getting qdisc lock.
>
> This shortens the lock's held time in __dev_xmit_skb().
>
> This permits more qdiscs to get TCQ_F_CAN_BYPASS status, avoiding lot of
> cache misses and so reducing latencies.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net_sched: sfq: allow divisor to be a parameter
From: David Miller @ 2011-01-21 0:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber, hawk, jarkao2, hadi, shemminger
In-Reply-To: <1295518498.2825.2.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Jan 2011 11:14:58 +0100
> SFQ currently uses a 1024 slots hash table, and its internal structure
> (sfq_sched_data) allocation needs order-1 page on x86_64
>
> Allow tc command to specify a divisor value (hash table size), between 1
> and 65536.
> If no value is provided, assume the 1024 default size.
>
> This allows admins to setup smaller (or bigger) SFQ for specific needs.
>
> This also brings back sfq_sched_data allocations to order-0 ones, saving
> 3KB per SFQ qdisc.
>
> Jesper uses ~55.000 SFQ in one machine, this patch should free 165 MB of
> memory.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] neigh: __rcu annotations
From: David Miller @ 2011-01-21 0:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1295510567.2653.487.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 20 Jan 2011 09:02:47 +0100
> fix some minor issues and sparse (__rcu) warnings
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: dev_close_many() is static
From: David Miller @ 2011-01-21 0:55 UTC (permalink / raw)
To: opurdila; +Cc: eric.dumazet, netdev
In-Reply-To: <201101201116.29031.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Thu, 20 Jan 2011 11:16:28 +0200
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thursday 20 January 2011, 09:23:22
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> CC: Octavian Purdila <opurdila@ixiacom.com>
> Oops, missed that. Thanks Eric !
>
> Reviewed-by: Octavian Purdila <opurdila@ixiacom.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atl1e: remove private #define.
From: David Miller @ 2011-01-21 0:50 UTC (permalink / raw)
To: romieu; +Cc: netdev, jcliburn, chris.snook, jie.yang
In-Reply-To: <20110120145922.GB7291@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 20 Jan 2011 15:59:23 +0100
> Either unused or duplicates from mii.h.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atl1c: remove private #define.
From: David Miller @ 2011-01-21 0:50 UTC (permalink / raw)
To: romieu; +Cc: netdev, jcliburn, chris.snook, jie.yang
In-Reply-To: <20110120145906.GA7291@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 20 Jan 2011 15:59:06 +0100
> Either unused or duplicates from mii.h.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Applied.
^ permalink raw reply
* Re: [PATCH] Ensure that we unshare skbs prior to calling pskb_may_pull in bonding driver
From: David Miller @ 2011-01-21 0:47 UTC (permalink / raw)
To: nhorman; +Cc: netdev, andy, fubar
In-Reply-To: <1295550151-25913-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 20 Jan 2011 14:02:31 -0500
> Recently reported oops:
Applied, but please compose reasonable Subject lines with your patches,
always begin the line with a subsystem tag followed by a colon.
This way we get
bonding: Foo bar baz
instead of
Foo bar baz in the bonding driver
Thanks.
^ permalink raw reply
* Re: [GIT] Networking
From: Davide Libenzi @ 2011-01-21 0:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Colin Walters, Eric Dumazet, David Miller, Andrew Morton, netdev,
Linux Kernel Mailing List
In-Reply-To: <AANLkTik8dk1o2u+JxzsijYFxJ7Y3ZV16DUNkc-+SYPnu@mail.gmail.com>
On Thu, 20 Jan 2011, Linus Torvalds wrote:
> On Thu, Jan 20, 2011 at 4:02 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So far I only did a revert, I didn't see exactly _which_ of the wakeup
> > cases it was. But it's definitely that commit.
>
> This patch - that adds all the appropriate POLLxxx flags - seems to
> fix it for me. Will commit. Anybody wants to review/ack?
I believe you can drop the POLLERR, otherwise looks good to me.
- Davide
^ permalink raw reply
* Re: [PATCH 0/7] netfilter: netfilter fixes for net-next
From: David Miller @ 2011-01-21 0:38 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1295554966-5263-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Thu, 20 Jan 2011 21:22:39 +0100
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Pulled, thanks Patrick.
^ permalink raw reply
* [net-next-2.6 PATCH] enic: Bug Fix: Dont reset ENIC_SET_APPLIED flag on port profile disassociate
From: Roopa Prabhu @ 2011-01-21 0:35 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Roopa Prabhu <roprabhu@cisco.com>
enic_get_vf_port returns port profile operation status only if ENIC_SET_APPLIED
flag is set. A recent rework of enic_set_port_profile added code to reset this
flag on disassociate. As a result of which a client calling enic_get_vf_port
to get the status of port profile disassociate will always get a return value
of ENODATA. This patch renames ENIC_SET_APPLIED to more appropriate
ENIC_PORT_REQUEST_APPLIED and reverts back the recent change so that the
flag is set both at associate and disassociate of a port profile.
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
---
drivers/net/enic/enic.h | 6 +++---
drivers/net/enic/enic_main.c | 10 ++++++----
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index a937f49..ca3be4f 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,8 +32,8 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "1.4.1.10"
-#define DRV_COPYRIGHT "Copyright 2008-2010 Cisco Systems, Inc"
+#define DRV_VERSION "2.1.1.2"
+#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
@@ -49,7 +49,7 @@ struct enic_msix_entry {
void *devid;
};
-#define ENIC_SET_APPLIED (1 << 0)
+#define ENIC_PORT_REQUEST_APPLIED (1 << 0)
#define ENIC_SET_REQUEST (1 << 1)
#define ENIC_SET_NAME (1 << 2)
#define ENIC_SET_INSTANCE (1 << 3)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index a0af48c..89664c6 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -1318,18 +1318,20 @@ static int enic_set_port_profile(struct enic *enic, u8 *mac)
vic_provinfo_free(vp);
if (err)
return err;
-
- enic->pp.set |= ENIC_SET_APPLIED;
break;
case PORT_REQUEST_DISASSOCIATE:
- enic->pp.set &= ~ENIC_SET_APPLIED;
break;
default:
return -EINVAL;
}
+ /* Set flag to indicate that the port assoc/disassoc
+ * request has been sent out to fw
+ */
+ enic->pp.set |= ENIC_PORT_REQUEST_APPLIED;
+
return 0;
}
@@ -1411,7 +1413,7 @@ static int enic_get_vf_port(struct net_device *netdev, int vf,
int err, error, done;
u16 response = PORT_PROFILE_RESPONSE_SUCCESS;
- if (!(enic->pp.set & ENIC_SET_APPLIED))
+ if (!(enic->pp.set & ENIC_PORT_REQUEST_APPLIED))
return -ENODATA;
err = enic_dev_init_done(enic, &done, &error);
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-01-21 0:11 UTC (permalink / raw)
To: Colin Walters, Davide Libenzi
Cc: Eric Dumazet, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTim71374Qb1TW5Lc8H+rpQNk5a25ARczHU-+cn=D@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 352 bytes --]
On Thu, Jan 20, 2011 at 4:02 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So far I only did a revert, I didn't see exactly _which_ of the wakeup
> cases it was. But it's definitely that commit.
This patch - that adds all the appropriate POLLxxx flags - seems to
fix it for me. Will commit. Anybody wants to review/ack?
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1773 bytes --]
fs/pipe.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index 89e9e19..da42f7d 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -441,7 +441,7 @@ redo:
break;
}
if (do_wakeup) {
- wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT);
+ wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
pipe_wait(pipe);
@@ -450,7 +450,7 @@ redo:
/* Signal writers asynchronously that there is more room. */
if (do_wakeup) {
- wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT);
+ wake_up_interruptible_sync_poll(&pipe->wait, POLLOUT | POLLWRNORM);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
if (ret > 0)
@@ -612,7 +612,7 @@ redo2:
break;
}
if (do_wakeup) {
- wake_up_interruptible_sync_poll(&pipe->wait, POLLIN);
+ wake_up_interruptible_sync_poll(&pipe->wait, POLLIN | POLLRDNORM);
kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
do_wakeup = 0;
}
@@ -623,7 +623,7 @@ redo2:
out:
mutex_unlock(&inode->i_mutex);
if (do_wakeup) {
- wake_up_interruptible_sync_poll(&pipe->wait, POLLIN);
+ wake_up_interruptible_sync_poll(&pipe->wait, POLLIN | POLLRDNORM);
kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
}
if (ret > 0)
@@ -715,7 +715,7 @@ pipe_release(struct inode *inode, int decr, int decw)
if (!pipe->readers && !pipe->writers) {
free_pipe_info(inode);
} else {
- wake_up_interruptible_sync_poll(&pipe->wait, POLLIN | POLLOUT);
+ wake_up_interruptible_sync_poll(&pipe->wait, POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM | POLLERR | POLLHUP);
kill_fasync(&pipe->fasync_readers, SIGIO, POLL_IN);
kill_fasync(&pipe->fasync_writers, SIGIO, POLL_OUT);
}
^ permalink raw reply related
* Re: [PATCH] Fix NULL dereference in rtlwifi driver
From: Jesper Juhl @ 2011-01-21 0:04 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, linux-wireless, linux-kernel, John W. Linville,
Chaoming Li
In-Reply-To: <4D38CB7E.5000304@lwfinger.net>
On Thu, 20 Jan 2011, Larry Finger wrote:
> On 01/20/2011 04:18 PM, Jesper Juhl wrote:
> > In drivers/net/wireless/rtlwifi/pci.c::_rtl_pci_rx_interrupt() we call
> > dev_alloc_skb(), which may fail and return NULL, but we do not check the
> > returned value against NULL before dereferencing the returned pointer.
> > This may lead to a NULL pointer dereference which means we'll crash - not
> > good.
> >
> > This patch tries to solve the issue by testing for NULL and bailing out if
> > we couldn't allocate a skb. However, I don't know this code well, so I'm
> > not sure that jumping to the 'done' label here is the correct action to
> > take. Someone more knowledgable about this code than me should definately
> > review it before it is applied anywhere.
> > While I was in the area I also moved an assignment in
> > _rtl_pci_init_rx_ring() a bit - if the dev_alloc_skb() call in that
> > function fails there's no reason to waste clock cycles assigning to the
> > local variable 'entry', we may as well do that after the NULL check and
> > potential bail out.
> >
> > Here's the proposed patch, but please don't take it as much more than a
> > bug report. If it happens to be correct, then by all means apply it, but
> > I'm not personally making any guarantees.
> >
> > Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> > ---
> > pci.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > compile tested only, I don't have the hardware to test for real.
> >
> > diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> > index 0fa36aa..5e99f89 100644
> > --- a/drivers/net/wireless/rtlwifi/pci.c
> > +++ b/drivers/net/wireless/rtlwifi/pci.c
> > @@ -619,6 +619,13 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
> > struct sk_buff *uskb = NULL;
> > u8 *pdata;
> > uskb = dev_alloc_skb(skb->len + 128);
> > + if (!uskb) {
> > + RT_TRACE(rtlpriv,
> > + (COMP_INTR | COMP_RECV),
> > + DBG_DMESG,
> > + ("can't alloc rx skb\n"));
> > + goto done;
> > + }
> > memcpy(IEEE80211_SKB_RXCB(uskb),
> > &rx_status,
> > sizeof(rx_status));
> > @@ -1066,9 +1073,9 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
> > struct sk_buff *skb =
> > dev_alloc_skb(rtlpci->rxbuffersize);
> > u32 bufferaddress;
> > - entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
> > if (!skb)
> > return 0;
> > + entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
> >
> > /*skb->dev = dev; */
> >
>
> This patch looks mostly good to me. The only change I would make is to replace
> "DBG_DMESG" in the RT_TRACE statement with "DBG_EMERG". The standard setting of
> the debug variable does not generate output for DBG_DMESG.
>
> With that change, ACK and
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>
Here you go.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
pci.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 0fa36aa..1758d44 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -619,6 +619,13 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
struct sk_buff *uskb = NULL;
u8 *pdata;
uskb = dev_alloc_skb(skb->len + 128);
+ if (!uskb) {
+ RT_TRACE(rtlpriv,
+ (COMP_INTR | COMP_RECV),
+ DBG_EMERG,
+ ("can't alloc rx skb\n"));
+ goto done;
+ }
memcpy(IEEE80211_SKB_RXCB(uskb),
&rx_status,
sizeof(rx_status));
@@ -641,7 +648,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
new_skb = dev_alloc_skb(rtlpci->rxbuffersize);
if (unlikely(!new_skb)) {
RT_TRACE(rtlpriv, (COMP_INTR | COMP_RECV),
- DBG_DMESG,
+ DBG_EMERG,
("can't alloc skb for rx\n"));
goto done;
}
@@ -1066,9 +1073,9 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
struct sk_buff *skb =
dev_alloc_skb(rtlpci->rxbuffersize);
u32 bufferaddress;
- entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
if (!skb)
return 0;
+ entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
/*skb->dev = dev; */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-01-21 0:02 UTC (permalink / raw)
To: Colin Walters, Davide Libenzi
Cc: Eric Dumazet, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTin-RBwg+J4MqOm7A40-TFAJ1sp4e6tzi6OaobNi@mail.gmail.com>
On Thu, Jan 20, 2011 at 3:43 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> But it turns out to be a kernel bug after all, although not in
> networking. It bisected down to commit e462c448fdc8: "pipe: use event
> aware wakeups".
>
> Anyway, I'll double-check my bisect by doing a revert of that commit
> on top of current -git, but I'm pretty sure the bisect was correct,
> since it did end up pointing to a commit that clearly changed poll
> behavior.
Confirmed. With that commit reverted, gnome-screensaver-dialog works again.
So far I only did a revert, I didn't see exactly _which_ of the wakeup
cases it was. But it's definitely that commit.
Linus
^ permalink raw reply
* Re: [PATCH] Fix NULL dereference in rtlwifi driver
From: Larry Finger @ 2011-01-20 23:55 UTC (permalink / raw)
To: Jesper Juhl
Cc: netdev, linux-wireless, linux-kernel, John W. Linville,
Chaoming Li
In-Reply-To: <alpine.LNX.2.00.1101202309030.11854@swampdragon.chaosbits.net>
On 01/20/2011 04:18 PM, Jesper Juhl wrote:
> In drivers/net/wireless/rtlwifi/pci.c::_rtl_pci_rx_interrupt() we call
> dev_alloc_skb(), which may fail and return NULL, but we do not check the
> returned value against NULL before dereferencing the returned pointer.
> This may lead to a NULL pointer dereference which means we'll crash - not
> good.
>
> This patch tries to solve the issue by testing for NULL and bailing out if
> we couldn't allocate a skb. However, I don't know this code well, so I'm
> not sure that jumping to the 'done' label here is the correct action to
> take. Someone more knowledgable about this code than me should definately
> review it before it is applied anywhere.
> While I was in the area I also moved an assignment in
> _rtl_pci_init_rx_ring() a bit - if the dev_alloc_skb() call in that
> function fails there's no reason to waste clock cycles assigning to the
> local variable 'entry', we may as well do that after the NULL check and
> potential bail out.
>
> Here's the proposed patch, but please don't take it as much more than a
> bug report. If it happens to be correct, then by all means apply it, but
> I'm not personally making any guarantees.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
> ---
> pci.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> compile tested only, I don't have the hardware to test for real.
>
> diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
> index 0fa36aa..5e99f89 100644
> --- a/drivers/net/wireless/rtlwifi/pci.c
> +++ b/drivers/net/wireless/rtlwifi/pci.c
> @@ -619,6 +619,13 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
> struct sk_buff *uskb = NULL;
> u8 *pdata;
> uskb = dev_alloc_skb(skb->len + 128);
> + if (!uskb) {
> + RT_TRACE(rtlpriv,
> + (COMP_INTR | COMP_RECV),
> + DBG_DMESG,
> + ("can't alloc rx skb\n"));
> + goto done;
> + }
> memcpy(IEEE80211_SKB_RXCB(uskb),
> &rx_status,
> sizeof(rx_status));
> @@ -1066,9 +1073,9 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
> struct sk_buff *skb =
> dev_alloc_skb(rtlpci->rxbuffersize);
> u32 bufferaddress;
> - entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
> if (!skb)
> return 0;
> + entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
>
> /*skb->dev = dev; */
>
This patch looks mostly good to me. The only change I would make is to replace
"DBG_DMESG" in the RT_TRACE statement with "DBG_EMERG". The standard setting of
the debug variable does not generate output for DBG_DMESG.
With that change, ACK and
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-01-20 23:43 UTC (permalink / raw)
To: Colin Walters, Davide Libenzi
Cc: Eric Dumazet, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTin6GM5W0nmWgD1a-2FK=CvHk=P3o6CYe-sFe6c=@mail.gmail.com>
On Thu, Jan 20, 2011 at 2:38 PM, Colin Walters <walters@verbum.org> wrote:
>
> It is actually; see src/gs-auth-pam.c; there is some pretty scary code
> there; basically all of PAM is put in a thread to avoid blocking the
> mainloop. Whether the code is actually buggy I can't say immediately;
> it's certainly possible.
I stand corrected.
But it turns out to be a kernel bug after all, although not in
networking. It bisected down to commit e462c448fdc8: "pipe: use event
aware wakeups".
I don't immediately see why, but I suspect it's the pipe_release()
case that needs to add POLLHUP to the wakeup cases. I suspect that
what is going on is that gnome-screensaver-dialog uses a pipe to talk
to the PAM code, and waits for the pipe to close. And we used to wake
it up unconditionally, but now we only wake up the poll waiter if it's
waiting for POLLIN/POLLOUT, rather than for anything else.
Anyway, I'll double-check my bisect by doing a revert of that commit
on top of current -git, but I'm pretty sure the bisect was correct,
since it did end up pointing to a commit that clearly changed poll
behavior.
Linus
^ permalink raw reply
* Re: [PATCH] CHOKe flow scheduler (0.10)
From: Eric Dumazet @ 2011-01-20 22:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Patrick McHardy, David Miller, netdev
In-Reply-To: <1295547589.2825.497.camel@edumazet-laptop>
Le jeudi 20 janvier 2011 à 19:19 +0100, Eric Dumazet a écrit :
> Le jeudi 20 janvier 2011 à 09:38 -0800, Stephen Hemminger a écrit :
>
> ...
>
> Hi Stephen
>
> I am contemplating choke_linearize_header() (yet another hash
> function... oh well...) and say :
>
> Instead of this boolean return, just use skb_get_rxhash(). It performs
> what you want, and return 32bits of information, instead of one bit.
>
> (if result (rxhash) is zero, it means you can drop packet because it is
> not linearized)
>
> So choke_match_flow() can be faster if rxhash differs (no cache miss on
> skb->data on an old skb)
> (Do the full check only if rxhash is equal on skb1 / skb2)
>
> More over, the skb_get_rxhash() call is _really_ needed only if CHOKe
> triggers :
> if (p->qavg <= p->qth_min)
> we dont have to compute rxhash at all.
>
> If you want, I can send a diff on your v0.10, just tell me !
Here is my diff against v 0.10
Seems to work well here
qdisc choke 11: parent 1:11 limit 130000b min 10833b max 32500b ewma 13 Plog 21 Scell_log 30
Sent 459876256 bytes 836183 pkt (dropped 318428, overlimits 28 requeues 0)
rate 51823Kbit 11779pps backlog 5926323b 10781p requeues 0
marked 0 early 28 pdrop 0 other 0 matched 159200
Thanks !
net/sched/sch_choke.c | 114 ++++++++++++----------------------------
1 file changed, 37 insertions(+), 77 deletions(-)
diff --git a/net/sched/sch_choke.c b/net/sched/sch_choke.c
index e1ac560..0e898ed 100644
--- a/net/sched/sch_choke.c
+++ b/net/sched/sch_choke.c
@@ -141,63 +141,24 @@ static void choke_drop_by_idx(struct Qdisc *sch, unsigned int idx)
--sch->q.qlen;
}
-/* Make sure network and transport headers can be dereferenced */
-static bool choke_linearize_header(struct sk_buff *skb)
-{
- int nhoff, poff;
- struct ipv6hdr *ip6;
- struct iphdr *ip;
- u8 ip_proto;
- u32 ihl;
-
- nhoff = skb_network_offset(skb);
-
- switch (skb->protocol) {
- case __constant_htons(ETH_P_IP):
- if (!pskb_may_pull(skb, sizeof(*ip) + nhoff))
- return false;
-
- ip = (struct iphdr *) (skb->data + nhoff);
- if (ip->frag_off & htons(IP_MF | IP_OFFSET))
- return false;
-
- ip_proto = ip->protocol;
- ihl = ip->ihl;
- break;
- case __constant_htons(ETH_P_IPV6):
- if (!pskb_may_pull(skb, sizeof(*ip6) + nhoff))
- return false;
-
- ip6 = (struct ipv6hdr *) (skb->data + nhoff);
- ip_proto = ip6->nexthdr;
- ihl = (40 >> 2);
- break;
- default:
- return true;
- }
-
- poff = proto_ports_offset(ip_proto);
- if (poff >= 0) {
- nhoff += ihl * 4 + poff;
- if (!pskb_may_pull(skb, nhoff + 4))
- return false;
- }
-
- return true;
-}
-
/*
* Compare flow of two packets
* Returns true only if source and destination address and port match.
* false for special cases
*/
-static bool choke_match_flow(const struct sk_buff *skb1,
- const struct sk_buff *skb2)
+static bool choke_match_flow(struct sk_buff *skb1,
+ struct sk_buff *skb2)
{
int off1, off2, poff;
+ const u32 *ports1, *ports2;
+ u8 ip_proto;
if (skb1->protocol != skb2->protocol)
return false;
+ if (skb_get_rxhash(skb1) != skb_get_rxhash(skb2))
+ return false;
+ if (!skb_get_rxhash(skb1))
+ return true;
off1 = skb_network_offset(skb1);
off2 = skb_network_offset(skb2);
@@ -209,27 +170,14 @@ static bool choke_match_flow(const struct sk_buff *skb1,
ip1 = (struct iphdr *) (skb1->data + off1);
ip2 = (struct iphdr *) (skb2->data + off2);
- if (ip1->protocol != ip2->protocol ||
+ ip_proto = ip1->protocol;
+ if (ip_proto != ip2->protocol ||
ip1->saddr != ip2->saddr || ip1->daddr != ip2->daddr)
return false;
-
- if (ip1->frag_off & htons(IP_MF | IP_OFFSET) ||
- ip2->frag_off & htons(IP_MF | IP_OFFSET))
- return ip1->id == ip2->id;
-
- poff = proto_ports_offset(ip1->protocol);
- if (poff < 0)
- return true;
- else {
- const u32 *ports1, *ports2;
-
- ports1 = (__force u32 *) (skb1->data + off1
- + ip1->ihl * 4 + poff);
- ports2 = (__force u32 *) (skb2->data + off2
- + ip2->ihl * 4 + poff);
-
- return *ports1 == *ports2;
- }
+ if ((ip1->frag_off | ip2->frag_off) & htons(IP_MF | IP_OFFSET))
+ ip_proto = 0;
+ off1 += ip1->ihl * 4;
+ off2 += ip2->ihl * 4;
break;
}
@@ -239,15 +187,32 @@ static bool choke_match_flow(const struct sk_buff *skb1,
ip1 = (struct ipv6hdr *) (skb1->data + off1);
ip2 = (struct ipv6hdr *) (skb2->data + off2);
- return (ip1->nexthdr == ip2->nexthdr &&
- ipv6_addr_cmp(&ip1->saddr, &ip2->saddr) == 0 &&
- ipv6_addr_cmp(&ip1->daddr, &ip2->daddr) == 0);
+ ip_proto = ip1->nexthdr;
+ if (ip_proto != ip2->nexthdr ||
+ ipv6_addr_cmp(&ip1->saddr, &ip2->saddr) ||
+ ipv6_addr_cmp(&ip1->daddr, &ip2->daddr))
+ return false;
+ off1 += 40;
+ off2 += 40;
}
default: /* Maybe compare MAC header here? */
return false;
}
- /* not reached */
+ poff = proto_ports_offset(ip_proto);
+ if (poff < 0)
+ return true;
+ off1 += poff;
+ off2 += poff;
+ if (!pskb_may_pull(skb1, off1 + 4))
+ return false;
+
+ if (!pskb_may_pull(skb2, off2 + 4))
+ return false;
+
+ ports1 = (__force u32 *)(skb1->data + off1);
+ ports2 = (__force u32 *)(skb2->data + off2);
+ return *ports1 == *ports2;
}
static inline void choke_set_classid(struct sk_buff *skb, u16 classid)
@@ -319,10 +284,10 @@ static struct sk_buff *choke_peek_random(const struct choke_sched_data *q,
* returns true if matched and sets *pidx
*/
static bool choke_match_random(const struct choke_sched_data *q,
- const struct sk_buff *nskb,
+ struct sk_buff *nskb,
unsigned int *pidx)
{
- const struct sk_buff *oskb;
+ struct sk_buff *oskb;
if (q->head == q->tail)
return false;
@@ -331,7 +296,6 @@ static bool choke_match_random(const struct choke_sched_data *q,
if (q->filter_list)
return choke_get_classid(nskb) == choke_get_classid(oskb);
-
return choke_match_flow(oskb, nskb);
}
@@ -345,10 +309,6 @@ static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
/* If using external classifiers, get result and record it. */
if (!choke_classify(skb, sch, &ret))
goto other_drop; /* Packet was eaten by filter */
- } else {
- /* for internal classifier, make header accessible */
- if (!choke_linearize_header(skb))
- goto other_drop;
}
/* Compute average queue usage (see RED) */
^ permalink raw reply related
* Re: [GIT] Networking
From: Colin Walters @ 2011-01-20 22:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Dumazet, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTikLY1B3=C2TjAbYKVHbub-aPeG2heaUBWRUAg=R@mail.gmail.com>
On Thu, Jan 20, 2011 at 5:21 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jan 20, 2011 at 1:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>> Then here ask for fd=3 both POLLIN and POLLOUT :
>> kernel answers : OK for POLLOUT (not POLLIN), so previous poll() call
>> was OK to be blocked after all...
>>
>> So I'm wondering if it could be a userland bug, that triggers with
>> recent kernel changes.
>
> As far as I can tell, that program isn't multi-threaded
It is actually; see src/gs-auth-pam.c; there is some pretty scary code
there; basically all of PAM is put in a thread to avoid blocking the
mainloop. Whether the code is actually buggy I can't say immediately;
it's certainly possible.
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-01-20 22:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <1295559646.2613.35.camel@edumazet-laptop>
On Thu, Jan 20, 2011 at 1:40 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Then here ask for fd=3 both POLLIN and POLLOUT :
> kernel answers : OK for POLLOUT (not POLLIN), so previous poll() call
> was OK to be blocked after all...
>
> So I'm wondering if it could be a userland bug, that triggers with
> recent kernel changes.
As far as I can tell, that program isn't multi-threaded, and it should
not have returned to user land at all (no signal, and a restart). So I
think it's a kernel-only thing - there should have been nothing that
could have changed the poll list in user space. But I didn't really
check the threading status.
I'm trying to bisect it now to figure out more hints.
Linus
^ permalink raw reply
* [PATCH] Fix NULL dereference in rtlwifi driver
From: Jesper Juhl @ 2011-01-20 22:18 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, linux-wireless, linux-kernel, John W. Linville,
Chaoming Li
In drivers/net/wireless/rtlwifi/pci.c::_rtl_pci_rx_interrupt() we call
dev_alloc_skb(), which may fail and return NULL, but we do not check the
returned value against NULL before dereferencing the returned pointer.
This may lead to a NULL pointer dereference which means we'll crash - not
good.
This patch tries to solve the issue by testing for NULL and bailing out if
we couldn't allocate a skb. However, I don't know this code well, so I'm
not sure that jumping to the 'done' label here is the correct action to
take. Someone more knowledgable about this code than me should definately
review it before it is applied anywhere.
While I was in the area I also moved an assignment in
_rtl_pci_init_rx_ring() a bit - if the dev_alloc_skb() call in that
function fails there's no reason to waste clock cycles assigning to the
local variable 'entry', we may as well do that after the NULL check and
potential bail out.
Here's the proposed patch, but please don't take it as much more than a
bug report. If it happens to be correct, then by all means apply it, but
I'm not personally making any guarantees.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
compile tested only, I don't have the hardware to test for real.
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 0fa36aa..5e99f89 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -619,6 +619,13 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
struct sk_buff *uskb = NULL;
u8 *pdata;
uskb = dev_alloc_skb(skb->len + 128);
+ if (!uskb) {
+ RT_TRACE(rtlpriv,
+ (COMP_INTR | COMP_RECV),
+ DBG_DMESG,
+ ("can't alloc rx skb\n"));
+ goto done;
+ }
memcpy(IEEE80211_SKB_RXCB(uskb),
&rx_status,
sizeof(rx_status));
@@ -1066,9 +1073,9 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
struct sk_buff *skb =
dev_alloc_skb(rtlpci->rxbuffersize);
u32 bufferaddress;
- entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
if (!skb)
return 0;
+ entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
/*skb->dev = dev; */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-01-20 21:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTin32jUnBtHF-EAkSMnFQM6cTbn-G3NZQJ3xjTWU@mail.gmail.com>
Le jeudi 20 janvier 2011 à 13:12 -0800, Linus Torvalds a écrit :
> ...
> read(3, 0x9806500, 4096) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12,
> events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9,
> events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=15,
> events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=0}, {fd=19,
> events=POLLIN}], 10, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
> restart_syscall(
>
Hmm, poll() here on fd=3 only asks events=POLLIN
> and that's it - it's now hung. So why did it work when I straced it
> while hung? And why is it doing that ERESTART_RESTARTBLOCK in the
> first place, I'm not seeing any signals there?
>
> So I tried sending it a useless signal, which will re-animate the
> strace, and now I get:
>
> restart_syscall(<... resuming interrupted call ...>) = 1
> --- SIGWINCH (Window changed) @ 0 (0) ---
> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>
Then here ask for fd=3 both POLLIN and POLLOUT :
kernel answers : OK for POLLOUT (not POLLIN), so previous poll() call
was OK to be blocked after all...
So I'm wondering if it could be a userland bug, that triggers with
recent kernel changes.
^ permalink raw reply
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-01-20 21:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <1295558748.2613.28.camel@edumazet-laptop>
Le jeudi 20 janvier 2011 à 22:25 +0100, Eric Dumazet a écrit :
> Do you know the type of socket ? UNIX or INET ?
>
> You could try a revert of 2c6607c611cb7bf0a6750bcea3
> (net: add POLLPRI to sock_def_readable())
>
> But I dont understand how it could hurt...
>
>
>
Another candidate (AF_UNIX side) would be 973a34aa8593dbfe84386343c69
(af_unix: optimize unix_dgram_poll())
Thanks
^ permalink raw reply
* Re: [GIT] Networking
From: Rafael J. Wysocki @ 2011-01-20 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel, Tejun Heo
In-Reply-To: <AANLkTin32jUnBtHF-EAkSMnFQM6cTbn-G3NZQJ3xjTWU@mail.gmail.com>
On Thursday, January 20, 2011, Linus Torvalds wrote:
> On Wed, Jan 19, 2011 at 6:04 PM, David Miller <davem@davemloft.net> wrote:
> >
> > 1) Revert a netlink flag sanity check that is causing regressions in
> > existing applications.
> ...
>
> This is a long-shot, but I thought I'd ask before I start trying to
> bisect the fourth independent suspend/resume related issue in this
> merge window..
>
> When I suspend/resume while logged in by closing the lid on my laptop
> on FC14, it causes the gnome-screensaver-dialog to start up. So far so
> fine, that's what I want, and it all works fin in 2.6.37.
>
> But in current -git (and in -rc8, so it's not changed by your latest
> pull request), gnome-screensaver-dialog gets stuck after I type in my
> password, making the box basically useless.
>
> So I straced it over the network, and if I attach _when_ it is already
> stuck, it immediately becomes unstuck. But if I attach to it before
> typing my password, I can see the hang in strace, and it looks like
> this:
>
> ...
> read(3, 0x9806500, 4096) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12,
> events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9,
> events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=15,
> events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=0}, {fd=19,
> events=POLLIN}], 10, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
> restart_syscall(
>
> and that's it - it's now hung. So why did it work when I straced it
> while hung? And why is it doing that ERESTART_RESTARTBLOCK in the
> first place, I'm not seeing any signals there?
>
> So I tried sending it a useless signal, which will re-animate the
> strace, and now I get:
>
> restart_syscall(<... resuming interrupted call ...>) = 1
> --- SIGWINCH (Window changed) @ 0 (0) ---
> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>
> Whee. That signal got it started again, and the poll finished immediately.
>
> And how/why did the input to the poll apparently change? That looks
> suspicious too. Might be some odd strace artifact, but whatever.
>
> So I'm contacting you because that fd=3 is a socket (I didn't check
> details), and because anything I find in the git logs that discusses
> "poll" seems to be network-related. So I'm wondering it this rings any
> bells, because bisecting this is going to be painful as hell (since I
> have to carefully work around all the _other_ problems I've bisected
> on that machine while doing so).
This is a long shot too, but perhaps it's related to
8cfe400 Freezer: Fix a race during freezing of TASK_STOPPED tasks
(adding Tejun to the CC just in case).
Rafael
^ permalink raw reply
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-01-20 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, akpm, netdev, linux-kernel
In-Reply-To: <AANLkTin32jUnBtHF-EAkSMnFQM6cTbn-G3NZQJ3xjTWU@mail.gmail.com>
Le jeudi 20 janvier 2011 à 13:12 -0800, Linus Torvalds a écrit :
> On Wed, Jan 19, 2011 at 6:04 PM, David Miller <davem@davemloft.net> wrote:
> >
> > 1) Revert a netlink flag sanity check that is causing regressions in
> > existing applications.
> ...
>
> This is a long-shot, but I thought I'd ask before I start trying to
> bisect the fourth independent suspend/resume related issue in this
> merge window..
>
> When I suspend/resume while logged in by closing the lid on my laptop
> on FC14, it causes the gnome-screensaver-dialog to start up. So far so
> fine, that's what I want, and it all works fin in 2.6.37.
>
> But in current -git (and in -rc8, so it's not changed by your latest
> pull request), gnome-screensaver-dialog gets stuck after I type in my
> password, making the box basically useless.
>
> So I straced it over the network, and if I attach _when_ it is already
> stuck, it immediately becomes unstuck. But if I attach to it before
> typing my password, I can see the hang in strace, and it looks like
> this:
>
> ...
> read(3, 0x9806500, 4096) = -1 EAGAIN (Resource
> temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12,
> events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9,
> events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=15,
> events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=0}, {fd=19,
> events=POLLIN}], 10, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
> restart_syscall(
>
> and that's it - it's now hung. So why did it work when I straced it
> while hung? And why is it doing that ERESTART_RESTARTBLOCK in the
> first place, I'm not seeing any signals there?
>
> So I tried sending it a useless signal, which will re-animate the
> strace, and now I get:
>
> restart_syscall(<... resuming interrupted call ...>) = 1
> --- SIGWINCH (Window changed) @ 0 (0) ---
> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>
> Whee. That signal got it started again, and the poll finished immediately.
>
> And how/why did the input to the poll apparently change? That looks
> suspicious too. Might be some odd strace artifact, but whatever.
>
> So I'm contacting you because that fd=3 is a socket (I didn't check
> details), and because anything I find in the git logs that discusses
> "poll" seems to be network-related. So I'm wondering it this rings any
> bells, because bisecting this is going to be painful as hell (since I
> have to carefully work around all the _other_ problems I've bisected
> on that machine while doing so).
>
Do you know the type of socket ? UNIX or INET ?
You could try a revert of 2c6607c611cb7bf0a6750bcea3
(net: add POLLPRI to sock_def_readable())
But I dont understand how it could hurt...
^ permalink raw reply
* Re: [GIT] Networking
From: Linus Torvalds @ 2011-01-20 21:12 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, linux-kernel
In-Reply-To: <20110119.180418.216749267.davem@davemloft.net>
On Wed, Jan 19, 2011 at 6:04 PM, David Miller <davem@davemloft.net> wrote:
>
> 1) Revert a netlink flag sanity check that is causing regressions in
> existing applications.
...
This is a long-shot, but I thought I'd ask before I start trying to
bisect the fourth independent suspend/resume related issue in this
merge window..
When I suspend/resume while logged in by closing the lid on my laptop
on FC14, it causes the gnome-screensaver-dialog to start up. So far so
fine, that's what I want, and it all works fin in 2.6.37.
But in current -git (and in -rc8, so it's not changed by your latest
pull request), gnome-screensaver-dialog gets stuck after I type in my
password, making the box basically useless.
So I straced it over the network, and if I attach _when_ it is already
stuck, it immediately becomes unstuck. But if I attach to it before
typing my password, I can see the hang in strace, and it looks like
this:
...
read(3, 0x9806500, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=12,
events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=9,
events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=15,
events=POLLIN}, {fd=16, events=POLLIN}, {fd=17, events=0}, {fd=19,
events=POLLIN}], 10, -1) = ? ERESTART_RESTARTBLOCK (To be restarted)
restart_syscall(
and that's it - it's now hung. So why did it work when I straced it
while hung? And why is it doing that ERESTART_RESTARTBLOCK in the
first place, I'm not seeing any signals there?
So I tried sending it a useless signal, which will re-animate the
strace, and now I get:
restart_syscall(<... resuming interrupted call ...>) = 1
--- SIGWINCH (Window changed) @ 0 (0) ---
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
Whee. That signal got it started again, and the poll finished immediately.
And how/why did the input to the poll apparently change? That looks
suspicious too. Might be some odd strace artifact, but whatever.
So I'm contacting you because that fd=3 is a socket (I didn't check
details), and because anything I find in the git logs that discusses
"poll" seems to be network-related. So I'm wondering it this rings any
bells, because bisecting this is going to be painful as hell (since I
have to carefully work around all the _other_ problems I've bisected
on that machine while doing so).
Linus
^ permalink raw reply
* Re: [Bugme-new] [Bug 27212] New: Warning kmemcheck: Caught 64-bit read from uninitialized memory in netlink_broadcast_filtered
From: Eric Dumazet @ 2011-01-20 20:41 UTC (permalink / raw)
To: Andrew Morton
Cc: netdev, bugzilla-daemon, bugme-daemon, casteyde.christian,
Changli Gao, Vegard Nossum, Pekka Enberg
In-Reply-To: <20110120122549.85863a84.akpm@linux-foundation.org>
Le jeudi 20 janvier 2011 à 12:25 -0800, Andrew Morton a écrit :
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 20 Jan 2011 20:08:32 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > https://bugzilla.kernel.org/show_bug.cgi?id=27212
> >
> > Summary: Warning kmemcheck: Caught 64-bit read from
> > uninitialized memory in netlink_broadcast_filtered
> > Product: Other
> > Version: 2.5
> > Kernel Version: 2.6.38-rc1
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > AssignedTo: other_other@kernel-bugs.osdl.org
> > ReportedBy: casteyde.christian@free.fr
> > Regression: Yes
> >
> >
> > Athlon 64 X2 3000 in 64bits
> > Slackware64 13.1
> > Kernel compiled with kmemcheck and other debug options
> >
> > At boot I got the following warning:
> >
> > PCI: Using ACPI for IRQ routing
> > PCI: pci_cache_line_size set to 64 bytes
> > pci 0000:00:00.0: address space collision: [mem 0xe0000000-0xefffffff pref]
> > conflicts with GART [mem 0x
> > e0000000-0xefffffff]
> > reserve RAM buffer: 000000000009fc00 - 000000000009ffff
> > reserve RAM buffer: 000000003ffb0000 - 000000003fffffff
> > WARNING: kmemcheck: Caught 64-bit read from uninitialized memory
> > (ffff88003e170eb0)
> > 0000000000000000010000000000000000000000000000000000000000000000
> > i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u u
> > ^
> >
> > Pid: 1, comm: swapper Not tainted 2.6.38-rc1 #2 K8 Combo-Z/K8 Combo-Z
> > RIP: 0010:[<ffffffff8127ad72>] [<ffffffff8127ad72>] memmove+0x122/0x1a0
> > RSP: 0018:ffff88003e0b3c60 EFLAGS: 00010202
> > RAX: ffff88003e170080 RBX: ffff88003e27b500 RCX: 0000000000000020
> > RDX: 0000000000000018 RSI: ffff88003e170ea0 RDI: ffff88003e1700a0
> > RBP: ffff88003e0b3c60 R08: 0000000000000001 R09: 0000000000000001
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000001
> > FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > CR2: ffff88003e018abc CR3: 0000000001a1c000 CR4: 00000000000006f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
> > [<ffffffff814741c2>] pskb_expand_head+0xc2/0x2a0
> > [<ffffffff81498fa7>] netlink_broadcast_filtered+0xa7/0x4a0
> > [<ffffffff814993b8>] netlink_broadcast+0x18/0x20
> > [<ffffffff8149b884>] genlmsg_mcast+0x144/0x180
> > [<ffffffff8149bc4a>] genl_ctrl_event+0xca/0x450
> > [<ffffffff8149c75d>] genl_register_mc_group+0x10d/0x2a0
> > [<ffffffff81ad9da4>] genl_init+0x6c/0x84
> > [<ffffffff810001de>] do_one_initcall+0x3e/0x170
> > [<ffffffff81aae6ea>] kernel_init+0x197/0x21b
> > [<ffffffff81003254>] kernel_thread_helper+0x4/0x10
> > [<ffffffffffffffff>] 0xffffffffffffffff
> > pnp: PnP ACPI init
> > ACPI: bus type pnp registered
> > pnp 00:00: [bus 00-ff]
> > pnp 00:00: [io 0x0cf8-0x0cff]
> >
> > This is specific to 2.6.38-rc1.
> >
>
Likely a false positive after commit ca44ac38
(net: don't reallocate skb->head unless the current one hasn't the
needed extra size or is shared)
ksize() allows us to use a bit more than what was asked at kmalloc()
time, because of discrete kmem caches sizes.
We probably need to instruct kmemcheck of this.
^ 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