* Re: [PATCH 2/2] via-ircc: Pass PCI device pointer to dma_{alloc,free}_coherent()
From: David Miller @ 2011-03-30 7:13 UTC (permalink / raw)
To: ben; +Cc: netdev, andrewb, samuel, 619450
In-Reply-To: <1301368372.26693.753.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Tue, 29 Mar 2011 04:12:52 +0100
> via-ircc has been passing a NULL pointer to DMA allocation functions,
> which is completely invalid and results in a BUG on PowerPC. Now
> that we always have the device pointer available, pass it in.
>
> Reference: http://bugs.debian.org/619450
> Reported-by: Andrew Buckeridge <andrewb@bgc.com.au>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Tested-by: Andrew Buckeridge <andrewb@bgc.com.au> [against 2.6.32]
Applied.
^ permalink raw reply
* Re: [Bugme-new] [Bug 28512] New: IPv6 SLAAC address preferred over static one as source address
From: Geert Hendrickx @ 2011-03-30 7:31 UTC (permalink / raw)
To: David Miller; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110329.172000.102543782.davem@davemloft.net>
On Tue, Mar 29, 2011 at 17:20:00 -0700, David Miller wrote:
> This is debatable.
>
> One could just as easily say that an address with a shorter preferred
> lifetime has been revalidated more recently, and therefore is more
> likely to be uptodate, valid, and lead to a usable path.
There we're at "most recent" again. In practice, this will often be a SLAAC
address, which will rarely be preferred over a staticly configured one.
> I think the lack of specification for the final tie-breaker in the RFC
> was intentional :-)
>
> The specification has to address this, and until the situation is more
> clear cut than it is now I don't see any benefit for changing Linux's
> behavior. Especially since there is a configuration based workaround
> which works for people in the short-term.
What workaround are you referring to?
Geert
--
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!
^ permalink raw reply
* Re: [Socketcan-users] poll broken (for can)
From: Kurt Van Dijck @ 2011-03-30 7:46 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Marc Kleine-Budde, Netdev, socketcan-users, Wolfgang Grandegger
In-Reply-To: <4D923B00.20500@hartkopp.net>
On Tue, Mar 29, 2011 at 10:03:12PM +0200, Oliver Hartkopp wrote:
> On 28.03.2011 21:32, Marc Kleine-Budde wrote:
> > On 03/28/2011 07:53 PM, Oliver Hartkopp wrote:
> >> On 28.03.2011 18:13, Marc Kleine-Budde wrote:
> >>> On 03/28/2011 05:55 PM, Wolfgang Grandegger wrote:
> > What do we really want to specify?
>
> Hm - the problem could be that people expect their frames to be sent 'in
> time', so if we increase the tx_queue_len, it's not transparent when the
> frames are potentially leaving the system - and if the application data is
> already out-dated when hitting the medium.
>
> What about having up to three CAN frames in each CAN_RAW socket send buffer
> and e.g.50 frames in the tx_queue_len of the netdevice as a starting point?
50 looks good, but 3 is a bit small IMHO.
>
>
> >
> > Something like: queue up to X frames per socket and queue only Y frames
> > per device. Where Y = X * n and n is "I don't know yet"?
> >
> > Y is simple, it's the tx_queue_len. But X is more complicated. The can
> > frames have non constant length (i.e. dlc) and I'm not sure that the
> > netdev people say if we misuse the sock_alloc_send_pskb() for our
> > tx-flow-control :)
>
> I would propose to count the CAN frames independently from the can_dlc.
ack.
> AFAIK
> the tx_queue_len is dealing with skb's - and the skb->len for the socket send
> buffer is also size of struct can_frame, right?
ack.
>
> Regards,
> Oliver
>
> _______________________________________________
> Socketcan-users mailing list
> Socketcan-users@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: poll broken (for can)
From: Marc Kleine-Budde @ 2011-03-30 8:53 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Netdev-u79uwXL29TY76Z2rM5mHXA,
socketcan-users-0fE9KPoRgkgATYTw5x5z8w, Wolfgang Grandegger
In-Reply-To: <4D923B00.20500-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3883 bytes --]
On 03/29/2011 10:03 PM, Oliver Hartkopp wrote:
> On 28.03.2011 21:32, Marc Kleine-Budde wrote:
>> On 03/28/2011 07:53 PM, Oliver Hartkopp wrote:
>>> On 28.03.2011 18:13, Marc Kleine-Budde wrote:
>>>> On 03/28/2011 05:55 PM, Wolfgang Grandegger wrote:
>>>>>> BTW: I figured out why poll() wakes you up but the next write will fail
>>>>>> with -ENOBUFS again.
>>>>>
>>>>> Ah, I'm curious? I also did realize that poll does burn CPU cycles
>>>>> (instead of waiting).
>>>>
>>>> The poll callback checks if the used memory is less than the half of per
>>>> socket snd buffer (IIRC ~60K). See:
>>>>
>>>> datagram_poll (http://lxr.linux.no/linux+v2.6.38/net/core/datagram.c#L737)
>>>> sock_writeable (http://lxr.linux.no/linux+v2.6.38/include/net/sock.h#L1618)
>>>>
>>>> Because the size of a can frame (+the skb overhead) is much less then
>>>> the ethernet frame (+overhead) the default value for the snd buffer is
>>>> too big for can.
>>>>
>>>> We get the -ENOBUF from write() if the tx_queue_len (default 10) is
>>>> exceeded.
>>>>
>>>> http://lxr.linux.no/linux+v2.6.38/drivers/net/can/dev.c#L435
>>>> http://lxr.linux.no/linux+v2.6.38/net/can/af_can.c#L268
>>>>
>>>
>>> What would be your suggestion? Decreasing the socket send buffer for CAN by
>>> default?
>>
>> I haven't done any testing.....As far as I understand the code, we can
>> a) increase the default tx_queue_len and/or
>> b) decrease the default snd buffer size.
>>
>> Note: a) is a per device setting whereas b) is a per socket setting.
>>
>> With the current settings the -ENOBUF is triggered if we have X unsend
>> can frames (per device) where X equals the tx_queue_len. This means
>> using 5 applications, it about 2 queued (i.e. unsent) frames per app and
>> device.
>>
>> If we increase the tx_queue_len to a high value (via ifconfig), so that
>> the snd buffer is fully used, before the tx_queue_len is exceeded the
>> write system call will block, (or return -EAGAIN of opened non
>> blocking). At least the last time I've done this.
>>
>> I think solution b) would lead to a similar behavioural change.
>>
>> What do we really want to specify?
>
> Hm - the problem could be that people expect their frames to be sent 'in
> time', so if we increase the tx_queue_len, it's not transparent when the
> frames are potentially leaving the system - and if the application data is
> already out-dated when hitting the medium.
>
> What about having up to three CAN frames in each CAN_RAW socket send buffer
> and e.g.50 frames in the tx_queue_len of the netdevice as a starting point?
With current the tx_queue_len of 10 it's 10 frames for a single
application scenario. But I don't have any real world CAN experience.
>> Something like: queue up to X frames per socket and queue only Y frames
>> per device. Where Y = X * n and n is "I don't know yet"?
>>
>> Y is simple, it's the tx_queue_len. But X is more complicated. The can
>> frames have non constant length (i.e. dlc) and I'm not sure that the
>> netdev people say if we misuse the sock_alloc_send_pskb() for our
>> tx-flow-control :)
> I would propose to count the CAN frames independently from the can_dlc. AFAIK
Sure - That's what we want. The code has to be written, though :)
> the tx_queue_len is dealing with skb's - and the skb->len for the socket send
> buffer is also size of struct can_frame, right?
I don't know the code in depth, but I think the skb holding the outgoing
can frame is allocated (or at least accounted) from the snd buffer.
Maybe even more data structures.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 191 bytes --]
_______________________________________________
Socketcan-users mailing list
Socketcan-users-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-users
^ permalink raw reply
* Re: [Bugme-new] [Bug 28512] New: IPv6 SLAAC address preferred over static one as source address
From: David Miller @ 2011-03-30 8:59 UTC (permalink / raw)
To: geert; +Cc: akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20110330073139.GA8190@boris.ghen.be>
From: Geert Hendrickx <geert@hendrickx.be>
Date: Wed, 30 Mar 2011 09:31:39 +0200
> What workaround are you referring to?
The script posted at:
http://www.davidc.net/networking/ipv6-source-address-selection-linux
to mark the addresses as deprecated.
^ permalink raw reply
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: David Miller @ 2011-03-30 9:01 UTC (permalink / raw)
To: rlandley; +Cc: linux-kernel, containers, netdev
In-Reply-To: <4D92E9DC.3070405@parallels.com>
From: Rob Landley <rlandley@parallels.com>
Date: Wed, 30 Mar 2011 03:29:16 -0500
> In the host context a find on /proc completes, but inside an lxc
> container a find on /proc never completes, due to the endless loop in
> the title. (It's not a symlink, it seems to be a cross linked directory.)
>
> This is vanilla 2.6.38, I can attach my .config if you think it'd help.
> (The container's the lxc debian sid template but that's probably not
> relevant.)
Please CC: netdev@vger.kernel.org when a bug might be related to
networking, as is obviously the case here.
This bug should be fixed by the following patch:
--------------------
commit 9d2a8fa96a44ba242de3a6f56acaef7a40a97b97
Author: Eric W. Biederman <ebiederm@aristanetworks.com>
Date: Mon Mar 21 18:23:34 2011 -0700
net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.
When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
by adding a mount point it appears I missed a critical ordering issue, in the
ipv6 initialization. I had not realized that ipv6_sysctl_register is called
at the very end of the ipv6 initialization and in particular after we call
neigh_sysctl_register from ndisc_init.
"neigh" needs to be initialized in ipv6_static_sysctl_register which is
the first ipv6 table to initialized, and definitely before ndisc_init.
This removes the weirdness of duplicate tables while still providing a
"neigh" mount point which prevents races in sysctl unregistering.
This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
Reported-by: sunkan@zappa.cx
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 7cb65ef..6dcf5e7 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -17,6 +17,16 @@
static struct ctl_table empty[1];
+static ctl_table ipv6_static_skeleton[] = {
+ {
+ .procname = "neigh",
+ .maxlen = 0,
+ .mode = 0555,
+ .child = empty,
+ },
+ { }
+};
+
static ctl_table ipv6_table_template[] = {
{
.procname = "route",
@@ -37,12 +47,6 @@ static ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
- {
- .procname = "neigh",
- .maxlen = 0,
- .mode = 0555,
- .child = empty,
- },
{ }
};
@@ -160,7 +164,7 @@ static struct ctl_table_header *ip6_base;
int ipv6_static_sysctl_register(void)
{
- ip6_base = register_sysctl_paths(net_ipv6_ctl_path, empty);
+ ip6_base = register_sysctl_paths(net_ipv6_ctl_path, ipv6_static_skeleton);
if (ip6_base == NULL)
return -ENOMEM;
return 0;
^ permalink raw reply related
* Re: [Bug 28512] IPv6 SLAAC address preferred over static one as source address
From: Geert Hendrickx @ 2011-03-30 9:11 UTC (permalink / raw)
To: bugzilla-daemon; +Cc: David Miller, netdev, bugme-daemon
In-Reply-To: <201103300900.p2U90PTc010650@demeter1.kernel.org>
On Wed, Mar 30, 2011 at 09:00:25 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> The script posted at:
>
> http://www.davidc.net/networking/ipv6-source-address-selection-linux
>
> to mark the addresses as deprecated.
That requires you to know the SLAAC address (and thus the MAC address) in
advance, so not always applicable. It's also no longer "stateless auto
configuration" if you have to hardcode the address in your startup config.
Geert
--
geert.hendrickx.be :: geert@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!
^ permalink raw reply
* Re: [Bug 28512] IPv6 SLAAC address preferred over static one as source address
From: David Miller @ 2011-03-30 9:13 UTC (permalink / raw)
To: geert; +Cc: bugzilla-daemon, netdev, bugme-daemon
In-Reply-To: <20110330091115.GA8520@boris.ghen.be>
From: Geert Hendrickx <geert@hendrickx.be>
Date: Wed, 30 Mar 2011 11:11:15 +0200
> On Wed, Mar 30, 2011 at 09:00:25 +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
>> The script posted at:
>>
>> http://www.davidc.net/networking/ipv6-source-address-selection-linux
>>
>> to mark the addresses as deprecated.
>
> That requires you to know the SLAAC address (and thus the MAC address) in
> advance, so not always applicable. It's also no longer "stateless auto
> configuration" if you have to hardcode the address in your startup config.
I said there was an existing workaround, I did not say it was perfect.
And in that context it's reasonable for me to require real guidance
from the IETF before we make a change.
^ permalink raw reply
* Re: [PATCH] bridge: mcast snooping, fix IPv6 MLD checksum calculation
From: David Miller @ 2011-03-30 9:29 UTC (permalink / raw)
To: linus.luessing; +Cc: bridge, shemminger, yoshfuji, herbert, netdev
In-Reply-To: <1301207244-10428-2-git-send-email-linus.luessing@web.de>
From: Linus Lüssing <linus.luessing@web.de>
Date: Sun, 27 Mar 2011 08:27:23 +0200
> In contrast to IGMP, the MLDv1/2 message checksum needs to include an
> IPv6 "pseudo-header" in the calculations (see RFC2710, section 3.3;
> RFC3810, section 5.1.2).
>
> The multicast snooping feature of the bridge code however did not take
> this "pseudo-header" into consideration for the checksum validation when
> parsing a snooped IPv6 MLDv1/2 message of another host, leading to
> possibly ignored, though valid MLDv1/2 messages. This commit shall fix
> this issue.
>
> Signed-off-by: Linus Lüssing <linus.luessing@web.de>
I'm waiting for am updated version of this patch which addresses Herbert
Xu's feedback.
^ permalink raw reply
* Re: [PATCH] bridge: mcast snooping, fix length check of snooped MLDv1/2
From: David Miller @ 2011-03-30 9:30 UTC (permalink / raw)
To: linus.luessing; +Cc: bridge, shemminger, yoshfuji, herbert, netdev
In-Reply-To: <1301207244-10428-3-git-send-email-linus.luessing@web.de>
From: Linus Lüssing <linus.luessing@web.de>
Date: Sun, 27 Mar 2011 08:27:24 +0200
> "len = ntohs(ip6h->payload_len)" does not include the length of the ipv6
> header itself, which the rest of this function assumes, though.
>
> This leads to a length check less restrictive as it should be in the
> following line for one thing. For another, it very likely leads to an
> integer underrun when substracting the offset and therefore to a very
> high new value of 'len' due to its unsignedness. This will ultimately
> lead to the pskb_trim_rcsum() practically never being called, even in
> the cases where it should.
>
> Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Applied.
^ permalink raw reply
* Re: [PATCH] phylib: phy_attach_direct: phy_init_hw can fail, add cleanup
From: David Miller @ 2011-03-30 9:31 UTC (permalink / raw)
To: mkl; +Cc: Netdev, kernel
In-Reply-To: <1301360048-14095-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 29 Mar 2011 02:54:08 +0200
> The function phy_attach_direct attaches the phy and calls phy_init_hw.
> phy_init_hw can fail, but the phy is still marked as attached. Successive
> calls to phy_attach_direct will fail because the phy is busy.
...
> This patch adds phy_detach to clean up if phy_init_hw fails.
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] net/usb: Ethernet quirks for the LG-VL600 4G modem
From: David Miller @ 2011-03-30 9:36 UTC (permalink / raw)
To: andrew.zaborowski; +Cc: netdev, oliver, dbrownell, linux-kernel, balrogg
In-Reply-To: <1301352993-21535-1-git-send-email-andrew.zaborowski@intel.com>
From: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Date: Tue, 29 Mar 2011 00:56:33 +0200
> This adds a driver for the CDC Ethernet part of this modem. The
> device's ID is blacklisted in cdc_ether.c and is white-listed in
> this new driver because of the quirks needed to make it useful.
> The modem's firmware exposes a CDC ACM port for modem control and a
> CDC Ethernet port for network data. The descriptors look fine but
> both ports actually are some sort of multiplexers requiring non-
> standard headers added/removed from every packet or they get
> ignored. All information is based on a usb traffic log from a
> Windows machine.
>
> On the Verizon 4G network I've seen speeds up to 1.1MB/s so far with
> this driver, a speed-o-meter site reports 16.2Mbps/10.5Mbps.
> Userspace scripts are required to talk to the CDC ACM port.
>
> Signed-off-by: Andrzej Zaborowski <balrogg@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] pl25a1_support
From: David Miller @ 2011-03-30 9:40 UTC (permalink / raw)
To: simon; +Cc: gregkh, linux-usb, netdev, linux-kernel, david-b
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
From: Simon Wood <simon@mungewell.org>
Date: Tue, 29 Mar 2011 21:44:27 -0600
> @@ -89,13 +97,17 @@ static int pl_reset(struct usbnet *dev)
> /* some units seem to need this reset, others reject it utterly.
> * FIXME be more like "naplink" or windows drivers.
> */
> - (void) pl_set_QuickLink_features(dev,
> + int status;
> +
> + status = pl_set_QuickLink_features(dev,
> PL_S_EN|PL_RESET_OUT|PL_RESET_IN|PL_PEER_E);
Poor indentation here in the status assignment, there should be
only a single TAB character before "status =".
Also, declare the local variable at the beginning of the function,
before the function, not after it. And get rid of that tab between
"int" and "status, like this:
int status;
/* some units seem to need this reset, others reject it utterly.
* FIXME be more like "naplink" or windows drivers.
*/
^ permalink raw reply
* [V4] dev : fix mtu check when TSO is enabled
From: Daniel Lezcano @ 2011-03-30 9:40 UTC (permalink / raw)
To: davem; +Cc: ebiederm, eric.dumazet, kaber, nightnord, netdev
From: Daniel Lezcano <daniel.lezcano@free.fr>
In case the device where is coming from the packet has TSO enabled,
we should not check the mtu size value as this one could be bigger
than the expected value.
This is the case for the macvlan driver when the lower device has
TSO enabled. The macvlan inherit this feature and forward the packets
without fragmenting them. Then the packets go through dev_forward_skb
and are dropped. This patch fix this by checking TSO is not enabled
when we want to check the mtu size.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Andrian Nord <nightnord@gmail.com>
---
net/core/dev.c | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 563ddc2..3da9fb0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1454,6 +1454,27 @@ static inline void net_timestamp_check(struct sk_buff *skb)
__net_timestamp(skb);
}
+static inline bool is_skb_forwardable(struct net_device *dev,
+ struct sk_buff *skb)
+{
+ unsigned int len;
+
+ if (!(dev->flags & IFF_UP))
+ return false;
+
+ len = dev->mtu + dev->hard_header_len + VLAN_HLEN;
+ if (skb->len <= len)
+ return true;
+
+ /* if TSO is enabled, we don't care about the length as the packet
+ * could be forwarded without being segmented before
+ */
+ if (skb_is_gso(skb))
+ return true;
+
+ return false;
+}
+
/**
* dev_forward_skb - loopback an skb to another netif
*
@@ -1477,8 +1498,7 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
skb_orphan(skb);
nf_reset(skb);
- if (unlikely(!(dev->flags & IFF_UP) ||
- (skb->len > (dev->mtu + dev->hard_header_len + VLAN_HLEN)))) {
+ if (unlikely(!is_skb_forwardable(dev, skb))) {
atomic_long_inc(&dev->rx_dropped);
kfree_skb(skb);
return NET_RX_DROP;
--
1.7.1
^ permalink raw reply related
* Re: [V4] dev : fix mtu check when TSO is enabled
From: David Miller @ 2011-03-30 9:42 UTC (permalink / raw)
To: daniel; +Cc: ebiederm, eric.dumazet, kaber, nightnord, netdev
In-Reply-To: <1301478035-324-1-git-send-email-daniel@free.fr>
From: Daniel Lezcano <daniel@free.fr>
Date: Wed, 30 Mar 2011 11:40:35 +0200
> From: Daniel Lezcano <daniel.lezcano@free.fr>
>
> In case the device where is coming from the packet has TSO enabled,
> we should not check the mtu size value as this one could be bigger
> than the expected value.
>
> This is the case for the macvlan driver when the lower device has
> TSO enabled. The macvlan inherit this feature and forward the packets
> without fragmenting them. Then the packets go through dev_forward_skb
> and are dropped. This patch fix this by checking TSO is not enabled
> when we want to check the mtu size.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: Rob Landley @ 2011-03-30 10:16 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, containers, netdev, stable
In-Reply-To: <20110330.020120.02272125.davem@davemloft.net>
On 03/30/2011 04:01 AM, David Miller wrote:
> From: Rob Landley <rlandley@parallels.com>
> Date: Wed, 30 Mar 2011 03:29:16 -0500
>
>> In the host context a find on /proc completes, but inside an lxc
>> container a find on /proc never completes, due to the endless loop in
>> the title. (It's not a symlink, it seems to be a cross linked directory.)
>>
>> This is vanilla 2.6.38, I can attach my .config if you think it'd help.
>> (The container's the lxc debian sid template but that's probably not
>> relevant.)
>
> Please CC: netdev@vger.kernel.org when a bug might be related to
> networking, as is obviously the case here.
>
> This bug should be fixed by the following patch:
>
> --------------------
> commit 9d2a8fa96a44ba242de3a6f56acaef7a40a97b97
> Author: Eric W. Biederman <ebiederm@aristanetworks.com>
> Date: Mon Mar 21 18:23:34 2011 -0700
>
> net ipv6: Fix duplicate /proc/sys/net/ipv6/neigh directory entries.
>
> When I was fixing issues with unregisgtering tables under /proc/sys/net/ipv6/neigh
> by adding a mount point it appears I missed a critical ordering issue, in the
> ipv6 initialization. I had not realized that ipv6_sysctl_register is called
> at the very end of the ipv6 initialization and in particular after we call
> neigh_sysctl_register from ndisc_init.
>
> "neigh" needs to be initialized in ipv6_static_sysctl_register which is
> the first ipv6 table to initialized, and definitely before ndisc_init.
> This removes the weirdness of duplicate tables while still providing a
> "neigh" mount point which prevents races in sysctl unregistering.
>
> This was initially reported at https://bugzilla.kernel.org/show_bug.cgi?id=31232
> Reported-by: sunkan@zappa.cx
> Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Yes, that fixed it. Pinging the stable guys to make sure this goes in a
dot release.
Thanks,
Rob
^ permalink raw reply
* Re: [PATCH] netfilter: Fix build failure when ipv6 but xt_tproxy is built in
From: Steven Rostedt @ 2011-03-30 10:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, hidden, akpm, netfilter-devel, kaber, netdev
In-Reply-To: <20110329.223536.245392030.davem@davemloft.net>
On Tue, 2011-03-29 at 22:35 -0700, David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Tue, 29 Mar 2011 22:13:19 -0400
>
> > While running ktest.pl doing ranconfigs, the following build error
> > occurred:
>
> Is sending netfilter patches to the explicitly listed maintainer in
> MAINTAINERS too much to ask Stephen? :-/
>
> CC:'d
>
Sorry David, I just did a git blame and Cc'd the ones that did the
original change. I'll do better next time.
-- Steve
^ permalink raw reply
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: David Miller @ 2011-03-30 10:35 UTC (permalink / raw)
To: rlandley; +Cc: linux-kernel, containers, netdev, stable
In-Reply-To: <4D9302F3.6080206@parallels.com>
From: Rob Landley <rlandley@parallels.com>
Date: Wed, 30 Mar 2011 05:16:19 -0500
> Pinging the stable guys to make sure this goes in a dot release.
Please do not do this.
I let fixes soak in Linus's tree for a week or even more before I submit
them to -stable.
^ permalink raw reply
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: Rob Landley @ 2011-03-30 10:45 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, containers, netdev, stable
In-Reply-To: <20110330.033529.71582712.davem@davemloft.net>
On 03/30/2011 05:35 AM, David Miller wrote:
> From: Rob Landley <rlandley@parallels.com>
> Date: Wed, 30 Mar 2011 05:16:19 -0500
>
>> Pinging the stable guys to make sure this goes in a dot release.
>
> Please do not do this.
Too late, but presumably they got your NAK.
> I let fixes soak in Linus's tree for a week or even more before I submit
> them to -stable.
So you think letting it soak in the merge window and the churn of -rc1
(which currently doesn't boot for me due to an ide issue) will provide
more validity than a specific "There was an infinite loop in the
filesystem, there is now no longer an infinite loop in the filesystem,
here's the specific test for it" and visual inspection ofthe patch?
*shrug* I hear what you say. It's certainly a point of view.
Rob
^ permalink raw reply
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: David Miller @ 2011-03-30 10:48 UTC (permalink / raw)
To: rlandley; +Cc: linux-kernel, containers, netdev, stable
In-Reply-To: <4D9309B4.2000501@parallels.com>
From: Rob Landley <rlandley@parallels.com>
Date: Wed, 30 Mar 2011 05:45:08 -0500
> So you think letting it soak in the merge window and the churn of -rc1
> (which currently doesn't boot for me due to an ide issue) will provide
> more validity than a specific "There was an infinite loop in the
> filesystem, there is now no longer an infinite loop in the filesystem,
> here's the specific test for it" and visual inspection ofthe patch?
Yes I absolutely do think it's better to let it soak somewhere than
to repeat the reason why this patch is necessary in the first place.
This patch is necessary because Eric already screwed up trying to fix
this neigh dirctory under ipv6 once, and he got it wrong.
That patch looked correct and straightforward.
Yet it introduced the bug you're seeing.
Given that consideration, are you still holding steady to your
opinion wise guy? :-)
^ permalink raw reply
* [PATCH] net: ethtool support to configure number of RX rings
From: Amit Kumar Salecha @ 2011-03-30 10:59 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
o Ethtool hook to configure number of RX rings.
o Implementation is scalable to support configuring TX rings.
o There exist ETHTOOL_GRXRINGS command for getting number of RX rings,
but it is tigtly coupled with RX flow hash configuration.
o Patches for qlcnic and netxen_nic driver supporting this features
will follow soon.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
include/linux/ethtool.h | 20 ++++++++++++++++++++
net/core/ethtool.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index aac3e2e..de0decd 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -226,6 +226,21 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/* for configuring number of RX ring */
+struct ethtool_ring {
+ __u32 cmd; /* ETHTOOL_{G,S}RING */
+
+ /* Read only attributes. These indicate the maximum number
+ * of RX rings the driver will allow the user to set.
+ */
+ __u32 rx_max;
+
+ /* Values changeable by the user. The valid values are
+ * in the range 1 to the "*_max" counterpart above.
+ */
+ __u32 rx_pending;
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd; /* ETHTOOL_{G,S}PAUSEPARAM */
@@ -764,6 +779,9 @@ struct ethtool_ops {
struct ethtool_rxfh_indir *);
int (*set_rxfh_indir)(struct net_device *,
const struct ethtool_rxfh_indir *);
+ void (*get_rings)(struct net_device *, struct ethtool_ring *);
+ int (*set_rings)(struct net_device *, struct ethtool_ring *);
+
};
#endif /* __KERNEL__ */
@@ -832,6 +850,8 @@ struct ethtool_ops {
#define ETHTOOL_GFEATURES 0x0000003a /* Get device offload settings */
#define ETHTOOL_SFEATURES 0x0000003b /* Change device offload settings */
+#define ETHTOOL_GRINGS 0x0000003c /* Get no of rings */
+#define ETHTOOL_SRINGS 0x0000003d /* Set no of rings */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..2d96b4d 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1426,6 +1426,33 @@ static int ethtool_set_ringparam(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->set_ringparam(dev, &ringparam);
}
+static int ethtool_get_rings(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_ring ring_val = { .cmd = ETHTOOL_GRINGS };
+
+ if (!dev->ethtool_ops->get_rings)
+ return -EOPNOTSUPP;
+
+ dev->ethtool_ops->get_rings(dev, &ring_val);
+
+ if (copy_to_user(useraddr, &ring_val, sizeof(ring_val)))
+ return -EFAULT;
+ return 0;
+}
+
+static int ethtool_set_rings(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_ring ring_val;
+
+ if (!dev->ethtool_ops->set_rings)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&ring_val, useraddr, sizeof(ring_val)))
+ return -EFAULT;
+
+ return dev->ethtool_ops->set_rings(dev, &ring_val);
+}
+
static int ethtool_get_pauseparam(struct net_device *dev, void __user *useraddr)
{
struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM };
@@ -1935,6 +1962,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_SGRO:
rc = ethtool_set_one_feature(dev, useraddr, ethcmd);
break;
+ case ETHTOOL_GRINGS:
+ rc = ethtool_get_rings(dev, useraddr);
+ break;
+ case ETHTOOL_SRINGS:
+ rc = ethtool_set_rings(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.3.2
^ permalink raw reply related
* Re: 2.6.38 containers bug: Infinite loop in /proc/sys/net/ipv6/neigh/neigh/neigh...
From: Rob Landley @ 2011-03-30 11:27 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, containers, netdev, stable
In-Reply-To: <20110330.034820.124005354.davem@davemloft.net>
On 03/30/2011 05:48 AM, David Miller wrote:
> From: Rob Landley <rlandley@parallels.com>
> Date: Wed, 30 Mar 2011 05:45:08 -0500
>
>> So you think letting it soak in the merge window and the churn of -rc1
>> (which currently doesn't boot for me due to an ide issue) will provide
>> more validity than a specific "There was an infinite loop in the
>> filesystem, there is now no longer an infinite loop in the filesystem,
>> here's the specific test for it" and visual inspection ofthe patch?
>
> Yes I absolutely do think it's better to let it soak somewhere than
> to repeat the reason why this patch is necessary in the first place.
>
> This patch is necessary because Eric already screwed up trying to fix
> this neigh dirctory under ipv6 once, and he got it wrong.
>
> That patch looked correct and straightforward.
>
> Yet it introduced the bug you're seeing.
>
> Given that consideration, are you still holding steady to your
> opinion wise guy? :-)
The patch fixed the specific bug I hit (find /proc hanging), and didn't
noticeably make the system worse in my use cases. I have a specific
test case which used to fail and now succeeds. The system _without_ the
patch is broken, and I weigh the possibility of breakage with the patch
against that. I wasn't particularly concerned with it being the "right"
fix from a long-term structural standpoint because that's what 2.6.39 is
for. I just wanted the obvious breakage (a regression from 2.6.37) to
go away, I tested this fix and it Worked For Me (tm), hence letting the
stable guys know about it being the obvious next move.
How many people do you think are likely to even try containers under
2.6.39-rc1 or -rc2? Eric's patch introducing the bug is dated January
31, and it was in 2.6.38-rc4. Apparently nobody noticed the breakage in
-rc5, -rc6, -rc7, or -rc8. His patch fixing the bug is dated one week
after 2.6.38 shipped. I also noticed it in the stable kernel, not in
any of the 2.6.38-rc releases. So at least two people hit this in
-stable already, and nobody hit it in -dev for four -rc releases. I
have tested it in 2.6.38 and it Worked For Me. Supposing the new patch
did introduce subtle breakage, how is leaving it in the 2.6.39-dev
series for a _month_ more likely to find it than the entire second half
of the 2.6.38 development cycle (when it was at its most stable, and
thus easiest to test)?
I have no idea if this patch fixes 2.6.39-rc1, because -rc1 still
doesn't _boot_ in my test environment. Many other things about -rc1 are
broken. That's sort of the point of -rc1. A fairly small number of
people test the development branch, and this is the most unstable time
of the development cycle where many things about it are _expected_ not
to work. Especially right now, I don't see how letting it "soak" for a
week or two in the -dev branch accomplishes anything whatsoever.
So yes, I am still holding steady to my opinion. But you're the
maintainer, so my opinion doesn't really matter here.
Rob
^ permalink raw reply
* Re: [PATCH] pl25a1_support
From: Sergei Shtylyov @ 2011-03-30 11:31 UTC (permalink / raw)
To: Simon Wood
Cc: Greg Kroah-Hartman, linux-usb, netdev, linux-kernel,
David Brownell
In-Reply-To: <1301456667-1648-1-git-send-email-simon@mungewell.org>
Hello.
On 30-03-2011 7:44, Simon Wood wrote:
> Adds support for 'Windows Easy Transfer' cables based around the
> Prolific PL-25A1 chip (includes Belkin F5U258& F5U279)
> Patch originally suggested by David Brownell here:
> http://www.mail-archive.com/netdev@vger.kernel.org/msg61926.html
> Modified to work with latest kernel, tested with F5U279.
>
> Signed-off-by: Simon Wood<simon@mungewell.org>
[...]
> diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
> index 08ad269..a20afac 100644
> --- a/drivers/net/usb/plusb.c
> +++ b/drivers/net/usb/plusb.c
[...]
> @@ -89,13 +97,17 @@ static int pl_reset(struct usbnet *dev)
> /* some units seem to need this reset, others reject it utterly.
> * FIXME be more like "naplink" or windows drivers.
> */
> - (void) pl_set_QuickLink_features(dev,
> + int status;
> +
> + status = pl_set_QuickLink_features(dev,
This line is indented with spaces ISO tab.
> + if (status != 0 && netif_msg_probe(dev))
> + netif_dbg(dev, link, dev->net, "pl_reset --> %d\n", status);
> return 0;
> }
Also, the above change doesn't seem to be related to the declared purpose
of the patch, so seems to be a matter of another patch...
> @@ -134,16 +153,16 @@ static struct usb_driver plusb_driver = {
>
> static int __init plusb_init(void)
> {
> - return usb_register(&plusb_driver);
> + return usb_register(&plusb_driver);
> }
> module_init(plusb_init);
>
> static void __exit plusb_exit(void)
> {
> - usb_deregister(&plusb_driver);
> + usb_deregister(&plusb_driver);
> }
Likewise, the whitespace fixes should be a matgter of a separate patch...
WBR, Sergei
^ permalink raw reply
* [PATCH] fib: add rtnl locking in ip_fib_net_exit
From: Eric Dumazet @ 2011-03-30 12:28 UTC (permalink / raw)
To: Daniel J Blueman, David Miller; +Cc: Linux Kernel, netdev
In-Reply-To: <AANLkTimv61zJhCjj-pgOHW6UYG4XSPLkjb8Z_yEMaFWo@mail.gmail.com>
Le mercredi 30 mars 2011 à 18:05 +0800, Daniel J Blueman a écrit :
> The loop in fib_table_flush [1] calls trie_firstleaf() which
> RCU-dereferences a structure outside a RCU read critical section,
> generating a warning [2].
>
Hi Daniel
> Since trie_leaf_remove() uses rcu_assign_pointer(), which should be
> outside the RCU read critical section, is there any better solution
> than spitting up the loop, with the first half covered by a RCU read
> critical section lock?
>
rcu_assign_pointer() can be done anywhere. This is done by a writer
(holding RTNL), while RCU read is used by readers.
> Daniel
>
> --- [1]
>
> int fib_table_flush(struct fib_table *tb)
> {
> struct trie *t = (struct trie *) tb->tb_data;
> struct leaf *l, *ll = NULL;
> int found = 0;
>
> for (l = trie_firstleaf(t); l; l = trie_nextleaf(l)) {
> found += trie_flush_leaf(l);
>
> if (ll && hlist_empty(&ll->list))
> trie_leaf_remove(t, ll);
> ll = l;
> }
>
> --- [2]
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> net/ipv4/fib_trie.c:1777 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 1
> 3 locks held by kworker/u:5/51:
> #0: (netns){.+.+.+}, at: [<ffffffff8107b639>] process_one_work+0x149/0x470
> #1: (net_cleanup_work){+.+.+.}, at: [<ffffffff8107b639>]
> process_one_work+0x149/0x470
> #2: (net_mutex){+.+.+.}, at: [<ffffffff8157b4b0>] cleanup_net+0x80/0x1b0
>
> stack backtrace:
> Pid: 51, comm: kworker/u:5 Tainted: G W 2.6.39-rc1-350cd #1
> Call Trace:
> [<ffffffff81094cd4>] lockdep_rcu_dereference+0xa4/0xc0
> [<ffffffff8160aa23>] trie_firstleaf+0x93/0xa0
> [<ffffffff8156feb8>] ? __sk_free+0x148/0x1e0
> [<ffffffff8160d890>] fib_table_flush+0x20/0x1a0
> [<ffffffff81606da5>] ip_fib_net_exit+0x95/0xd0
> [<ffffffff81606e10>] fib_net_exit+0x30/0x40
> [<ffffffff8157ab8e>] ops_exit_list+0x2e/0x70
> [<ffffffff8157b52b>] cleanup_net+0xfb/0x1b0
> [<ffffffff8107b69a>] process_one_work+0x1aa/0x470
> [<ffffffff8107b639>] ? process_one_work+0x149/0x470
> [<ffffffff8157b430>] ? net_free+0x30/0x30
> [<ffffffff8107bd97>] worker_thread+0x157/0x3c0
> [<ffffffff816ea484>] ? preempt_schedule+0x44/0x60
> [<ffffffff8107bc40>] ? rescuer_thread+0x2e0/0x2e0
> [<ffffffff81080236>] kthread+0xb6/0xc0
> [<ffffffff81095f1d>] ? trace_hardirqs_on_caller+0x14d/0x190
> [<ffffffff816ef094>] kernel_thread_helper+0x4/0x10
> [<ffffffff810553f8>] ? finish_task_switch+0x78/0x110
> [<ffffffff816ed7c4>] ? retint_restore_args+0xe/0xe
> [<ffffffff81080180>] ? __init_kthread_worker+0x70/0x70
> [<ffffffff816ef090>] ? gs_change+0xb/0xb
So fib_table_flush() is called (from ip_fib_net_exit) without RTNL being
held.
Here is patch to fix this.
Thanks
[PATCH] fib: add rtnl locking in ip_fib_net_exit
Daniel J Blueman reported a lockdep splat in trie_firstleaf(), caused by
RTNL being not locked before a call to fib_table_flush()
Reported-by: Daniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/fib_frontend.c | 2 ++
1 files changed, 2 insertions(+)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index f116ce8..4510883 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1068,6 +1068,7 @@ static void ip_fib_net_exit(struct net *net)
fib4_rules_exit(net);
#endif
+ rtnl_lock();
for (i = 0; i < FIB_TABLE_HASHSZ; i++) {
struct fib_table *tb;
struct hlist_head *head;
@@ -1080,6 +1081,7 @@ static void ip_fib_net_exit(struct net *net)
fib_free_table(tb);
}
}
+ rtnl_unlock();
kfree(net->ipv4.fib_table_hash);
}
^ permalink raw reply related
* Re: connector: convert to synchronous netlink message processing
From: Evgeniy Polyakov @ 2011-03-30 13:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Linux Netdev List
In-Reply-To: <4D90D5E8.4080002@trash.net>
Hi Patrick
On Mon, Mar 28, 2011 at 08:39:36PM +0200, Patrick McHardy (kaber@trash.net) wrote:
> This patch fixes up connector to work properly with the recent
> netlink changes that require synchronous netlink message processing.
>
> The patch is so far only compile tested since I'm still looking
> for a good way to test it. If you could point me to some software
> using the proc events that would be appreciated.
There is test module in Documentation/connector/ and/or samples/ which I
used for tests. It was quite for a while when it was used last time
though.
Your patch looks very good and I definitely ack this :)
Thank you.
> commit 21c40e4675954b42c939334e3ed15e1bd0a4da29
> Author: Patrick McHardy <kaber@trash.net>
> Date: Mon Mar 28 20:20:26 2011 +0200
>
> connector: convert to synchronous netlink message processing
>
> Commits 01a16b21 (netlink: kill eff_cap from struct netlink_skb_parms)
> and c53fa1ed (netlink: kill loginuid/sessionid/sid members from struct
> netlink_skb_parms) removed some members from struct netlink_skb_parms
> that depend on the current context, all netlink users are now required
> to do synchronous message processing.
>
> connector however queues received messages and processes them in a work
> queue, which is not valid anymore. This patch converts connector to do
> synchronous message processing by invoking the registered callback handler
> directly from the netlink receive function.
>
> In order to avoid invoking the callback with connector locks held, a
> reference count is added to struct cn_callback_entry, the reference
> is taken when finding a matching callback entry on the device's queue_list
> and released after the callback handler has been invoked.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
--
Evgeniy Polyakov
^ 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