* Re: Fwd: a Great Idea - include Kademlia networking protocol in kernel -- REVISITED
From: Honglei Cong @ 2010-11-16 16:11 UTC (permalink / raw)
To: Marcos; +Cc: Eric Dumazet, netdev
In-Reply-To: <AANLkTimoZRYssbop-JhryUVae5zy+KFsxny9T4ssHnqE@mail.gmail.com>
On Tue, Nov 16, 2010 at 2:21 PM, Marcos <stalkingtime@gmail.com> wrote:
> [Eric Dumazet wrote:]
>> But we dont want a "super operating system". We want a good one.
>
> Yes, well you have that, I think, speaking at the kernel level. But
> the thing is, people are building tools that mimic such anyway, and
> the next wave of new value will be found there.
>
>> Memory stores done in userland are as fast as memory stores done in
>> kernel.
>
> Really? And how about the abstraction-level? because that will either
> make it lucrative or not for developers to build applications for
> it.....
>
>> Once you need to access files, perform complex searches, timers,
>> logging, and all the stuff, you really want to do it from userland, in
>> high level language that many programmers master, or get something that
>> is too complex/buggy.
>
> Yes, of course, all that will have to be considered. But I'm
> suggesting that such a move is an investment in the future, that the
> the number of machines that will want or request peer-2-peer
> connectivity will (or should) only increase. Done right, such a move
> should *simplify* things. We're biased to think in centralized ways
> because of the centuries-old history of *who* has the resources. But
> as networking, computation, and storage become commodified further,
> whole new topologies for the *right* architecture become available.
> The idea of "the OS" itself morphs. And the *only* way maximize the
Agree with u. But 'kernel' is not.
> value of the network is to make it easy to connect and communicate
> between peers -- what happens after that is so radical it can hardly
> be speculated because it gets into the realm of emergent complexity.
> Again, I refer you to Reed's law on the value of such networks.
>
> marcos
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: Attention Please.
From: Jozef Ruud Roosevelt @ 2010-11-16 16:06 UTC (permalink / raw)
Attention Please,
I am Jozef Ruud Roosevelt, a Dutch National presently residing in
Newcastle United Kingdom, I have a proposition Involving an investment
initiative in your country economy to discuss with you, It will be of
mutual benefit to both of us, and I believe we can handle it together,
once we have a common understanding and mutual cooperation in the
execution of the modalities. I work with Abn Amro Bank as an auditor.
Should you be interested, please e-mail back to me through this email
address: (jozef.rosevelt@yahoo.co.uk).
I await your earliest response.
Yours Sincerely,
Jozef Ruud Roosevel.
^ permalink raw reply
* Re: [PATCH v2] filter: Optimize instruction revalidation code.
From: Eric Dumazet @ 2010-11-16 16:30 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: mjt, davem, drosenberg, netdev
In-Reply-To: <201011162331.CGH00026.OFOSFVMFQtLHOJ@I-love.SAKURA.ne.jp>
Le mardi 16 novembre 2010 à 23:31 +0900, Tetsuo Handa a écrit :
> Eric Dumazet wrote:
> > Patch seems fine to me, with the 'const' codes[] Michael Tokarev already
> > spotted.
>
> Sorry, I forgot to evaluate
>
> default:
> return -EINVAL;
> }
>
> case. If caller passed ftest->code == BPF_S_ALU_DIV_K (translated value)
> rather than ftest->code == BPF_ALU|BPF_DIV|BPF_K (original value), the check
>
> case BPF_ALU|BPF_DIV|BPF_K:
> if (ftest->k == 0)
> return -EINVAL;
> ftest->code = BPF_S_ALU_DIV_K;
> break;
>
> is bypassed. The problem is that original value and translated value overwraps.
> Can we change translated value in order to guarantee that these values never
> overwraps?
I dont understand the problem...
Once translated, you have to test the translated code, not the original
one ;)
> ----------------------------------------
> From 7b6a7b784fa096383aadc86d32bff6b8329a2e66 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Tue, 16 Nov 2010 22:37:45 +0900
> Subject: [PATCH v2] filter: optimize instruction revalidation code.
>
> Since repeating small value to small value conversion using switch() clause's
> case statement is wasteful, this patch instroduces u16 to u16 mapping table
> and removes most of case statements. As a result, the size of net/core/filter.o
> is reduced by about 27% on x86.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> net/core/filter.c | 223 ++++++++++++++++-------------------------------------
> 1 files changed, 68 insertions(+), 155 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 23e9b2a..ef1d226 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -383,7 +383,57 @@ EXPORT_SYMBOL(sk_run_filter);
> */
> int sk_chk_filter(struct sock_filter *filter, int flen)
> {
> - struct sock_filter *ftest;
> + /*
> + * Valid instructions are initialized to non-0.
> + * Invalid instructions are initialized to 0.
> + */
> + static const u16 codes[] = {
why u16 ?
You store translated instructions, so u8 is OK
> + [BPF_ALU|BPF_ADD|BPF_K] = BPF_S_ALU_ADD_K + 1,
> + [BPF_ALU|BPF_ADD|BPF_X] = BPF_S_ALU_ADD_X + 1,
> + [BPF_ALU|BPF_SUB|BPF_K] = BPF_S_ALU_SUB_K + 1,
> + [BPF_ALU|BPF_SUB|BPF_X] = BPF_S_ALU_SUB_X + 1,
> + [BPF_ALU|BPF_MUL|BPF_K] = BPF_S_ALU_MUL_K + 1,
Also fix the indentation at the end of sk_chk_filter()
You have 3 extra tabulations :
/* last instruction must be a RET code */
switch (filter[flen - 1].code) {
case BPF_S_RET_K:
case BPF_S_RET_A:
return 0;
break;
!here! default:
!here! return -EINVAL;
!here! }
}
EXPORT_SYMBOL(sk_chk_filter);
^ permalink raw reply
* [net-next-2.6 PATCH v2] net: zero kobject in rx_queue_release
From: John Fastabend @ 2010-11-16 16:31 UTC (permalink / raw)
To: davem; +Cc: john.r.fastabend, netdev, eric.dumazet, therbert
netif_set_real_num_rx_queues() can decrement and increment
the number of rx queues. For example ixgbe does this as
features and offloads are toggled. Presumably this could
also happen across down/up on most devices if the available
resources changed (cpu offlined).
The kobject needs to be zero'd in this case so that the
state is not preserved across kobject_put()/kobject_init_and_add().
This resolves the following error report.
ixgbe 0000:03:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX
kobject (ffff880324b83210): tried to init an initialized object, something is seriously wrong.
Pid: 1972, comm: lldpad Not tainted 2.6.37-rc18021qaz+ #169
Call Trace:
[<ffffffff8121c940>] kobject_init+0x3a/0x83
[<ffffffff8121cf77>] kobject_init_and_add+0x23/0x57
[<ffffffff8107b800>] ? mark_lock+0x21/0x267
[<ffffffff813c6d11>] net_rx_queue_update_kobjects+0x63/0xc6
[<ffffffff813b5e0e>] netif_set_real_num_rx_queues+0x5f/0x78
[<ffffffffa0261d49>] ixgbe_set_num_queues+0x1c6/0x1ca [ixgbe]
[<ffffffffa0262509>] ixgbe_init_interrupt_scheme+0x1e/0x79c [ixgbe]
[<ffffffffa0274596>] ixgbe_dcbnl_set_state+0x167/0x189 [ixgbe]
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
net/core/net-sysfs.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 3ba526b..7abeb7c 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -711,13 +711,18 @@ static void rx_queue_release(struct kobject *kobj)
map = rcu_dereference_raw(queue->rps_map);
- if (map)
+ if (map) {
+ RCU_INIT_POINTER(queue->rps_map, NULL);
call_rcu(&map->rcu, rps_map_release);
+ }
flow_table = rcu_dereference_raw(queue->rps_flow_table);
- if (flow_table)
+ if (flow_table) {
+ RCU_INIT_POINTER(queue->rps_flow_table, NULL);
call_rcu(&flow_table->rcu, rps_dev_flow_table_release);
+ }
+ memset(kobj, 0, sizeof(*kobj));
dev_put(queue->dev);
}
^ permalink raw reply related
* Re: [PATCH 06/10] drivers/net/usb: Remove unnecessary casts of netdev_priv
From: Petko Manolov @ 2010-11-16 17:59 UTC (permalink / raw)
To: Joe Perches
Cc: Jiri Kosina, Petko Manolov, Greg Kroah-Hartman, linux-usb, netdev,
linux-kernel
In-Reply-To: <66a3d7996e4ce8a84610237e86adf4b15a48514a.1289855436.git.joe@perches.com>
ACK! :-)
Petko
On Mon, 15 Nov 2010, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/usb/pegasus.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
> index 6710f093..ef36676 100644
> --- a/drivers/net/usb/pegasus.c
> +++ b/drivers/net/usb/pegasus.c
> @@ -359,7 +359,7 @@ fail:
>
> static int mdio_read(struct net_device *dev, int phy_id, int loc)
> {
> - pegasus_t *pegasus = (pegasus_t *) netdev_priv(dev);
> + pegasus_t *pegasus = netdev_priv(dev);
> u16 res;
>
> read_mii_word(pegasus, phy_id, loc, &res);
> @@ -397,7 +397,7 @@ fail:
>
> static void mdio_write(struct net_device *dev, int phy_id, int loc, int val)
> {
> - pegasus_t *pegasus = (pegasus_t *) netdev_priv(dev);
> + pegasus_t *pegasus = netdev_priv(dev);
>
> write_mii_word(pegasus, phy_id, loc, val);
> }
> --
> 1.7.3.1.g432b3.dirty
>
>
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] can: Topcliff: PCH_CAN driver: Add Flow control,
From: David Miller @ 2010-11-16 17:11 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
wg-5Yr1BZd7O62+XT7JhA+gdA, kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <001401cb854d$b46e13c0$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
From: "Tomoya MORINAGA" <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Tue, 16 Nov 2010 14:18:26 +0900
> On Monday, November 15, 2010 6:11 PM, Marc Kleine-Budde wrote:
>> Please make it one patch per topic. A review of your patch will follow.
>
> It's too late now.
> This is difficult to separete patch per topic from current our CAN driver.
I am not applying your patches unless you split them up properly.
None of your excuses for not doing this fundamental task are
reasonable.
Thanks.
^ permalink raw reply
* Re: [PATCH] 3c59x: fix build failure on !CONFIG_PCI
From: Randy Dunlap @ 2010-11-16 17:14 UTC (permalink / raw)
To: Namhyung Kim; +Cc: Steffen Klassert, netdev, linux-kernel
In-Reply-To: <1289921271-15295-1-git-send-email-namhyung@gmail.com>
On Wed, 17 Nov 2010 00:27:51 +0900 Namhyung Kim wrote:
> VORTEX_PCI() could return NULL so it needs to be casted before
> accessing any member of struct pci_dev. This fixes following
> build failure. Likewise VORTEX_EISA() was changed also.
>
> CC [M] drivers/net/3c59x.o
> drivers/net/3c59x.c: In function 'acpi_set_WOL':
> drivers/net/3c59x.c:3211:39: warning: dereferencing 'void *' pointer
> drivers/net/3c59x.c:3211:39: error: request for member 'current_state' in something not a structure or union
> make[3]: *** [drivers/net/3c59x.o] Error 1
> make[2]: *** [drivers/net/3c59x.o] Error 2
> make[1]: *** [sub-make] Error 2
> make: *** [all] Error 2
>
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
> ---
> drivers/net/3c59x.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
> index e1da258..0a92436 100644
> --- a/drivers/net/3c59x.c
> +++ b/drivers/net/3c59x.c
> @@ -699,7 +699,8 @@ DEFINE_WINDOW_IO(32)
> #define DEVICE_PCI(dev) NULL
> #endif
>
> -#define VORTEX_PCI(vp) (((vp)->gendev) ? DEVICE_PCI((vp)->gendev) : NULL)
> +#define VORTEX_PCI(vp) \
> + ((struct pci_dev *) (((vp)->gendev) ? DEVICE_PCI((vp)->gendev) : NULL))
>
> #ifdef CONFIG_EISA
> #define DEVICE_EISA(dev) (((dev)->bus == &eisa_bus_type) ? to_eisa_device((dev)) : NULL)
> @@ -707,7 +708,8 @@ DEFINE_WINDOW_IO(32)
> #define DEVICE_EISA(dev) NULL
> #endif
>
> -#define VORTEX_EISA(vp) (((vp)->gendev) ? DEVICE_EISA((vp)->gendev) : NULL)
> +#define VORTEX_EISA(vp) \
> + ((struct eisa_device *) (((vp)->gendev) ? DEVICE_EISA((vp)->gendev) : NULL))
>
> /* The action to take with a media selection timer tick.
> Note that we deviate from the 3Com order by checking 10base2 before AUI.
> --
Hi,
Interesting patch. I have reported this build error and looked
into fixing it, but did not come up with this solution.
Looking at it more: if CONFIG_PCI is not enabled, DEVICE_PCI() is NULL.
That makes VORTEX_PCI() (with or without your patch) have a value of NULL.
Is the line with the reported syntax error (3211) executed in
function acpi_set_WOL() ? If so, let's assume that vp->enable_wol is true.
Then what happens on line 3211 (or 3213 after your patch)?
if (VORTEX_PCI(vp)->current_state < PCI_D3hot)
return;
or if I am really confuzed this morning, please tell me how it works.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH net-next-2.6 v4] can: Topcliff: PCH_CAN driver: Add Flow control/Fix Endianess issue/Separate IF register/Enumerate LEC macro/Move MSI processing/Use BIT(X)/Change Message Object index/Add prefix PCH_
From: David Miller @ 2010-11-16 17:14 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <4CE275A4.9010400-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Way too many changes in one patch.
Please post one that fixes the endianness issues.
One that fixes the register interface seperation.
One that adds flow control processing.
etc.
When you combine many tasks into one patch it's impossible
to bisect through your changes to debug problems in order
to figure out which changed introduced a bug.
I am not applying this, and I will not apply your patches
until you split them up properly.
You may think that there is zero value in this, but there
is huge value in it for anyone who tries to debug your
changes in the future. Right now you are making that a
nearly impossible task.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-11-15
From: David Miller @ 2010-11-16 17:22 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20101115212520.GD2297-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 15 Nov 2010 16:25:21 -0500
> Here is the traditional first huge pull request intended for the 2.6.38!
>
> Included are the usual batch of updates to various wireless drivers.
> For good measure, Luis also gives us a few wireless regulatory control
> patches as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-2.6 PATCH] ipv6: fix missing in6_ifa_put in addrconf
From: David Miller @ 2010-11-16 17:35 UTC (permalink / raw)
To: john.r.fastabend; +Cc: eric.dumazet, netdev, shemminger
In-Reply-To: <20101116062921.31164.70903.stgit@jf-dev1-dcblab>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 15 Nov 2010 22:29:21 -0800
> Fix ref count bug introduced by
>
> commit 2de795707294972f6c34bae9de713e502c431296
> Author: Lorenzo Colitti <lorenzo@google.com>
> Date: Wed Oct 27 18:16:49 2010 +0000
>
> ipv6: addrconf: don't remove address state on ifdown if the address
> is being kept
>
>
> Fix logic so that addrconf_ifdown() decrements the inet6_ifaddr
> refcnt correctly with in6_ifa_put().
>
> Reported-by: Stephen Hemminger <shemminger@vyatta.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Applied, thanks a lot.
^ permalink raw reply
* Re: [RFC] irda: irttp: allow zero byte packets
From: David Miller @ 2010-11-16 17:51 UTC (permalink / raw)
To: w.sang; +Cc: irda-users, netdev, samuel
In-Reply-To: <1289344787-12160-1-git-send-email-w.sang@pengutronix.de>
From: Wolfram Sang <w.sang@pengutronix.de>
Date: Wed, 10 Nov 2010 00:19:47 +0100
> Sending zero byte packets is not neccessarily an error (AF_INET accepts it,
> too), so just apply a shortcut. This was discovered because of a non-working
> software with WINE. See
>
> http://bugs.winehq.org/show_bug.cgi?id=19397#c86
> http://thread.gmane.org/gmane.linux.irda.general/1643
>
> for very detailed debugging information and a testcase. Kudos to Wolfgang for
> those!
>
> Reported-by: Wolfgang Schwotzer <wolfgang.schwotzer@gmx.net>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Tested-by: Mike Evans <mike.evans@cardolan.com>
This looks good to me, applied, thanks!
^ permalink raw reply
* Re: [patch] netlink: let nlmsg and nla functions take pointer-to-const args
From: David Miller @ 2010-11-16 17:52 UTC (permalink / raw)
To: jengelh; +Cc: netdev
In-Reply-To: <alpine.LNX.2.01.1011100106010.10874@obet.zrqbmnf.qr>
From: Jan Engelhardt <jengelh@medozas.de>
Date: Wed, 10 Nov 2010 01:06:36 +0100 (CET)
> parent 2531add5568de01edcabf321d1bbb69a6a6d6c27 (v2.6.36-4468-g2531add)
> commit f87d7f1b74689c96cc2f53b8cabfd309d7ad1bda
> Author: Jan Engelhardt <jengelh@medozas.de>
> Date: Wed Nov 10 00:10:55 2010 +0100
>
> netlink: let nlmsg and nla functions take pointer-to-const args
>
> The changed functions do not modify the NL messages and/or attributes
> at all. They should use const (similar to strchr), so that callers
> which have a const nlmsg/nlattr around can make use of them without
> casting.
>
> While at it, constify a data array.
>
> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/9] drivers/isdn/mISDN: Use printf extension %pV
From: David Miller @ 2010-11-16 18:23 UTC (permalink / raw)
To: joe; +Cc: linux-kernel, isdn, netdev
In-Reply-To: <b7079ecc43454c8b8baaef07f8cf1c1756c2ce3e.1289348757.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Tue, 9 Nov 2010 16:35:16 -0800
> Using %pV reduces the number of printk calls and
> eliminates any possible message interleaving from
> other printk calls.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] Enhance AF_PACKET implementation to not require high order contiguous memory allocation (v4)
From: David Miller @ 2010-11-16 18:25 UTC (permalink / raw)
To: nhorman; +Cc: netdev, eric.dumazet, zenczykowski
In-Reply-To: <1289416194-1844-1-git-send-email-nhorman@tuxdriver.com>
From: nhorman@tuxdriver.com
Date: Wed, 10 Nov 2010 14:09:54 -0500
> Version 4 of this patch.
Applied, thanks a lot for doing this.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] macvlan: lockless tx path
From: David Miller @ 2010-11-16 18:59 UTC (permalink / raw)
To: kaber; +Cc: eric.dumazet, netdev, greearb, bhutchings
In-Reply-To: <4CDCF8C3.6010007@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 12 Nov 2010 09:20:19 +0100
> On 11.11.2010 08:14, Eric Dumazet wrote:
>> macvlan is a stacked device, like tunnels. We should use the lockless
>> mechanism we are using in tunnels and loopback.
>>
>> This patch completely removes locking in TX path.
>>
>> tx stat counters are added into existing percpu stat structure, renamed
>> from rx_stats to pcpu_stats.
>>
>> Note : this reverts commit 2c11455321f37 (macvlan: add multiqueue
>> capability)
>>
>> Note : rx_errors converted to a 32bit counter, like tx_dropped, since
>> they dont need 64bit range.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Ben Greear <greearb@candelatech.com>
>> Cc: Ben Hutchings <bhutchings@solarflare.com>
>> ---
>> V2: correct kerneldoc
>> u32 for tx_dropped and rx_errors
>
> Looks good to me.
>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks everyone.
^ permalink raw reply
* Re: network device reference leak with net-next
From: Lorenzo Colitti @ 2010-11-16 19:21 UTC (permalink / raw)
To: John Fastabend
Cc: Stephen Hemminger, Eric Dumazet, netdev@vger.kernel.org,
brian.haley, maze
In-Reply-To: <4CE1BFCE.70105@intel.com>
On Tue, Nov 16, 2010 at 12:18 AM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> Quick glance looks like an in6_ifa_put is missed?
Oops. Sorry about that.
I'm testing your fix, it seems to work so far.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: lockless transmit path
From: David Miller @ 2010-11-16 19:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber
In-Reply-To: <1289468520.17691.1018.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 11 Nov 2010 10:42:00 +0100
> vlan is a stacked device, like tunnels. We should use the lockless
> mechanism we are using in tunnels and loopback.
>
> This patch completely removes locking in TX path.
>
> tx stat counters are added into existing percpu stat structure, renamed
> from vlan_rx_stats to vlan_pcpu_stats.
>
> Note : this partially reverts commit 2e59af3dcbdf (vlan: multiqueue vlan
> device)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, although there were some conflicts since John Fastabend
made some vlan changes recently.
Please double check my work.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: remove ndo_select_queue() logic
From: David Miller @ 2010-11-16 19:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: jesse, netdev, kaber
In-Reply-To: <1289504565.17691.1710.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 11 Nov 2010 20:42:45 +0100
> [PATCH] vlan: remove ndo_select_queue() logic
>
> Now vlan are lockless, we dont need special ndo_select_queue() logic.
> dev_pick_tx() will do the multiqueue stuff on the real device transmit.
>
> Suggested-by: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Also applied, but again there were conflicts I had to resolve,
please check that I got it right.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] udp: use atomic_inc_not_zero_hint
From: David Miller @ 2010-11-16 19:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1289887106.3364.53.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 16 Nov 2010 06:58:26 +0100
> UDP sockets refcount is usually 2, unless an incoming frame is going to
> be queued in receive or backlog queue.
>
> Using atomic_inc_not_zero_hint() permits to reduce latency, because
> processor issues less memory transactions.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6 V2] net: reorder struct sock fields
From: David Miller @ 2010-11-16 19:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1289922964.5372.443.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 16 Nov 2010 16:56:04 +0100
> Le mardi 16 novembre 2010 à 08:12 +0100, Eric Dumazet a écrit :
>> Right now, fields in struct sock are not optimally ordered, because each
>> path (RX softirq, TX completion, RX user, TX user) has to touch fields
>> that are contained in many different cache lines.
>>
>
> Performance testing pointed out I forgot :
>
> - sk_drops, read for each queued packet, and incremented on packet drops
> - sk_flags tested in sock_def_readable()
> - sk_policy[0]
>
> Here is V2 of patch :
>
> [PATCH net-next-2.6 V2] net: reorder struct sock fields
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] mpc52xx: cleanup locking
From: David Miller @ 2010-11-16 19:39 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, a.llano, grant.likely, jhautbois
In-Reply-To: <1288799798.2511.164.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 03 Nov 2010 16:56:38 +0100
> commit 1e4e0767ecb1 (Fix locking on fec_mpc52xx driver) assumed IRQ are
> enabled when an IRQ handler is called.
>
> It is not the case anymore (IRQF_DISABLED is deprecated), so we can use
> regular spin_lock(), no need for spin_lock_irqsave().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Tested-by: Jean-Michel Hautbois <jhautbois@gmail.com>
> Cc: Asier Llano <a.llano@ziv.es>
> Cc: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks Eric.
^ permalink raw reply
* [PATCH] net: irda: irttp: sync error paths of data- and udata-requests
From: Wolfram Sang @ 2010-11-16 19:40 UTC (permalink / raw)
To: netdev; +Cc: Wolfram Sang, Samuel Ortiz, David Miller
In-Reply-To: <20101116.095101.115945762.davem@davemloft.net>
irttp_data_request() returns meaningful errorcodes, while irttp_udata_request()
just returns -1 in similar situations. Sync the two and the loglevels of the
accompanying output.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: David Miller <davem@davemloft.net>
---
Thank you David for picking up the zero-byte-packet-patch. Now as it was
applied, this one might be interesting, too (on top of it)? Nothing seriously
needed, but looks more proper IMHO. LXR says that are callers of these
functions check with < 0 anyhow.
net/irda/irttp.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/irda/irttp.c b/net/irda/irttp.c
index 6cfaeaf..f6054f9 100644
--- a/net/irda/irttp.c
+++ b/net/irda/irttp.c
@@ -550,7 +550,7 @@ EXPORT_SYMBOL(irttp_close_tsap);
*/
int irttp_udata_request(struct tsap_cb *self, struct sk_buff *skb)
{
- int ret = -1;
+ int ret;
IRDA_ASSERT(self != NULL, return -1;);
IRDA_ASSERT(self->magic == TTP_TSAP_MAGIC, return -1;);
@@ -566,13 +566,14 @@ int irttp_udata_request(struct tsap_cb *self, struct sk_buff *skb)
/* Check that nothing bad happens */
if (!self->connected) {
- IRDA_DEBUG(1, "%s(), Not connected\n", __func__);
+ IRDA_WARNING("%s(), Not connected\n", __func__);
+ ret = -ENOTCONN;
goto err;
}
if (skb->len > self->max_seg_size) {
- IRDA_DEBUG(1, "%s(), UData is too large for IrLAP!\n",
- __func__);
+ IRDA_ERROR("%s(), UData is too large for IrLAP!\n", __func__);
+ ret = -EMSGSIZE;
goto err;
}
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] xfrm: update flowi saddr in icmp_send if unset
From: David Miller @ 2010-11-16 19:46 UTC (permalink / raw)
To: uweber; +Cc: netdev
In-Reply-To: <20101105113912.GA14694@babylon>
From: Ulrich Weber <uweber@astaro.com>
Date: Fri, 5 Nov 2010 12:39:12 +0100
> otherwise xfrm_lookup will fail to find correct policy
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
Looks good, applied to net-2.6
Sorry for taking so long but I wanted to validate this change
against how the rest of this code handles source addresses.
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: remove ndo_select_queue() logic
From: Eric Dumazet @ 2010-11-16 19:54 UTC (permalink / raw)
To: David Miller; +Cc: jesse, netdev, kaber
In-Reply-To: <20101116.112454.179916339.davem@davemloft.net>
Le mardi 16 novembre 2010 à 11:24 -0800, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 11 Nov 2010 20:42:45 +0100
>
> > [PATCH] vlan: remove ndo_select_queue() logic
> >
> > Now vlan are lockless, we dont need special ndo_select_queue() logic.
> > dev_pick_tx() will do the multiqueue stuff on the real device transmit.
> >
> > Suggested-by: Jesse Gross <jesse@nicira.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Also applied, but again there were conflicts I had to resolve,
> please check that I got it right.
>
Both patches seem fine to me.
I am going to test them.
Thanks !
^ permalink raw reply
* Re: iproute2: use automake
From: Jan Engelhardt @ 2010-11-16 20:12 UTC (permalink / raw)
To: David Miller
Cc: shemminger, stephen.hemminger, Netfilter Developer Mailing List,
netdev
In-Reply-To: <alpine.LNX.2.01.1011162017320.24880@obet.zrqbmnf.qr>
On Tuesday 2010-11-16 18:41, David Miller wrote:
>
>> Until you make a convincing case that the existing infrastructure
>> is a problem, choosing an alternative solution is bogus.
>
>I can't count the amount of times I've seen major source trees
>invest tons of engineering into things to decrease the pain of
>using things like automake and libtool.
The pro argument for a build system is not that Linux-only projects
receive unneeded portability work, but that the work involved with
maintaining all the commands in Makefiles, which tend to be a source
of update anomalies, gets reduced.
>X11 even has a script that basically turns libtool into one big
>fat NOP, because on Linux everything libtool tries to figure out
>is completely superfluous.
(I was not trying to make a case for Libtool specifically.)
And yet they do use a build system (which happens to be Automake, but
that's not my point). Was their time spent just to produce,
"unnecessary non-sense", as you call it? I can imagine they will
disagree with you.
>Don't crap up the tree with unnecessary non-sense just for some
>theoretical gain. Things work just fine right now.
They do not.
* running make in subdirs is broken
* iproute2/arpd compilation fails if db_185.h, atm.h is not present
and
* people could not quite opt out building arpd when they are
fine with not having it
* the DESTDIR variable was completely abused
* data files were shoven into /usr/lib where they don't even belong
(that is, if you care about FHS even a tiny bit)
* NO_SHARED_LIBS=y is broken
* -lresolv was added unconditionally when it's not even needed
* CFLAGS was overriden, which means a user running make CFLAGS="-g"
will kill the all-important -Wall and -I../include
* Out-of-tree building, anyone?
But what do I say; if it works _for you_, I must be wrong by
definition.
^ 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