* Re: [PATCH net v2] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-14 10:23 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131114101028.GQ19702@redhat.com>
On 2013/11/14 18:10, Veaceslav Falico wrote:
> On Thu, Nov 14, 2013 at 10:35:44AM +0800, Ding Tianhong wrote:
> ...snip...
>> - newtarget = in_aton(buf + 1);
>> + if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
>> + newtarget == 0) {
>
> Good catch on that newtarget verification, forgot to add it. However, the
> previous checked not only for all-zeroes, but also for the broadcast, so
> it'd be great if you could maintain the previous functionality/checks.
>
> Or, even better, you could do something like SCTP does in
> IS_IPV4_UNUSABLE_ADDRESS():
>
> 353 #define IS_IPV4_UNUSABLE_ADDRESS(a) \
> 354 ((htonl(INADDR_BROADCAST) == a) || \
> 355 ipv4_is_multicast(a) || \
> 356 ipv4_is_zeronet(a) || \
> 357 ipv4_is_test_198(a) || \
> 358 ipv4_is_anycast_6to4(a))
>
> It's up to you, though, I think that either way works good - it's
> sysadmin's job to know which addresses can/have to be used.
>
> Also, fix the identation.
>
> Thanks!
>
ok
>> + pr_err("%s: invalid ARP target %pI4 specified for addition\n",
>> + bond->dev->name, &newtarget);
>> + goto out;
>> + }
>> /* look for adds */
>> if (buf[0] == '+') {
>> - if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
>> - pr_err("%s: invalid ARP target %pI4 specified for addition\n",
>> - bond->dev->name, &newtarget);
>> - goto out;
>> - }
>> -
>> if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
>> pr_err("%s: ARP target %pI4 is already present\n",
>> bond->dev->name, &newtarget);
> ...snip...
>
> .
>
^ permalink raw reply
* Re: [PATCH net] sit: fix use after free of fb_tunnel_dev
From: Nicolas Dichtel @ 2013-11-14 10:31 UTC (permalink / raw)
To: Willem de Bruijn, davem, edumazet, netdev
In-Reply-To: <1384396058-26850-1-git-send-email-willemb@google.com>
Le 14/11/2013 03:27, Willem de Bruijn a écrit :
> Bug: The fallback device is created in sit_init_net and assumed to be
> freed in sit_exit_net. First, it is dereferenced in that function, in
> sit_destroy_tunnels:
>
> struct net *net = dev_net(sitn->fb_tunnel_dev);
>
> Prior to this, rtnl_unlink_register has removed all devices that match
> rtnl_link_ops == sit_link_ops.
>
> Commit 205983c43700 added the line
>
> + sitn->fb_tunnel_dev->rtnl_link_ops = &sit_link_ops;
>
> which cases the fallback device to match here and be freed before it
> is last dereferenced.
>
> Fix: This commit adds an explicit .delllink callback to sit_link_ops
> that skips deallocation at rtnl_unlink_register for the fallback
> device. This mechanism is comparable to the one in ip_tunnel.
>
> It also modifies sit_destroy_tunnels and its only caller sit_exit_net
> to avoid the offending dereference in the first place. That double
> lookup is more complicated than required.
>
> Test: The bug is only triggered when CONFIG_NET_NS is enabled. It
> causes a GPF only when CONFIG_DEBUG_SLAB is enabled. Verified that
> this bug exists at the mentioned commit, at davem-net HEAD and at
> 3.11.y HEAD. Verified that it went away after applying this patch.
>
> Fixes: 205983c43700 ("sit: allow to use rtnl ops on fb tunnel")
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
With your patch, it's no more possible to remove manually the fallback device:
'ip link del sit0', but it's better so ;-)
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net v2] ipv4: fix wildcard search with inet_confirm_addr()
From: Nicolas Dichtel @ 2013-11-14 10:32 UTC (permalink / raw)
To: Julian Anastasov; +Cc: davem, netdev
In-Reply-To: <alpine.LFD.2.03.1311132244001.1712@ssi.bg>
Le 13/11/2013 22:27, Julian Anastasov a écrit :
>
> Hello,
>
> On Wed, 13 Nov 2013, Nicolas Dichtel wrote:
>
>> Help of this function says: "in_dev: only on this interface, 0=any interface",
>> but since commit 39a6d0630012 ("[NETNS]: Process inet_confirm_addr in the
>> correct namespace."), the code supposes that it will never be NULL. This
>> function is never called with in_dev == NULL, but it's exported and may be used
>> by an external module.
>>
>> Because this patch restore the ability to call inet_confirm_addr() with in_dev
>> == NULL, I partially revert the above commit, as suggested by Julian.
>>
>> CC: Julian Anastasov <ja@ssi.bg>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> This patch looks ok to me, thanks!
>
> Reviewed-by: Julian Anastasov <ja@ssi.bg>
>
> Still, I think this is a net-next material
> and you have to wait some days... The net tree that
Ok.
> you are using is missing the changes that remove
> 'extern', so I think you have to port it to net-next
> tree to avoid the conflict in include/linux/inetdevice.h.
Yes, checkpatch already warns about this extern kerword.
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH v2] mac80211: add assoc beacon timeout logic
From: Felipe Contreras @ 2013-11-14 10:44 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless Mailing List, netdev, John W. Linville,
David S. Miller
In-Reply-To: <1384367422.14578.20.camel@jlt4.sipsolutions.net>
On Wed, Nov 13, 2013 at 12:30 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2013-11-11 at 12:06 -0600, Felipe Contreras wrote:
>
>> > The not receiving part is a bug. I think you're probably receiving
>> > beacons once associated though?
>>
>> Nope. Never.
>
> That's odd, firmware bug? But it's still odd since windows works?
>
>> Moreover, if continuing the association without beacons has a legal a
>> problem, that problem would exist for drivers that don't have the
>> IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC flag, wouldn't it? How exactly
>> would trying to associate with need_beacon break the law, but not if
>> !need_beacon?
>
> Well, it's actually somewhat unlikely you'd break the law, although
> possible, since eventually you'd get disconnected from the AP anyway?
I get disconnected from the AP due to other bugs, you are making the
assumption that it's because of the lack of beacons.
I saw this the last time I experienced a disconnect:
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: fail to flush all
tx fifo queues Q 2
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Current SW read_ptr
213 write_ptr 214
Nov 13 16:29:48 nysa kernel: iwl data: 00000000: 00 00 20 00 00 00 00
00 00 00 00 00 00 00 00 00 .. .............
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(0) = 0x8000302e
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(1) = 0x801020d5
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(2) = 0x80201016
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(3) = 0x803000fb
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(7) = 0x00709010
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 0 is active and
mapped to fifo 3 ra_tid 0x0000 [252,252]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 1 is active and
mapped to fifo 2 ra_tid 0x0000 [23,23]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 2 is active and
mapped to fifo 1 ra_tid 0x0000 [213,214]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 3 is active and
mapped to fifo 0 ra_tid 0x0000 [47,47]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 4 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 5 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 6 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 7 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 8 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 9 is active and
mapped to fifo 7 ra_tid 0x0000 [17,17]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 10 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 11 is inactive
and mapped to fifo 1 ra_tid 0x0000 [163,163]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 12 is inactive
and mapped to fifo 3 ra_tid 0x0006 [236,236]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 13 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 14 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 15 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 16 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 17 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 18 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Nov 13 16:29:48 nysa kernel: iwlwifi 0000:02:00.0: Q 19 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
> In any case - your argumentation above isn't true because every device
> listens for beacons, and if none are received then it should eventually
> disconnect. That should be true even with your hack here.
Should it? I don't see that happening. Where exactly in the code is that check?
> In any case, I'm not really comfortable connecting to an AP that we
> never ever receive beacons from.
Well, we are *already* doing that for every driver, except the ones
that do IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC, which are few.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
From: Milan Kocian @ 2013-11-14 10:18 UTC (permalink / raw)
To: netdev; +Cc: jeffrey.t.kirsher, jesse.brandeburg
hi,
its probably for intel's guys ...
I see 'Detected Hardware Unit Hang' in log repeatedly until
transmit hangs forever (until reboot:-)). I tried old fixeep
script which I got from Jesse Brandeburg some years ago but
no success. Any ideas ? Many thanks for any answer.
kernel 3.10.18
Outputs & logs:
ethtool -i eth0
driver: e1000e
version: 2.3.2-k
firmware-version: 0.13-4
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
Subsystem: Intel Corporation Device 2036
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at f7d00000 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at f7d35000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f080 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0100c Data: 4172
Capabilities: [e0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: e1000e
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <a9>
TDT <7>
next_to_use <7>
next_to_clean <a6>
buffer_info[next_to_clean]:
time_stamp <4af1c>
next_to_watch <a9>
jiffies <4b12e>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <a9>
TDT <7>
next_to_use <7>
next_to_clean <a6>
buffer_info[next_to_clean]:
time_stamp <4af1c>
next_to_watch <a9>
jiffies <4b386>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <a9>
TDT <7>
next_to_use <7>
next_to_clean <a6>
buffer_info[next_to_clean]:
time_stamp <4af1c>
next_to_watch <a9>
jiffies <4b5de>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <a9>
TDT <7>
next_to_use <7>
next_to_clean <a6>
buffer_info[next_to_clean]:
time_stamp <4af1c>
next_to_watch <a9>
jiffies <4b836>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1cc/0x1e0()
NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
Modules linked in: tun ipv6 xt_nat xt_conntrack xt_tcpudp xt_LOG xt_limit iptable_nat nf_nat_ipv4 nf_nat iptable_filter ip_tables x_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_pci ehci_hcd e1000e coretemp xhci_hcd hwmon usbcore crc32_pclmul iTCO_wdt iTCO_vendor_support lpc_ich crc32c_intel mfd_core ptp pps_core usb_common i2c_i801 i2c_core microcode
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.18-core2-router18 #3
Hardware name: /DQ77KB, BIOS KBQ7710H.86A.0049.2013.0130.1732 01/30/2013
c12ad3ea c102836e c135ece0 f540bf58 000000ff c123b38c c123b38c 00000000
f4d98000 000005dc 0004b964 c10283c3 00000009 f540bf40 c135ece0 f540bf58
c123b38c c135bdec 000000ff c135ece0 f4d98000 f8184740 00000000 00000100
Call Trace:
[<c12ad3ea>] ? dump_stack+0xa/0x13
[<c102836e>] ? warn_slowpath_common+0x5e/0x80
[<c123b38c>] ? dev_watchdog+0x1cc/0x1e0
[<c123b38c>] ? dev_watchdog+0x1cc/0x1e0
[<c10283c3>] ? warn_slowpath_fmt+0x33/0x40
[<c123b38c>] ? dev_watchdog+0x1cc/0x1e0
[<c123b1c0>] ? dev_graft_qdisc+0x60/0x60
[<c1033636>] ? call_timer_fn.isra.35+0x16/0x70
[<c1045168>] ? hrtimer_run_pending+0x28/0xe0
[<c10337a9>] ? run_timer_softirq+0x119/0x1a0
[<c102e9e3>] ? __do_softirq+0xa3/0x160
[<c102e940>] ? remote_softirq_receive+0x40/0x40
<IRQ> [<c102eb85>] ? irq_exit+0x45/0x50
[<c101a912>] ? smp_apic_timer_interrupt+0x52/0x90
[<c12b02a5>] ? apic_timer_interrupt+0x2d/0x34
[<c1008002>] ? default_idle+0x2/0x10
[<c10085a6>] ? arch_cpu_idle+0x6/0x10
[<c1052767>] ? cpu_startup_entry+0xa7/0xf0
[<c13be926>] ? start_kernel+0x285/0x28a
[<c13be4ed>] ? repair_env_string+0x4d/0x4d
---[ end trace a052b68b72311803 ]---
e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <92>
TDT <b6>
next_to_use <b6>
next_to_clean <92>
buffer_info[next_to_clean]:
time_stamp <526ff>
next_to_watch <92>
jiffies <529e2>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
TDH <92>
TDT <b6>
next_to_use <b6>
next_to_clean <92>
buffer_info[next_to_clean]:
time_stamp <526ff>
next_to_watch <92>
jiffies <52c3a>
next_to_watch.status <0>
MAC Status <80083>
PHY Status <796d>
PHY 1000BASE-T Status <3c00>
PHY Extended Status <3000>
PCI Status <10>
e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
--
Milan Kocian
^ permalink raw reply
* Re: [PATCH 1/8] net: smc91x: Fix device tree based configuration so it's usable
From: Mark Rutland @ 2013-11-14 11:03 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Nicolas Pitre, David S. Miller, netdev@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <1384396537-3486-2-git-send-email-tony@atomide.com>
On Thu, Nov 14, 2013 at 02:35:30AM +0000, Tony Lindgren wrote:
> Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
> added minimal device tree support to smc91x, but it's not working on
> many platforms because of the lack of some key configuration bits.
>
> Fix the issue by parsing the necessary configuration like the
> smc911x driver is doing.
>
> Cc: Nicolas Pitre <nico@fluxnic.net>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> If this looks OK, I'd like to merge this as a fix via arm-soc tree
> along with the other patches in this series as my later patches
> depend on patches in this series.
>
> ---
> .../devicetree/bindings/net/smsc-lan91c111.txt | 4 ++
> drivers/net/ethernet/smsc/smc91x.c | 52 +++++++++++++++++-----
> 2 files changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> index 953049b..53d69e3 100644
> --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
> @@ -8,3 +8,7 @@ Required properties:
> Optional properties:
> - phy-device : phandle to Ethernet phy
> - local-mac-address : Ethernet mac address to use
> +- reg-io-width : Specify the size (in bytes) of the IO accesses that
> + should be performed on the device. Valid value for SMSC LAN is
> + 1, 2 or 4. If it's omitted or invalid, the size would be 2.
In the driver the supported access sizes are not mutually exclusive. It
would be nice for the binding to have the same property.
> +- smsc,nowait : Setup for fast register access with no waits
I'm confused by what this means. When would this be selected, and when
wouldn't it be?
Thanks,
Mark.
^ permalink raw reply
* [PATCH net v3] bonding: add ip checks when store ip target
From: Ding Tianhong @ 2013-11-14 11:02 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
I met a Bug when I add ip target with the wrong ip address:
echo +500.500.500.500 > /sys/class/net/bond0/bonding/arp_ip_target
the wrong ip address will transfor to 245.245.245.244 and add
to the ip target success, it is uncorrect, so I add checks to avoid
adding wrong address.
The in4_pton() will set wrong ip address to 0.0.0.0, it will return by
the next check and will not add to ip target.
Thanks for Veaceslav's opinion and make the code more simplify, more correctly.
Suggested-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
drivers/net/bonding/bond_sysfs.c | 19 ++++++-------------
drivers/net/bonding/bonding.h | 3 +++
2 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 47749c9..147dd9c 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -611,15 +611,14 @@ static ssize_t bonding_store_arp_targets(struct device *d,
return restart_syscall();
targets = bond->params.arp_targets;
- newtarget = in_aton(buf + 1);
+ if (!in4_pton(buf + 1, -1, (u8 *)&newtarget, -1, NULL) ||
+ IS_IP_TARGET_UNUSABLE_ADDRESS(newtarget)) {
+ pr_err("%s: invalid ARP target %pI4 specified for addition\n",
+ bond->dev->name, &newtarget);
+ goto out;
+ }
/* look for adds */
if (buf[0] == '+') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for addition\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
if (bond_get_targets_ip(targets, newtarget) != -1) { /* dup */
pr_err("%s: ARP target %pI4 is already present\n",
bond->dev->name, &newtarget);
@@ -642,12 +641,6 @@ static ssize_t bonding_store_arp_targets(struct device *d,
targets[ind] = newtarget;
write_unlock_bh(&bond->lock);
} else if (buf[0] == '-') {
- if ((newtarget == 0) || (newtarget == htonl(INADDR_BROADCAST))) {
- pr_err("%s: invalid ARP target %pI4 specified for removal\n",
- bond->dev->name, &newtarget);
- goto out;
- }
-
ind = bond_get_targets_ip(targets, newtarget);
if (ind == -1) {
pr_err("%s: unable to remove nonexistent ARP target %pI4.\n",
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 046a605..253d5da 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -63,6 +63,9 @@
(((mode) == BOND_MODE_TLB) || \
((mode) == BOND_MODE_ALB))
+#define IS_IP_TARGET_UNUSABLE_ADDRESS(a) \
+ ((htonl(INADDR_BROADCAST) == a) || \
+ ipv4_is_zeronet(a))
/*
* Less bad way to call ioctl from within the kernel; this needs to be
* done some other way to get the call out of interrupt context.
--
1.7.12
^ permalink raw reply related
* Cannot send unicast Ethernet Frame from tap0 to tap1 via bridge
From: Albert Krenz @ 2013-11-14 11:09 UTC (permalink / raw)
To: netdev
Hello together,
i am experiencing a strange behaviour in a bridge which bridges two
tap Interfaces (namely tap0 and tap1) that are generated by two
C-Applications.
It looks like the following:
+------------------------+
+-----------------------+
| |
| |
| Application 1 | ------- tap0 ----- br1 ---- tap1 ----- |
Application 2 |
| |
| |
+------------------------+
+-----------------------+
Application 1 creates tap0 and Application 2 creates tap1. The
creation of the devices is done like in
https://www.kernel.org/doc/Documentation/networking/tuntap.txt
Both Applications acces their respective tap-device via File-IO. The
bridge should bridge the network devices of both tap's.
Here are the MAC-addresses of both tap devices (they only differ in
the last byte):
tap0: XX:XX:XX:XX:XX:B4
tap1: XX:XX:XX:XX:XX:B3
What i want to accomplish is sending an Ethernet Frame (Layer 2, so no
IP Frames) from Application 1 to Application 2 and vice versa.
Therefore i am periodically (1 time per second) writing a Frame with
Dst-addr. of tap1 and Src-addr. of tap0 and vice-versa, to the
File-descriptor of the respectiv tap-device.
I can now check the traversing of the Frame via Wireshark from tap0 to
br1, but it never gets to tap1 and therefore Application 2 never
receives a Frame. Also in the other direction the Frames never pass
through br1 but get stuck.
If i am not using the MAC-addr. of the TAP Devices but a random
unknown Dst-addr like XX:XX:XX:XX:XX:F0 (MAC address not known in the
bridge) it works like a charm and the Frame passes through the bridge
and is received by Application 1 or Application 2.
The same goes for Broadcast/Multicast addresses.
I then tried disabling network Filtering via:
echo 0 > bridge-nf-call-arptables
echo 0 > bridge-nf-call-iptables
echo 0 > bridge-nf-call-ip6tables
but this didn't do the trick.
What also did not work was setting tap0/tap1/br1 into promiscuous
mode. Maybe i first have to add a routing rule via ebtables? I have
tried:
ebtables - A FORWARD -i br1 -o br1 -j ACCEPT
which i found on the internet and did also not work.
My Questions is now: is it possible to bridge two tap devices to send
RAW Ethernet Frames between two Applications? I think this should work
cause it is similar to an KVM/QEMU setup where multiple Virtual Guest
OS's are also able to communicate between each other (via IP frames).
So does anyone have an idea what i am missing?
Greetings
Albert Krenz
^ permalink raw reply
* Re: network namespaces usage in routing appplications with VRF-like features
From: Rami Rosen @ 2013-11-14 11:18 UTC (permalink / raw)
To: Jacob Avraham; +Cc: netdev@vger.kernel.org
In-Reply-To: <292D0115604A314481EE77AB54A844C5672403D2@CMP-EX-DB3.cmpsys.com>
Hi,
> Does RTNETLINK API support adding routes to a particular namespace routing table?
No, at least not directly (though there are cases where you can
specify a network device the RTNETLINK API requests. And in network
namespaces, a network device can belong only to one network namespace
at a given moment. But I am not sure if it is enough for your needs)
Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen
On Wed, Nov 13, 2013 at 2:56 PM, Jacob Avraham
<Jacob.Avraham@compass-eos.com> wrote:
> Hi,
> I'm trying to evaluate the use of network namespaces in some routing applications, which are currently based on the VFR patchset.
> I was thinking about distributing several interfaces among a few namespaces, whereby each namespace has its own routing table(s), ala VRF.
> The questions that I have are:
> 1. Can I open a listening socket that accepts traffic from all interfaces in all namespaces? That's the current behavior of my routing protocol daemons.
> 2. Does RTNETLINK API support adding routes to a particular namespace routing table?
>
> Thanks,
> Jacob
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-14 11:54 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Stefan Priebe, Vlad Yasevich, Linux Netdev List
In-Reply-To: <52843EEA.3020905@redhat.com>
On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>Can you try out attached patch please. I ran it in my environment and
>always get promisc link when attaching devices to the bridge.
It's interesting, actually, why do we need to check for IFF_UP at all when
changing flags.
The addition of IFF_UP goes up to:
commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Oct 7 15:26:48 2008 -0700
net: only invoke dev->change_rx_flags when device is UP
Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
device down that is in promiscous mode:
When the VLAN device is set down, the promiscous count on the real
device is decremented by one by vlan_dev_stop(). When removing the
promiscous flag from the VLAN device afterwards, the promiscous
count on the real device is decremented a second time by the
vlan_change_rx_flags() callback.
... snip ...
However, I'm not sure that this is still needed, cause:
commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
Author: Matthijs Kooijman <matthijs@stdin.nl>
Date: Mon Oct 31 04:53:13 2011 +0000
vlan: Don't propagate flag changes on down interfaces.
When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
flags are cleared or set on the underlying interface. So, if these flags
are changed on a vlan interface that is not up, the flags underlying
interface might be set or cleared twice.
Only propagating flag changes when a device is up makes sure this does
not happen. It also makes sure that an underlying device is not set to
promiscuous or allmulti mode for a vlan device that is down.
... snip ...
which fixed completely the initial issue with vlans.
Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
let the drivers using it handle its own logic, as vlan does?
Something like this:
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ffc52e..9615cd7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
{
const struct net_device_ops *ops = dev->netdev_ops;
- if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
+ if (ops->ndo_change_rx_flags)
ops->ndo_change_rx_flags(dev, flags);
}
>
>Thanks
>-vlad
^ permalink raw reply related
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
From: Veaceslav Falico @ 2013-11-14 12:29 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: vyasevic, Vlad Yasevich, Linux Netdev List
In-Reply-To: <52848010.8030103@profihost.ag>
On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG wrote:
>Hi,
>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>
>thos one works fine now.
>
>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>
>this one does not. Another note to this one. It also never worked on
>RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>3.10. But it was the only one where gvrp on vlans had worked.
bridge device in this config is neither master nor slave, if I read it
correctly.
You might want to try my patch to see if it works (my previous email).
>
>Greets,
>Stefan
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Mugunthan V N @ 2013-11-14 12:45 UTC (permalink / raw)
To: Daniel Mack, netdev; +Cc: davem
In-Reply-To: <1384347180-3490-1-git-send-email-zonque@gmail.com>
On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
> on dual MAC enabled machines.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index edd3e79..702b063 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>
> if (netif_running(ndev))
> cpsw_ndo_stop(ndev);
> +
> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
> + if (priv->data.dual_emac)
> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
Is this tested on a system with both ports in switch mode?
I don't think this will not work with both ports in switch mode.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH net 5/6] ti_cpsw: Validate hwtstamp_config completely before applying it
From: Mugunthan V N @ 2013-11-14 12:49 UTC (permalink / raw)
To: Ben Hutchings, David Miller, Felipe Balbi; +Cc: netdev, Richard Cochran
In-Reply-To: <1384390056.29151.12.camel@bwh-desktop.uk.level5networks.com>
On Thursday 14 November 2013 06:17 AM, Ben Hutchings wrote:
> cpsw_hwtstamp_ioctl() should validate all fields of hwtstamp_config,
> and the hardware version, before making any changes. Currently it
> sets the TX configuration before validating the rx_filter field
> or that the hardware supports timestamping.
>
> Also correct the error code for hardware versions that don't
> support timestamping. ENOTSUPP is used by the NFS implementation
> and is not part of userland API; we want EOPNOTSUPP (which glibc
> also calls ENOTSUP, with one 'P').
>
> Untested as I don't have a cross-compiler to hand.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
Acked-by: Mugunthan V N <mugunthanvnm@gmail.com>
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH net 2/3] sit: link local routes are missing
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
When a link local address was added to a sit interface, the corresponding route
was not configured. This breaks routing protocols that use the link local
address, like OSPFv3.
To ease the code reading, I remove sit_route_add(), which only adds v4 mapped
routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link
local and v4 mapped routes are configured in the same place.
Reported-by: Li Hongjun <hongjun.li@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 24 +++++-------------------
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 4e558e5e0e42..237bceb74c4e 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2006,23 +2006,6 @@ static void addrconf_add_mroute(struct net_device *dev)
ip6_route_add(&cfg);
}
-#if IS_ENABLED(CONFIG_IPV6_SIT)
-static void sit_route_add(struct net_device *dev)
-{
- struct fib6_config cfg = {
- .fc_table = RT6_TABLE_MAIN,
- .fc_metric = IP6_RT_PRIO_ADDRCONF,
- .fc_ifindex = dev->ifindex,
- .fc_dst_len = 96,
- .fc_flags = RTF_UP | RTF_NONEXTHOP,
- .fc_nlinfo.nl_net = dev_net(dev),
- };
-
- /* prefix length - 96 bits "::d.d.d.d" */
- ip6_route_add(&cfg);
-}
-#endif
-
static struct inet6_dev *addrconf_add_dev(struct net_device *dev)
{
struct inet6_dev *idev;
@@ -2556,6 +2539,7 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
struct net_device *dev;
struct net *net = dev_net(idev->dev);
int scope, plen;
+ u32 pflags = 0;
ASSERT_RTNL();
@@ -2569,10 +2553,12 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
} else {
scope = IPV6_ADDR_COMPATv4;
plen = 96;
+ pflags |= RTF_NONEXTHOP;
}
if (addr.s6_addr32[3]) {
add_addr(idev, &addr, plen, scope);
+ addrconf_prefix_route(&addr, plen, idev->dev, 0, pflags);
return;
}
@@ -2596,6 +2582,8 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
}
add_addr(idev, &addr, plen, flag);
+ addrconf_prefix_route(&addr, plen, idev->dev, 0,
+ pflags);
}
}
}
@@ -2731,8 +2719,6 @@ static void addrconf_sit_config(struct net_device *dev)
if (dev->flags&IFF_POINTOPOINT)
addrconf_add_mroute(dev);
- else
- sit_route_add(dev);
}
#endif
--
1.8.4.1
^ permalink raw reply related
* [PATCH net 3/3] sit/gre6: don't try to add the same route two times
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
addrconf_add_linklocal() already adds the link local route, so there is no
reason to add it before calling this function.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 237bceb74c4e..cfc47b364e51 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2709,7 +2709,6 @@ static void addrconf_sit_config(struct net_device *dev)
struct in6_addr addr;
ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 64, dev, 0, 0);
if (!ipv6_generate_eui64(addr.s6_addr + 8, dev))
addrconf_add_linklocal(idev, &addr);
return;
@@ -2736,8 +2735,6 @@ static void addrconf_gre_config(struct net_device *dev)
}
ipv6_addr_set(&addr, htonl(0xFE800000), 0, 0, 0);
- addrconf_prefix_route(&addr, 64, dev, 0, 0);
-
if (!ipv6_generate_eui64(addr.s6_addr + 8, dev))
addrconf_add_linklocal(idev, &addr);
}
--
1.8.4.1
^ permalink raw reply related
* [PATCH net 1/3] sit: fix prefix length of ll and v4mapped addresses
From: Nicolas Dichtel @ 2013-11-14 12:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel
When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is
correctly set, ie 64 if the address is a link local one or 96 if the address is
a v4 mapped one.
But when the local endpoint is specified, the prefix length is set to 128 for
both kind of address. This patch fix this wrong prefix length.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
net/ipv6/addrconf.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cd3fb301da38..4e558e5e0e42 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2555,7 +2555,7 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
struct in6_addr addr;
struct net_device *dev;
struct net *net = dev_net(idev->dev);
- int scope;
+ int scope, plen;
ASSERT_RTNL();
@@ -2565,12 +2565,14 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
if (idev->dev->flags&IFF_POINTOPOINT) {
addr.s6_addr32[0] = htonl(0xfe800000);
scope = IFA_LINK;
+ plen = 64;
} else {
scope = IPV6_ADDR_COMPATv4;
+ plen = 96;
}
if (addr.s6_addr32[3]) {
- add_addr(idev, &addr, 128, scope);
+ add_addr(idev, &addr, plen, scope);
return;
}
@@ -2582,7 +2584,6 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
int flag = scope;
for (ifa = in_dev->ifa_list; ifa; ifa = ifa->ifa_next) {
- int plen;
addr.s6_addr32[3] = ifa->ifa_local;
@@ -2593,10 +2594,6 @@ static void sit_add_v4_addrs(struct inet6_dev *idev)
continue;
flag |= IFA_HOST;
}
- if (idev->dev->flags&IFF_POINTOPOINT)
- plen = 64;
- else
- plen = 96;
add_addr(idev, &addr, plen, flag);
}
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Daniel Mack @ 2013-11-14 12:56 UTC (permalink / raw)
To: Mugunthan V N, netdev; +Cc: davem
In-Reply-To: <5284C602.8000103@ti.com>
On 11/14/2013 01:45 PM, Mugunthan V N wrote:
> On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
>> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
>> on dual MAC enabled machines.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>> index edd3e79..702b063 100644
>> --- a/drivers/net/ethernet/ti/cpsw.c
>> +++ b/drivers/net/ethernet/ti/cpsw.c
>> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>>
>> if (netif_running(ndev))
>> cpsw_ndo_stop(ndev);
>> +
>> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
>> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>> + if (priv->data.dual_emac)
>> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>
> Is this tested on a system with both ports in switch mode?
Nope. I got an Ooops when I tried to suspend a machine that has only one
slave configured in DTS.
> I don't think this will not work with both ports in switch mode.
Why? Isn't priv->data.dual_emac in that case? The same condition is
checked for in cpsw_remove().
Thanks,
Daniel
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] udp: add sk opt to allow sending pkt with src 0.0.0.0
From: Nicolas Dichtel @ 2013-11-14 13:05 UTC (permalink / raw)
To: David Miller
Cc: hannes, netdev, David.Laight, jiri, vyasevich, kuznet, jmorris,
yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131111.001803.110603937316567461.davem@davemloft.net>
Le 11/11/2013 06:18, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Date: Sat, 9 Nov 2013 01:54:34 +0100
>
>> This feature allows to a send packets with address source set to 0.0.0.0 even if
>> an ip address is available on another interface.
>>
>> It's useful for DHCP client, to allow them to use UDP sockets and be compliant
>> with the RFC2131, Section 4.1:
>>
>> 4.1 Constructing and sending DHCP messages
>> ...
>> DHCP messages broadcast by a client prior to that client obtaining
>> its IP address must have the source address field in the IP header
>> set to 0.
>>
>> Based on a previous work from
>> Guillaume Gaudonville <guillaume.gaudonville@6wind.com>.
>>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> This requirement of the RFC is inconsistent with a host based
> addressing model, that which Linux employs, it assumes an interface
> based one.
There are some exceptions, for example when user tunes arp_ignore sysctl ;-)
>
> The wording here is also very ambiguous.
>
> This RFC fails to even remotely consider what the right behavior
> should be in a host based addressing environment at all, and anyone
> reading this RFC should just accept that.
I agree that this is ambiguous. And it's a 'must', not a 'MUST', which
is not the same for an RFC ;-)
>
> Furthermore, the fact that you're implementing _addressing_ policy in
> the UDP code makes this change even more unreasonable.
>
I made this choice because using 0.0.0.0, for TCP for example, seems a
non-sense.
But fair enough, let's drop this patch.
Thank you,
Nicolas
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti/cpsw: do not crash on single-MAC machines during resume
From: Mugunthan V N @ 2013-11-14 13:09 UTC (permalink / raw)
To: Daniel Mack, netdev; +Cc: davem
In-Reply-To: <5284C87A.60404@gmail.com>
On Thursday 14 November 2013 06:26 PM, Daniel Mack wrote:
> On 11/14/2013 01:45 PM, Mugunthan V N wrote:
>> On Wednesday 13 November 2013 06:23 PM, Daniel Mack wrote:
>>> To prevent Oopses, cpsw_suspend() should only soft-reset sliver 1
>>> on dual MAC enabled machines.
>>>
>>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>>> ---
>>> drivers/net/ethernet/ti/cpsw.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
>>> index edd3e79..702b063 100644
>>> --- a/drivers/net/ethernet/ti/cpsw.c
>>> +++ b/drivers/net/ethernet/ti/cpsw.c
>>> @@ -2173,8 +2173,11 @@ static int cpsw_suspend(struct device *dev)
>>>
>>> if (netif_running(ndev))
>>> cpsw_ndo_stop(ndev);
>>> +
>>> soft_reset("sliver 0", &priv->slaves[0].sliver->soft_reset);
>>> - soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>>> + if (priv->data.dual_emac)
>>> + soft_reset("sliver 1", &priv->slaves[1].sliver->soft_reset);
>> Is this tested on a system with both ports in switch mode?
> Nope. I got an Ooops when I tried to suspend a machine that has only one
> slave configured in DTS.
But the changes above will fail with system with two ports and in switch
mode.
>
>> I don't think this will not work with both ports in switch mode.
> Why? Isn't priv->data.dual_emac in that case? The same condition is
> checked for in cpsw_remove().
In cpsw_remove that check is used to unregister the second network
interface registered for same device for port 2. Now I got the issue,
this has to be done via for_each_slave().
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH net 0/6] net_tstamp: Validate hwtstamp_config completely before applying it
From: Richard Cochran @ 2013-11-14 13:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1384389542.29151.5.camel@bwh-desktop.uk.level5networks.com>
On Thu, Nov 14, 2013 at 12:39:02AM +0000, Ben Hutchings wrote:
> This series fixes very similar bugs in 6 implementations of
> SIOCSHWTSTAMP.
>
> Ben.
>
> Ben Hutchings (6):
> tg3: Validate hwtstamp_config completely before applying it
> e1000e: Validate hwtstamp_config completely before applying it
> pch_gbe: Validate hwtstamp_config completely before applying it
> stmmac: Validate hwtstamp_config completely before applying it
> ti_cpsw: Validate hwtstamp_config completely before applying it
> ixp4xx_eth: Validate hwtstamp_config completely before applying it
For the series,
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [RFC 8/7] genetlink: make all genl_ops users const
From: Johannes Berg @ 2013-11-14 13:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1384420486-8713-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Now that genl_ops are no longer modified in place when
registering, they can be made const. This patch was done
mostly with spatch:
@@
identifier ops;
@@
+const
struct genl_ops ops[] = {
...
};
(except the struct thing in net/openvswitch/datapath.c)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/team/team.c | 2 +-
drivers/net/wireless/mac80211_hwsim.c | 2 +-
kernel/taskstats.c | 2 +-
net/core/drop_monitor.c | 2 +-
net/hsr/hsr_netlink.c | 2 +-
net/ieee802154/netlink.c | 2 +-
net/ipv4/tcp_metrics.c | 2 +-
net/irda/irnetlink.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
net/netlabel/netlabel_cipso_v4.c | 2 +-
net/netlabel/netlabel_mgmt.c | 2 +-
net/netlabel/netlabel_unlabeled.c | 2 +-
net/nfc/netlink.c | 2 +-
net/openvswitch/datapath.c | 10 +++++-----
net/wimax/stack.c | 2 +-
net/wireless/nl80211.c | 2 +-
17 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 50e43e6..6390254 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -2644,7 +2644,7 @@ static int team_nl_cmd_port_list_get(struct sk_buff *skb,
return err;
}
-static struct genl_ops team_nl_ops[] = {
+static const struct genl_ops team_nl_ops[] = {
{
.cmd = TEAM_CMD_NOOP,
.doit = team_nl_cmd_noop,
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index de0df86..cfc3fda 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -2097,7 +2097,7 @@ out:
}
/* Generic Netlink operations array */
-static struct genl_ops hwsim_ops[] = {
+static const struct genl_ops hwsim_ops[] = {
{
.cmd = HWSIM_CMD_REGISTER,
.policy = hwsim_genl_policy,
diff --git a/kernel/taskstats.c b/kernel/taskstats.c
index 609e77f..76595cd 100644
--- a/kernel/taskstats.c
+++ b/kernel/taskstats.c
@@ -673,7 +673,7 @@ err:
nlmsg_free(rep_skb);
}
-static struct genl_ops taskstats_ops[] = {
+static const struct genl_ops taskstats_ops[] = {
{
.cmd = TASKSTATS_CMD_GET,
.doit = taskstats_user_cmd,
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 5e78d44..f9fe2f2 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -333,7 +333,7 @@ out:
return NOTIFY_DONE;
}
-static struct genl_ops dropmon_ops[] = {
+static const struct genl_ops dropmon_ops[] = {
{
.cmd = NET_DM_CMD_CONFIG,
.doit = net_dm_cmd_config,
diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c
index 8f52a9f..79d72ca 100644
--- a/net/hsr/hsr_netlink.c
+++ b/net/hsr/hsr_netlink.c
@@ -389,7 +389,7 @@ fail:
}
-static struct genl_ops hsr_ops[] = {
+static const struct genl_ops hsr_ops[] = {
{
.cmd = HSR_C_GET_NODE_STATUS,
.flags = 0,
diff --git a/net/ieee802154/netlink.c b/net/ieee802154/netlink.c
index eb9faef..3ffcdbb 100644
--- a/net/ieee802154/netlink.c
+++ b/net/ieee802154/netlink.c
@@ -109,7 +109,7 @@ out:
return -ENOBUFS;
}
-static struct genl_ops ieee8021154_ops[] = {
+static const struct genl_ops ieee8021154_ops[] = {
/* see nl-phy.c */
IEEE802154_DUMP(IEEE802154_LIST_PHY, ieee802154_list_phy,
ieee802154_dump_phy),
diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c
index 2ab09cb..9b780c1 100644
--- a/net/ipv4/tcp_metrics.c
+++ b/net/ipv4/tcp_metrics.c
@@ -988,7 +988,7 @@ static int tcp_metrics_nl_cmd_del(struct sk_buff *skb, struct genl_info *info)
return 0;
}
-static struct genl_ops tcp_metrics_nl_ops[] = {
+static const struct genl_ops tcp_metrics_nl_ops[] = {
{
.cmd = TCP_METRICS_CMD_GET,
.doit = tcp_metrics_nl_cmd_get,
diff --git a/net/irda/irnetlink.c b/net/irda/irnetlink.c
index c3297126..bf5d7d4 100644
--- a/net/irda/irnetlink.c
+++ b/net/irda/irnetlink.c
@@ -131,7 +131,7 @@ static const struct nla_policy irda_nl_policy[IRDA_NL_ATTR_MAX + 1] = {
[IRDA_NL_ATTR_MODE] = { .type = NLA_U32 },
};
-static struct genl_ops irda_nl_ops[] = {
+static const struct genl_ops irda_nl_ops[] = {
{
.cmd = IRDA_NL_CMD_SET_MODE,
.doit = irda_nl_set_mode,
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index be446d5..57db66e 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -793,7 +793,7 @@ static struct nla_policy l2tp_nl_policy[L2TP_ATTR_MAX + 1] = {
},
};
-static struct genl_ops l2tp_nl_ops[] = {
+static const struct genl_ops l2tp_nl_ops[] = {
{
.cmd = L2TP_CMD_NOOP,
.doit = l2tp_nl_cmd_noop,
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 62786a4..fc8a04e 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -3567,7 +3567,7 @@ out:
}
-static struct genl_ops ip_vs_genl_ops[] __read_mostly = {
+static const struct genl_ops ip_vs_genl_ops[] __read_mostly = {
{
.cmd = IPVS_CMD_NEW_SERVICE,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c
index a110064..7066917 100644
--- a/net/netlabel/netlabel_cipso_v4.c
+++ b/net/netlabel/netlabel_cipso_v4.c
@@ -737,7 +737,7 @@ static int netlbl_cipsov4_remove(struct sk_buff *skb, struct genl_info *info)
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_cipsov4_ops[] = {
+static const struct genl_ops netlbl_cipsov4_ops[] = {
{
.cmd = NLBL_CIPSOV4_C_ADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index dd1c37d..7de6f66 100644
--- a/net/netlabel/netlabel_mgmt.c
+++ b/net/netlabel/netlabel_mgmt.c
@@ -705,7 +705,7 @@ version_failure:
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_mgmt_genl_ops[] = {
+static const struct genl_ops netlbl_mgmt_genl_ops[] = {
{
.cmd = NLBL_MGMT_C_ADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/netlabel/netlabel_unlabeled.c b/net/netlabel/netlabel_unlabeled.c
index 8f08974..76ee925 100644
--- a/net/netlabel/netlabel_unlabeled.c
+++ b/net/netlabel/netlabel_unlabeled.c
@@ -1323,7 +1323,7 @@ unlabel_staticlistdef_return:
* NetLabel Generic NETLINK Command Definitions
*/
-static struct genl_ops netlbl_unlabel_genl_ops[] = {
+static const struct genl_ops netlbl_unlabel_genl_ops[] = {
{
.cmd = NLBL_UNLABEL_C_STATICADD,
.flags = GENL_ADMIN_PERM,
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 84b7e3e..f558561 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -1364,7 +1364,7 @@ static int nfc_genl_se_io(struct sk_buff *skb, struct genl_info *info)
return dev->ops->se_io(dev, se_idx, apdu, apdu_len, se_io_cb, ctx);
}
-static struct genl_ops nfc_genl_ops[] = {
+static const struct genl_ops nfc_genl_ops[] = {
{
.cmd = NFC_CMD_GET_DEVICE,
.doit = nfc_genl_get_device,
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 1408adc..91e1c92 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -557,7 +557,7 @@ static const struct nla_policy packet_policy[OVS_PACKET_ATTR_MAX + 1] = {
[OVS_PACKET_ATTR_ACTIONS] = { .type = NLA_NESTED },
};
-static struct genl_ops dp_packet_genl_ops[] = {
+static const struct genl_ops dp_packet_genl_ops[] = {
{ .cmd = OVS_PACKET_CMD_EXECUTE,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = packet_policy,
@@ -1034,7 +1034,7 @@ static int ovs_flow_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-static struct genl_ops dp_flow_genl_ops[] = {
+static const struct genl_ops dp_flow_genl_ops[] = {
{ .cmd = OVS_FLOW_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = flow_policy,
@@ -1392,7 +1392,7 @@ static int ovs_dp_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
return skb->len;
}
-static struct genl_ops dp_datapath_genl_ops[] = {
+static const struct genl_ops dp_datapath_genl_ops[] = {
{ .cmd = OVS_DP_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = datapath_policy,
@@ -1753,7 +1753,7 @@ out:
return skb->len;
}
-static struct genl_ops dp_vport_genl_ops[] = {
+static const struct genl_ops dp_vport_genl_ops[] = {
{ .cmd = OVS_VPORT_CMD_NEW,
.flags = GENL_ADMIN_PERM, /* Requires CAP_NET_ADMIN privilege. */
.policy = vport_policy,
@@ -1779,7 +1779,7 @@ static struct genl_ops dp_vport_genl_ops[] = {
struct genl_family_and_ops {
struct genl_family *family;
- struct genl_ops *ops;
+ const struct genl_ops *ops;
int n_ops;
struct genl_multicast_group *group;
};
diff --git a/net/wimax/stack.c b/net/wimax/stack.c
index 4b7f15a..47170c9 100644
--- a/net/wimax/stack.c
+++ b/net/wimax/stack.c
@@ -415,7 +415,7 @@ static const struct nla_policy wimax_gnl_policy[WIMAX_GNL_ATTR_MAX + 1] = {
},
};
-static struct genl_ops wimax_gnl_ops[] = {
+static const struct genl_ops wimax_gnl_ops[] = {
{
.cmd = WIMAX_GNL_OP_MSG_FROM_USER,
.flags = GENL_ADMIN_PERM,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a7f4e79..7a92c45 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8937,7 +8937,7 @@ static void nl80211_post_doit(struct genl_ops *ops, struct sk_buff *skb,
rtnl_unlock();
}
-static struct genl_ops nl80211_ops[] = {
+static const struct genl_ops nl80211_ops[] = {
{
.cmd = NL80211_CMD_GET_WIPHY,
.doit = nl80211_get_wiphy,
--
1.8.4.rc3
^ permalink raw reply related
* RE: [PATCH] rds: Error on offset mismatch if not loopback
From: Venkat Venkatsubra @ 2013-11-14 13:43 UTC (permalink / raw)
To: Honggang LI, Josh Hunt; +Cc: David Miller, jjolly, LKML, netdev
In-Reply-To: <52841F95.7040204@redhat.com>
-----Original Message-----
From: Honggang LI [mailto:honli@redhat.com]
Sent: Wednesday, November 13, 2013 6:56 PM
To: Josh Hunt; Venkat Venkatsubra
Cc: David Miller; jjolly@suse.com; LKML; netdev@vger.kernel.org
Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
On 11/14/2013 01:40 AM, Josh Hunt wrote:
> On Wed, Nov 13, 2013 at 9:16 AM, Venkat Venkatsubra
> <venkat.x.venkatsubra@oracle.com> wrote:
>>
>> -----Original Message-----
>> From: Josh Hunt [mailto:joshhunt00@gmail.com]
>> Sent: Tuesday, November 12, 2013 10:25 PM
>> To: David Miller
>> Cc: jjolly@suse.com; LKML; Venkat Venkatsubra; netdev@vger.kernel.org
>> Subject: Re: [PATCH] rds: Error on offset mismatch if not loopback
>>
>> On Tue, Nov 12, 2013 at 10:22 PM, Josh Hunt <joshhunt00@gmail.com> wrote:
>>> On Sat, Sep 22, 2012 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: John Jolly <jjolly@suse.com>
>>>> Date: Fri, 21 Sep 2012 15:32:40 -0600
>>>>
>>>>> Attempting an rds connection from the IP address of an IPoIB
>>>>> interface to itself causes a kernel panic due to a BUG_ON() being triggered.
>>>>> Making the test less strict allows rds-ping to work without
>>>>> crashing the machine.
>>>>>
>>>>> A local unprivileged user could use this flaw to crash the system.
>>>>>
>>>>> Signed-off-by: John Jolly <jjolly@suse.com>
>>>> Besides the questions being asked of you by Venkat Venkatsubra,
>>>> this patch has another issue.
>>>>
>>>> It has been completely corrupted by your email client, it has
>>>> turned all TAB characters into spaces, making the patch useless.
>>>>
>>>> Please learn how to send a patch unmolested in the body of your
>>>> email. Test it by emailing the patch to yourself, and verifying
>>>> that you can in fact apply the patch you receive in that email.
>>>> Then, and only then, should you consider making a new submission of
>>>> this patch.
>>>>
>>>> Use Documentation/email-clients.txt for guidance.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>> I think this issue was lost in the shuffle. It appears that redhat,
>>> ubuntu, and oracle are maintaining local patches to resolve this:
>>>
>>> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d636
>>> 85
>>> 2be130fa15fa8be10d4704e8
>>> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>>> http://ubuntu.5.x6.nabble.com/CVE-2012-2372-RDS-local-ping-DOS-td498
>>> 53
>>> 88.html
>>>
>>> Given that Oracle has applied it I'll make the assumption that
>>> Venkat's question was answered at some point.
>>>
>>> David - I can resubmit the patch with the proper signed-off-by and
>>> formatting if you are willing to apply it unless John wants to try
>>> again. I think it's time this got upstream.
>>>
>>> --
>>> Josh
>> Ugh.. hopefully resending with all the html crap removed...
>>
>> --
>> Josh
>>
>> Hi Josh,
>>
>> No, I still didn't get an answer for how "off" could be non-zero in case of rds-ping to hit BUG_ON(off % RDS_FRAG_SIZE).
>> Because, rds-ping uses zero byte messages to ping.
>> If you have a test case that reproduces the kernel panic I can try it out and see how that can happen.
>> The Oracle's internal code I checked doesn't have that patch applied.
>>
>> Venkat
> No I don't have a test case. I came across this CVE while doing an
> audit and noticed it was patched in Ubuntu's kernel and other distros,
> but was not in the upstream kernel yet. Quick googling of lkml showed
> that there were at least two attempts to get this patch upstream, but
> both had issues due to not following the proper submission process:
>
> https://lkml.org/lkml/2012/10/22/433
> https://lkml.org/lkml/2012/9/21/505
>
> From my searching it appears the initial bug was found by someone at redhat:
> https://bugzilla.redhat.com/show_bug.cgi?id=822754
>
> I've added Li Honggang the reporter of this issue from Redhat to the
> mail. Hopefully he can share his testcase.
The test case is very simple:
Steps to Reproduce:
1. yum install -y rds-tools
2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You may need to wait for a few seconds before the kernel panic.)
>
> and possibly requires certain hardware as Jay writes in the first link above:
> "...some Infiniband HCAs(QLogic, possibly others) the machine will panic..."
This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko), QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
As I know the upstream code of RDS is broken. There are *many* RDS bugs.
Best regards.
Honggang
>
> I was referring to this oracle commit:
> https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=c7b6a0a1d8d63685
> 2be130fa15fa8be10d4704e8
>
> I have no experience with this code. There were a few comments around
> the reset and xmit fns about making sure the caller did certain things
> if not they were racy, but I have no idea if that's coming into play
> here.
>
Hi Honggang,
I ran rds-ping over local interface for 30 minutes. I stopped it after that.
It didn't hit any panic.
# ip addr show dev ib0
6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast qlen 1024
link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:21:28:00:01:cf:63:db brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
inet 10.196.4.125/30 brd 10.196.4.127 scope global ib0
inet6 fe80::221:2800:1cf:63db/64 scope link
valid_lft forever preferred_lft forever
#
# rds-ping 10.196.4.125
1: 170 usec
2: 171 usec
....
....
....
1860: 173 usec
1861: 171 usec
1862: 177 usec
1863: 168 usec
1864: 171 usec
1865: 175 usec
^C#
I tested with Oracle UEK2 which is based on 2.6.39 kernel. Mellanox IB adaptor.
19:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0)
There is something about your setup that must be causing it for you.
Can I work with you offline if you are available ?
The panic you are hitting is not making sense to me.
Venkat
^ permalink raw reply
* Re: [PATCH] rds: fix local ping DoS
From: Josh Hunt @ 2013-11-14 13:45 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, venkat.x.venkatsubra@oracle.com,
linux-kernel@vger.kernel.org, jjolly@suse.com,
fenlason@redhat.com, honli@redhat.com
In-Reply-To: <20131114.020355.1973894145326845195.davem@davemloft.net>
On 11/14/2013 01:03 AM, David Miller wrote:
> From: Josh Hunt <johunt@akamai.com>
> Date: Wed, 13 Nov 2013 17:15:43 -0800
>
>> The rds_ib_xmit function in net/rds/ib_send.c in the Reliable Datagram Sockets
>> (RDS) protocol implementation allows local users to cause a denial of service
>> (BUG_ON and kernel panic) by establishing an RDS connection with the source
>> IP address equal to the IPoIB interface's own IP address, as demonstrated by
>> rds-ping.
>>
>> A local unprivileged user could use this flaw to crash the system.
>>
>> CVE-2012-2372
>>
>> Reported-by: Honggang Li <honli@redhat.com>
>> Signed-off-by: Josh Hunt <johunt@akamai.com>
>
> I'm sorry I can't apply this. This commit message needs to be much
> less terse and explain things more.
>
> First of all, why is the "off % RDS_FRAG_SIZE" important?
>
> And, even more importantly, why is is OK to avoid this assertion just
> because we're going over loopback?
>
> Furthermore, why doesn't net/rds/iw_send.c:rds_iw_xmit() have the same
> exact problem? It makes the same exact assertion check.
>
> I know this RDS code is a steaming pile of poo, but that doesn't mean
> we just randomly adjust assertions to make crashes go away without
> sufficient understanding of exactly what's going on.
>
> Thanks.
>
Sure understandable questions. Unfortunately I don't have the hardware
to properly debug and analyze. I was just trying to get this through on
the assumption that the previous attempts just failed due to incorrect
submission procedures and lack of a reproducible testcase. If nothing
else this whole thing brought out the testcase :)
Testcase from Honggang's earlier mail:
<snip>
The test case is very simple:
Steps to Reproduce:
1. yum install -y rds-tools
2. [root@rdma3 ~]# ifconfig ib0 | grep 'inet addr'
inet addr:172.31.0.3 Bcast:172.31.0.255 Mask:255.255.255.0
3. [root@rdma3 ~]# /usr/bin/rds-ping 172.31.0.3 <<<< kernel panic (You
may need to wait for a few seconds before the kernel panic.)
This bug can be reproduced with Mellanox HCAs (mlx4_ib.ko and mthca.ko),
QLogic HCA (ib_qib.ko). I did not test the QLogic HCA running "ib_ipath.ko".
</snip>
Perhaps Venkat or someone else with the hardware mentioned can provide a
better explanation and better solution to the crash.
Josh
^ permalink raw reply
* Re: [PATCH] net: sctp: bug-fixing: retran_path not set properly after transports recovering (v3)
From: Neil Horman @ 2013-11-14 13:55 UTC (permalink / raw)
To: Chang Xiangzhong; +Cc: vyasevich, davem, linux-sctp, netdev
In-Reply-To: <1384387106-8105-1-git-send-email-changxiangzhong@gmail.com>
On Thu, Nov 14, 2013 at 12:58:26AM +0100, Chang Xiangzhong wrote:
> When a transport recovers due to the new coming sack, SCTP should
> iterate all of its transport_list to locate the __two__ most recently used
> transport and set to active_path and retran_path respectively. The exising
> code does not find the two properly - In case of the following list:
>
> [most-recent] -> [2nd-most-recent] -> ...
>
> Both active_path and retran_path would be set to the 1st element.
>
> The bug happens when:
> 1) multi-homing
> 2) failure/partial_failure transport recovers
> Both active_path and retran_path would be set to the same most-recent one, in
> other words, retran_path would not take its role - an end user might not even
> notice this issue.
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH net v2 0/2] macvlan: disable LRO on lowerdev instead of a macvlan
From: Michal Kubecek @ 2013-11-14 14:00 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Patrick McHardy, John Fastabend
A customer of ours encountered a problem with LRO on an ixgbe network
card. Analysis showed that it was a known conflict of forwarding and LRO
but the forwarding was enabled in an LXC container where only a macvlan
was, not the ethernet device itself.
I believe the solution is exactly the same as what we do for "normal"
(802.1q) VLAN devices: if dev_disable_lro() is called for such device,
LRO is disabled on the underlying "real" device instead.
v2: adapt to changes merged from net-next
Michal Kubecek (2):
macvlan: introduce macvlan_dev_real_dev() helper function
macvlan: disable LRO on lower device instead of macvlan
include/linux/if_macvlan.h | 16 ++++++++++++++++
net/core/dev.c | 5 +++++
2 files changed, 21 insertions(+)
--
1.8.1.4
^ 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