* Re: [PATCH] at91_ether: use gpio_is_valid for phy IRQ line
From: David Miller @ 2011-11-29 23:53 UTC (permalink / raw)
To: nicolas.ferre
Cc: jamie, netdev, plagnioj, sfr, linux-next, linux-kernel,
linux-arm-kernel
In-Reply-To: <1322169674-4109-1-git-send-email-nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Thu, 24 Nov 2011 22:21:14 +0100
> Use the generic gpiolib gpio_is_valid() function to test
> if the phy IRQ line GPIO is actually provided.
>
> For non-connected or non-existing phy IRQ lines, -EINVAL
> value is used for phy_irq_pin field of struct at91_eth_data.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I'm assuming this goes through the ARM tree, because in both of my networking
trees there is no ARM at91 implementation of gpio_is_valid().
^ permalink raw reply
* Re: [PATCH] icplus: mdio_write(), remove unnecessary for loop
From: David Miller @ 2011-11-29 23:47 UTC (permalink / raw)
To: patrick.kelle81; +Cc: netdev, romieu, sorbica
In-Reply-To: <1322149145-32242-1-git-send-email-patrick.kelle81@gmail.com>
From: Patrick Kelle <patrick.kelle81@gmail.com>
Date: Thu, 24 Nov 2011 16:39:05 +0100
> At this point the variable j is always set to 7 and the code within
> the loop has to run only once anyway.
>
> Signed-off-by: Patrick Kelle <patrick.kelle81@gmail.com>
You can simply this even further since p[7] is what is used here,
and this means len is one, the inner loop therefore executes only
once, and the p[7].field value is not used (it's zero in the table)
and the write to it is completely thrown away.
It all reduces to something like:
ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_LO | polarity);
ipg_r8(PHY_CTRL);
ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_HI | polarity);
Which is just asserting the management clock low, then high, and
doing a PHY_CTRL read in between to force the write out, the read
data is not used at all.
^ permalink raw reply
* Re: Bonding fixes for 2.6.33.y
From: Josh Boyer @ 2011-11-29 23:46 UTC (permalink / raw)
To: Greg KH
Cc: Ben Hutchings, stable, Jay Vosburgh, Andy Gospodarek, Neil Horman,
netdev
In-Reply-To: <20111129224909.GA27909@kroah.com>
On Tue, Nov 29, 2011 at 5:49 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 29, 2011 at 02:19:59AM +0000, Ben Hutchings wrote:
>> These have been applied to 2.6.32.y but are missing from 2.6.33.y:
>
> Perhaps because 2.6.33.y is not end-of-life and is not having any more
> releases?
s/is not end-of-life/is now end-of-life/
?
josh
^ permalink raw reply
* Re: [patch v2] isdn: avoid copying too long drvid
From: David Miller @ 2011-11-29 23:40 UTC (permalink / raw)
To: dan.carpenter; +Cc: isdn, lucas.demarchi, nhorman, netdev, kernel-janitors
In-Reply-To: <20111124124209.GI3195@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 24 Nov 2011 15:42:09 +0300
> "cfg->drvid" comes from the user so there is a possibility they
> didn't NUL terminate it properly.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: use strnlen() instead of strlen().
Applied.
^ permalink raw reply
* Re: [patch v2] isdn: make sure strings are null terminated
From: David Miller @ 2011-11-29 23:40 UTC (permalink / raw)
To: dan.carpenter; +Cc: eric.dumazet, isdn, netdev, kernel-janitors
In-Reply-To: <20111124124149.GH3195@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 24 Nov 2011 15:41:49 +0300
> These strings come from the user. We strcpy() them inside
> cf_command() so we should check that they are NULL terminated and
> return an error if not.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> v2: use strnlen() instead of strlen().
Applied.
^ permalink raw reply
* Re: [PATCH next-next 0/2] can: cc770: add support for the Bosch CC770 and Intel AN82527
From: David Miller @ 2011-11-29 23:39 UTC (permalink / raw)
To: wg; +Cc: netdev, linux-can, socketcan-users, boir1, stanislavelensky
In-Reply-To: <1322136448-7311-1-git-send-email-wg@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 24 Nov 2011 13:07:26 +0100
> Already since a while we have support for the Bosch CC770 and Intel
> AN82527 CAN controllers in our out-of-tree Socket-CAN repository.
> It would be nice if somebody could test the driver. Unfortunately,
> I currently do not have hardware at hand. I have not yet ported the
> OF platform driver as it needs further attaention due to the merge
> of the platform and OF platform interface.
>
> Wolfgang Grandegger (2):
> can: cc770: add driver core for the Bosch CC770 and Intel AN82527
> can: cc770: legacy CC770 ISA bus driver
All applied, thank you.
^ permalink raw reply
* Re: [PATCH 2/2 v5] net/smsc911x: Add regulator support
From: David Miller @ 2011-11-29 23:37 UTC (permalink / raw)
To: robert.marklund
Cc: netdev, steve.glendinning, mathieu.poirier, lethal, linux-sh,
s.hauer, tony, linux-omap, vapier, uclinux-dist-devel,
linus.walleij
In-Reply-To: <1322132587-2049-1-git-send-email-robert.marklund@stericsson.com>
From: Robert Marklund <robert.marklund@stericsson.com>
Date: Thu, 24 Nov 2011 12:03:07 +0100
> Add some basic regulator support for the power pins, as needed
> by the ST-Ericsson Snowball platform that powers up the SMSC911
> chip using an external regulator.
>
> Platforms that use regulators and the smsc911x and have no defined
> regulator for the smsc911x and claim complete regulator
> constraints with no dummy regulators will need to provide it, for
> example using a fixed voltage regulator. It appears that this may
> affect (apart from Ux500 Snowball) possibly these archs/machines
> that from some grep:s appear to define both CONFIG_SMSC911X and
> CONFIG_REGULATOR:
>
> - ARM Freescale mx3 and OMAP 2 plus, Raumfeld machines
> - Blackfin
> - Super-H
>
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: linux-sh@vger.kernel.org
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap@vger.kernel.org
> Cc: Mike Frysinger <vapier@gentoo.org>
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] can: sja1000_isa: convert to platform driver to support x86_64 systems
From: David Miller @ 2011-11-29 23:36 UTC (permalink / raw)
To: wg; +Cc: Netdev, linux-can, lambert.willy
In-Reply-To: <4ECE153E.7090408@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 24 Nov 2011 10:58:22 +0100
> This driver is currently not supported on x86_64 systems because the
> "isa_driver" interface is used (CONFIG_ISA=y). To overcome this
> limitation, the driver is converted to a platform driver, similar to
> the serial 8250 driver.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] bonding: only use primary address for ARP
From: David Miller @ 2011-11-29 23:33 UTC (permalink / raw)
To: henrik.e.persson; +Cc: netdev, fubar
In-Reply-To: <20111124093715.GA25365@as68121.uab.ericsson.se>
From: Henrik Saavedra Persson <henrik.e.persson@ericsson.com>
Date: Thu, 24 Nov 2011 10:37:15 +0100
> Only use the primary address of the bond device
> for master_ip. This will prevent changing the ARP source
> address in Active-Backup mode whenever a secondry address
> is added to the bond device.
>
> Signed-off-by: Henrik Saavedra Persson <henrik.e.persson@ericsson.com>
Bonding hackers, please review this.
^ permalink raw reply
* Re: [PATCH] ipv4: remove useless codes in ipmr_device_event()
From: David Miller @ 2011-11-29 23:32 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1322125852-15395-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 24 Nov 2011 17:10:52 +0800
> From: RongQing.Li <roy.qing.li@gmail.com>
>
> Commit 7dc00c82 added a 'notify' parameter for vif_delete() to
> distinguish whether to unregister the device.
>
> When notify=1 means we does not need to unregister the device,
> so calling unregister_netdevice_many is useless.
>
> Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCH] can: sja1000_isa: fix "limited range" compiler warnings
From: David Miller @ 2011-11-29 23:29 UTC (permalink / raw)
To: wg; +Cc: Netdev, linux-can
In-Reply-To: <4ECE0993.6050902@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Thu, 24 Nov 2011 10:08:35 +0100
> This patch fixes the compiler warnings: "comparison is always
> false due to limited range of data type" by using "0xff" instead
> of "-1" for unsigned values.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] Fix skb_update_prio
From: David Miller @ 2011-11-29 23:25 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <1322243094-10420-2-git-send-email-igorm@etf.rs>
From: igorm@etf.rs
Date: Fri, 25 Nov 2011 18:44:54 +0100
> From: Igor Maravic <igorm@etf.rs>
>
> Change function rcu_dereference to rcu_dereference_bh to avoid warning
>
> [ INFO: suspicious RCU usage. ]
> -------------------------------
> net/core/dev.c:2459 suspicious rcu_dereference_check() usage!
>
> because we are locking with
>
> rcu_read_lock_bh();
>
> in function dev_queue_xmit(struct sk_buff *skb)
>
> Signed-off-by: Igor Maravic <igorm@etf.rs>
Applied, thanks.
^ permalink raw reply
* Re: RCU'ed dst_get_neighbour()
From: Eric Dumazet @ 2011-11-29 23:25 UTC (permalink / raw)
To: David Miller
Cc: tsi-yfeSBMgouQgsA/PxXw9srA, roland-DgEjT+Ai2ygdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111129.182441.956675970003939556.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Le mardi 29 novembre 2011 à 18:24 -0500, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed, 30 Nov 2011 00:11:01 +0100
>
> > For example, recently added skb_update_prio() is buggy, since it uses
> > rcu_dereference() while its caller, dev_queue_xmit() called
> > rcu_read_lock_bh()
>
> We have a fixed queued up for that from Igor, I'll apply that right now.
OK, fine :)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: RCU'ed dst_get_neighbour()
From: David Miller @ 2011-11-29 23:24 UTC (permalink / raw)
To: eric.dumazet; +Cc: tsi, roland, netdev, linux-rdma
In-Reply-To: <1322608261.2596.48.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 30 Nov 2011 00:11:01 +0100
> For example, recently added skb_update_prio() is buggy, since it uses
> rcu_dereference() while its caller, dev_queue_xmit() called
> rcu_read_lock_bh()
We have a fixed queued up for that from Igor, I'll apply that right now.
^ permalink raw reply
* [PATCH net-next] net: proper locking in skb_update_prio()
From: Eric Dumazet @ 2011-11-29 23:24 UTC (permalink / raw)
To: Marc Aurele La France, Neil Horman
Cc: Roland Dreier, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1322608261.2596.48.camel@edumazet-laptop>
Le mercredi 30 novembre 2011 à 00:11 +0100, Eric Dumazet a écrit :
> Some changes are needed now rcu_read_lock_bh() doesnt imply
> rcu_read_lock().
>
> For example, recently added skb_update_prio() is buggy, since it uses
> rcu_dereference() while its caller, dev_queue_xmit() called
> rcu_read_lock_bh()
>
>
[PATCH net-next] net: proper locking in skb_update_prio()
We must use rcu_read_lock() in skb_update_prio(), since dev_queue_xmit()
uses rcu_read_lock_bh()
[ 15.441620] [ INFO: suspicious RCU usage. ]
[ 15.441622] -------------------------------
[ 15.441624] net/core/dev.c:2476 suspicious rcu_dereference_check() usage!
[ 15.441625]
[ 15.441626] other info that might help us debug this:
[ 15.441626]
[ 15.441628]
[ 15.441628] rcu_scheduler_active = 1, debug_locks = 1
[ 15.441630] 1 lock held by arping/4373:
[ 15.441632] #0: (rcu_read_lock_bh){......}, at: [<c13049b0>] dev_queue_xmit+0x0/0xa90
[ 15.441641]
[ 15.441642] stack backtrace:
[ 15.441644] Pid: 4373, comm: arping Not tainted 3.2.0-rc2-12727-gd69d22a-dirty #1261
[ 15.441646] Call Trace:
[ 15.441651] [<c13bae42>] ? printk+0x18/0x1e
[ 15.441656] [<c107f1aa>] lockdep_rcu_suspicious+0xaa/0xc0
[ 15.441658] [<c130507a>] dev_queue_xmit+0x6ca/0xa90
[ 15.441661] [<c13049b0>] ? dev_hard_start_xmit+0x810/0x810
[ 15.441665] [<c131cb84>] ? eth_header+0x24/0xb0
[ 15.441668] [<c139c4f8>] packet_sendmsg+0x978/0x9d0
[ 15.441671] [<c131cb60>] ? eth_rebuild_header+0x80/0x80
[ 15.441675] [<c12f3173>] ? sock_update_netprioidx+0xa3/0x110
[ 15.441678] [<c12ee93e>] sock_sendmsg+0xce/0x100
[ 15.441682] [<c10e354e>] ? might_fault+0x2e/0x80
[ 15.441684] [<c10e354e>] ? might_fault+0x2e/0x80
[ 15.441687] [<c10e3594>] ? might_fault+0x74/0x80
[ 15.441691] [<c11ce55f>] ? _copy_from_user+0x3f/0x60
[ 15.441693] [<c12f03e2>] sys_sendto+0xb2/0xe0
[ 15.441696] [<c108288b>] ? lock_release_non_nested+0x8b/0x300
[ 15.441699] [<c10e354e>] ? might_fault+0x2e/0x80
[ 15.441701] [<c10e354e>] ? might_fault+0x2e/0x80
[ 15.441704] [<c12f0cd0>] sys_socketcall+0x1a0/0x280
[ 15.441708] [<c13bfc90>] sysenter_do_call+0x12/0x36
Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
---
net/core/dev.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 91a5991..903fd9d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2473,10 +2473,15 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
#if IS_ENABLED(CONFIG_NETPRIO_CGROUP)
static void skb_update_prio(struct sk_buff *skb)
{
- struct netprio_map *map = rcu_dereference(skb->dev->priomap);
+ if (!skb->priority && skb->sk) {
+ struct netprio_map *map;
- if ((!skb->priority) && (skb->sk) && map)
- skb->priority = map->priomap[skb->sk->sk_cgrp_prioidx];
+ rcu_read_lock();
+ map = rcu_dereference(skb->dev->priomap);
+ if (map)
+ skb->priority = map->priomap[skb->sk->sk_cgrp_prioidx];
+ rcu_read_unlock();
+ }
}
#else
#define skb_update_prio(skb)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 related
* Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: David Miller @ 2011-11-29 23:23 UTC (permalink / raw)
To: ja; +Cc: jeroen, netdev
In-Reply-To: <alpine.LFD.2.00.1111300010150.2020@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Wed, 30 Nov 2011 01:06:46 +0200 (EET)
> May be the solution is to convert inet_addr_lst
> from hlist to normal list, so that we can append new
> addresses at tail and __ip_dev_find to find the first
> device where IP was added.
Sure, but do we really want to guarentee this behavior forever?
^ permalink raw reply
* Re: Bonding fixes for 2.6.33.y
From: Greg KH @ 2011-11-29 22:49 UTC (permalink / raw)
To: Ben Hutchings; +Cc: stable, Jay Vosburgh, Andy Gospodarek, Neil Horman, netdev
In-Reply-To: <1322533200.26733.15.camel@bwh-desktop>
On Tue, Nov 29, 2011 at 02:19:59AM +0000, Ben Hutchings wrote:
> These have been applied to 2.6.32.y but are missing from 2.6.33.y:
Perhaps because 2.6.33.y is not end-of-life and is not having any more
releases?
sorry,
greg k-h
^ permalink raw reply
* Re: ebtables on a stick
From: Michal Soltys @ 2011-11-29 23:11 UTC (permalink / raw)
To: David Lamparter; +Cc: Greg Scott, netdev
In-Reply-To: <20111128143901.GA589422@jupiter.n2.diac24.net>
On 11-11-28 15:39, David Lamparter wrote:
> On Sun, Nov 27, 2011 at 09:10:08AM -0600, Greg Scott wrote:
>> I have a situation that needs to route mostly and bridge only a
>> little bit.
>>
>> I have a private internal LAN, 192.168.10.nnn. But one host in the
>> internal side needs a real public IP Address, call it 1.2.115.157.
>> Everything except that public IP host needs to route. The public
>> host needs to bridge so it can interact with the world. But it also
>> needs to interact with the internal LAN.
>>
>> I have a Linux brouter set up with eth0 facing the Internet, eth1
>> facing the LAN as follows:
>>
>> ifconfig eth0 1.2.115.146 mask 255.255.255.240 ifconfig eth1
>> 192.168.10.1 mask 255.255.255.0
> [...]
>
> This doesn't answer your question, but your use case is better solved
> with proxy arp.
>
> ip route add 1.2.115.157/32 dev eth1
> ip neigh add proxy 1.2.115.157 dev eth0
> # ... adjust iptables rules to make sure traffic is allowed
> # optional, but I'd recommend:
> iptables -t raw -I PREROUTING -d 1.2.115.157 -j NOTRACK
> iptables -t raw -I PREROUTING -s 1.2.115.157 -j NOTRACK
>
> on the target host:
>
> ip addr add 1.2.115.157/32 dev ethX
> ip route add 192.168.10.1/24 dev ethX
> ip route add default via 192.168.10.1
In addition to what David wrote, you might want specify 'src' option on
certain routes, and/or specify scopes by hand.
For example if the lan host in question has something like:
ip add add 192.168.10.2/24 broad + dev eth0 scope link ip add add
1.2.115.157/32 dev eth0 scope global ip ro add unicast default via
192.168.10.1 dev eth0 src 1.2.115.157
Then the 'src' will prefer public ip for non-lan communication (even
without scopes).
Make sure, when you (likely) do snat with iptables on the router, to
skip this address in such case (in case of not using notrack).
BTW, scopes can help with masquerade target on router (not important in
your case as you have static addresses, but still), as it will choose
candidates with global scope.
^ permalink raw reply
* Re: RCU'ed dst_get_neighbour()
From: Eric Dumazet @ 2011-11-29 23:11 UTC (permalink / raw)
To: Marc Aurele La France
Cc: Roland Dreier, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.WNT.2.00.1111291600220.228@TSI>
Le mardi 29 novembre 2011 à 16:03 -0700, Marc Aurele La France a écrit :
> No, only warnings (splats as you call them) would be produced. The fact
> is you added side-effects to dst_get_neighbour(), and I would expect all
> its invocations to be affected.
>
A splat _is_ a bad thing.
We certainly have some bugs, but I sent an infiniband patch, not a
'change the world' one ;)
Most of the network stack is run under rcu_read_lock() already.
If you notice other lockdep splats, please shout :)
Some changes are needed now rcu_read_lock_bh() doesnt imply
rcu_read_lock().
For example, recently added skb_update_prio() is buggy, since it uses
rcu_dereference() while its caller, dev_queue_xmit() called
rcu_read_lock_bh()
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: Daughterboard Jetway JAD3RTLANG with three RTL-8110SC/8169SC Gigabit Ethernet is curious
From: Francois Romieu @ 2011-11-29 23:04 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <4ED4E946.40209@gmx.de>
Markus Feldmann <feldmann_markus@gmx.de> :
[...]
> You mean the latest Linux kernel was patched for a better
> initialization? At the moment i am using the kernel 3.0.8. As i
> understood the firmware must be loaded at every power on.
What do you mean ? Afaik there is no out-of-driver firmware for the
(old) 8169sc.
Can either of you or Carsten compare and send 'lspci -vv' before and
after windows installs ?
--
Ueimor
^ permalink raw reply
* Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: Julian Anastasov @ 2011-11-29 23:06 UTC (permalink / raw)
To: Jeroen van Ingen; +Cc: netdev
In-Reply-To: <1322585087.25018.115.camel@icts-sp-039>
Hello,
On Tue, 29 Nov 2011, Jeroen van Ingen wrote:
> Hi,
>
> We're having an issue on our Linux PPTP servers. After the first PPTP
> client is connected, locally generated broadcast packets go out the ppp0
> interface while the routing rules should select eth0.
>
> Some details were already mentioned on the linux-kernel list, see eg
> http://lkml.indiana.edu/hypermail/linux/kernel/1111.2/00290.html for
> reference.
>
> Finally we were able to narrow it down to one specific commit:
> e066008b38ca9ace1b6de8dbbac8ed460640791d ("ipv4: Fix __ip_dev_find() to
> use ifa_local instead of ifa_address."). With all recent kernels (tested
> up to 3.2.0rc3) we observe this issue and it's solved by reverting this
> single patch.
>
> This is the first time we've had to debug a kernel issue. Any advice on
> how to proceed would be very welcome. If it's not possible to have this
> patch reverted in the kernel, hopefully someone can explain how to work
> around this behavior.
__ip_dev_find can cause problem if same IP is added on many
interfaces because it uses hash table implemented with hlist.
Old versions used only routing lookup and the routing returns
the first created local route, i.e. the first device where this
IP was added is returned.
And now it is risky to use __ip_dev_find in
ip_route_output_slow when:
- saddr is provided
- desired oif is 0
- daddr is multicast/lbcast
We select oif by ignoring route ordering. May be some
ppp device wins here because it has this saddr added last but
is first in hlist.
What is the case after first client is connected, can
you show output from:
ip addr show
ip route list table local
If the above is true may be we have to find a
way to return the first device where the IP is added.
May be this is the main rule that is used when one adds
same IP on many interfaces.
May be the solution is to convert inet_addr_lst
from hlist to normal list, so that we can append new
addresses at tail and __ip_dev_find to find the first
device where IP was added.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: RCU'ed dst_get_neighbour()
From: Marc Aurele La France @ 2011-11-29 23:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Roland Dreier, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1322606542.2596.43.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1650 bytes --]
On Tue, 29 Nov 2011, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 15:32 -0700, Marc Aurele La France a écrit :
>> But your audit is incomplete, a grep of 3.1.3 for dst_get_neighbour() and
>> dst_get_neighbour_raw() reveals occurrences in ...
>> include/net/dst.h
>> net/atm/clip.c
>> net/sched/sch_teql.c
>> net/core/neighbour.c
>> net/ipv4/ip_gre.c
>> net/ipv4/ip_output.c
>> net/ipv4/route.c
>> net/xfrm/xfrm_policy.c
>> net/bridge/br_netfilter.c
>> net/decnet/dn_neigh.c
>> net/decnet/dn_route.c
>> net/ipv6/sit.c
>> net/ipv6/addrconf.c
>> net/ipv6/route.c
>> net/ipv6/ndisc.c
>> net/ipv6/ip6_output.c
>> net/ipv6/ip6_fib.c
> All these are already covered, or else bad things would already
> happened.
No, only warnings (splats as you call them) would be produced. The fact
is you added side-effects to dst_get_neighbour(), and I would expect all
its invocations to be affected.
Marc.
+----------------------------------+----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi-yfeSBMgouQgsA/PxXw9srA@public.gmane.org |
| 352 General Services Building +----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+----------------------------------+
^ permalink raw reply
* Re: RCU'ed dst_get_neighbour()
From: Eric Dumazet @ 2011-11-29 22:42 UTC (permalink / raw)
To: Marc Aurele La France
Cc: Roland Dreier, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.WNT.2.00.1111291527360.228@TSI>
Le mardi 29 novembre 2011 à 15:32 -0700, Marc Aurele La France a écrit :
> On Tue, 29 Nov 2011, Eric Dumazet wrote:
>
> > Le mardi 29 novembre 2011 à 22:17 +0100, Eric Dumazet a écrit :
> >> Le mardi 29 novembre 2011 à 14:00 -0700, Marc Aurele La France a écrit :
> >>> On Tue, 29 Nov 2011, Eric Dumazet wrote:
> >>>> Oh well, I forgot one rcu_read_unlock(), I'll send a V2...
>
> >>> This also doesn't address the other dst_get_neighbour() instances
> >>> introduced by
> >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=69cce1d1404968f78b177a0314f5822d5afdbbfb
>
> >> Oh well, a complete audit is needed, and I have no choice but doing it.
>
> > Here is the result of this audit, please double check and test it, I
> > only compiled this.
>
> > [PATCH V2] drivers/infiniband: fix lockdep splats
>
> > commit f2c31e32b37 (net: fix NULL dereferences in check_peer_redir())
> > forgot to take care of infiniband uses of dst neighbours.
>
> > Many thanks to Marc Aurele who provided a nice bug report and feedback.
>
> > Reported-by: Marc Aurele La France <tsi-yfeSBMgouQgsA/PxXw9srA@public.gmane.org>
> > Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > CC: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > ---
> > drivers/infiniband/core/addr.c | 9 +++++--
> > drivers/infiniband/hw/cxgb3/iwch_cm.c | 4 +++
> > drivers/infiniband/hw/cxgb4/cm.c | 6 +++++
> > drivers/infiniband/hw/nes/nes_cm.c | 6 +++--
> > drivers/infiniband/ulp/ipoib/ipoib_main.c | 18 +++++++++------
> > drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 +++--
> > 6 files changed, 35 insertions(+), 14 deletions(-)
>
> This looks good to me, although I'm a little iffy on your use of
> dst_get_neighbour_raw(), but that could be just me.
>
If you only test the neigh pointer being null (or not null), you dont
need to rcu_read_lock() before.
> But your audit is incomplete, a grep of 3.1.3 for dst_get_neighbour() and
> dst_get_neighbour_raw() reveals occurrences in ...
>
:=)
> include/net/dst.h
> net/atm/clip.c
> net/sched/sch_teql.c
> net/core/neighbour.c
> net/ipv4/ip_gre.c
> net/ipv4/ip_output.c
> net/ipv4/route.c
> net/xfrm/xfrm_policy.c
> net/bridge/br_netfilter.c
> net/decnet/dn_neigh.c
> net/decnet/dn_route.c
> net/ipv6/sit.c
> net/ipv6/addrconf.c
> net/ipv6/route.c
> net/ipv6/ndisc.c
> net/ipv6/ip6_output.c
> net/ipv6/ip6_fib.c
>
So you did a grep but did not an analysis, did you ?
All these are already covered, or else bad things would already
happened.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: RCU'ed dst_get_neighbour()
From: Marc Aurele La France @ 2011-11-29 22:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Roland Dreier, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1322602283.2596.25.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3486 bytes --]
On Tue, 29 Nov 2011, Eric Dumazet wrote:
> Le mardi 29 novembre 2011 à 22:17 +0100, Eric Dumazet a écrit :
>> Le mardi 29 novembre 2011 à 14:00 -0700, Marc Aurele La France a écrit :
>>> On Tue, 29 Nov 2011, Eric Dumazet wrote:
>>>> Oh well, I forgot one rcu_read_unlock(), I'll send a V2...
>>> This also doesn't address the other dst_get_neighbour() instances
>>> introduced by
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=69cce1d1404968f78b177a0314f5822d5afdbbfb
>> Oh well, a complete audit is needed, and I have no choice but doing it.
> Here is the result of this audit, please double check and test it, I
> only compiled this.
> [PATCH V2] drivers/infiniband: fix lockdep splats
> commit f2c31e32b37 (net: fix NULL dereferences in check_peer_redir())
> forgot to take care of infiniband uses of dst neighbours.
> Many thanks to Marc Aurele who provided a nice bug report and feedback.
> Reported-by: Marc Aurele La France <tsi-yfeSBMgouQgsA/PxXw9srA@public.gmane.org>
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> CC: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> drivers/infiniband/core/addr.c | 9 +++++--
> drivers/infiniband/hw/cxgb3/iwch_cm.c | 4 +++
> drivers/infiniband/hw/cxgb4/cm.c | 6 +++++
> drivers/infiniband/hw/nes/nes_cm.c | 6 +++--
> drivers/infiniband/ulp/ipoib/ipoib_main.c | 18 +++++++++------
> drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 +++--
> 6 files changed, 35 insertions(+), 14 deletions(-)
This looks good to me, although I'm a little iffy on your use of
dst_get_neighbour_raw(), but that could be just me.
But your audit is incomplete, a grep of 3.1.3 for dst_get_neighbour() and
dst_get_neighbour_raw() reveals occurrences in ...
drivers/scsi/cxgbi/cxgb3i/cxgb3i.c
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
drivers/scsi/cxgbi/libcxgbi.c
drivers/s390/net/qeth_l3_main.c
drivers/net/cxgb3/cxgb3_offload.c
drivers/infiniband/hw/cxgb3/iwch_cm.c
drivers/infiniband/hw/nes/nes_cm.c
drivers/infiniband/hw/cxgb4/cm.c
drivers/infiniband/core/addr.c
drivers/infiniband/ulp/ipoib/ipoib_main.c
drivers/infiniband/ulp/ipoib/ipoib_multicast.c
include/net/dst.h
net/atm/clip.c
net/sched/sch_teql.c
net/core/neighbour.c
net/ipv4/ip_gre.c
net/ipv4/ip_output.c
net/ipv4/route.c
net/xfrm/xfrm_policy.c
net/bridge/br_netfilter.c
net/decnet/dn_neigh.c
net/decnet/dn_route.c
net/ipv6/sit.c
net/ipv6/addrconf.c
net/ipv6/route.c
net/ipv6/ndisc.c
net/ipv6/ip6_output.c
net/ipv6/ip6_fib.c
(I'd list them all here, but I'm having issues with my MUA when I do so.)
Marc.
+----------------------------------+----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi-yfeSBMgouQgsA/PxXw9srA@public.gmane.org |
| 352 General Services Building +----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+----------------------------------+
^ permalink raw reply
* Re: [RFC PATCH 00/18] netfilter: IPv6 NAT
From: Jan Engelhardt @ 2011-11-29 22:21 UTC (permalink / raw)
To: Krzysztof Olędzki
Cc: Ulrich Weber, Amos Jeffries, sclark46@earthlink.net,
kaber@trash.net, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <4ED550E7.1090609@ans.pl>
On Tuesday 2011-11-29 22:38, Krzysztof Olędzki wrote:
>>
>> Same network prefix, some cookies, or a login form. Blam, identified,
>> or at least (Almost-)Uniquely Identified Visitor tagging.
>
> But without NAT you have pretty big chance to have the same IPv6 *suffix*
> everywhere, based on you MAC address.
Everywhere? No, one small village of indomitable Gauls.^^^^^^^^W
$ ip a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:0d:93:9e:08:78 brd ff:ff:ff:ff:ff:ff
inet6 2001:638:600:8810:d070:3a36:464e:b3db/64 scope global temporary dynamic
valid_lft 583732sec preferred_lft 64732sec
inet6 2001:638:600:8810:d9f5:18f5:4fc1:9a20/64 scope global temporary deprecated dynamic
valid_lft 497938sec preferred_lft 0sec
[...]
Same suffix? Certainly not with contemporary configurations (and
Linux did this quite on its own there). In fact, now that there is
almost v6-NAT in the kernel, I fear that users who are blinded by NAT
now make the problem worse by actually feeding perfectly good Privacy
Extension Addresses into a n:1-configured SNAT/MASQUERADE target
instead of a NETMAP.
> In your Home, your Work, in a Cafe or in
> a hotel during your vacations in Portugal.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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