* Re: DDoS attack causing bad effect on conntrack searches
From: Eric Dumazet @ 2010-06-01 5:05 UTC (permalink / raw)
To: Changli Gao
Cc: hawk, Jesper Dangaard Brouer, paulmck, Patrick McHardy,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <AANLkTikw3uonDB4nPXg8FVFN_07F_wq0SA_ayyAHL6VM@mail.gmail.com>
Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > I had a look at current conntrack and found the 'unconfirmed' list was
> > maybe a candidate for a potential blackhole.
> >
> > That is, if a reader happens to hit an entry that is moved from regular
> > hash table slot 'hash' to unconfirmed list,
>
> Sorry, but I can't find where we do this things. unconfirmed list is
> used to track the unconfirmed cts, whose corresponding skbs are still
> in path from the first to the last netfilter hooks. As soon as the
> skbs end their travel in netfilter, the corresponding cts will be
> confirmed(moving ct from unconfirmed list to regular hash table).
>
So netfilter is a monolithic thing.
When a packet begins its travel into netfilter, you guarantee that no
other packet can also begin its travel and find an unconfirmed
conntrack ?
I wonder why we use atomic ops then to track the confirmed bit :)
> unconfirmed list should be small, as networking receiving is in BH.
So according to you, netfilter/ct runs only in input path ?
So I assume a packet is handled by CPU X, creates a new conntrack
(possibly early droping an old entry that was previously in a standard
hash chain), inserted in unconfirmed list. _You_ guarantee another CPU
Y, handling another packet, possibly sent by a hacker reading your
netdev mails, cannot find the conntrack that was early dropped ?
> How about implementing unconfirmed list as a per cpu variable?
I first implemented such a patch to reduce cache line contention, then I
asked to myself : What is exactly an unconfirmed conntrack ? Can their
number be unbounded ? If yes, we have a problem, even on a two cpus
machine. Using two lists instead of one wont solve the fundamental
problem.
The real question is, why do we need this unconfirmed 'list' in the
first place. Is it really a private per cpu thing ? Can you prove this,
in respect of lockless lookups, and things like NFQUEUE ?
Each conntrack object has two list anchors. One for IP_CT_DIR_ORIGINAL,
one for IP_CT_DIR_REPLY.
Unconfirmed list use the first anchor. This means another cpu can
definitely find an unconfirmed item in a regular hash chain, since we
dont respect an RCU grace period before re-using an object.
If memory was not a problem, we probably would use a third anchor to
avoid this, or regular RCU instead of SLAB_DESTROY_BY_RCU variant.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: DDoS attack causing bad effect on conntrack searches
From: Changli Gao @ 2010-06-01 5:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: hawk, Jesper Dangaard Brouer, paulmck, Patrick McHardy,
Linux Kernel Network Hackers, Netfilter Developers
In-Reply-To: <1275368732.2478.88.camel@edumazet-laptop>
On Tue, Jun 1, 2010 at 1:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
>> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >
>> > I had a look at current conntrack and found the 'unconfirmed' list was
>> > maybe a candidate for a potential blackhole.
>> >
>> > That is, if a reader happens to hit an entry that is moved from regular
>> > hash table slot 'hash' to unconfirmed list,
>>
>> Sorry, but I can't find where we do this things. unconfirmed list is
>> used to track the unconfirmed cts, whose corresponding skbs are still
>> in path from the first to the last netfilter hooks. As soon as the
>> skbs end their travel in netfilter, the corresponding cts will be
>> confirmed(moving ct from unconfirmed list to regular hash table).
>>
>
> So netfilter is a monolithic thing.
>
> When a packet begins its travel into netfilter, you guarantee that no
> other packet can also begin its travel and find an unconfirmed
> conntrack ?
>
> I wonder why we use atomic ops then to track the confirmed bit :)
seems no need.
>
>
>> unconfirmed list should be small, as networking receiving is in BH.
>
> So according to you, netfilter/ct runs only in input path ?
No. there are another entrances: local out and nf_reinject. If there
isn't any packet queued, as netfilter is in atomic context, the nubmer
of unconfirmed cts should be small( at most, 2 * nr_cpu?).
>
> So I assume a packet is handled by CPU X, creates a new conntrack
> (possibly early droping an old entry that was previously in a standard
> hash chain), inserted in unconfirmed list.
>
Oh, Thanks, I got it.
> _You_ guarantee another CPU
> Y, handling another packet, possibly sent by a hacker reading your
> netdev mails, cannot find the conntrack that was early dropped ?
>
>> How about implementing unconfirmed list as a per cpu variable?
>
> I first implemented such a patch to reduce cache line contention, then I
> asked to myself : What is exactly an unconfirmed conntrack ? Can their
> number be unbounded ? If yes, we have a problem, even on a two cpus
> machine. Using two lists instead of one wont solve the fundamental
> problem.
>
> The real question is, why do we need this unconfirmed 'list' in the
> first place. Is it really a private per cpu thing ?
No, it isn't really private. But most of time, it is accessed locally,
if it is implemented as a per cpu var.
> Can you prove this,
> in respect of lockless lookups, and things like NFQUEUE ?
>
> Each conntrack object has two list anchors. One for IP_CT_DIR_ORIGINAL,
> one for IP_CT_DIR_REPLY.
>
> Unconfirmed list use the first anchor. This means another cpu can
> definitely find an unconfirmed item in a regular hash chain, since we
> dont respect an RCU grace period before re-using an object.
>
> If memory was not a problem, we probably would use a third anchor to
> avoid this, or regular RCU instead of SLAB_DESTROY_BY_RCU variant.
>
thanks for your explaining.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] can: mpc5xxx_can.c: Fix build failure
From: Wolfgang Grandegger @ 2010-06-01 6:20 UTC (permalink / raw)
To: Anatolij Gustschin
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, Grant Likely
In-Reply-To: <4C03FF75.3010208-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On 05/31/2010 08:27 PM, Wolfgang Grandegger wrote:
> Hi Anatolij,
>
> On 05/31/2010 06:31 PM, Anatolij Gustschin wrote:
>> Fixes build error caused by the OF device_node pointer
>> being moved into struct device.
>>
>> Signed-off-by: Anatolij Gustschin <agust-ynQEQJNshbs@public.gmane.org>
>> Cc: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
>> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH] net: sock_queue_err_skb() dont mess with sk_forward_alloc
From: David Miller @ 2010-06-01 6:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: anton, netdev
In-Reply-To: <1275321766.3291.100.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 31 May 2010 18:02:46 +0200
> There is also a problem in ip_recv_error(), not called with socket
> locked, skb freed -> potential corruption.
>
> If current socket is 'owned' by a user thread, then we can still corrupt
> sk_forward_alloc, even if we use bh_lock_sock()
>
> I dont think we need to have another backlog for such case, maybe we
> could account for skb->truesize in sk_rmem_alloc (this is atomic), and
> not account for sk_mem_charge ?
That sounds fine to me.
> [PATCH] net: sock_queue_err_skb() dont mess with sk_forward_alloc
>
> Correct sk_forward_alloc handling for error_queue would need to use a
> backlog of frames that softirq handler could not deliver because socket
> is owned by user thread. Or extend backlog processing to be able to
> process normal and error packets.
>
> Another possibility is to not use mem charge for error queue, this is
> what I implemented in this patch.
>
> Note: this reverts commit 29030374
> (net: fix sk_forward_alloc corruptions), since we dont need to lock
> socket anymore.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter fixes
From: David Miller @ 2010-06-01 6:45 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1275322487-19026-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Mon, 31 May 2010 18:14:45 +0200
> the following two patches fix two problems with the recent introduction of
> a seperately allocated jumpstack for xtables rulesets:
>
> - a memory leak when registering new tables, from Xiaotian Feng
>
> - performance degradation caused by not using per-CPU allocations
> for the jumpstack, from Eric
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks Patrick.
^ permalink raw reply
* Re: [PATCH] net/ipv4/tcp_input.c: fix compilation breakage when FASTRETRANS_DEBUG > 1
From: David Miller @ 2010-06-01 6:48 UTC (permalink / raw)
To: joe; +Cc: netdev, eric.dumazet
In-Reply-To: <1275330055.14079.8.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 11:20:55 -0700
> Commit: c720c7e8383aff1cb219bddf474ed89d850336e3 missed these.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* [PATCH] be2net: convert hdr.timeout in be_cmd_loopback_test() to le32
From: Sathya Perla @ 2010-06-01 7:01 UTC (permalink / raw)
To: netdev
The current code fails on ppc as hdr.timeout is not being converted
to le32.
Pls apply to net-2.6.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_cmds.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 9e305d7..b9ad799 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1593,7 +1593,7 @@ int be_cmd_loopback_test(struct be_adapter *adapter, u32 port_num,
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_LOWLEVEL,
OPCODE_LOWLEVEL_LOOPBACK_TEST, sizeof(*req));
- req->hdr.timeout = 4;
+ req->hdr.timeout = cpu_to_le32(4);
req->pattern = cpu_to_le64(pattern);
req->src_port = cpu_to_le32(port_num);
--
1.6.5.2
^ permalink raw reply related
* [patch 1/2] caif: remove unneeded variable from caif_net_open()
From: Dan Carpenter @ 2010-06-01 7:08 UTC (permalink / raw)
To: Sjur Braendeland; +Cc: netdev, David S. Miller, kernel-janitors
We don't use the "ser" variable so I've removed it.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index 09257ca..f30a6a0 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -410,8 +410,6 @@ static void caifdev_setup(struct net_device *dev)
static int caif_net_open(struct net_device *dev)
{
- struct ser_device *ser;
- ser = netdev_priv(dev);
netif_wake_queue(dev);
return 0;
}
^ permalink raw reply related
* [patch 2/2] caif: add newlines after declarations in caif_serial.c
From: Dan Carpenter @ 2010-06-01 7:09 UTC (permalink / raw)
To: Sjur Braendeland; +Cc: netdev, kernel-janitors, David S. Miller
I added newlines after the declarations in caif_serial.c. This is
normal kernel style, although I can't see anywhere it's documented.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index f30a6a0..3e706f0 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -174,6 +174,7 @@ static void ldisc_receive(struct tty_struct *tty, const u8 *data,
struct ser_device *ser;
int ret;
u8 *p;
+
ser = tty->disc_data;
/*
@@ -221,6 +222,7 @@ static int handle_tx(struct ser_device *ser)
struct tty_struct *tty;
struct sk_buff *skb;
int tty_wr, len, room;
+
tty = ser->tty;
ser->tx_started = true;
@@ -281,6 +283,7 @@ error:
static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ser_device *ser;
+
BUG_ON(dev == NULL);
ser = netdev_priv(dev);
@@ -299,6 +302,7 @@ static int caif_xmit(struct sk_buff *skb, struct net_device *dev)
static void ldisc_tx_wakeup(struct tty_struct *tty)
{
struct ser_device *ser;
+
ser = tty->disc_data;
BUG_ON(ser == NULL);
BUG_ON(ser->tty != tty);
@@ -348,6 +352,7 @@ static void ldisc_close(struct tty_struct *tty)
struct ser_device *ser = tty->disc_data;
/* Remove may be called inside or outside of rtnl_lock */
int islocked = rtnl_is_locked();
+
if (!islocked)
rtnl_lock();
/* device is freed automagically by net-sysfs */
@@ -374,6 +379,7 @@ static struct tty_ldisc_ops caif_ldisc = {
static int register_ldisc(void)
{
int result;
+
result = tty_register_ldisc(N_CAIF, &caif_ldisc);
if (result < 0) {
pr_err("cannot register CAIF ldisc=%d err=%d\n", N_CAIF,
@@ -391,6 +397,7 @@ static const struct net_device_ops netdev_ops = {
static void caifdev_setup(struct net_device *dev)
{
struct ser_device *serdev = netdev_priv(dev);
+
dev->features = 0;
dev->netdev_ops = &netdev_ops;
dev->type = ARPHRD_CAIF;
@@ -423,6 +430,7 @@ static int caif_net_close(struct net_device *dev)
static int __init caif_ser_init(void)
{
int ret;
+
ret = register_ldisc();
debugfsdir = debugfs_create_dir("caif_serial", NULL);
return ret;
@@ -433,6 +441,7 @@ static void __exit caif_ser_exit(void)
struct ser_device *ser = NULL;
struct list_head *node;
struct list_head *_tmp;
+
list_for_each_safe(node, _tmp, &ser_list) {
ser = list_entry(node, struct ser_device, node);
dev_close(ser->dev);
^ permalink raw reply related
* [PATCH] greth: Fix build after OF device conversions.
From: David Miller @ 2010-06-01 7:10 UTC (permalink / raw)
To: grant.likely; +Cc: netdev
Signed-off-by: David S. Miller <davem@davemloft.net>
---
I've pushed this to net-2.6
drivers/net/greth.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index f37a4c1..3a029d0 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -1607,14 +1607,13 @@ static struct of_device_id greth_of_match[] = {
MODULE_DEVICE_TABLE(of, greth_of_match);
static struct of_platform_driver greth_of_driver = {
- .name = "grlib-greth",
- .match_table = greth_of_match,
+ .driver = {
+ .name = "grlib-greth",
+ .owner = THIS_MODULE,
+ .of_match_table = greth_of_match,
+ },
.probe = greth_of_probe,
.remove = __devexit_p(greth_of_remove),
- .driver = {
- .owner = THIS_MODULE,
- .name = "grlib-greth",
- },
};
static int __init greth_init(void)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] can: mpc5xxx_can.c: Fix build failure
From: David Miller @ 2010-06-01 7:11 UTC (permalink / raw)
To: wg; +Cc: agust, socketcan-core, netdev, grant.likely
In-Reply-To: <4C04A6C2.2090705@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Tue, 01 Jun 2010 08:20:50 +0200
> On 05/31/2010 08:27 PM, Wolfgang Grandegger wrote:
>> Hi Anatolij,
>>
>> On 05/31/2010 06:31 PM, Anatolij Gustschin wrote:
>>> Fixes build error caused by the OF device_node pointer
>>> being moved into struct device.
>>>
>>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>>> Cc: Wolfgang Grandegger <wg@grandegger.com>
>>> Cc: Grant Likely <grant.likely@secretlab.ca>
>
> Acked-by: Wolfgang Grandegger <wg@grandegger.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 19/21] net/ipv4/igmp.c: Remove unnecessary kmalloc casts
From: David Miller @ 2010-06-01 7:17 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <cac9f44ad085db78698681859236a7c3a0983e49.1275360951.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 20:23:21 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 20/21] net/ipv6/mcast.c: Remove unnecessary kmalloc casts
From: David Miller @ 2010-06-01 7:17 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <52b8781064af8d4b1051f5ac175f7b7f175ff1ed.1275360951.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 20:23:22 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 10/21] drivers/net/gianfar.c: Remove unnecessary kmalloc casts
From: David Miller @ 2010-06-01 7:17 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, netdev
In-Reply-To: <787b5a04a6f7f854b0809c4358671d3d69f70efc.1275360951.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 20:23:12 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 11/21] drivers/net/tulip/eeprom.c: Remove unnecessary kmalloc casts
From: David Miller @ 2010-06-01 7:17 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, grundler, kyle, netdev
In-Reply-To: <4fc0e008a2fc826c5696c07bf25a68440e36353b.1275360951.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Mon, 31 May 2010 20:23:13 -0700
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] tulip: explicity set to D0 power state during init
From: David Miller @ 2010-06-01 7:18 UTC (permalink / raw)
To: stevenrwalter; +Cc: grundler, kyle, netdev
In-Reply-To: <1275361913-5630-1-git-send-email-stevenrwalter@gmail.com>
From: Steven Walter <stevenrwalter@gmail.com>
Date: Mon, 31 May 2010 23:11:53 -0400
> During the first suspend the chip would refuse to enter D3. Subsequent
> suspends worked okay. During resume the chip is commanded into D0.
> Doing so during initialization fixes the initial suspend.
>
> Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
> Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] tulip: implement wake-on-lan support
From: David Miller @ 2010-06-01 7:18 UTC (permalink / raw)
To: stevenrwalter; +Cc: grundler, kyle, netdev
In-Reply-To: <1275345283-10650-2-git-send-email-stevenrwalter@gmail.com>
From: Steven Walter <stevenrwalter@gmail.com>
Date: Mon, 31 May 2010 18:34:43 -0400
> Based on a patch from http://simon.baatz.info/wol-support-for-an983b/
>
> Tested to resume from suspend by magic packet.
>
> Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] r6040: implement phylib
From: David Miller @ 2010-06-01 7:18 UTC (permalink / raw)
To: florian; +Cc: netdev
In-Reply-To: <201005312118.58728.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 31 May 2010 21:18:57 +0200
> This patch adds support for using phylib and adds the required mdiobus driver
> stubs. This allows for less code to be present in the driver and removes
> the PHY status specific timer which is now handled by phylib directly.
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/2] r6040: bump version to 0.26 and date to 30 May 2010
From: David Miller @ 2010-06-01 7:18 UTC (permalink / raw)
To: florian; +Cc: netdev
In-Reply-To: <201005312119.04553.florian@openwrt.org>
From: Florian Fainelli <florian@openwrt.org>
Date: Mon, 31 May 2010 21:19:04 +0200
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] ixp4xx: Support the all multicast flag on the NPE devices.
From: David Miller @ 2010-06-01 7:18 UTC (permalink / raw)
To: khc; +Cc: richardcochran, netdev, linux-arm-kernel
In-Reply-To: <m3typoyr86.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Mon, 31 May 2010 18:24:09 +0200
> Richard Cochran <richardcochran@gmail.com> writes:
>
>> This patch adds support for the IFF_ALLMULTI flag. Previously only the
>> IFF_PROMISC flag was supported.
>>
>> Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
...
> Acked-By: Krzysztof Halasa <khc@pm.waw.pl>
Applied.
^ permalink raw reply
* RE: [patch 1/2] caif: remove unneeded variable from caif_net_open()
From: Sjur BRENDELAND @ 2010-06-01 7:19 UTC (permalink / raw)
To: Dan Carpenter
Cc: netdev@vger.kernel.org, David S. Miller,
kernel-janitors@vger.kernel.org
In-Reply-To: <20100601070855.GD5483@bicker>
Dan Carpenter wrote:
> We don't use the "ser" variable so I've removed it.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Looks good thanks,
Acked-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
^ permalink raw reply
* Re: [PATCH] be2net: convert hdr.timeout in be_cmd_loopback_test() to le32
From: David Miller @ 2010-06-01 7:19 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100601070122.GA2608@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Tue, 1 Jun 2010 12:31:22 +0530
> The current code fails on ppc as hdr.timeout is not being converted
> to le32.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/2] be2net: cleanup in case of error in be_open()
From: David Miller @ 2010-06-01 7:19 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100531093345.GA2812@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 31 May 2010 15:03:45 +0530
> This patch adds cleanup code (things like unregistering irq,
> disabling napi etc) to be_open() when an error occurs inside the
> routine.
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] be2net: replace udelay() with schedule_timeout() in mbox polling
From: David Miller @ 2010-06-01 7:19 UTC (permalink / raw)
To: sathyap; +Cc: netdev
In-Reply-To: <20100531093414.GA2867@serverengines.com>
From: Sathya Perla <sathyap@serverengines.com>
Date: Mon, 31 May 2010 15:04:14 +0530
> As mbox polling is done only in process context, it is better to
> use schedule_timeout() instead of udelay().
>
> Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH] virtio-net: pass gfp to add_buf
From: David Miller @ 2010-06-01 7:22 UTC (permalink / raw)
To: rusty; +Cc: netdev, mst
In-Reply-To: <201005312040.01737.rusty@rustcorp.com.au>
From: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon, 31 May 2010 20:40:01 +0930
> From: "Michael S. Tsirkin" <mst@redhat.com>
>
> (Dave: the virtqueue_add_buf_gfp is in Linus' tree, so please queue
> this trivial use now. Thanks!)
>
> virtio-net bounces buffer allocations off to
> a thread if it can't allocate buffers from the atomic
> pool. However, if posting buffers still requires atomic
> buffers, this is unlikely to succeed.
> Fix by passing in the proper gfp_t parameter.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Your code sucks, and you're wrong.
Please give me positive feedback and tell me how right I am to pump up
my ego or else I will verbally destroy you and make you feel small.
Applied :-)))))))))))))))
^ 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