* Re: [PATCH net-next-2.6] ip6mr: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE859AB.8030801@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 15:48:11 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ip6tnl: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE86063.3080005@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:16:51 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ipmr: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE86182.80804@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:21:38 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bridge: Optimize multiple unregistration
From: David Miller @ 2009-10-29 8:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE864C7.3060100@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 28 Oct 2009 16:35:35 +0100
> Speedup module unloading by factorizing synchronize_rcu() calls
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 0/2] qlge: Fixes for qlge.
From: David Miller @ 2009-10-29 8:17 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1256755161-29606-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 28 Oct 2009 11:39:19 -0700
> Fix EEH and firmware mailbox command processor.
Both applied to net-2.6, thanks Ron.
^ permalink raw reply
* Re: iproute uses too small of a receive buffer
From: David Miller @ 2009-10-29 8:17 UTC (permalink / raw)
To: kaber; +Cc: eric.dumazet, shemminger, greearb, netdev
In-Reply-To: <4AE895E8.60308@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 28 Oct 2009 20:05:12 +0100
> How about this? It will double the receive queue limit on ENOBUFS
> up to 1024 * 1024b, then bail out with the normal error message on
> further ENOBUFS.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCHv4 0/7] Per route TCP options support kill switches
From: David Miller @ 2009-10-29 8:29 UTC (permalink / raw)
To: gilad; +Cc: netdev, ori
In-Reply-To: <1256739327-11576-1-git-send-email-gilad@codefidence.com>
From: Gilad Ben-Yossef <gilad@codefidence.com>
Date: Wed, 28 Oct 2009 16:15:20 +0200
> Allow selectively turning off support for specific TCP options
> on a per route basis.
Ok, I can live with these changes, good job.
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] [RESEND] netdev: usb: dm9601.c can drive a device not supported yet, add support for it
From: David Miller @ 2009-10-29 8:32 UTC (permalink / raw)
To: jkrzyszt; +Cc: jacmet, netdev
In-Reply-To: <200910281634.23635.jkrzyszt@tis.icnet.pl>
From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Date: Wed, 28 Oct 2009 16:34:21 +0100
> I found that the current version of drivers/net/usb/dm9601.c can be used to
> successfully drive a low-power, low-cost network adapter with USB ID
> 0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
> present in the kernel, I have created a patch that adds support for the device
> to the dm9601 driver.
>
> Created and tested against linux-2.6.32-rc5.
>
> Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
> Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 0/9] Gigaset driver patches for 2.6.33
From: David Miller @ 2009-10-29 8:37 UTC (permalink / raw)
To: tilman; +Cc: isdn, hjlipp, netdev, linux-kernel, isdn4linux, i4ldeveloper
In-Reply-To: <20091023-patch-gigaset-00.tilman@imap.cc>
From: Tilman Schmidt <tilman@imap.cc>
Date: Sun, 25 Oct 2009 20:29:27 +0100 (CET)
> David, Karsten,
>
> here's a series of patches that should be applied on top of those
> currently in net-next. I'm sending them now to leave you enough time
> before the next merge window to decide who wants to handle them.
> In particular, patch 3 provides an important bugfix to the new CAPI
> interface which is necessary for using it with pppd capiplugin.
All of these patches look reasonable, so I've applied them
to net-next-2.6
Thanks!
^ permalink raw reply
* Re: [PATCH] net: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4AE1D2D9.5000906@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 17:59:21 +0200
> optlen is unsigned so the `< 0' test is never true.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: chas, netdev, akpm
In-Reply-To: <4AE1D553.8010406@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 18:09:55 +0200
> The variables are unsigned so the `< 0' test always fails, the
> other part of the test catches wrapped values.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Cleanup redundant tests on unsigned
From: David Miller @ 2009-10-29 8:40 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, eis, linux-x25, akpm
In-Reply-To: <4AE1CA14.10304@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 23 Oct 2009 17:21:56 +0200
> If there is data, the unsigned skb->len is greater than 0.
>
> rt.sigdigits is unsigned as well, so the test `>= 0' is
> always true, the other part of the test catches wrapped
> values.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: Introduce dev_get_by_index_rcu()
From: David Miller @ 2009-10-29 8:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: shemminger, netdev
In-Reply-To: <4ADD4839.9010500@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 07:18:49 +0200
> [PATCH net-next-2.6] net: Introduce dev_get_by_index_rcu()
>
> Some workloads hit dev_base_lock rwlock pretty hard.
> We can use RCU lookups to avoid touching this rwlock.
>
> netdevices are already freed after a RCU grace period, so this patch
> adds no penalty at device dismantle time.
>
> dev_ifname() converted to dev_get_by_index_rcu()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 1/7] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
From: Akinobu Mita @ 2009-10-29 8:53 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, FUJITA Tomonori, David S. Miller, sparclinux,
Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Greg Kroah-Hartman, Lothar Wassmann, linux-usb, Roland Dreier,
Yevgeny Petrilin, netdev, Tony Luck, Fenghua Yu, linux-ia64,
linux-altix, Joerg Roedel
In-Reply-To: <20091028131141.523854cb.akpm@linux-foundation.org>
2009/10/29 Andrew Morton <akpm@linux-foundation.org>:
>
> Why were these patches resent? What changed?
>
> Everybody who is going to review these patches has already reviewed
> them and now they need to review them all again?
I resent the patches because the iommu-helper change was not correct
and I introduced serious bug in bitmap_find_next_zero_area()
if align_mask != 0 in follow-up patch then those were dropped from
the -mm tree.
Only [PATCH 1/7] and [PATCH 2/7] have changes since the first submission of
this patch set.
* [PATCH 1/7]
- Rewrite bitmap_set() and bitmap_clear()
- Let bitmap_find_next_zero_area() check the last bit of the limit
- Add kerneldoc for bitmap_find_next_zero_area()
* [PATCH 2/7]
- Convert find_next_zero_area() to use bitmap_find_next_zero_area() correctly
iommu-helper doesn't want to search the last bit of the limist in bitmap
* [PATCH 3/7] - [PATCH 7/7]
- No changes
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" 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
* 2%interest rate loan.
From: global loan company @ 2009-10-27 10:50 UTC (permalink / raw)
contact us for 2%interest rate loan.
^ permalink raw reply
* 2%interest rate loan.
From: global loan company @ 2009-10-27 10:52 UTC (permalink / raw)
contact us for 2%interest rate loan.
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 9:32 UTC (permalink / raw)
To: netdev; +Cc: David Miller, avorontsov
In-Reply-To: <20091028.024325.134189895.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, October 28, 2009 3:13 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>Date: Tue, 27 Oct 2009 22:25:18 +0530
>
>> This patch adds mdio support for etsec2.0 devices.
>>
>> Modified the fsl_pq_mdio structure to include the new mdio members.
>>
>> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>
>This is the third time you've submitted this patch, and for
>the third time it DOES NOT apply to net-next-2.6 at all when I
>try to apply this gianfar patch series.
>
>You must be patching against another tree that has some
>changes that conflict with this one.
>
>Sort this out before submitting this again.
>
>If you submit once more this same series, and it doesn't apply
>properly to net-next-2.6, I will flat our ignore your
>submissions for a week or so.
>
>You are wasting that much of my time by doing this over and over.
>
>Get your act together.
>
>
Hi All,
I couldn't find the following commit on the net-next-2.6 tree:
commit e72701acbe0b35e52d3f04d442837c06b4e64f1c
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed Oct 14 14:54:52 2009 -0700
net: Fix OF platform drivers coldplug/hotplug when compiled as
modules
Some OF platform drivers are missing module device tables, so they
won't
load automatically on boot. This patch fixes the issue by adding
proper
MODULE_DEVICE_TABLE() macros to the drivers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The same commit is present on the linux-next tree
I cloned the 2 trees from the following links:
linux-next from:
http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
And net-next-2.6 from:
http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
The absence of the above mentioned commit in the net-next-2.6 tree is
causing
some issues with patches getting applied.
Can you let me know if the net-next-2.6 tree that I am cloning is the
proper one ?
I based all my patches on net-next-2.6 tree cloned from the above link.
But some how when David tries to apply
my patches they fail. I took a diff at the linux-next and net-next-2.6
and the said commit is missing.
-Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 9:45 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950352@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:02:44 +0530
> The absence of the above mentioned commit in the net-next-2.6 tree
> is causing some issues with patches getting applied.
You should never use linux-next as you base for working against
other people's trees.
Instead, clone net-next-2.6 and work purely against that when sending
me patches.
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: David Miller @ 2009-10-29 10:00 UTC (permalink / raw)
To: gorcunov; +Cc: netdev
In-Reply-To: <20091024163226.GA5204@lenovo>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat, 24 Oct 2009 20:32:26 +0400
> net,socket: introduce DECLARE_SOCKADDR helper to catch overflow at build time
>
> proto_ops->getname implies copying protocol specific data
> into storage unit (particulary to __kernel_sockaddr_storage).
> So when we implement new protocol support we should keep such
> a detail in mind (which is easy to forget about).
>
> Lets introduce DECLARE_SOCKADDR helper which check if
> storage unit is not overfowed at build time.
>
> Eventually inet_getname is switched to use DECLARE_SOCKADDR
> (to show example of usage).
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
I like this, applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: nfs broken in net-next?
From: Yinghai Lu @ 2009-10-29 10:03 UTC (permalink / raw)
To: Suresh Jayaraman; +Cc: David Miller, Linux Kernel Mailing List, NetDev
In-Reply-To: <4AE9430B.3060105@suse.de>
On Thu, Oct 29, 2009 at 12:23 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote:
> On 10/29/2009 01:43 AM, Yinghai Lu wrote:
>> pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
>> mount.nfs: rpc.statd is not running but is required for remote locking.
>> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
>
> rpc.statd on client should have be started by mount.nfs when a nfs
> filesystem is mounted. Is this not happening for some reason or do you
> see any errors in syslog?
>
>>
>> using opensuse11.1
>>
>
> Are you using 11.1 betas? I know of a problem where non-root user mounts
> fail to start rpc.statd in betas that got fixed later:
>
> http://marc.info/?l=linux-nfs&m=122748525624094&w=2
>
> Is the problem seen only recently (after updating to net-next)?
>
only happen with net-next.
linus tree and tip tree are ok.
YH
^ permalink raw reply
* [PATCH] net: fix kmemcheck annotations
From: Eric Dumazet @ 2009-10-29 10:10 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
struct sk_buff kmemcheck annotations enlarged this structure by 8/16 bytes
Fix this by moving 'protocol' inside flags1 bitfield,
and queue_mapping inside flags2 bitfield.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0c68fbd..defd51d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -354,8 +354,8 @@ struct sk_buff {
ipvs_property:1,
peeked:1,
nf_trace:1;
+ __be16 protocol:16;
kmemcheck_bitfield_end(flags1);
- __be16 protocol;
void (*destructor)(struct sk_buff *skb);
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
@@ -367,7 +367,6 @@ struct sk_buff {
#endif
int iif;
- __u16 queue_mapping;
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
#ifdef CONFIG_NET_CLS_ACT
@@ -376,6 +375,7 @@ struct sk_buff {
#endif
kmemcheck_bitfield_begin(flags2);
+ __u16 queue_mapping:16;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
^ permalink raw reply related
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 10:11 UTC (permalink / raw)
To: netdev; +Cc: avorontsov, David Miller
In-Reply-To: <20091029.024546.90958594.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, October 29, 2009 3:16 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org; avorontsov@ru.mvista.com
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
>Date: Thu, 29 Oct 2009 15:02:44 +0530
>
>> The absence of the above mentioned commit in the
>net-next-2.6 tree is
>> causing some issues with patches getting applied.
>
>You should never use linux-next as you base for working
>against other people's trees.
>
>Instead, clone net-next-2.6 and work purely against that when
>sending me patches.
This is the tree I generated the patches against initially.
The initial set of patches were generated against this tree:
(http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
Can you please confirm that the above tree is correct.
After you reported the failure,
I merged against the linux-next tree, therein I too got a similar
failure.
The reason being the commit from Anton present in linux-next and absent
on net-next.
The patches sent by me applies cleanly to the above mentioned
net-next-2.6 tree.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 10:16 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B95035E@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:41:22 +0530
> This is the tree I generated the patches against initially.
> The initial set of patches were generated against this tree:
> (http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
>
> Can you please confirm that the above tree is correct.
Yes.
> The patches sent by me applies cleanly to the above mentioned
> net-next-2.6 tree.
It may have applied cleanly when you sent them, but by the
time I applied them it didn't.
Resend a fresh patch set against a fresh net-next-2.6 checkout
and let's see what happens :-)
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: David Miller @ 2009-10-29 10:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE96A1D.8050300@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 11:10:37 +0100
> @@ -367,7 +367,6 @@ struct sk_buff {
> #endif
>
> int iif;
> - __u16 queue_mapping;
> #ifdef CONFIG_NET_SCHED
> __u16 tc_index; /* traffic control index */
> #ifdef CONFIG_NET_CLS_ACT
> @@ -376,6 +375,7 @@ struct sk_buff {
> #endif
>
> kmemcheck_bitfield_begin(flags2);
> + __u16 queue_mapping:16;
> #ifdef CONFIG_IPV6_NDISC_NODETYPE
> __u8 ndisc_nodetype:2;
> #endif
We may be trading size for performance here, I wonder if
it's wise to move queue_mapping like that and what
locality change we get as a result.
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-29 10:19 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091015201028.GA9780@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Thu, 15 Oct 2009 22:10:29 +0200
> Currently PACKET_TX_RING forces certain amount of every frame to remain
> unused. This probably originates from an early version of the
> PACKET_TX_RING patch that in fact used the extra space when the (since
> removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
> code does not make any use of this extra space.
>
> This patch removes the extra space reservation and lets userspace make
> use of the full frame size.
>
> Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
Applied, thanks!
^ 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