* Re: bonding and SR-IOV -- do we need arp_validation for loadbalancing too?
From: Chris Friesen @ 2012-07-24 21:38 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Jiri Pirko, netdev, andy
In-Reply-To: <24104.1343162975@death.nxdomain>
On 07/24/2012 02:49 PM, Jay Vosburgh wrote:
> Chris Friesen<chris.friesen@genband.com> wrote:
>
>> In loadbalance mode wouldn't it just work similar to active-backup? If
>> it's a reply then verify that it came from the arp target, if it's a
>> request then check to see if it came from one of the other slaves.
>
> The problem isn't verifying the requests or replies, it's that
> the ARP packets are not distributed across all slaves (because the
> switch ports are in a channel group / aggregator), so some slaves do not
> receive any ARPs.
Yeah, okay. And if we turn on arp validation then we ignore all the
other packets and so they looks dead. Got it.
In our environment (ATCA shelf) the switches have been customized to
handle some of this stuff so arpmon does work reliably with xor.
In the general case it sounds like the "PF bonding ignores packets from
VFs" is a better bet then.
>> On 07/24/2012 02:18 PM, Chris Friesen wrote:
>>> A more general solution might be to have the device driver also track
>>> the time of the last incoming packet that came from the external network
>>> (rather than a VF) and having the bond driver ignore those packets for
>>> the purpose of link health. Doing this efficiently would likely require
>>> some kind of hardware support though--as an example the 82599 seems to
>>> support this with the "LB" bit in the rx descriptor.
>>
>> That should of course be reversed. We want the bond driver to only use
>> the packets from the external network for the purpose of link health.
>>
>> Does anyone other than bonding actually care about dev->last_rx? If not
>> then we could just change the drivers to only set it for external packets.
> That should of course be reversed. We want the bond driver to only use
>> the packets from the external network for the purpose of link health.
>>
> I believe bonding is the main user of last_rx (a search shows a
> couple of drivers using it internally). For bonding use, in current
> mainline last_rx is set by bonding itself, not in the network device
> driver.
Right, I was looking at older code. In that case presumably the driver
could set an skb flag (external vs VF loopback) that the bonding code
could check?
Chris
^ permalink raw reply
* Re: [PATCH 2/3] net: Make skb->skb_iif always track skb->dev
From: Nicolas de Pesloüan @ 2012-07-24 21:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ja, Jiri Pirko
In-Reply-To: <20120723.164542.1890653324956444632.davem@davemloft.net>
Le 24/07/2012 01:45, David Miller a écrit :
>
> Make it follow device decapsulation, from things such as VLAN and
> bonding.
>
> The stuff that actually cares about pre-demuxed device pointers, is
> handled by the "orig_dev" variable in __netif_receive_skb(). And
> the only consumer of that is the po->origdev feature of AF_PACKET
> sockets.
>
> Signed-off-by: David S. Miller<davem@davemloft.net>
Jiri tried to remove this orig_dev usage in af_packet in march 2011, without success, by using the
value of skb_iif instead :-)
In case my opinion might be relevant:
Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Nicolas.
^ permalink raw reply
* Crash in e1000e, 3.3.8+ (tainted)
From: Ben Greear @ 2012-07-24 21:46 UTC (permalink / raw)
To: e1000-devel list, netdev
We have a somewhat reproducible crash using a 6-port NIC
with 3.3.8+ kernel. This kernel is tainted with a proprietary
module, but the module is not in use.
The rx-all and related patches that were later accepted
upstream have been applied to this kernel.
It seems that buffer_info is NULL in the code below?
(gdb) list e1000_alloc_rx_buffers+0x5b
Junk at end of line specification.
(gdb) list *(e1000_alloc_rx_buffers+0x5b)
0x15822 is in e1000_alloc_rx_buffers (/home/greearb/git/linux-3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:611).
606
607 i = rx_ring->next_to_use;
608 buffer_info = &rx_ring->buffer_info[i];
609
610 while (cleaned_count--) {
611 skb = buffer_info->skb;
612 if (skb) {
613 skb_trim(skb, 0);
614 goto map_skb;
615 }
(gdb)
ADDRCONF(NETDEV_UP): rddVR1-p: link is not ready
ADDRCONF(NETDEV_UP): eth16: link is not ready
8021q: adding VLAN 0 to HW filter on device eth16
e1000e: eth17 NIC Link is Down
e1000e 0000:04:00.1: eth17: Reset adapter
------------[ cut here ]------------
WARNING: at /home/greearb/git/linux-3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:3937 e1000_close+0x38/0x134 [e1000e]()
Hardware name: To be filled by O.E.M.
Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd mei(C) microcode
cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core
video [last unloaded: scsi_wait_scan]
Pid: 2360, comm: ip Tainted: P C O 3.3.8+ #51
Call Trace:
[<ffffffff81055bd1>] warn_slowpath_common+0x80/0x98
[<ffffffff81055bfe>] warn_slowpath_null+0x15/0x17
[<ffffffffa0199f49>] e1000_close+0x38/0x134 [e1000e]
[<ffffffff8141239f>] __dev_close_many+0x88/0xb9
[<ffffffff81412401>] __dev_close+0x31/0x42
[<ffffffff8140fd39>] __dev_change_flags+0xb9/0x13c
[<ffffffff81412d48>] dev_change_flags+0x1c/0x52
[<ffffffff8141dfac>] do_setlink+0x2b8/0x7ca
[<ffffffff8141cfd7>] ? rtnl_fill_ifinfo+0x9f1/0xab1
[<ffffffff8141e7f3>] rtnl_newlink+0x266/0x4b7
[<ffffffff8141e630>] ? rtnl_newlink+0xa3/0x4b7
[<ffffffff8141db55>] ? rtnl_dump_ifinfo+0x134/0x15d
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
[<ffffffff811d7328>] ? security_capable+0x13/0x15
[<ffffffff8141d78b>] rtnetlink_rcv_msg+0x21e/0x23b
[<ffffffff8141d56d>] ? rtnetlink_rcv+0x28/0x28
[<ffffffff8142fbb6>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff8141d566>] rtnetlink_rcv+0x21/0x28
[<ffffffff8142f991>] netlink_unicast+0xe9/0x152
[<ffffffff814300ea>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813fed37>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813fed7f>] __sock_sendmsg+0x3d/0x48
[<ffffffff813ff61f>] sock_sendmsg+0xa3/0xbc
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
[<ffffffff814c623b>] ? _raw_spin_unlock+0x28/0x33
[<ffffffff810e73ae>] ? do_wp_page+0x548/0x5af
[<ffffffff813fe77d>] ? copy_from_user+0x9/0xb
[<ffffffff813ff2c7>] ? move_addr_to_kernel+0x2b/0x65
[<ffffffff814099b1>] ? copy_from_user+0x9/0xb
[<ffffffff81409cfe>] ? verify_iovec+0x4f/0xa3
[<ffffffff813ffd81>] __sys_sendmsg+0x20f/0x29c
[<ffffffff810e8241>] ? handle_mm_fault+0x1ac/0x1c4
[<ffffffff814c9195>] ? do_page_fault+0x2de/0x350
[<ffffffff810ebdd3>] ? do_brk+0x2b8/0x31a
[<ffffffff813fff6b>] sys_sendmsg+0x3d/0x5b
[<ffffffff814cb0f9>] system_call_fastpath+0x16/0x1b
---[ end trace 059af067cdc81b69 ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
PGD 0
Oops: 0000 [#1] PREEMPT SMP
CPU 2
Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd mei(C) microcode
cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core
video [last unloaded: scsi_wait_scan]
Pid: 140, comm: kworker/2:1 Tainted: P WC O 3.3.8+ #51 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffffa019a7fe>] [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
RSP: 0018:ffff88021e185cc0 EFLAGS: 00010206
RAX: ffff8802203ae090 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 00000000000000d0 RSI: 00000000000000ff RDI: ffff88021e8a4800
RBP: ffff88021e185d20 R08: ffff88021e184000 R09: ffffffff81a8f658
R10: ffff88021e185be0 R11: ffff88021e185fd8 R12: ffff88021e8a4800
R13: 0000000000000000 R14: ffff88021dda2360 R15: 00000000000000ff
FS: 0000000000000000(0000) GS:ffff88022bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 0000000001a05000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task ffff88021fc0dd00)
Stack:
0000000000000000 ffffffffa0194ea7 000000d01e185d00 ffff88021e8a4000
000005f21dda2360 ffff8802203ae090 ffff88021e185d00 ffff88021e8a4800
ffff88021dda2360 0000000000001000 0000000004008002 ffff88021dda2960
Call Trace:
[<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
[<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
[<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
[<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
[<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
[<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
[<ffffffff81069df7>] ? schedule_work+0x13/0x15
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
[<ffffffff8106837e>] process_one_work+0x1a6/0x278
[<ffffffff8106a3d1>] worker_thread+0x136/0x255
[<ffffffff8106a29b>] ? manage_workers+0x190/0x190
[<ffffffff8106da7d>] kthread+0x84/0x8c
[<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
[<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
[<ffffffff814cc4a0>] ? gs_change+0x13/0x13
Code: 00 00 89 45 c4 41 0f b7 5e 18 48 8b 87 a8 04 00 00 41 89 dd 48 05 90 00 00 00 4d 6b ed 28 4d 03 6e 20 48 89 45 c8 e9 ea 00 00 00 <49> 8b 45 08 48 85 c0 74
14 48 89 c7 31 f6 48 89 45 a8 e8 76 b1
RIP [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
RSP <ffff88021e185cc0>
CR2: 0000000000000008
---[ end trace 059af067cdc81b6a ]---
BUG: unable to handle kernel paging request at fffffffffffffff8
IP: [<ffffffff8106d618>] kthread_data+0xb/0x11
PGD 1a07067 PUD 1a08067 PMD 0
Oops: 0000 [#2] PREEMPT SMP
CPU 2
Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd mei(C) microcode
cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core
video [last unloaded: scsi_wait_scan]
Pid: 140, comm: kworker/2:1 Tainted: P D WC O 3.3.8+ #51 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffff8106d618>] [<ffffffff8106d618>] kthread_data+0xb/0x11
RSP: 0018:ffff88021e1858b8 EFLAGS: 00010092
RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000002
RDX: ffffffff81bee730 RSI: 0000000000000002 RDI: ffff88021fc0dd00
RBP: ffff88021e1858b8 R08: 0000000000000400 R09: ffff88021fc0e0b8
R10: ffff88021e185978 R11: 0000000000000000 R12: ffff88021fc0e0b8
R13: ffff88021e1859b8 R14: 0000000000000002 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff88022bd00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 0000000001a05000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task ffff88021fc0dd00)
Stack:
ffff88021e1858d8 ffffffff81069e8f ffff88021e1858d8 ffff88022bd12340
ffff88021e185978 ffffffff814c5041 ffff88021e185918 0000000000000246
ffff88021e184010 ffff88021fc0dd00 ffff88021e185fd8 0000000000012340
Call Trace:
[<ffffffff81069e8f>] wq_worker_sleeping+0x10/0x8a
[<ffffffff814c5041>] __schedule+0x17f/0x562
[<ffffffff814c54c9>] schedule+0x55/0x57
[<ffffffff81059b09>] do_exit+0x73e/0x742
[<ffffffff814c73c7>] oops_end+0xba/0xc2
[<ffffffff8102df05>] no_context+0x25a/0x269
[<ffffffff8107cee0>] ? load_balance+0x98/0x6b0
[<ffffffff8102e0db>] __bad_area_nosemaphore+0x1c7/0x1e7
[<ffffffff8102e109>] bad_area_nosemaphore+0xe/0x10
[<ffffffff814c902d>] do_page_fault+0x176/0x350
[<ffffffff81009785>] ? __switch_to+0x1cd/0x37c
[<ffffffff814c62bc>] ? _raw_spin_unlock_irq+0x2f/0x3a
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
[<ffffffff814c6925>] page_fault+0x25/0x30
[<ffffffffa019a7fe>] ? e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
[<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
[<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
[<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
[<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
[<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
[<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
[<ffffffff81069df7>] ? schedule_work+0x13/0x15
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffff81077243>] ? get_parent_ip+0x11/0x42
[<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
[<ffffffff8106837e>] process_one_work+0x1a6/0x278
[<ffffffff8106a3d1>] worker_thread+0x136/0x255
[<ffffffff8106a29b>] ? manage_workers+0x190/0x190
[<ffffffff8106da7d>] kthread+0x84/0x8c
[<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
[<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
[<ffffffff814cc4a0>] ? gs_change+0x13/0x13
Code: ea ff ff ff eb 9d 90 55 65 48 8b 04 25 00 c7 00 00 48 8b 80 60 03 00 00 48 89 e5 8b 40 f0 c9 c3 48 8b 87 60 03 00 00 55 48 89 e5 <48> 8b 40 f8 c9 c3 48 3b
3d 7b 10 b8 00 55 48 89 e5 75 09 0f bf
RIP [<ffffffff8106d618>] kthread_data+0xb/0x11
RSP <ffff88021e1858b8>
CR2: fffffffffffffff8
---[ end trace 059af067cdc81b6b ]---
Fixing recursive fault but reboot is needed!
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: Crash in e1000e, 3.3.8+ (tainted)
From: Allan, Bruce W @ 2012-07-24 22:02 UTC (permalink / raw)
To: Ben Greear, e1000-devel list, netdev
In-Reply-To: <500F17A0.30906@candelatech.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Ben Greear
> Sent: Tuesday, July 24, 2012 2:46 PM
> To: e1000-devel list; netdev
> Subject: Crash in e1000e, 3.3.8+ (tainted)
>
> We have a somewhat reproducible crash using a 6-port NIC
> with 3.3.8+ kernel. This kernel is tainted with a proprietary
> module, but the module is not in use.
>
> The rx-all and related patches that were later accepted
> upstream have been applied to this kernel.
>
> It seems that buffer_info is NULL in the code below?
>
>
> (gdb) list e1000_alloc_rx_buffers+0x5b
> Junk at end of line specification.
> (gdb) list *(e1000_alloc_rx_buffers+0x5b)
> 0x15822 is in e1000_alloc_rx_buffers (/home/greearb/git/linux-
> 3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:611).
> 606
> 607 i = rx_ring->next_to_use;
> 608 buffer_info = &rx_ring->buffer_info[i];
> 609
> 610 while (cleaned_count--) {
> 611 skb = buffer_info->skb;
> 612 if (skb) {
> 613 skb_trim(skb, 0);
> 614 goto map_skb;
> 615 }
> (gdb)
>
>
>
> ADDRCONF(NETDEV_UP): rddVR1-p: link is not ready
> ADDRCONF(NETDEV_UP): eth16: link is not ready
> 8021q: adding VLAN 0 to HW filter on device eth16
> e1000e: eth17 NIC Link is Down
> e1000e 0000:04:00.1: eth17: Reset adapter
> ------------[ cut here ]------------
> WARNING: at /home/greearb/git/linux-
> 3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:3937
> e1000_close+0x38/0x134 [e1000e]()
> Hardware name: To be filled by O.E.M.
> Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
> sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput
> snd_hda_codec_realtek
> snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
> ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e
> snd mei(C) microcode
> cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc
> iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper
> drm i2c_algo_bit i2c_core
> video [last unloaded: scsi_wait_scan]
> Pid: 2360, comm: ip Tainted: P C O 3.3.8+ #51
> Call Trace:
> [<ffffffff81055bd1>] warn_slowpath_common+0x80/0x98
> [<ffffffff81055bfe>] warn_slowpath_null+0x15/0x17
> [<ffffffffa0199f49>] e1000_close+0x38/0x134 [e1000e]
> [<ffffffff8141239f>] __dev_close_many+0x88/0xb9
> [<ffffffff81412401>] __dev_close+0x31/0x42
> [<ffffffff8140fd39>] __dev_change_flags+0xb9/0x13c
> [<ffffffff81412d48>] dev_change_flags+0x1c/0x52
> [<ffffffff8141dfac>] do_setlink+0x2b8/0x7ca
> [<ffffffff8141cfd7>] ? rtnl_fill_ifinfo+0x9f1/0xab1
> [<ffffffff8141e7f3>] rtnl_newlink+0x266/0x4b7
> [<ffffffff8141e630>] ? rtnl_newlink+0xa3/0x4b7
> [<ffffffff8141db55>] ? rtnl_dump_ifinfo+0x134/0x15d
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff811d7328>] ? security_capable+0x13/0x15
> [<ffffffff8141d78b>] rtnetlink_rcv_msg+0x21e/0x23b
> [<ffffffff8141d56d>] ? rtnetlink_rcv+0x28/0x28
> [<ffffffff8142fbb6>] netlink_rcv_skb+0x3e/0x8f
> [<ffffffff8141d566>] rtnetlink_rcv+0x21/0x28
> [<ffffffff8142f991>] netlink_unicast+0xe9/0x152
> [<ffffffff814300ea>] netlink_sendmsg+0x1f8/0x216
> [<ffffffff813fed37>] __sock_sendmsg_nosec+0x5f/0x6a
> [<ffffffff813fed7f>] __sock_sendmsg+0x3d/0x48
> [<ffffffff813ff61f>] sock_sendmsg+0xa3/0xbc
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff814c623b>] ? _raw_spin_unlock+0x28/0x33
> [<ffffffff810e73ae>] ? do_wp_page+0x548/0x5af
> [<ffffffff813fe77d>] ? copy_from_user+0x9/0xb
> [<ffffffff813ff2c7>] ? move_addr_to_kernel+0x2b/0x65
> [<ffffffff814099b1>] ? copy_from_user+0x9/0xb
> [<ffffffff81409cfe>] ? verify_iovec+0x4f/0xa3
> [<ffffffff813ffd81>] __sys_sendmsg+0x20f/0x29c
> [<ffffffff810e8241>] ? handle_mm_fault+0x1ac/0x1c4
> [<ffffffff814c9195>] ? do_page_fault+0x2de/0x350
> [<ffffffff810ebdd3>] ? do_brk+0x2b8/0x31a
> [<ffffffff813fff6b>] sys_sendmsg+0x3d/0x5b
> [<ffffffff814cb0f9>] system_call_fastpath+0x16/0x1b
> ---[ end trace 059af067cdc81b69 ]---
> BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000008
> IP: [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> PGD 0
> Oops: 0000 [#1] PREEMPT SMP
> CPU 2
> Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
> sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput
> snd_hda_codec_realtek
> snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
> ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e
> snd mei(C) microcode
> cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc
> iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper
> drm i2c_algo_bit i2c_core
> video [last unloaded: scsi_wait_scan]
>
> Pid: 140, comm: kworker/2:1 Tainted: P WC O 3.3.8+ #51 To be filled by
> O.E.M. To be filled by O.E.M./To be filled by O.E.M.
> RIP: 0010:[<ffffffffa019a7fe>] [<ffffffffa019a7fe>]
> e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> RSP: 0018:ffff88021e185cc0 EFLAGS: 00010206
> RAX: ffff8802203ae090 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 00000000000000d0 RSI: 00000000000000ff RDI: ffff88021e8a4800
> RBP: ffff88021e185d20 R08: ffff88021e184000 R09: ffffffff81a8f658
> R10: ffff88021e185be0 R11: ffff88021e185fd8 R12: ffff88021e8a4800
> R13: 0000000000000000 R14: ffff88021dda2360 R15: 00000000000000ff
> FS: 0000000000000000(0000) GS:ffff88022bd00000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000008 CR3: 0000000001a05000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task
> ffff88021fc0dd00)
> Stack:
> 0000000000000000 ffffffffa0194ea7 000000d01e185d00 ffff88021e8a4000
> 000005f21dda2360 ffff8802203ae090 ffff88021e185d00 ffff88021e8a4800
> ffff88021dda2360 0000000000001000 0000000004008002 ffff88021dda2960
> Call Trace:
> [<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
> [<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
> [<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
> [<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
> [<ffffffff81069df7>] ? schedule_work+0x13/0x15
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffff8106837e>] process_one_work+0x1a6/0x278
> [<ffffffff8106a3d1>] worker_thread+0x136/0x255
> [<ffffffff8106a29b>] ? manage_workers+0x190/0x190
> [<ffffffff8106da7d>] kthread+0x84/0x8c
> [<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
> [<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
> [<ffffffff814cc4a0>] ? gs_change+0x13/0x13
> Code: 00 00 89 45 c4 41 0f b7 5e 18 48 8b 87 a8 04 00 00 41 89 dd 48 05 90 00 00
> 00 4d 6b ed 28 4d 03 6e 20 48 89 45 c8 e9 ea 00 00 00 <49> 8b 45 08 48 85 c0 74
> 14 48 89 c7 31 f6 48 89 45 a8 e8 76 b1
> RIP [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> RSP <ffff88021e185cc0>
> CR2: 0000000000000008
> ---[ end trace 059af067cdc81b6a ]---
> BUG: unable to handle kernel paging request at fffffffffffffff8
> IP: [<ffffffff8106d618>] kthread_data+0xb/0x11
> PGD 1a07067 PUD 1a08067 PMD 0
> Oops: 0000 [#2] PREEMPT SMP
> CPU 2
> Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
> sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput
> snd_hda_codec_realtek
> snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
> ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e
> snd mei(C) microcode
> cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc
> iTCO_wdt iTCO_vendor_support parport_pc parport i915 drm_kms_helper
> drm i2c_algo_bit i2c_core
> video [last unloaded: scsi_wait_scan]
>
> Pid: 140, comm: kworker/2:1 Tainted: P D WC O 3.3.8+ #51 To be filled by
> O.E.M. To be filled by O.E.M./To be filled by O.E.M.
> RIP: 0010:[<ffffffff8106d618>] [<ffffffff8106d618>] kthread_data+0xb/0x11
> RSP: 0018:ffff88021e1858b8 EFLAGS: 00010092
> RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000002
> RDX: ffffffff81bee730 RSI: 0000000000000002 RDI: ffff88021fc0dd00
> RBP: ffff88021e1858b8 R08: 0000000000000400 R09: ffff88021fc0e0b8
> R10: ffff88021e185978 R11: 0000000000000000 R12: ffff88021fc0e0b8
> R13: ffff88021e1859b8 R14: 0000000000000002 R15: 0000000000000001
> FS: 0000000000000000(0000) GS:ffff88022bd00000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 0000000001a05000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task
> ffff88021fc0dd00)
> Stack:
> ffff88021e1858d8 ffffffff81069e8f ffff88021e1858d8 ffff88022bd12340
> ffff88021e185978 ffffffff814c5041 ffff88021e185918 0000000000000246
> ffff88021e184010 ffff88021fc0dd00 ffff88021e185fd8 0000000000012340
> Call Trace:
> [<ffffffff81069e8f>] wq_worker_sleeping+0x10/0x8a
> [<ffffffff814c5041>] __schedule+0x17f/0x562
> [<ffffffff814c54c9>] schedule+0x55/0x57
> [<ffffffff81059b09>] do_exit+0x73e/0x742
> [<ffffffff814c73c7>] oops_end+0xba/0xc2
> [<ffffffff8102df05>] no_context+0x25a/0x269
> [<ffffffff8107cee0>] ? load_balance+0x98/0x6b0
> [<ffffffff8102e0db>] __bad_area_nosemaphore+0x1c7/0x1e7
> [<ffffffff8102e109>] bad_area_nosemaphore+0xe/0x10
> [<ffffffff814c902d>] do_page_fault+0x176/0x350
> [<ffffffff81009785>] ? __switch_to+0x1cd/0x37c
> [<ffffffff814c62bc>] ? _raw_spin_unlock_irq+0x2f/0x3a
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff814c6925>] page_fault+0x25/0x30
> [<ffffffffa019a7fe>] ? e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> [<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
> [<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
> [<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
> [<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
> [<ffffffff81069df7>] ? schedule_work+0x13/0x15
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffff8106837e>] process_one_work+0x1a6/0x278
> [<ffffffff8106a3d1>] worker_thread+0x136/0x255
> [<ffffffff8106a29b>] ? manage_workers+0x190/0x190
> [<ffffffff8106da7d>] kthread+0x84/0x8c
> [<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
> [<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
> [<ffffffff814cc4a0>] ? gs_change+0x13/0x13
> Code: ea ff ff ff eb 9d 90 55 65 48 8b 04 25 00 c7 00 00 48 8b 80 60 03 00 00 48
> 89 e5 8b 40 f0 c9 c3 48 8b 87 60 03 00 00 55 48 89 e5 <48> 8b 40 f8 c9 c3 48 3b
> 3d 7b 10 b8 00 55 48 89 e5 75 09 0f bf
> RIP [<ffffffff8106d618>] kthread_data+0xb/0x11
> RSP <ffff88021e1858b8>
> CR2: fffffffffffffff8
> ---[ end trace 059af067cdc81b6b ]---
> Fixing recursive fault but reboot is needed!
I believe this has already been fixed in 3.4 via commit bb9e44d0. Please try patching
your kernel with that and let us know so we can have it back-ported to stable.
Thanks,
Bruce.
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Change rt->rt_iif encoding.
From: Nicolas de Pesloüan @ 2012-07-24 22:13 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20120723.161446.36265037346365173.davem@davemloft.net>
Le 24/07/2012 01:14, David Miller a écrit :
[...]
> I wonder if we should just get rid of all of that orig_dev logic and
> simply update skb->skb_iif every time we hit the code starting at
> label "another_round"
It clearly depends on the exact meaning of orig_dev.
When we studied the usage of orig_dev before removing it from bonding, it was clear that two
different meanings existed:
- From the bonding point of view, is was "the device one level below current device" (the slave,
from the master's point of view).
- From the af_packet point of view, is was "the real original device that received the packet".
As bonding don't use orig_dev anymore, the remaining meaning should logically be "the real original
device that received the packet". But as __netif_receive_skb() is recursively called in many cases,
setting orig_dev to something new every time, this meaning is probably mostly inconsistent. As such,
it sounds appropriate to remove orig_dev and use skb_iif instead.
Nicolas.
^ permalink raw reply
* RE: [PATCH 10/17] Tools: hv: Gather ipv[4,6] gateway information
From: KY Srinivasan @ 2012-07-24 22:13 UTC (permalink / raw)
To: Dan Williams, Stephen Hemminger
Cc: Olaf Hering, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
virtualization@lists.osdl.org, apw@canonical.com,
netdev@vger.kernel.org, ben@decadent.org.uk
In-Reply-To: <1343155010.29196.1.camel@dcbw.foobar.com>
> -----Original Message-----
> From: Dan Williams [mailto:dcbw@redhat.com]
> Sent: Tuesday, July 24, 2012 2:37 PM
> To: Stephen Hemminger
> Cc: Olaf Hering; KY Srinivasan; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; apw@canonical.com; netdev@vger.kernel.org;
> ben@decadent.org.uk
> Subject: Re: [PATCH 10/17] Tools: hv: Gather ipv[4,6] gateway information
>
> On Tue, 2012-07-24 at 09:56 -0700, Stephen Hemminger wrote:
> > On Tue, 24 Jul 2012 18:53:59 +0200
> > Olaf Hering <olaf@aepfle.de> wrote:
> >
> > > On Tue, Jul 24, Stephen Hemminger wrote:
> > >
> > > > On Tue, 24 Jul 2012 09:01:34 -0700
> > > > "K. Y. Srinivasan" <kys@microsoft.com> wrote:
> > > >
> > > > > + memset(cmd, 0, sizeof(cmd));
> > > > > + strcat(cmd, "/sbin/ip -f inet route | grep -w ");
> > > > > + strcat(cmd, if_name);
> > > > > + strcat(cmd, " | awk '/default/ {print $3 }'");
> > > >
> > > >
> > > > Much simpler method:
> > > >
> > > > ip route show match 0/0
> > >
> > > This also has the benefit that ip is not called with absolute path, now
> > > that distros move binaries around.
> > >
> > > Olaf
> >
> > It is also not hard to do the same thing with a little function
> > using libmnl
>
> Yeah seriously, netlink anyone? You'll even get nicer error reporting
> that way.
While I will be the first admit that using C API is always better (in C code),
in this particular instance I am not so sure. All I am doing is retrieving information
on default gateways. If there is an error, that is ok and this won't be reported
back to the host. Using the ip command significantly simplifies the code here.
Regards,
K. Y
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Change rt->rt_iif encoding.
From: David Miller @ 2012-07-24 22:18 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: ja, netdev
In-Reply-To: <500F1E23.7090803@gmail.com>
From: Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>
Date: Wed, 25 Jul 2012 00:13:55 +0200
> - From the af_packet point of view, is was "the real original device
> - that received the packet".
>
> As bonding don't use orig_dev anymore, the remaining meaning should
> logically be "the real original device that received the packet". But
> as __netif_receive_skb() is recursively called in many cases, setting
> orig_dev to something new every time, this meaning is probably mostly
> inconsistent. As such, it sounds appropriate to remove orig_dev and
> use skb_iif instead.
I don't think we can, otherwise people who set po->origdev will no
longer get what they expect.
For the simpler cases of bonding and VLANs, it does currently behaved
as expected.
That's why I left it alone.
^ permalink raw reply
* Re: [PATCH 2/2] ipv4: Change rt->rt_iif encoding.
From: Nicolas de Pesloüan @ 2012-07-24 22:25 UTC (permalink / raw)
To: David Miller; +Cc: ja, netdev
In-Reply-To: <20120724.151801.1576915988616906722.davem@davemloft.net>
Le 25/07/2012 00:18, David Miller a écrit :
> From: Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>
> Date: Wed, 25 Jul 2012 00:13:55 +0200
>
>> - From the af_packet point of view, is was "the real original device
>> - that received the packet".
>>
>> As bonding don't use orig_dev anymore, the remaining meaning should
>> logically be "the real original device that received the packet". But
>> as __netif_receive_skb() is recursively called in many cases, setting
>> orig_dev to something new every time, this meaning is probably mostly
>> inconsistent. As such, it sounds appropriate to remove orig_dev and
>> use skb_iif instead.
>
> I don't think we can, otherwise people who set po->origdev will no
> longer get what they expect.
>
> For the simpler cases of bonding and VLANs, it does currently behaved
> as expected.
>
> That's why I left it alone.
Do they get what they expect when stacking interfaces?
__netif_receive_skb starts with orig_dev = skb->dev. So when calling __netif_receive_skb
recursively, after changing skb->dev, they get the packet several times, with a different orig_dev
value?
Any way, both looks good to me.
Nicolas.
^ permalink raw reply
* Re: [PATCH] mlx4: Add support for EEH error recovery
From: Or Gerlitz @ 2012-07-24 22:30 UTC (permalink / raw)
To: David Miller
Cc: klebers, netdev, jackm, yevgenyp, ogerlitz, cascardo, brking,
Shlomo Pongratz
In-Reply-To: <20120724.140353.1432900101600410863.davem@davemloft.net>
On Wed, Jul 25, 2012 at 12:03 AM, David Miller <davem@davemloft.net> wrote:
> Or, you promised an ACK today, I still haven't seen it.
It turned out that reacted we did, but not the ACK way.
Again, code review wise, we intended to ack it, but Shlomo has set
testing environment, under which he had some issues with the patch, as
such he preferred not to ACK it but rather bring up the issues on the
list and sort them out 1st. I thought it would be wrong to over-rule
this preference of him, and this way is fair-enough with the author
and your guide-lines, maybe I had to be more aggressive with ACKing
this, as of the merge window closing coming. So tomorrow.
Or.
> There is no reason Kleber should be penalized and have his work
> miss the merge window just because you guys can't be bothered
> to approve this patch in a reasonable amount of time.
>
> Therefore I'm just going to apply it later today, and don't do this
> with someone's submission ever again, it impedes progress and
> frustrates contributors.
^ permalink raw reply
* RE: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
From: Dave, Tushar N @ 2012-07-24 23:13 UTC (permalink / raw)
To: Ben Greear, e1000-devel list, netdev
In-Reply-To: <500F17A0.30906@candelatech.com>
>-----Original Message-----
>From: Ben Greear [mailto:greearb@candelatech.com]
>Sent: Tuesday, July 24, 2012 2:46 PM
>To: e1000-devel list; netdev
>Subject: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
>
>We have a somewhat reproducible crash using a 6-port NIC with 3.3.8+
>kernel. This kernel is tainted with a proprietary module, but the module
>is not in use.
>
>The rx-all and related patches that were later accepted upstream have been
>applied to this kernel.
>
>It seems that buffer_info is NULL in the code below?
>
>
>(gdb) list e1000_alloc_rx_buffers+0x5b
>Junk at end of line specification.
>(gdb) list *(e1000_alloc_rx_buffers+0x5b)
>0x15822 is in e1000_alloc_rx_buffers (/home/greearb/git/linux-
>3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:611).
>606
>607 i = rx_ring->next_to_use;
>608 buffer_info = &rx_ring->buffer_info[i];
>609
>610 while (cleaned_count--) {
>611 skb = buffer_info->skb;
>612 if (skb) {
>613 skb_trim(skb, 0);
>614 goto map_skb;
>615 }
>(gdb)
>
>
Ben,
This looks familiar to me, I believe this is due to race between adapter reset and e1000_close.
Let me check if we have fix upstream or not.
-Tushar
>
>ADDRCONF(NETDEV_UP): rddVR1-p: link is not ready
>ADDRCONF(NETDEV_UP): eth16: link is not ready
>8021q: adding VLAN 0 to HW filter on device eth16
>e1000e: eth17 NIC Link is Down
>e1000e 0000:04:00.1: eth17: Reset adapter ------------[ cut here ]--------
>----
>WARNING: at /home/greearb/git/linux-
>3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:3937
>e1000_close+0x38/0x134 [e1000e]() Hardware name: To be filled by O.E.M.
>Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
>sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
>snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
>ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd
>mei(C) microcode
>cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt
>iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm
>i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
>Pid: 2360, comm: ip Tainted: P C O 3.3.8+ #51
>Call Trace:
> [<ffffffff81055bd1>] warn_slowpath_common+0x80/0x98
> [<ffffffff81055bfe>] warn_slowpath_null+0x15/0x17
> [<ffffffffa0199f49>] e1000_close+0x38/0x134 [e1000e]
> [<ffffffff8141239f>] __dev_close_many+0x88/0xb9
> [<ffffffff81412401>] __dev_close+0x31/0x42
> [<ffffffff8140fd39>] __dev_change_flags+0xb9/0x13c
> [<ffffffff81412d48>] dev_change_flags+0x1c/0x52
> [<ffffffff8141dfac>] do_setlink+0x2b8/0x7ca
> [<ffffffff8141cfd7>] ? rtnl_fill_ifinfo+0x9f1/0xab1
> [<ffffffff8141e7f3>] rtnl_newlink+0x266/0x4b7
> [<ffffffff8141e630>] ? rtnl_newlink+0xa3/0x4b7
> [<ffffffff8141db55>] ? rtnl_dump_ifinfo+0x134/0x15d
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff811d7328>] ? security_capable+0x13/0x15
> [<ffffffff8141d78b>] rtnetlink_rcv_msg+0x21e/0x23b
> [<ffffffff8141d56d>] ? rtnetlink_rcv+0x28/0x28
> [<ffffffff8142fbb6>] netlink_rcv_skb+0x3e/0x8f
> [<ffffffff8141d566>] rtnetlink_rcv+0x21/0x28
> [<ffffffff8142f991>] netlink_unicast+0xe9/0x152
> [<ffffffff814300ea>] netlink_sendmsg+0x1f8/0x216
> [<ffffffff813fed37>] __sock_sendmsg_nosec+0x5f/0x6a
> [<ffffffff813fed7f>] __sock_sendmsg+0x3d/0x48
> [<ffffffff813ff61f>] sock_sendmsg+0xa3/0xbc
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff814c623b>] ? _raw_spin_unlock+0x28/0x33
> [<ffffffff810e73ae>] ? do_wp_page+0x548/0x5af
> [<ffffffff813fe77d>] ? copy_from_user+0x9/0xb
> [<ffffffff813ff2c7>] ? move_addr_to_kernel+0x2b/0x65
> [<ffffffff814099b1>] ? copy_from_user+0x9/0xb
> [<ffffffff81409cfe>] ? verify_iovec+0x4f/0xa3
> [<ffffffff813ffd81>] __sys_sendmsg+0x20f/0x29c
> [<ffffffff810e8241>] ? handle_mm_fault+0x1ac/0x1c4
> [<ffffffff814c9195>] ? do_page_fault+0x2de/0x350
> [<ffffffff810ebdd3>] ? do_brk+0x2b8/0x31a
> [<ffffffff813fff6b>] sys_sendmsg+0x3d/0x5b
> [<ffffffff814cb0f9>] system_call_fastpath+0x16/0x1b ---[ end trace
>059af067cdc81b69 ]---
>BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>IP: [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e] PGD 0
>Oops: 0000 [#1] PREEMPT SMP
>CPU 2
>Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
>sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
>snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
>ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd
>mei(C) microcode
>cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt
>iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm
>i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
>
>Pid: 140, comm: kworker/2:1 Tainted: P WC O 3.3.8+ #51 To be filled
>by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
>RIP: 0010:[<ffffffffa019a7fe>] [<ffffffffa019a7fe>]
>e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
>RSP: 0018:ffff88021e185cc0 EFLAGS: 00010206
>RAX: ffff8802203ae090 RBX: 0000000000000000 RCX: 0000000000000000
>RDX: 00000000000000d0 RSI: 00000000000000ff RDI: ffff88021e8a4800
>RBP: ffff88021e185d20 R08: ffff88021e184000 R09: ffffffff81a8f658
>R10: ffff88021e185be0 R11: ffff88021e185fd8 R12: ffff88021e8a4800
>R13: 0000000000000000 R14: ffff88021dda2360 R15: 00000000000000ff
>FS: 0000000000000000(0000) GS:ffff88022bd00000(0000)
>knlGS:0000000000000000
>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>CR2: 0000000000000008 CR3: 0000000001a05000 CR4: 00000000000006e0
>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process
>kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task ffff88021fc0dd00)
>Stack:
> 0000000000000000 ffffffffa0194ea7 000000d01e185d00 ffff88021e8a4000
> 000005f21dda2360 ffff8802203ae090 ffff88021e185d00 ffff88021e8a4800
> ffff88021dda2360 0000000000001000 0000000004008002 ffff88021dda2960 Call
>Trace:
> [<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
> [<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
> [<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
> [<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
> [<ffffffff81069df7>] ? schedule_work+0x13/0x15
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffff8106837e>] process_one_work+0x1a6/0x278
> [<ffffffff8106a3d1>] worker_thread+0x136/0x255
> [<ffffffff8106a29b>] ? manage_workers+0x190/0x190
> [<ffffffff8106da7d>] kthread+0x84/0x8c
> [<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
> [<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
> [<ffffffff814cc4a0>] ? gs_change+0x13/0x13
>Code: 00 00 89 45 c4 41 0f b7 5e 18 48 8b 87 a8 04 00 00 41 89 dd 48 05 90
>00 00 00 4d 6b ed 28 4d 03 6e 20 48 89 45 c8 e9 ea 00 00 00 <49> 8b 45 08
>48 85 c0 74
>14 48 89 c7 31 f6 48 89 45 a8 e8 76 b1
>RIP [<ffffffffa019a7fe>] e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> RSP <ffff88021e185cc0>
>CR2: 0000000000000008
>---[ end trace 059af067cdc81b6a ]---
>BUG: unable to handle kernel paging request at fffffffffffffff8
>IP: [<ffffffff8106d618>] kthread_data+0xb/0x11 PGD 1a07067 PUD 1a08067 PMD
>0
>Oops: 0000 [#2] PREEMPT SMP
>CPU 2
>Modules linked in: veth 8021q garp stp llc fuse macvlan wanlink(PO) pktgen
>sbs sbshc f71882fg coretemp hwmon sunrpc ipv6 uinput snd_hda_codec_realtek
>snd_hda_intel ath9k snd_hda_codec mac80211 joydev snd_hwdep snd_seq
>ath9k_common ath9k_hw snd_seq_device snd_pcm ath snd_timer e1000e snd
>mei(C) microcode
>cfg80211 ppdev i2c_i801 soundcore serio_raw pcspkr snd_page_alloc iTCO_wdt
>iTCO_vendor_support parport_pc parport i915 drm_kms_helper drm
>i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
>
>Pid: 140, comm: kworker/2:1 Tainted: P D WC O 3.3.8+ #51 To be filled
>by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
>RIP: 0010:[<ffffffff8106d618>] [<ffffffff8106d618>] kthread_data+0xb/0x11
>RSP: 0018:ffff88021e1858b8 EFLAGS: 00010092
>RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000002
>RDX: ffffffff81bee730 RSI: 0000000000000002 RDI: ffff88021fc0dd00
>RBP: ffff88021e1858b8 R08: 0000000000000400 R09: ffff88021fc0e0b8
>R10: ffff88021e185978 R11: 0000000000000000 R12: ffff88021fc0e0b8
>R13: ffff88021e1859b8 R14: 0000000000000002 R15: 0000000000000001
>FS: 0000000000000000(0000) GS:ffff88022bd00000(0000)
>knlGS:0000000000000000
>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>CR2: fffffffffffffff8 CR3: 0000000001a05000 CR4: 00000000000006e0
>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process
>kworker/2:1 (pid: 140, threadinfo ffff88021e184000, task ffff88021fc0dd00)
>Stack:
> ffff88021e1858d8 ffffffff81069e8f ffff88021e1858d8 ffff88022bd12340
> ffff88021e185978 ffffffff814c5041 ffff88021e185918 0000000000000246
> ffff88021e184010 ffff88021fc0dd00 ffff88021e185fd8 0000000000012340 Call
>Trace:
> [<ffffffff81069e8f>] wq_worker_sleeping+0x10/0x8a
> [<ffffffff814c5041>] __schedule+0x17f/0x562
> [<ffffffff814c54c9>] schedule+0x55/0x57
> [<ffffffff81059b09>] do_exit+0x73e/0x742
> [<ffffffff814c73c7>] oops_end+0xba/0xc2
> [<ffffffff8102df05>] no_context+0x25a/0x269
> [<ffffffff8107cee0>] ? load_balance+0x98/0x6b0
> [<ffffffff8102e0db>] __bad_area_nosemaphore+0x1c7/0x1e7
> [<ffffffff8102e109>] bad_area_nosemaphore+0xe/0x10
> [<ffffffff814c902d>] do_page_fault+0x176/0x350
> [<ffffffff81009785>] ? __switch_to+0x1cd/0x37c
> [<ffffffff814c62bc>] ? _raw_spin_unlock_irq+0x2f/0x3a
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff814c9382>] ? sub_preempt_count+0x92/0xa5
> [<ffffffff814c6925>] page_fault+0x25/0x30
> [<ffffffffa019a7fe>] ? e1000_alloc_rx_buffers+0x5b/0x162 [e1000e]
> [<ffffffffa0194ea7>] ? e1000e_set_rx_mode+0xbc/0x260 [e1000e]
> [<ffffffffa0195a6d>] e1000_configure+0x51c/0x525 [e1000e]
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffffa0195a87>] e1000e_up+0x11/0xbc [e1000e]
> [<ffffffffa01992b1>] e1000e_reinit_locked+0x3f/0x4c [e1000e]
> [<ffffffffa0199a29>] e1000_reset_task+0x6dd/0x6ec [e1000e]
> [<ffffffff81069df7>] ? schedule_work+0x13/0x15
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffff81077243>] ? get_parent_ip+0x11/0x42
> [<ffffffffa019934c>] ? e1000_set_features+0x8e/0x8e [e1000e]
> [<ffffffff8106837e>] process_one_work+0x1a6/0x278
> [<ffffffff8106a3d1>] worker_thread+0x136/0x255
> [<ffffffff8106a29b>] ? manage_workers+0x190/0x190
> [<ffffffff8106da7d>] kthread+0x84/0x8c
> [<ffffffff814cc4a4>] kernel_thread_helper+0x4/0x10
> [<ffffffff8106d9f9>] ? __init_kthread_worker+0x37/0x37
> [<ffffffff814cc4a0>] ? gs_change+0x13/0x13
>Code: ea ff ff ff eb 9d 90 55 65 48 8b 04 25 00 c7 00 00 48 8b 80 60 03 00
>00 48 89 e5 8b 40 f0 c9 c3 48 8b 87 60 03 00 00 55 48 89 e5 <48> 8b 40 f8
>c9 c3 48 3b 3d 7b 10 b8 00 55 48 89 e5 75 09 0f bf RIP
>[<ffffffff8106d618>] kthread_data+0xb/0x11
> RSP <ffff88021e1858b8>
>CR2: fffffffffffffff8
>---[ end trace 059af067cdc81b6b ]---
>Fixing recursive fault but reboot is needed!
>
>
>
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>
>
>--------------------------------------------------------------------------
>----
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>E1000-devel mailing list
>E1000-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/e1000-devel
>To learn more about Intel® Ethernet, visit
>http://communities.intel.com/community/wired
^ permalink raw reply
* Re: Crash in e1000e, 3.3.8+ (tainted)
From: Ben Greear @ 2012-07-24 23:20 UTC (permalink / raw)
To: Dave, Tushar N; +Cc: e1000-devel list, netdev, bruce.w.allan
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA89130D50549@ORSMSX102.amr.corp.intel.com>
On 07/24/2012 04:13 PM, Dave, Tushar N wrote:
>> -----Original Message-----
>> From: Ben Greear [mailto:greearb@candelatech.com]
>> Sent: Tuesday, July 24, 2012 2:46 PM
>> To: e1000-devel list; netdev
>> Subject: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
>>
>> We have a somewhat reproducible crash using a 6-port NIC with 3.3.8+
>> kernel. This kernel is tainted with a proprietary module, but the module
>> is not in use.
>>
>> The rx-all and related patches that were later accepted upstream have been
>> applied to this kernel.
>>
>> It seems that buffer_info is NULL in the code below?
>>
>>
>> (gdb) list e1000_alloc_rx_buffers+0x5b
>> Junk at end of line specification.
>> (gdb) list *(e1000_alloc_rx_buffers+0x5b)
>> 0x15822 is in e1000_alloc_rx_buffers (/home/greearb/git/linux-
>> 3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:611).
>> 606
>> 607 i = rx_ring->next_to_use;
>> 608 buffer_info = &rx_ring->buffer_info[i];
>> 609
>> 610 while (cleaned_count--) {
>> 611 skb = buffer_info->skb;
>> 612 if (skb) {
>> 613 skb_trim(skb, 0);
>> 614 goto map_skb;
>> 615 }
>> (gdb)
>>
>>
> Ben,
>
> This looks familiar to me, I believe this is due to race between adapter reset and e1000_close.
> Let me check if we have fix upstream or not.
I'm testing Bruce Allen's suggestion now: bb9e44d0 (from 3.4).
It applies with fuzz to my 3.3.8+ tree.
So far, so good...but need to do some more reboots to be sure.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
From: Dave, Tushar N @ 2012-07-24 23:23 UTC (permalink / raw)
To: Ben Greear; +Cc: e1000-devel list, netdev, Allan, Bruce W
In-Reply-To: <500F2DD8.8030300@candelatech.com>
>-----Original Message-----
>From: Ben Greear [mailto:greearb@candelatech.com]
>Sent: Tuesday, July 24, 2012 4:21 PM
>To: Dave, Tushar N
>Cc: e1000-devel list; netdev; Allan, Bruce W
>Subject: Re: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
>
>On 07/24/2012 04:13 PM, Dave, Tushar N wrote:
>>> -----Original Message-----
>>> From: Ben Greear [mailto:greearb@candelatech.com]
>>> Sent: Tuesday, July 24, 2012 2:46 PM
>>> To: e1000-devel list; netdev
>>> Subject: [E1000-devel] Crash in e1000e, 3.3.8+ (tainted)
>>>
>>> We have a somewhat reproducible crash using a 6-port NIC with 3.3.8+
>>> kernel. This kernel is tainted with a proprietary module, but the
>>> module is not in use.
>>>
>>> The rx-all and related patches that were later accepted upstream have
>>> been applied to this kernel.
>>>
>>> It seems that buffer_info is NULL in the code below?
>>>
>>>
>>> (gdb) list e1000_alloc_rx_buffers+0x5b Junk at end of line
>>> specification.
>>> (gdb) list *(e1000_alloc_rx_buffers+0x5b)
>>> 0x15822 is in e1000_alloc_rx_buffers (/home/greearb/git/linux-
>>> 3.3.dev.y/drivers/net/ethernet/intel/e1000e/netdev.c:611).
>>> 606
>>> 607 i = rx_ring->next_to_use;
>>> 608 buffer_info = &rx_ring->buffer_info[i];
>>> 609
>>> 610 while (cleaned_count--) {
>>> 611 skb = buffer_info->skb;
>>> 612 if (skb) {
>>> 613 skb_trim(skb, 0);
>>> 614 goto map_skb;
>>> 615 }
>>> (gdb)
>>>
>>>
>> Ben,
>>
>> This looks familiar to me, I believe this is due to race between adapter
>reset and e1000_close.
>> Let me check if we have fix upstream or not.
>
>I'm testing Bruce Allen's suggestion now: bb9e44d0 (from 3.4).
Yep, commit bb9e44d0 the one.
>
>It applies with fuzz to my 3.3.8+ tree.
>
>So far, so good...but need to do some more reboots to be sure.
>
>Thanks,
>Ben
>
>--
>Ben Greear <greearb@candelatech.com>
>Candela Technologies Inc http://www.candelatech.com
>
>
^ permalink raw reply
* Re: [PATCH 11/17] Tools: hv: Gather DNS information
From: Ben Hutchings @ 2012-07-24 23:38 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, olaf, apw, netdev
In-Reply-To: <1343145701-3691-11-git-send-email-kys@microsoft.com>
On Tue, Jul 24, 2012 at 09:01:35AM -0700, K. Y. Srinivasan wrote:
> Now gather DNS information. This information cannot be gathered in
> a distro independent fashion. Invoke an external script (that can be
> distro dependent) to gather the DNS information.
[...]
> + memset(cmd, 0, sizeof(cmd));
> + strcat(cmd, "/sbin/hv_get_dns_info ");
> + strcat(cmd, if_name);
[...]
This is a weird way to build a string; why are you not using
snprintf()? Not to mention that interface names can contain several
characters that are special to the shell - in fact the only disallowed
characters are / and whitespace.
Also, the external script will not be useful to anything other than
hv_kvp_daemon, so it probably belongs somewhere under /usr/share.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
^ permalink raw reply
* [PATCH] be2net: Missing byteswap in be_get_fw_log_level causes oops on PowerPC
From: Anton Blanchard @ 2012-07-25 1:05 UTC (permalink / raw)
To: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev
We are seeing an oops in be_get_fw_log_level on ppc64 where we walk
off the end of memory.
commit 941a77d582c8 (be2net: Fix to allow get/set of debug levels in
the firmware.) requires byteswapping of num_modes and num_modules.
Cc: stable@vger.kernel.org # 3.5+
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 63e51d4..59ee51a 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -910,8 +910,9 @@ static void be_set_fw_log_level(struct be_adapter *adapter, u32 level)
if (!status) {
cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
sizeof(struct be_cmd_resp_hdr));
- for (i = 0; i < cfgs->num_modules; i++) {
- for (j = 0; j < cfgs->module[i].num_modes; j++) {
+ for (i = 0; i < le32_to_cpu(cfgs->num_modules); i++) {
+ u32 num_modes = le32_to_cpu(cfgs->module[i].num_modes);
+ for (j = 0; j < num_modes; j++) {
if (cfgs->module[i].trace_lvl[j].mode ==
MODE_UART)
cfgs->module[i].trace_lvl[j].dbg_lvl =
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 501dfa9..bd5cf7e 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3479,7 +3479,7 @@ u32 be_get_fw_log_level(struct be_adapter *adapter)
if (!status) {
cfgs = (struct be_fat_conf_params *)(extfat_cmd.va +
sizeof(struct be_cmd_resp_hdr));
- for (j = 0; j < cfgs->module[0].num_modes; j++) {
+ for (j = 0; j < le32_to_cpu(cfgs->module[0].num_modes); j++) {
if (cfgs->module[0].trace_lvl[j].mode == MODE_UART)
level = cfgs->module[0].trace_lvl[j].dbg_lvl;
}
^ permalink raw reply related
* Re: [PATCH 03/17] Drivers: hv: kvp: Cleanup error handling in KVP
From: Ben Hutchings @ 2012-07-25 1:10 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, olaf, apw, netdev
In-Reply-To: <1343145701-3691-3-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> In preparation to implementing IP injection, cleanup the way we propagate
> and handle errors both in the driver as well as in the user level daemon.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> drivers/hv/hv_kvp.c | 112 +++++++++++++++++++++++++++++++++++++---------
> include/linux/hyperv.h | 17 +++++---
> tools/hv/hv_kvp_daemon.c | 70 +++++++++++++++-------------
> 3 files changed, 138 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/hv/hv_kvp.c b/drivers/hv/hv_kvp.c
> index 0012eed..9b7fc4a 100644
> --- a/drivers/hv/hv_kvp.c
> +++ b/drivers/hv/hv_kvp.c
[...]
> @@ -109,27 +154,52 @@ kvp_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
> {
> struct hv_kvp_msg *message;
> struct hv_kvp_msg_enumerate *data;
> + int error = 0;
>
> message = (struct hv_kvp_msg *)msg->data;
> - switch (message->kvp_hdr.operation) {
> +
> + /*
> + * If we are negotiating the version information
> + * with the daemon; handle that first.
> + */
> +
> + if (in_hand_shake) {
> + if (kvp_handle_handshake(message))
> + in_hand_shake = false;
> + return;
> + }
> +
> + /*
> + * Based on the version of the daemon, we propagate errors from the
> + * daemon differently.
> + */
> +
> + data = &message->body.kvp_enum_data;
> +
> + switch (dm_reg_value) {
> case KVP_OP_REGISTER:
> - pr_info("KVP: user-mode registering done.\n");
> - kvp_register();
> - kvp_transaction.active = false;
> - hv_kvp_onchannelcallback(kvp_transaction.kvp_context);
> + /*
> + * Null string is used to pass back error condition.
> + */
> + if (!strlen(data->data.key))
Do we know that the key is null-terminated here? Shouldn't we just
check whether data->data.key[0] == 0?
> + error = HV_S_CONT;
> break;
>
> - default:
> - data = &message->body.kvp_enum_data;
> + case KVP_OP_REGISTER1:
> /*
> - * Complete the transaction by forwarding the key value
> - * to the host. But first, cancel the timeout.
> + * We use the message header information from
> + * the user level daemon to transmit errors.
> */
> - if (cancel_delayed_work_sync(&kvp_work))
> - kvp_respond_to_host(data->data.key,
> - data->data.value,
> - !strlen(data->data.key));
> + error = *((int *)(&message->kvp_hdr.operation));
[...]
What's with the casting (repeated in many other places)? Wouldn't it be
better to redefine struct hv_kvp_msg to start with something like:
union {
struct hv_kvp_hdr request;
int error;
} kvp_hdr;
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 08/17] Tools: hv: Gather subnet information
From: Ben Hutchings @ 2012-07-25 1:14 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: gregkh, linux-kernel, devel, virtualization, olaf, apw, netdev
In-Reply-To: <1343145701-3691-8-git-send-email-kys@microsoft.com>
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> Now gather sub-net information for the specified interface.
>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
> ---
> tools/hv/hv_kvp_daemon.c | 31 +++++++++++++++++++++++++++++--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
> index 79eb130..2c24ebf 100644
> --- a/tools/hv/hv_kvp_daemon.c
> +++ b/tools/hv/hv_kvp_daemon.c
> @@ -534,6 +534,7 @@ kvp_get_ip_address(int family, char *if_name, int op,
> struct ifaddrs *ifap;
> struct ifaddrs *curp;
> int offset = 0;
> + int sn_offset = 0;
> const char *str;
> int error = 0;
> char *buffer;
> @@ -594,12 +595,38 @@ kvp_get_ip_address(int family, char *if_name, int op,
> * Gather info other than the IP address.
> * IP address info will be gathered later.
> */
> - if (curp->ifa_addr->sa_family == AF_INET)
> + if (curp->ifa_addr->sa_family == AF_INET) {
> ip_buffer->addr_family |= ADDR_FAMILY_IPV4;
> - else
> + /*
> + * Get subnet info.
> + */
> + error = kvp_process_ip_address(
> + curp->ifa_netmask,
> + AF_INET,
> + (char *)
> + ip_buffer->sub_net,
> + length,
> + &sn_offset);
[...]
This is barely readable; why don't you indent the arguments by just one
extra tab?
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 13/17] Tools: hv: Implement the KVP verb - KVP_OP_SET_IP_INFO
From: Ben Hutchings @ 2012-07-25 1:24 UTC (permalink / raw)
To: K. Y. Srinivasan
Cc: olaf, gregkh, linux-kernel, virtualization, netdev, apw, devel
In-Reply-To: <1343145701-3691-13-git-send-email-kys@microsoft.com>
[-- Attachment #1.1: Type: text/plain, Size: 3358 bytes --]
On Tue, 2012-07-24 at 09:01 -0700, K. Y. Srinivasan wrote:
> Implement the KVP verb - KVP_OP_SET_IP_INFO. This operation configures the
> specified interface based on the given configuration. Since configuring
> an interface is very distro specific, we invoke an external script to
> configure the interface.
[...]
> +static int kvp_write_file(FILE *f, char *s1, char *s2, char *s3)
> +{
> + char str[256];
> + int error;
> +
> + memset(str, 0, sizeof(str));
> + strcat(str, s1);
> + if (s2 != NULL)
> + strcat(str, s2);
> + strcat(str, "=");
> + strcat(str, s3);
> + strcat(str, "\n");
> +
> + error = fputs(str, f);
This style of string pasting is crazy; have you never heard of
fprintf()?
[...]
> + /*
> + * Set the configuration for the specified interface with
> + * the information provided. Since there is no standard
> + * way to configure an interface, we will have an external
> + * script that does the job of configuring the interface and
> + * flushing the configuration.
> + *
> + * The parameters passed to this external script are:
> + * 1. A configuration file that has the specified configuration.
> + *
> + * We will embed the name of the interface in the configuration
> + * file: ifcfg-ethx (where ethx is the interface name).
> + *
> + * Here is the format of the ip configuration file:
> + *
> + * HWADDR=macaddr
Is the interface supposed to be matched by name or by MAC address?
> + * BOOTPROTO=dhcp (dhcp enabled for the interface)
The BOOTPROTO line may or may not appear.
> + * NM_CONTROLLED=no (this interface will not be controlled by NM)
> + * PEERDNS=yes
I wonder what the point is of including constant lines in the file.
What is the external script supposed to do if it these apparent
constants change in future?
> + * IPADDR_x=ipaddr
> + * NETMASK_x=netmask
> + * GATEWAY_x=gateway
> + * DNSx=dns
A strangely familiar format...
> + * IPV6 addresses will be tagged as IPV6ADDR, IPV6 gateway will be
> + * tagged as IPV6_DEFAULTGW and IPV6 NETMASK will be tagged as
> + * IPV6NETMASK.
> + */
> +
> + memset(if_file, 0, sizeof(if_file));
> + strcat(if_file, "/var/opt/hyperv/ifcfg-");
Like I said before about the key-value files, this should be under
/var/lib if the daemon is included in a distribution. You should
perhaps use a macro for the "/var/opt" part so it can be overridden
depending on whether it's built as a distribution or add-on package.
> + strcat(if_file, if_name);
> +
> + file = fopen(if_file, "w");
> +
> + if (file == NULL) {
> + syslog(LOG_ERR, "Failed to open config file");
> + return HV_E_FAIL;
> + }
> +
> + /*
> + * First write out the MAC address.
> + */
> +
> + mac_addr = kvp_if_name_to_mac(if_name);
> + if (mac_addr == NULL) {
> + error = HV_E_FAIL;
> + goto setval_error;
> + }
> +
> + error = kvp_write_file(file, "HWADDR", NULL, mac_addr);
> + if (error)
> + goto setval_error;
> +
> + error = kvp_write_file(file, "ONBOOT", NULL, "yes");
> + if (error)
> + goto setval_error;
> +
> + error = kvp_write_file(file, "IPV6INIT", NULL, "yes");
> + if (error)
> + goto setval_error;
[...]
This line isn't mentioned in the above comment.
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
^ permalink raw reply
* RE: [RFC] r8169 : why SG / TX checksum are default disabled
From: hayeswang @ 2012-07-25 2:10 UTC (permalink / raw)
To: 'David Miller'; +Cc: romieu, eric.dumazet, netdev, 'nic_swsd'
In-Reply-To: <20120723.235931.725099984853258732.davem@davemloft.net>
David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, July 24, 2012 3:00 PM
> To: Hayeswang
> Cc: romieu@fr.zoreil.com; eric.dumazet@gmail.com;
> netdev@vger.kernel.org
> Subject: Re: [RFC] r8169 : why SG / TX checksum are default disabled
>
[...]
>
> I still have not seen a good explanation why the chip modifies fields
> in the packet, such as the length, when we ask it only to compute the
> checksum?
I don't know the history and the detail about the bug. I think only our designer
could answer your question. I guess it is a careless mistake.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Kevin Groeneveld @ 2012-07-25 2:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <1343110954.2626.11040.camel@edumazet-glaptop>
On Tue, Jul 24, 2012 at 2:22 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2012-07-23 at 21:53 -0400, Kevin Groeneveld wrote:
>> On Mon, Jul 23, 2012 at 11:59 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> >> Would proper synchronization in this case just be wrapping the updates
>> >> in a spin_lock/spin_unlock?
>> >
>> > Would be fine (if the proper BH safe variant is used), or you could also
>> > use atomic64_t.
>>
>> Which would you recommend, spin locks or atomic64_t?
>>
>> atomic64_t seems like it would be simpler.
>
> Simpler but a bit more expensive when two counters are changed at the
> same time.
>
> (two atomic ops instead of a single one for the spinlock)
After looking at the existing ppp code more I wonder if I would even
need to add my own spinlocks. It seems the only spots I am updating
the 64 bit stats are already protected by either ppp->wlock or
ppp->rlock spinlocks. If I used two separate u64_stats_sync
structures, one for tx stats and one for rx stats, wouldn't the
existing spinlocks be enough?
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:28 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: xufeng zhang, sri, davem, linux-sctp, netdev, linux-kernel
In-Reply-To: <75bdd73e-1c47-4fd6-bc29-5b86ee6da69a@email.android.com>
On 7/24/12, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>> And I should clarify the above judgment code.
>>>> AFAIK, there should be two cases for the bundling when invalid
>>stream
>>>> identifier error happens:
>>>> 1). COOKIE_ACK ERROR SACK
>>>> 2). ERROR SACK
>>>> So I need to deal with the two cases differently.
>>>>
>>>>
>>> Sorry but I just don't buy that the above are the only 2 cases. What
>>if there are addip chunks as well? What if there are some other
>>extensions also. This code has to be generic enough to handle any
>>condition.
>>>
>>Aha, you are right, this may happens.
>>So I think the general solution is to fix this problem in the enqueue
>>side.
>>What do you think? any better suggestion!
>>
>
> Don't have code in front of me but what if we carry the error condition to
> where we queue the Sack and add the error side effect then?
Yes, this is the most direct way to fix this problem.
But I don't think it's the best way since we will take care of a lot
of things and
it also involves in lots of changes to side effect processing.
I prefer to Neil Horman's way for the solution since only COOKIE_ACK chunk is
allowed to place ahead of SACK chunk when bundling into one packet.
What do you think?
Thanks,
Xufeng Zhang
>
> -vlad
^ permalink raw reply
* Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
From: Xufeng Zhang @ 2012-07-25 2:34 UTC (permalink / raw)
To: Neil Horman
Cc: xufeng zhang, vyasevich, sri, davem, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20120724113802.GA30142@hmsreliant.think-freely.org>
On 7/24/12, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Tue, Jul 24, 2012 at 09:50:18AM +0800, xufeng zhang wrote:
>> On 07/23/2012 08:14 PM, Neil Horman wrote:
>> >On Mon, Jul 23, 2012 at 10:30:34AM +0800, xufeng zhang wrote:
>> >>On 07/23/2012 08:49 AM, Neil Horman wrote:
>> >>>Not sure I understand how you came into this error. If we get an
>> >>> invalid
>> >>>stream, we issue an SCTP_REPORT_TSN side effect, followed by an
>> >>> SCTP_CMD_REPLY
>> >>>which sends the error chunk. The reply goes through
>> >>>sctp_outq_tail->sctp_outq_chunk->sctp_outq_transmit_chunk->sctp_outq_append_chunk.
>> >>>That last function checks to see if a sack is already part of the
>> >>> packet, and if
>> >>>there isn't one, appends one, using the updated tsn map.
>> >>Yes, you are right, but consider the invalid stream identifier's
>> >>DATA chunk is the first
>> >>DATA chunk in the association which will need SACK immediately.
>> >>Here is what I thought of the scenario:
>> >> sctp_sf_eat_data_6_2()
>> >> -->sctp_eat_data()
>> >> -->sctp_make_op_error()
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> >> SCTP_CHUNK(err))
>> >> -->sctp_outq_tail() /* First enqueue ERROR chunk
>> >> */
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_GEN_SACK, SCTP_FORCE())
>> >> -->sctp_gen_sack()
>> >> -->sctp_make_sack()
>> >> -->sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> >>SCTP_CHUNK(sack))
>> >> -->sctp_outq_tail() /* Then enqueue SACK chunk
>> >> */
>> >>
>> >>So SACK chunk is enqueued after ERROR chunk.
>> >Ah, I see. Since the ERROR and SACK chunks are both control chunks, and
>> > since
>> >we explicitly add the SACK to the control queue instead of going through
>> > the
>> >bundle path in sctp_packet_append_chunk the ordering gets wrong.
>> >
>> >Ok, so the problem makes sense. I think the soultion could be alot
>> > easier
>> >though. IIRC SACK chunks always live at the head of a packet, so why not
>> > just
>> >special case it in sctp_outq_tail? I.e. instead of doing a
>> > list_add_tail, in
>> >the else clause of sctp_outq_tail check the chunk_hdr->type to see if
>> > its
>> >SCTP_CID_SACK. If it is, use list_add_head rather than list_add_tail. I
>> > think
>> >that will fix up both the COOKIE_ECHO and ESTABLISHED cases, won't it?
>> > And then
>> >you won't have keep track of extra state in the packet configuration.
>> Yes, it's a good idea, but I think the premise is not correct:
>> RFC 4960 page 57:
>> "D) Upon reception of the COOKIE ECHO chunk, endpoint "Z" will reply
>> with a COOKIE ACK chunk after building a TCB and moving to the
>> ESTABLISHED state. A COOKIE ACK chunk may be bundled with any
>> pending DATA chunks (and/or SACK chunks), *but the COOKIE ACK chunk
>> MUST be the first chunk in the packet*."
>>
>> So we can't put SACK chunk always at the head of the packet.
>>
> Ok, Fair point, but that just changes the ordering a bit to:
> COOKIE_ACK
> SACK
> OTHER CONTROL CHUNKS
>
> What about something like this? Its completely untested, and I'm sure it
> can be
> cleaned up a bunch, but this keeps us from having to add additional state to
> the
> packet structure.
Yeah! I like this modification, thank you very much for your work!
I'll try to send a V2 patch based on your changes and run some tests.
Thanks,
Xufeng Zhang
>
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index e7aa177c..eeac32f 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -300,7 +300,7 @@ void sctp_outq_free(struct sctp_outq *q)
> int sctp_outq_tail(struct sctp_outq *q, struct sctp_chunk *chunk)
> {
> int error = 0;
> -
> + struct sctp_chunk *cptr;
> SCTP_DEBUG_PRINTK("sctp_outq_tail(%p, %p[%s])\n",
> q, chunk, chunk && chunk->chunk_hdr ?
> sctp_cname(SCTP_ST_CHUNK(chunk->chunk_hdr->type))
> @@ -344,7 +344,21 @@ int sctp_outq_tail(struct sctp_outq *q, struct
> sctp_chunk *chunk)
> break;
> }
> } else {
> - list_add_tail(&chunk->list, &q->control_chunk_list);
> + list_del_init(&chunk->list);
> + if (chunk->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + list_add_head(&chunk->list, &q->control_chunk_list);
> + else if (!list_empty(&q->control_chunk_list) &&
> + chunk->chunk_hdr->type == SCTP_CID_SACK) {
> + list_for_each_entry(cptr, &q->control_chunk_list, list) {
> + if (cptr->chunk_hdr->type == SCTP_CID_COOKIE_ACK)
> + continue;
> + list_add(&chunk->list, &cptr->list);
> + break;
> + }
> + }
> +
> + if (list_empty(&chunk->list))
> + list_add_tail(&chunk->list, &q->control_chunk_list);
> SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> }
>
>>
>> Thanks,
>> Xufeng Zhang
>> >Regards
>> >Neil
>> >
>> >
>>
>
^ permalink raw reply
* Re: [PATCH] ppp: add 64 bit stats
From: Eric Dumazet @ 2012-07-25 4:04 UTC (permalink / raw)
To: Kevin Groeneveld; +Cc: netdev
In-Reply-To: <CABF+-6Wpn8yEvru1FDsaFbXYZ7tyeQqqbEU2VY8hLKvmXXFBXA@mail.gmail.com>
On Tue, 2012-07-24 at 22:27 -0400, Kevin Groeneveld wrote:
> After looking at the existing ppp code more I wonder if I would even
> need to add my own spinlocks. It seems the only spots I am updating
> the 64 bit stats are already protected by either ppp->wlock or
> ppp->rlock spinlocks. If I used two separate u64_stats_sync
> structures, one for tx stats and one for rx stats, wouldn't the
> existing spinlocks be enough?
It there are spinlocks already, why even adding u64_stats_sync ?
Just use existing spinlocks to protect your new u64 fields (in the
ngso_get_stats64())
^ permalink raw reply
* [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Li Wei @ 2012-07-25 5:25 UTC (permalink / raw)
To: David Miller; +Cc: David.Laight, netdev, shemminger
In-Reply-To: <20120720.112241.2111041227435292899.davem@davemloft.net>
When userspace use RTM_GETROUTE to dump route table, with an already
expired route entry, we always got an 'expires' value(2147157)
calculated base on INT_MAX.
The reason of this problem is in the following satement:
rt->dst.expires - jiffies < INT_MAX
gcc promoted the type of both sides of '<' to unsigned long, thus
a small negative value would be considered greater than INT_MAX.
This patch fix this by use the same trick as time_after macro to
avoid the 'unsigned long' type promotion and deal with jiffies
wrapping.
Also we should do some fix in rtnl_put_cacheinfo() which use
jiffies_to_clock_t(which take an unsigned long as parameter) to
convert jiffies to clock_t to handle the negative expires.
With the help of David Laight, we can make the code a little clean.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/core/rtnetlink.c | 3 ++-
net/ipv6/route.c | 11 ++++++-----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 334b930..2e96396 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
};
if (expires)
- ci.rta_expires = jiffies_to_clock_t(expires);
+ ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
+ : -jiffies_to_clock_t(-expires);
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cf02cb9..6efeb28 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
goto nla_put_failure;
if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
goto nla_put_failure;
- if (!(rt->rt6i_flags & RTF_EXPIRES))
+ if (!(rt->rt6i_flags & RTF_EXPIRES)) {
expires = 0;
- else if (rt->dst.expires - jiffies < INT_MAX)
- expires = rt->dst.expires - jiffies;
- else
- expires = INT_MAX;
+ } else {
+ expires = (long)rt->dst.expires - (long)jiffies;
+ if (expires != (int)expires)
+ expires = expires > 0 ? INT_MAX : INT_MIN;
+ }
if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
goto nla_put_failure;
--
1.7.10.1
^ permalink raw reply related
* iproute2 - IPsec ESN support
From: Geanta Neag Horia Ioan-B05471 @ 2012-07-25 6:14 UTC (permalink / raw)
To: netdev@vger.kernel.org, linux-crypto@vger.kernel.org
Cc: Stephen Hemminger, Steffen Klassert
Hello,
Is there any way to create an IPsec tunnel and indicate using
extended sequnce numbers?
It seems that currently iproute2 doesn't support this.
Grepping for "esn" reveals that XFRM_STATE_ESN shows only in kernel headers.
The only relevant thing I found was a RFC sent by Steffen (Cc-ed),
but it was never applied (don't know why):
[RFC] iproute2: Add IPsec extended sequence number support
http://patchwork.ozlabs.org/patch/85962/
Thank you,
Horia
^ permalink raw reply
* Re: [PATCH V3] ipv6: fix incorrect route 'expires' value passed to userspace
From: Eric Dumazet @ 2012-07-25 6:51 UTC (permalink / raw)
To: Li Wei; +Cc: David Miller, David.Laight, netdev, shemminger
In-Reply-To: <500F8356.5040008@cn.fujitsu.com>
On Wed, 2012-07-25 at 13:25 +0800, Li Wei wrote:
> When userspace use RTM_GETROUTE to dump route table, with an already
> expired route entry, we always got an 'expires' value(2147157)
> calculated base on INT_MAX.
>
> The reason of this problem is in the following satement:
> rt->dst.expires - jiffies < INT_MAX
> gcc promoted the type of both sides of '<' to unsigned long, thus
> a small negative value would be considered greater than INT_MAX.
>
> This patch fix this by use the same trick as time_after macro to
> avoid the 'unsigned long' type promotion and deal with jiffies
> wrapping.
>
> Also we should do some fix in rtnl_put_cacheinfo() which use
> jiffies_to_clock_t(which take an unsigned long as parameter) to
> convert jiffies to clock_t to handle the negative expires.
>
> With the help of David Laight, we can make the code a little clean.
>
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
> ---
> net/core/rtnetlink.c | 3 ++-
> net/ipv6/route.c | 11 ++++++-----
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 334b930..2e96396 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -626,7 +626,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
> };
>
> if (expires)
> - ci.rta_expires = jiffies_to_clock_t(expires);
> + ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
> + : -jiffies_to_clock_t(-expires);
>
> return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
> }
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index cf02cb9..6efeb28 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2480,12 +2480,13 @@ static int rt6_fill_node(struct net *net,
> goto nla_put_failure;
> if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
> goto nla_put_failure;
> - if (!(rt->rt6i_flags & RTF_EXPIRES))
> + if (!(rt->rt6i_flags & RTF_EXPIRES)) {
> expires = 0;
> - else if (rt->dst.expires - jiffies < INT_MAX)
> - expires = rt->dst.expires - jiffies;
> - else
> - expires = INT_MAX;
> + } else {
> + expires = (long)rt->dst.expires - (long)jiffies;
> + if (expires != (int)expires)
> + expires = expires > 0 ? INT_MAX : INT_MIN;
> + }
>
> if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
> goto nla_put_failure;
All this sounds not very clean.
rtnl_put_cacheinfo( ... long expires ... )
Any out of bound checks should be done in rtnl_put_cacheinfo(), _after_
conversion to clock_t.
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 334b930..c1c950b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -625,9 +625,13 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
.rta_id = id,
};
- if (expires)
- ci.rta_expires = jiffies_to_clock_t(expires);
+ if (expires) {
+ unsigned long clock;
+ clock = jiffies_to_clock_t(abs(expires));
+ clock = min_t(unsigned long, clock, INT_MAX);
+ ci.rta_expires = (expires > 0) ? clock : -clock;
+ }
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
EXPORT_SYMBOL_GPL(rtnl_put_cacheinfo);
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index cf02cb9..8e80fd2 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2480,12 +2480,8 @@ static int rt6_fill_node(struct net *net,
goto nla_put_failure;
if (nla_put_u32(skb, RTA_PRIORITY, rt->rt6i_metric))
goto nla_put_failure;
- if (!(rt->rt6i_flags & RTF_EXPIRES))
- expires = 0;
- else if (rt->dst.expires - jiffies < INT_MAX)
- expires = rt->dst.expires - jiffies;
- else
- expires = INT_MAX;
+
+ expires = (rt->rt6i_flags & RTF_EXPIRES) ? rt->dst.expires - jiffies : 0;
if (rtnl_put_cacheinfo(skb, &rt->dst, 0, expires, rt->dst.error) < 0)
goto nla_put_failure;
^ permalink raw reply related
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