* Re: net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu
From: Paul E. McKenney @ 2017-04-26 15:13 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Josh Triplett,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Eric Dumazet,
Cong Wang, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAAeHK+zZgV9c2RfVhX1m737Kx4mfrHUCf1txiaFi8Er4c1Zr=w@mail.gmail.com>
On Wed, Apr 26, 2017 at 04:45:51PM +0200, Andrey Konovalov wrote:
> On Wed, Apr 26, 2017 at 3:59 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Wed, Apr 26, 2017 at 02:34:15PM +0200, Andrey Konovalov wrote:
> >> Hi,
> >>
> >> I've got the following error report while fuzzing the kernel with syzkaller.
> >>
> >> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).
> >>
> >> Unfortunately it's not reproducible.
> >>
> >> I'm not sure whether is is an issue with rcu or ipv6.
> >>
> >> ==================================================================
> >> BUG: KASAN: use-after-free in __call_rcu.constprop.77+0x13be/0x1640
> >
> > Does building with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y show any splats?
> > (Yeah, kind of a stupid question if it is not reproducible, but had
> > to ask!)
>
> Hi Paul,
>
> I'll try enabling this config.
>
> In the meantime, while I was trying to reproduce this issue, I got this warning:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 4590 at kernel/rcu/tree.c:2919
> rcu_do_batch.isra.65+0x845/0xbd0
> Modules linked in:
> CPU: 0 PID: 4590 Comm: syz-executor Not tainted 4.11.0-rc8+ #270
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x192/0x22d lib/dump_stack.c:52
> __warn+0x19f/0x1e0 kernel/panic.c:549
> warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
> rcu_do_batch.isra.65+0x845/0xbd0 kernel/rcu/tree.c:2919
> invoke_rcu_callbacks kernel/rcu/tree.c:3142
> __rcu_process_callbacks kernel/rcu/tree.c:3109
> rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
> __do_softirq+0x253/0x78b kernel/softirq.c:284
> invoke_softirq kernel/softirq.c:364
> irq_exit+0x149/0x180 kernel/softirq.c:405
> exiting_irq ./arch/x86/include/asm/apic.h:657
> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
> apic_timer_interrupt+0x89/0x90
> RIP: 0010:do_anonymous_page mm/memory.c:2962
> RIP: 0010:handle_pte_fault mm/memory.c:3721
> RIP: 0010:__handle_mm_fault+0xdab/0x1c00 mm/memory.c:3841
> RSP: 0018:ffff88006a02f7d0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
> RAX: 000000000005dab0 RBX: 1ffff1000d405f00 RCX: 1ffff1000d28cd3f
> RDX: dffffc0000000000 RSI: 8000000000000025 RDI: ffff8800694669f8
> RBP: ffff88006a02f9a8 R08: 00000000014280ca R09: 1ffff1000d405eb0
> R10: ffff88006a02f660 R11: dffffc0000000000 R12: ffff88006a02f8e0
> R13: ffff88006a02f980 R14: ffff8800694669b0 R15: ffff880069466a00
> </IRQ>
> handle_mm_fault+0x1aa/0x450 mm/memory.c:3878
> faultin_page mm/gup.c:408
> __get_user_pages+0x606/0x14a0 mm/gup.c:607
> populate_vma_page_range+0xd9/0x100 mm/gup.c:1062
> __mm_populate+0x278/0x540 mm/gup.c:1112
> mm_populate ./include/linux/mm.h:2132
> vm_mmap_pgoff+0x258/0x280 mm/util.c:314
> SYSC_mmap_pgoff mm/mmap.c:1503
> SyS_mmap_pgoff+0x22c/0x5e0 mm/mmap.c:1461
> SYSC_mmap arch/x86/kernel/sys_x86_64.c:96
> SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:87
> entry_SYSCALL_64_fastpath+0x1a/0xa9 arch/x86/entry/entry_64.S:204
> RIP: 0033:0x4458e9
> RSP: 002b:00007f3a15ce4b58 EFLAGS: 00000282 ORIG_RAX: 0000000000000009
> RAX: ffffffffffffffda RBX: 00007f3a15ce5700 RCX: 00000000004458e9
> RDX: 0000000000000002 RSI: 00000000009b8000 RDI: 0000000020000000
> RBP: 0000000000000000 R08: ffffffffffffffff R09: 8000000000000000
> R10: 0000000000008032 R11: 0000000000000282 R12: 0000000000000000
> R13: 0000000000000000 R14: 00007f3a15ce59c0 R15: 00007f3a15ce5700
> ---[ end trace e36457085170396e ]---
This is current mainline, somewhere after v4.11-rc1 and linus/master?
If so, this warning indicates that RCU's callback list has been corrupted.
This could be a bug in RCU, and if this was 4.12-rc1 and later, my
first guess would be upcoming changes in RCU callback handling. But I
am pretty sure that you are not running 4.12-rc1.
So I will instead guess that you are double-call_rcu()-ing (sort of like
double-free, except with call_rcu() and friends instead of kfree()).
Or, alternatively, the call_rcu() counterpart to use-after-free.
Thanx, Paul
> >> kernel/rcu/tree.c:3269 at addr ffff88003b842280
> >> Write of size 8 by task kworker/u10:1/180
> >> CPU: 2 PID: 180 Comm: kworker/u10:1 Not tainted 4.11.0-rc8+ #270
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >> Workqueue: events_unbound call_usermodehelper_exec_work
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:16 [inline]
> >> dump_stack+0x192/0x22d lib/dump_stack.c:52
> >> kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
> >> print_address_description mm/kasan/report.c:202 [inline]
> >> kasan_report_error mm/kasan/report.c:291 [inline]
> >> kasan_report+0x252/0x510 mm/kasan/report.c:347
> >> __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:373
> >> __call_rcu.constprop.77+0x13be/0x1640 kernel/rcu/tree.c:3269
> >> call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
> >> free_pid+0x446/0x5d0 kernel/pid.c:293
> >> __change_pid+0x2a1/0x3d0 kernel/pid.c:411
> >> detach_pid+0x1f/0x30 kernel/pid.c:416
> >> __unhash_process kernel/exit.c:74 [inline]
> >> __exit_signal kernel/exit.c:155 [inline]
> >> release_task+0xbb0/0x1d90 kernel/exit.c:199
> >> wait_task_zombie kernel/exit.c:1230 [inline]
> >> wait_consider_task+0x11fe/0x3410 kernel/exit.c:1458
> >> do_wait_thread kernel/exit.c:1521 [inline]
> >> do_wait+0x3ea/0x8e0 kernel/exit.c:1592
> >> SYSC_wait4 kernel/exit.c:1720 [inline]
> >> SyS_wait4+0x208/0x340 kernel/exit.c:1689
> >> call_usermodehelper_exec_sync kernel/kmod.c:292 [inline]
> >> call_usermodehelper_exec_work+0x1a7/0x2b0 kernel/kmod.c:329
> >> process_one_work+0x9f7/0x1580 kernel/workqueue.c:2097
> >> worker_thread+0x1df/0x14b0 kernel/workqueue.c:2231
> >> kthread+0x31f/0x3f0 kernel/kthread.c:231
> >> ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
> >> Object at ffff88003b842018, in cache kmalloc-1024 size: 1024
> >> Allocated:
> >> PID = 1
> >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> >> set_track mm/kasan/kasan.c:525 [inline]
> >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
> >> kmem_cache_alloc_trace+0x61/0x170 mm/slub.c:2745
> >> kmalloc include/linux/slab.h:490 [inline]
> >> kzalloc include/linux/slab.h:663 [inline]
> >> ipv6_add_dev+0x199/0x1380 net/ipv6/addrconf.c:380
> >> addrconf_init+0xd0/0x29a net/ipv6/addrconf.c:6405
> >> inet6_init+0x2f6/0x584 net/ipv6/af_inet6.c:962
> >> do_one_initcall+0xf3/0x380 init/main.c:792
> >> do_initcall_level init/main.c:858 [inline]
> >> do_initcalls init/main.c:866 [inline]
> >> do_basic_setup init/main.c:884 [inline]
> >> kernel_init_freeable+0x54d/0x622 init/main.c:1035
> >> kernel_init+0x13/0x180 init/main.c:959
> >> ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
> >> Freed:
> >> PID = 6479
> >> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
> >> set_track mm/kasan/kasan.c:525 [inline]
> >> kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
> >> slab_free_hook mm/slub.c:1357 [inline]
> >> slab_free_freelist_hook mm/slub.c:1379 [inline]
> >> slab_free mm/slub.c:2961 [inline]
> >> kfree+0x91/0x190 mm/slub.c:3882
> >> in6_dev_finish_destroy_rcu+0x97/0xc0 net/ipv6/addrconf_core.c:150
> >> __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
> >> rcu_do_batch.isra.65+0x6de/0xbd0 kernel/rcu/tree.c:2879
> >> invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
> >> __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
> >> rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
> >> __do_softirq+0x253/0x78b kernel/softirq.c:284
> >> Memory state around the buggy address:
> >> ffff88003b842180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff88003b842200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> >ffff88003b842280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ^
> >> ffff88003b842300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff88003b842380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ==================================================================
> >>
> >
>
^ permalink raw reply
* Re: [iproute2] iplink: add support for IFLA_CARRIER attribute
From: Stephen Hemminger @ 2017-04-26 15:07 UTC (permalink / raw)
To: Zhang Shengju; +Cc: netdev
In-Reply-To: <1493190519-5518-1-git-send-email-zhangshengju@cmss.chinamobile.com>
On Wed, 26 Apr 2017 15:08:39 +0800
Zhang Shengju <zhangshengju@cmss.chinamobile.com> wrote:
> Add support to set IFLA_CARRIER attribute.
>
> Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
> ---
> ip/iplink.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/ip/iplink.c b/ip/iplink.c
> index 866ad72..263bfdd 100644
> --- a/ip/iplink.c
> +++ b/ip/iplink.c
> @@ -72,6 +72,7 @@ void iplink_usage(void)
> " [ allmulticast { on | off } ]\n"
> " [ promisc { on | off } ]\n"
> " [ trailers { on | off } ]\n"
> + " [ carrier { on | off } ]\n"
> " [ txqueuelen PACKETS ]\n"
> " [ name NEWNAME ]\n"
> " [ address LLADDR ]\n"
> @@ -673,6 +674,17 @@ int iplink_parse(int argc, char **argv, struct iplink_req *req,
> req->i.ifi_flags |= IFF_NOARP;
> else
> return on_off("arp", *argv);
> + } else if (strcmp(*argv, "carrier") == 0) {
> + int carrier;
> + NEXT_ARG();
> + if (strcmp(*argv, "on") == 0)
> + carrier = 1;
> + else if (strcmp(*argv, "off") == 0)
> + carrier = 0;
> + else
> + return on_off("carrier", *argv);
> +
> + addattr8(&req->n, sizeof(*req), IFLA_CARRIER, carrier);
> } else if (strcmp(*argv, "vf") == 0) {
> struct rtattr *vflist;
>
The general policy of ip link command is all options should be invertable.
There are some VPN's that use this to save and restore state. So if you add
an option to set something there should be similar output under the detailed show command.
^ permalink raw reply
* Re: [PATCH net-next v8 2/3] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: Jiri Pirko @ 2017-04-26 14:58 UTC (permalink / raw)
To: David Miller; +Cc: jhs, simon.horman, xiyou.wangcong, eric.dumazet, netdev
In-Reply-To: <20170426.104658.547156121898948265.davem@davemloft.net>
Wed, Apr 26, 2017 at 04:46:58PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 26 Apr 2017 15:05:06 +0200
>
>> Wed, Apr 26, 2017 at 02:46:22PM CEST, jhs@mojatatu.com wrote:
>>>On 17-04-26 07:02 AM, Simon Horman wrote:
>>>> On Tue, Apr 25, 2017 at 06:04:45PM +0200, Jiri Pirko wrote:
>>>[..]
>>>
>>>> > So fix iproute2. It is always first kernel, then iproute2.
>>>>
>>>> Perhaps I am missing the point or somehow misguided but I would expect that
>>>> if the UAPI uses BIT() it also provides BIT().
>>>
>>>There is a user of BIT() already in iproute2 (devlink). We can move
>>>the code to be more generally available for other iproute2 users.
>>>Then this UAPI change makes use of it.
>>
>> Should be part of UAPI as well
>> I see that include/uapi/rdma/vmw_pvrdma-abi.h is using BIT macro.
>> I don't see BIT macro defined in UAPI (I thought it is). So either
>> define it there (not sure where) or just use "<<"
>
>"BIT" is a pretty crazy small simple name to pollute into the global
>namespace, IMHO.
Btw, this is also something resolvable nicely if we have NLA_FLAGS
netlink attribute type. We can have some helper in UAPI like:
#define TCA_FLAG_LARGE_DUMP_ON NLA_FLAGS_F(0)
^ permalink raw reply
* Re: bluetooth 6lowpan interfaces are not virtual anymore
From: Michael Richardson @ 2017-04-26 15:05 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Alexander Aring, Network Development, Jukka Rissanen,
linux-wpan@vger.kernel.org, Linux Bluetooth
In-Reply-To: <CABBYNZJqChBfB4jNCN3edmKSfhNd-haTKOjeYy1toK-Mn=qzoA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3153 bytes --]
I said that BT people hadn't replied, but it was next in my inbox :-)
Luiz Augusto von Dentz <luiz.dentz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> At least if you want to try to make a more efficient qdisc handling,
>> means dropping skb's in queue when userspace sends too much. You will
>> change it back, control two queues seems to be difficult.
> It is wrong only if you look at 6LoWPAN interface as being owned by
> 6lowpan modules, but it doesn't, in fact it won't anything by itself so
> it basically acts as a library to that perform 6LoWPAN operation on the
> packet level, thus why it is possible to switch from virtual to real
> interface. Also in terms of 15.4, the 6LoWPAN interfaces you depicted
> above is also no controlled by 6LoWPAN itself, in fact it seeems to
> represent links in 15.4, and I also assume these links may not use
> 6LoWPAN.
At present I do not think we support any 15.4 links which are not 6lowpan in the Kernel.
Perhaps a userspace can open the device in raw mode and do stuff with it
directly. Do such users exist right now?
>> This queue should have the same meaning like our queue in IEEE
>> 802.15.4 interface which you mentioned above. At this point, we have
>> no difference. There exists already a queue for your real transeiver
>> hardware.
> The queue here is per channel, btw the queue size is not decided by us
> it is the remote side that provides the tx credits so to some extend
> the tx_queue is actually the remote queue in case of CoC. When testing
> this it was quite clear this does not work in practice, with IPv6 at
> least, because the remote side may not have enough credits for a single
> packet (MPS * tx_credits < MTU) which means without proper queueing
> support we would be dropping every packet.
Would a longer amortization interval help this?
It seems that if there isn't bandwidth to send the packet, that userspace has
to learn about this fact...
>> At least, having a queue and don't put anything anymore into the queue
>> when "tx credits" is at zero (because queue is full). _Is_ a kind of
>> qdisc handling.
> The tx_credits operate at L2CAP segment level (MPS), so it is at a
> completely different level, there are no guarantees the credits will
> attend to a single IP packet.
That seems like a problem.
I think that we need to either send the entire packet, or none.
Spreading the credits across two packets would just make the system stutter,
as an upper layer retransmits packets that were half-sent, but then delayed.
Is there someway we can wait, at the IP packet queue level, until there are
sufficient credits to send all the fragments? That way, the IP qdisc layer
can decide to abort(drop,defer) an IP packet from the queue in favour of a more
important packet.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr-SWp7JaYWvAQV+D8aMU/kSg@public.gmane.org http://www.sandelman.ca/ | ruby on rails [
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply
* Re: bluetooth 6lowpan interfaces are not virtual anymore
From: Michael Richardson @ 2017-04-26 14:55 UTC (permalink / raw)
To: Alexander Aring
Cc: Network Development, Jukka Rissanen, Luiz Augusto von Dentz,
linux-wpan@vger.kernel.org, Linux Bluetooth
In-Reply-To: <11cf222a-0c1f-4136-091d-719ee68824e1@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
Alexander Aring <aar@pengutronix.de> wrote:
>> In a classic SVR4 STREAMS works, it would have been just another
>> module. (No, I'm not a fan of *STREAMS* or of SVR4 in general,
>> although I liked some of the ideas).
>>
> ok, I see you complain about "having a virtual on top of wpan
> interface", or?
> I wanted to talk at first about the queue handling which is introduced
> when 6LoWPAN is not a virtual interface anymore. Or do you want to have
> a queue in front of 6lowpan adaptation (see other mail reply with ASCII
> graphics).
I would like to have a single queue, as close to the hardware as possible,
such that BQL can do it's thing easily. Should we rethink outgoing fragment
handling for 6lowpan? Clearly the BT people had a need.
I don't think they've had a chance to respond to your complaints.
> We can change that you can run multiple interfaces on one
> PHY. Currently we just allow one, because address filtering. Disable
> address filtering
> we will loose ACK handling on hardware.
Yes, that's a limitation of some hardware, and if you enable multiple PANIDs,
that might be the consequence....
> I can try to implement all stuff in software "for fun, maybe see what
> we can do to handle ACK in software, etc" Then you can run multiple
I'm not asking you to do it, I'm asking, now that we've gotten to a certain
point, we have a better idea what the various requirements are, and can we
re-evaluate things and maybe tweak some things.
^ permalink raw reply
* [PATCH net-next] net: vrf: Do not allow looback to be moved to a VRF
From: David Ahern @ 2017-04-26 14:58 UTC (permalink / raw)
To: netdev; +Cc: rshearma, David Ahern
Moving the loopback into a VRF breaks networking for the default VRF.
Since the VRF device is the loopback for VRF domains, there is no
reason to move the loopback. Given the repercussions, block attempts
to set lo into a VRF.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
drivers/net/vrf.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index aa5d30428bba..ceda5861da78 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -877,6 +877,12 @@ static int do_vrf_add_slave(struct net_device *dev, struct net_device *port_dev)
{
int ret;
+ /* do not allow loopback device to be enslaved to a VRF.
+ * The vrf device acts as the loopback for the vrf.
+ */
+ if (port_dev == dev_net(dev)->loopback_dev)
+ return -EOPNOTSUPP;
+
port_dev->priv_flags |= IFF_L3MDEV_SLAVE;
ret = netdev_master_upper_dev_link(port_dev, dev, NULL, NULL);
if (ret < 0)
--
2.1.4
^ permalink raw reply related
* Re: more test_progs...
From: David Miller @ 2017-04-26 14:55 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <590056F2.5010600@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 26 Apr 2017 10:14:42 +0200
> On 04/26/2017 05:42 AM, Alexei Starovoitov wrote:
>> That sucks for sparc, of course. I don't have good suggestions for
>> workaround other than marking tcphdr as packed :(
>> From code efficiency point of view it still will be faster than
>> LD_ABS insn.
>
> Plus, ld_abs would also only work on skbs right now, and would
> need JIT support for XDP. But it's also cumbersome to use with
> f.e. IPv6, etc, so should not be encouraged, imo.
>
> One other option for !HAVE_EFFICIENT_UNALIGNED_ACCESS archs could
> be to provide a bpf_skb_load_bytes() helper equivalent for XDP,
> where you eventually do the memcpy() inside. We could see to inline
> the helper itself to optimize it slightly.
We have to do something that works transparently and always,
regardless of whether HAVE_EFFICIENT_UNALIGNED_ACCESS is in
play or not.
And no, marking objects with __packed is not the answer.
What's happening right now is completely unacceptable.
^ permalink raw reply
* Re: linux-next: Tree for Apr 26 (net/can/bcm.c)
From: Randy Dunlap @ 2017-04-26 14:53 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org, linux-can
In-Reply-To: <20170426180321.3c8c16a2@canb.auug.org.au>
On 04/26/17 01:03, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170424:
>
on x86_64:
when CONFIG_PROC_FS is not enabled:
../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
2 of those are "protected" by
if (IS_ENABLED(CONFIG_PROC_FS)) {
but that doesn't seem to help/work here.
gcc v4.8.5
--
~Randy
^ permalink raw reply
* [PATCH v1 net-next 6/6] net: ethernet: update drivers to make both SW and HW TX timestamps
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
Some drivers were calling the skb_tx_timestamp() function only when
a hardware timestamp was not requested. Now that applications can use
the SOF_TIMESTAMPING_OPT_TX_SWHW option to request both software and
hardware timestamps, the drivers need to be modified to unconditionally
call skb_tx_timestamp().
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 3 +--
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++--
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 3 +--
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 ++----
4 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 89b21d7..5a2ad9c 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -1391,8 +1391,7 @@ static void xgbe_prep_tx_tstamp(struct xgbe_prv_data *pdata,
spin_unlock_irqrestore(&pdata->tstamp_lock, flags);
}
- if (!XGMAC_GET_BITS(packet->attributes, TX_PACKET_ATTRIBUTES, PTP))
- skb_tx_timestamp(skb);
+ skb_tx_timestamp(skb);
}
static void xgbe_prep_vlan(struct sk_buff *skb, struct xgbe_packet_data *packet)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 940a79e..a149dff 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5856,10 +5856,10 @@ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
adapter->tx_hwtstamp_skb = skb_get(skb);
adapter->tx_hwtstamp_start = jiffies;
schedule_work(&adapter->tx_hwtstamp_work);
- } else {
- skb_tx_timestamp(skb);
}
+ skb_tx_timestamp(skb);
+
netdev_sent_queue(netdev, skb->len);
e1000_tx_queue(tx_ring, tx_flags, count);
/* Make sure there is space in the ring for the next send. */
diff --git a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
index d54490d..50c182c 100644
--- a/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
+++ b/drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c
@@ -1418,8 +1418,7 @@ static netdev_tx_t sxgbe_xmit(struct sk_buff *skb, struct net_device *dev)
priv->hw->desc->tx_enable_tstamp(first_desc);
}
- if (!tqueue->hwts_tx_en)
- skb_tx_timestamp(skb);
+ skb_tx_timestamp(skb);
priv->hw->dma->enable_dma_transmission(priv->ioaddr, txq_index);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3115700..7f857ee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2880,8 +2880,7 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
priv->xstats.tx_set_ic_bit++;
}
- if (!priv->hwts_tx_en)
- skb_tx_timestamp(skb);
+ skb_tx_timestamp(skb);
if (unlikely((skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
priv->hwts_tx_en)) {
@@ -3084,8 +3083,7 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
priv->xstats.tx_set_ic_bit++;
}
- if (!priv->hwts_tx_en)
- skb_tx_timestamp(skb);
+ skb_tx_timestamp(skb);
/* Ready to fill the first descriptor and set the OWN bit w/o any
* problems because all the descriptors are actually ready to be
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 5/6] net: allow simultaneous SW and HW transmit timestamping
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
Add SOF_TIMESTAMPING_OPT_TX_SWHW option to allow an outgoing packet to
be looped to the socket's error queue with a software timestamp even
when a hardware transmit timestamp is expected to be provided by the
driver.
Applications using this option will receive two separate messages from
the error queue, one with a software timestamp and the other with a
hardware timestamp. As the hardware timestamp is saved to the shared skb
info, which may happen before the first message with software timestamp
is received by the application, the hardware timestamp is copied to the
SCM_TIMESTAMPING control message only when the skb has no software
timestamp or it is an incoming packet.
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
Documentation/networking/timestamping.txt | 14 ++++++++++++--
include/linux/skbuff.h | 3 +--
include/uapi/linux/net_tstamp.h | 3 ++-
net/core/skbuff.c | 4 ++++
net/socket.c | 1 +
5 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 6c07e7c..ab29a6e 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -201,6 +201,14 @@ SOF_TIMESTAMPING_OPT_PKTINFO:
which received the packet and its length at layer 2. This option
works only if CONFIG_NET_RX_BUSY_POLL is enabled.
+SOF_TIMESTAMPING_OPT_TX_SWHW:
+
+ Request both hardware and software timestamps for outgoing packets
+ when SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_TX_SOFTWARE
+ are enabled at the same time. If both timestamps are generated,
+ two separate messages will be looped to the socket's error queue,
+ each containing just one timestamp.
+
New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
regardless of the setting of sysctl net.core.tstamp_allow_data.
@@ -320,8 +328,10 @@ struct scm_timestamping {
};
The structure can return up to three timestamps. This is a legacy
-feature. Only one field is non-zero at any time. Most timestamps
-are passed in ts[0]. Hardware timestamps are passed in ts[2].
+feature. Most timestamps are passed in ts[0]. Hardware timestamps
+are passed in ts[2]. Incoming packets may have timestamps in both
+ts[0] and ts[2], but for outgoing packets only one field is non-zero
+at any time.
ts[1] used to hold hardware timestamps converted to system time.
Instead, expose the hardware clock device on the NIC directly as
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 81ef53f..42bff22 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3300,8 +3300,7 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
static inline void sw_tx_timestamp(struct sk_buff *skb)
{
- if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP &&
- !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
+ if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)
skb_tstamp_tx(skb, NULL);
}
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 8fcae35..d251972 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -27,8 +27,9 @@ enum {
SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
SOF_TIMESTAMPING_OPT_STATS = (1<<12),
SOF_TIMESTAMPING_OPT_PKTINFO = (1<<13),
+ SOF_TIMESTAMPING_OPT_TX_SWHW = (1<<14),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_PKTINFO,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_TX_SWHW,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 58604c1..db5aa19 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3874,6 +3874,10 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb,
if (!sk)
return;
+ if (!hwtstamps && !(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TX_SWHW) &&
+ skb_shinfo(orig_skb)->tx_flags & SKBTX_IN_PROGRESS)
+ return;
+
tsonly = sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TSONLY;
if (!skb_may_tx_timestamp(sk, tsonly))
return;
diff --git a/net/socket.c b/net/socket.c
index 68b9304..14b7688 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -720,6 +720,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
empty = 0;
if (shhwtstamps &&
(sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
+ (empty || !skb_is_err_queue(skb)) &&
ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2)) {
empty = 0;
if ((sk->sk_tsflags & SOF_TIMESTAMPING_OPT_PKTINFO) &&
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 2/6] net: ethernet: update drivers to handle HWTSTAMP_FILTER_NTP_ALL
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
Include HWTSTAMP_FILTER_NTP_ALL in net_hwtstamp_validate() as a valid
filter and update drivers which can timestamp all packets, or which
explicitly list unsupported filters instead of using a default case, to
handle the filter.
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
drivers/net/ethernet/cavium/liquidio/lio_main.c | 1 +
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 1 +
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 1 +
drivers/net/ethernet/intel/e1000e/netdev.c | 1 +
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 1 +
drivers/net/ethernet/intel/igb/igb_ptp.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 +
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_clock.c | 1 +
drivers/net/ethernet/neterion/vxge/vxge-main.c | 1 +
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 1 +
drivers/net/ethernet/sfc/ef10.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
drivers/net/ethernet/ti/cpsw.c | 1 +
drivers/net/ethernet/tile/tilegx.c | 1 +
net/core/dev_ioctl.c | 1 +
18 files changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index c772420..89b21d7 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -1268,6 +1268,7 @@ static int xgbe_set_hwtstamp_settings(struct xgbe_prv_data *pdata,
case HWTSTAMP_FILTER_NONE:
break;
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
XGMAC_SET_BITS(mac_tscr, MAC_TSCR, TSENALL, 1);
XGMAC_SET_BITS(mac_tscr, MAC_TSCR, TSENA, 1);
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index a851f95..2f30b1a 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -15351,6 +15351,7 @@ int bnx2x_configure_ptp_filters(struct bnx2x *bp)
break;
case HWTSTAMP_FILTER_ALL:
case HWTSTAMP_FILTER_SOME:
+ case HWTSTAMP_FILTER_NTP_ALL:
bp->rx_filter = HWTSTAMP_FILTER_NONE;
break;
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 927617c..7a0ef5b 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -3020,6 +3020,7 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
conf.rx_filter = HWTSTAMP_FILTER_ALL;
break;
default:
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
index 34c7782..15e21b5 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
@@ -2100,6 +2100,7 @@ static int hwtstamp_ioctl(struct net_device *netdev, struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
conf.rx_filter = HWTSTAMP_FILTER_ALL;
break;
default:
diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index a213868..2887bca 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -755,6 +755,7 @@ static int octeon_mgmt_ioctl_hwtstamp(struct net_device *netdev,
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
p->has_rx_tstamp = have_hw_timestamps;
config.rx_filter = HWTSTAMP_FILTER_ALL;
if (p->has_rx_tstamp) {
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 667fc45..940a79e 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3668,6 +3668,7 @@ static int e1000e_config_hwtstamp(struct e1000_adapter *adapter,
* Delay Request messages but not both so fall-through to
* time stamp all packets.
*/
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
is_l2 = true;
is_l4 = true;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index 2caee35..198b770 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -562,6 +562,7 @@ static int i40e_ptp_set_timestamp_mode(struct i40e_pf *pf,
config->rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT;
}
break;
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
default:
return -ERANGE;
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index 7a3fd4d..d333d6d 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -941,6 +941,7 @@ static int igb_ptp_set_timestamp_mode(struct igb_adapter *adapter,
is_l4 = true;
break;
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
/* 82576 cannot timestamp all packets, which it needs to do to
* support both V1 Sync and Delay_Req messages
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index ef0635e..d44c728 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -883,6 +883,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,
IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER);
break;
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
/* The X550 controller is capable of timestamping all packets,
* which allows it to accept any filter.
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 94fab20..8243674 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -2375,6 +2375,7 @@ static int mlx4_en_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
config.rx_filter = HWTSTAMP_FILTER_ALL;
break;
default:
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
index e706a87..e294944 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_clock.c
@@ -128,6 +128,7 @@ int mlx5e_hwstamp_set(struct net_device *dev, struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
/* Disable CQE compression */
netdev_warn(dev, "Disabling cqe compression");
err = mlx5e_modify_rx_cqe_compression_locked(priv, false);
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-main.c b/drivers/net/ethernet/neterion/vxge/vxge-main.c
index 6a4310a..50ea69d 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-main.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-main.c
@@ -3218,6 +3218,7 @@ static int vxge_hwtstamp_set(struct vxgedev *vdev, void __user *data)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
if (vdev->devh->config.hwts_en != VXGE_HW_HWTS_ENABLE)
return -EFAULT;
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.c b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
index 2e62dec..e977745 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
@@ -250,6 +250,7 @@ static int qede_ptp_cfg_filters(struct qede_dev *edev)
break;
case HWTSTAMP_FILTER_ALL:
case HWTSTAMP_FILTER_SOME:
+ case HWTSTAMP_FILTER_NTP_ALL:
ptp->rx_filter = HWTSTAMP_FILTER_NONE;
break;
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 78efb28..ad9c4de 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -6068,6 +6068,7 @@ static int efx_ef10_ptp_set_ts_config(struct efx_nic *efx,
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
init->rx_filter = HWTSTAMP_FILTER_ALL;
rc = efx_ptp_change_mode(efx, true, 0);
if (!rc)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index cd8c601..3115700 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -644,6 +644,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, struct ifreq *ifr)
ptp_over_ethernet = PTP_TCR_TSIPENA;
break;
+ case HWTSTAMP_FILTER_NTP_ALL:
case HWTSTAMP_FILTER_ALL:
/* time stamp any incoming packet */
config.rx_filter = HWTSTAMP_FILTER_ALL;
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fa674a8..8da70fa 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1718,6 +1718,7 @@ static int cpsw_hwtstamp_set(struct net_device *dev, struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
case HWTSTAMP_FILTER_PTP_V1_L4_SYNC:
case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
return -ERANGE;
case HWTSTAMP_FILTER_PTP_V2_L4_EVENT:
case HWTSTAMP_FILTER_PTP_V2_L4_SYNC:
diff --git a/drivers/net/ethernet/tile/tilegx.c b/drivers/net/ethernet/tile/tilegx.c
index 7c634bc..aec9538 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net/ethernet/tile/tilegx.c
@@ -512,6 +512,7 @@ static int tile_hwtstamp_set(struct net_device *dev, struct ifreq *rq)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
config.rx_filter = HWTSTAMP_FILTER_ALL;
break;
default:
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index b94b1d2..77f04e7 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -225,6 +225,7 @@ static int net_hwtstamp_validate(struct ifreq *ifr)
case HWTSTAMP_FILTER_PTP_V2_EVENT:
case HWTSTAMP_FILTER_PTP_V2_SYNC:
case HWTSTAMP_FILTER_PTP_V2_DELAY_REQ:
+ case HWTSTAMP_FILTER_NTP_ALL:
rx_filter_valid = 1;
break;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 4/6] net: don't make false software transmit timestamps
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
If software timestamping is enabled by the SO_TIMESTAMP(NS) option
when a message without timestamp is already waiting in the queue, the
__sock_recv_timestamp() function will read the current time to make a
timestamp in order to always have something for the application.
However, this applies also to outgoing packets looped back to the error
queue when hardware timestamping is enabled by the SO_TIMESTAMPING
option. A software transmit timestamp made after the actual transmission
is added to messages with hardware timestamps.
Modify the function to save the current time as a software timestamp
only if it's for a received packet (i.e. it's not in the error queue).
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
net/socket.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index 5ea5f29..68b9304 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -688,7 +688,8 @@ static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb)
void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
struct sk_buff *skb)
{
- int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
+ int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP) &&
+ !skb_is_err_queue(skb);
struct scm_timestamping tss;
int empty = 1;
struct skb_shared_hwtstamps *shhwtstamps =
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 1/6] net: define receive timestamp filter for NTP
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
Add HWTSTAMP_FILTER_NTP_ALL to the hwtstamp_rx_filters enum for
timestamping of NTP packets. There is currently only one driver
(phyter) that could support it directly.
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
include/uapi/linux/net_tstamp.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 464dcca..0749fb1 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -125,6 +125,9 @@ enum hwtstamp_rx_filters {
HWTSTAMP_FILTER_PTP_V2_SYNC,
/* PTP v2/802.AS1, any layer, Delay_req packet */
HWTSTAMP_FILTER_PTP_V2_DELAY_REQ,
+
+ /* NTP, UDP, all versions and packet modes */
+ HWTSTAMP_FILTER_NTP_ALL,
};
#endif /* _NET_TIMESTAMPING_H */
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 3/6] net: add new control message for incoming HW-timestamped packets
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170426145035.25846-1-mlichvar@redhat.com>
Add SOF_TIMESTAMPING_OPT_PKTINFO option to request a new control message
for incoming packets with hardware timestamps. It contains the index of
the real interface which received the packet and the length of the
packet at layer 2.
The index is useful with bonding, bridges and other interfaces, where
IP_PKTINFO doesn't allow applications to determine which PHC made the
timestamp. With the L2 length (and link speed) it is possible to
transpose preamble timestamps to trailer timestamps, which are used in
the NTP protocol.
While this information could be provided by two new socket options
independently from timestamping, it doesn't look like it would be very
useful. With this option any performance impact is limited to hardware
timestamping.
As skb currently has no field for the original interface index, use
napi_id to look up the device and its index. This limits the option to
kernels with enabled CONFIG_NET_RX_BUSY_POLL and drivers using napi,
which should cover all current MAC drivers that support hardware
timestamping.
CC: Richard Cochran <richardcochran@gmail.com>
CC: Willem de Bruijn <willemb@google.com>
Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
---
Documentation/networking/timestamping.txt | 8 ++++++++
include/linux/netdevice.h | 1 +
include/uapi/asm-generic/socket.h | 2 ++
include/uapi/linux/net_tstamp.h | 9 ++++++++-
net/core/dev.c | 18 ++++++++++++++++++
net/socket.c | 26 +++++++++++++++++++++++++-
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 96f5069..6c07e7c 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -193,6 +193,14 @@ SOF_TIMESTAMPING_OPT_STATS:
the transmit timestamps, such as how long a certain block of
data was limited by peer's receiver window.
+SOF_TIMESTAMPING_OPT_PKTINFO:
+
+ Enable the SCM_TIMESTAMPING_PKTINFO control message for incoming
+ packets with hardware timestamps. The message contains struct
+ scm_ts_pktinfo, which supplies the index of the real interface
+ which received the packet and its length at layer 2. This option
+ works only if CONFIG_NET_RX_BUSY_POLL is enabled.
+
New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to
disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate
regardless of the setting of sysctl net.core.tstamp_allow_data.
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8c5c8cd..c7ce189 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2451,6 +2451,7 @@ static inline int dev_recursion_level(void)
struct net_device *dev_get_by_index(struct net *net, int ifindex);
struct net_device *__dev_get_by_index(struct net *net, int ifindex);
struct net_device *dev_get_by_index_rcu(struct net *net, int ifindex);
+struct net_device *dev_get_by_napi_id(unsigned int napi_id);
int netdev_get_name(struct net *net, char *name, int ifindex);
int dev_restart(struct net_device *dev);
int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb);
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 2b48856..a5f6e81 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -100,4 +100,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/include/uapi/linux/net_tstamp.h b/include/uapi/linux/net_tstamp.h
index 0749fb1..8fcae35 100644
--- a/include/uapi/linux/net_tstamp.h
+++ b/include/uapi/linux/net_tstamp.h
@@ -26,8 +26,9 @@ enum {
SOF_TIMESTAMPING_OPT_CMSG = (1<<10),
SOF_TIMESTAMPING_OPT_TSONLY = (1<<11),
SOF_TIMESTAMPING_OPT_STATS = (1<<12),
+ SOF_TIMESTAMPING_OPT_PKTINFO = (1<<13),
- SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_STATS,
+ SOF_TIMESTAMPING_LAST = SOF_TIMESTAMPING_OPT_PKTINFO,
SOF_TIMESTAMPING_MASK = (SOF_TIMESTAMPING_LAST - 1) |
SOF_TIMESTAMPING_LAST
};
@@ -130,4 +131,10 @@ enum hwtstamp_rx_filters {
HWTSTAMP_FILTER_NTP_ALL,
};
+/* SCM_TIMESTAMPING_PKTINFO control message */
+struct scm_ts_pktinfo {
+ int if_index;
+ int pkt_length;
+};
+
#endif /* _NET_TIMESTAMPING_H */
diff --git a/net/core/dev.c b/net/core/dev.c
index 1b3317c..0a78f7f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -160,6 +160,7 @@ static int netif_rx_internal(struct sk_buff *skb);
static int call_netdevice_notifiers_info(unsigned long val,
struct net_device *dev,
struct netdev_notifier_info *info);
+static struct napi_struct *napi_by_id(unsigned int napi_id);
/*
* The @dev_base_head list is protected by @dev_base_lock and the rtnl
@@ -863,6 +864,23 @@ struct net_device *dev_get_by_index(struct net *net, int ifindex)
}
EXPORT_SYMBOL(dev_get_by_index);
+struct net_device *dev_get_by_napi_id(unsigned int napi_id)
+{
+ struct net_device *dev = NULL;
+ struct napi_struct *napi;
+
+ rcu_read_lock();
+
+ napi = napi_by_id(napi_id);
+ if (napi)
+ dev = napi->dev;
+
+ rcu_read_unlock();
+
+ return dev;
+}
+EXPORT_SYMBOL(dev_get_by_napi_id);
+
/**
* netdev_get_name - get a netdevice name, knowing its ifindex.
* @net: network namespace
diff --git a/net/socket.c b/net/socket.c
index c2564eb..5ea5f29 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -662,6 +662,26 @@ static bool skb_is_err_queue(const struct sk_buff *skb)
return skb->pkt_type == PACKET_OUTGOING;
}
+static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb)
+{
+#ifdef CONFIG_NET_RX_BUSY_POLL
+ struct scm_ts_pktinfo ts_pktinfo;
+ struct net_device *orig_dev;
+
+ if (skb->napi_id < MIN_NAPI_ID || !skb_mac_header_was_set(skb))
+ return;
+
+ orig_dev = dev_get_by_napi_id(skb->napi_id);
+ if (!orig_dev)
+ return;
+
+ ts_pktinfo.if_index = orig_dev->ifindex;
+ ts_pktinfo.pkt_length = skb->len - skb_mac_offset(skb);
+ put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
+ sizeof(ts_pktinfo), &ts_pktinfo);
+#endif
+}
+
/*
* called from sock_recv_timestamp() if sock_flag(sk, SOCK_RCVTSTAMP)
*/
@@ -699,8 +719,12 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
empty = 0;
if (shhwtstamps &&
(sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
- ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2))
+ ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2)) {
empty = 0;
+ if ((sk->sk_tsflags & SOF_TIMESTAMPING_OPT_PKTINFO) &&
+ !skb_is_err_queue(skb))
+ put_ts_pktinfo(msg, skb);
+ }
if (!empty) {
put_cmsg(msg, SOL_SOCKET,
SCM_TIMESTAMPING, sizeof(tss), &tss);
--
2.9.3
^ permalink raw reply related
* [PATCH v1 net-next 0/6] Extend socket timestamping API
From: Miroslav Lichvar @ 2017-04-26 14:50 UTC (permalink / raw)
To: netdev
Cc: Richard Cochran, Willem de Bruijn, Soheil Hassas Yeganeh,
Keller, Jacob E, Denny Page, Jiri Benc
Changes RFC->v1:
- reworked SOF_TIMESTAMPING_OPT_PKTINFO patch to not add new fields to
skb shared info (net device is now looked up by napi_id), not require
any changes in drivers, and restrict the cmsg to incoming packets
- renamed SOF_TIMESTAMPING_OPT_MULTIMSG to SOF_TIMESTAMPING_OPT_TX_SWHW
and fixed its description
- moved struct scm_ts_pktinfo from errqueue.h to net_tstamp.h as it
can't be received from the error queue anymore
- improved commit descriptions and removed incorrect comment
This patchset adds new options to the timestamping API that will be
useful for NTP implementations and possibly other applications.
The first patch specifies a timestamp filter for NTP packets. The second
patch updates drivers that can timestamp all packets, or need to list
the filter as unsupported. There is no attempt to add the support to the
phyter driver.
The third patch adds a new option to get a new control message with the
L2 length and interface index for incoming packets with hardware
timestamps.
The fourth patch fixes the code to not make a false software TX
timestamp when hardware timestamping is enabled. The fifth patch depends
on this fix.
The fifth patch adds a new option to request both software and hardware
timestamps for outgoing packets. The sixth patch updates drivers that
assumed software timestamping cannot be used together with hardware
timestamping.
The patches have been tested on x86_64 machines with igb and e1000e
drivers.
Miroslav Lichvar (6):
net: define receive timestamp filter for NTP
net: ethernet: update drivers to handle HWTSTAMP_FILTER_NTP_ALL
net: add new control message for incoming HW-timestamped packets
net: don't make false software transmit timestamps
net: allow simultaneous SW and HW transmit timestamping
net: ethernet: update drivers to make both SW and HW TX timestamps
Documentation/networking/timestamping.txt | 22 ++++++++++++++--
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 4 +--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 1 +
drivers/net/ethernet/cavium/liquidio/lio_main.c | 1 +
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 1 +
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 1 +
drivers/net/ethernet/intel/e1000e/netdev.c | 5 ++--
drivers/net/ethernet/intel/i40e/i40e_ptp.c | 1 +
drivers/net/ethernet/intel/igb/igb_ptp.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 1 +
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_clock.c | 1 +
drivers/net/ethernet/neterion/vxge/vxge-main.c | 1 +
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 1 +
drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 3 +--
drivers/net/ethernet/sfc/ef10.c | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++--
drivers/net/ethernet/ti/cpsw.c | 1 +
drivers/net/ethernet/tile/tilegx.c | 1 +
include/linux/netdevice.h | 1 +
include/linux/skbuff.h | 3 +--
include/uapi/asm-generic/socket.h | 2 ++
include/uapi/linux/net_tstamp.h | 13 +++++++++-
net/core/dev.c | 18 +++++++++++++
net/core/dev_ioctl.c | 1 +
net/core/skbuff.c | 4 +++
net/socket.c | 30 ++++++++++++++++++++--
27 files changed, 110 insertions(+), 17 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next v8 2/3] net sched actions: dump more than TCA_ACT_MAX_PRIO actions per batch
From: David Miller @ 2017-04-26 14:46 UTC (permalink / raw)
To: jiri; +Cc: jhs, simon.horman, xiyou.wangcong, eric.dumazet, netdev
In-Reply-To: <20170426130506.GF1867@nanopsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 26 Apr 2017 15:05:06 +0200
> Wed, Apr 26, 2017 at 02:46:22PM CEST, jhs@mojatatu.com wrote:
>>On 17-04-26 07:02 AM, Simon Horman wrote:
>>> On Tue, Apr 25, 2017 at 06:04:45PM +0200, Jiri Pirko wrote:
>>[..]
>>
>>> > So fix iproute2. It is always first kernel, then iproute2.
>>>
>>> Perhaps I am missing the point or somehow misguided but I would expect that
>>> if the UAPI uses BIT() it also provides BIT().
>>
>>There is a user of BIT() already in iproute2 (devlink). We can move
>>the code to be more generally available for other iproute2 users.
>>Then this UAPI change makes use of it.
>
> Should be part of UAPI as well
> I see that include/uapi/rdma/vmw_pvrdma-abi.h is using BIT macro.
> I don't see BIT macro defined in UAPI (I thought it is). So either
> define it there (not sure where) or just use "<<"
"BIT" is a pretty crazy small simple name to pollute into the global
namespace, IMHO.
^ permalink raw reply
* Re: net/ipv6: use-after-free in __call_rcu/in6_dev_finish_destroy_rcu
From: Andrey Konovalov @ 2017-04-26 14:45 UTC (permalink / raw)
To: Paul E. McKenney
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML, Josh Triplett,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Eric Dumazet,
Cong Wang, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <20170426135950.GO3956@linux.vnet.ibm.com>
On Wed, Apr 26, 2017 at 3:59 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Wed, Apr 26, 2017 at 02:34:15PM +0200, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while fuzzing the kernel with syzkaller.
>>
>> On commit 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).
>>
>> Unfortunately it's not reproducible.
>>
>> I'm not sure whether is is an issue with rcu or ipv6.
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in __call_rcu.constprop.77+0x13be/0x1640
>
> Does building with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y show any splats?
> (Yeah, kind of a stupid question if it is not reproducible, but had
> to ask!)
Hi Paul,
I'll try enabling this config.
In the meantime, while I was trying to reproduce this issue, I got this warning:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4590 at kernel/rcu/tree.c:2919
rcu_do_batch.isra.65+0x845/0xbd0
Modules linked in:
CPU: 0 PID: 4590 Comm: syz-executor Not tainted 4.11.0-rc8+ #270
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:16
dump_stack+0x192/0x22d lib/dump_stack.c:52
__warn+0x19f/0x1e0 kernel/panic.c:549
warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
rcu_do_batch.isra.65+0x845/0xbd0 kernel/rcu/tree.c:2919
invoke_rcu_callbacks kernel/rcu/tree.c:3142
__rcu_process_callbacks kernel/rcu/tree.c:3109
rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
__do_softirq+0x253/0x78b kernel/softirq.c:284
invoke_softirq kernel/softirq.c:364
irq_exit+0x149/0x180 kernel/softirq.c:405
exiting_irq ./arch/x86/include/asm/apic.h:657
smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
apic_timer_interrupt+0x89/0x90
RIP: 0010:do_anonymous_page mm/memory.c:2962
RIP: 0010:handle_pte_fault mm/memory.c:3721
RIP: 0010:__handle_mm_fault+0xdab/0x1c00 mm/memory.c:3841
RSP: 0018:ffff88006a02f7d0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
RAX: 000000000005dab0 RBX: 1ffff1000d405f00 RCX: 1ffff1000d28cd3f
RDX: dffffc0000000000 RSI: 8000000000000025 RDI: ffff8800694669f8
RBP: ffff88006a02f9a8 R08: 00000000014280ca R09: 1ffff1000d405eb0
R10: ffff88006a02f660 R11: dffffc0000000000 R12: ffff88006a02f8e0
R13: ffff88006a02f980 R14: ffff8800694669b0 R15: ffff880069466a00
</IRQ>
handle_mm_fault+0x1aa/0x450 mm/memory.c:3878
faultin_page mm/gup.c:408
__get_user_pages+0x606/0x14a0 mm/gup.c:607
populate_vma_page_range+0xd9/0x100 mm/gup.c:1062
__mm_populate+0x278/0x540 mm/gup.c:1112
mm_populate ./include/linux/mm.h:2132
vm_mmap_pgoff+0x258/0x280 mm/util.c:314
SYSC_mmap_pgoff mm/mmap.c:1503
SyS_mmap_pgoff+0x22c/0x5e0 mm/mmap.c:1461
SYSC_mmap arch/x86/kernel/sys_x86_64.c:96
SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:87
entry_SYSCALL_64_fastpath+0x1a/0xa9 arch/x86/entry/entry_64.S:204
RIP: 0033:0x4458e9
RSP: 002b:00007f3a15ce4b58 EFLAGS: 00000282 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 00007f3a15ce5700 RCX: 00000000004458e9
RDX: 0000000000000002 RSI: 00000000009b8000 RDI: 0000000020000000
RBP: 0000000000000000 R08: ffffffffffffffff R09: 8000000000000000
R10: 0000000000008032 R11: 0000000000000282 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f3a15ce59c0 R15: 00007f3a15ce5700
---[ end trace e36457085170396e ]---
>
> Thanx, Paul
>
>> kernel/rcu/tree.c:3269 at addr ffff88003b842280
>> Write of size 8 by task kworker/u10:1/180
>> CPU: 2 PID: 180 Comm: kworker/u10:1 Not tainted 4.11.0-rc8+ #270
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Workqueue: events_unbound call_usermodehelper_exec_work
>> Call Trace:
>> __dump_stack lib/dump_stack.c:16 [inline]
>> dump_stack+0x192/0x22d lib/dump_stack.c:52
>> kasan_object_err+0x1c/0x70 mm/kasan/report.c:164
>> print_address_description mm/kasan/report.c:202 [inline]
>> kasan_report_error mm/kasan/report.c:291 [inline]
>> kasan_report+0x252/0x510 mm/kasan/report.c:347
>> __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:373
>> __call_rcu.constprop.77+0x13be/0x1640 kernel/rcu/tree.c:3269
>> call_rcu_sched+0x12/0x20 kernel/rcu/tree.c:3288
>> free_pid+0x446/0x5d0 kernel/pid.c:293
>> __change_pid+0x2a1/0x3d0 kernel/pid.c:411
>> detach_pid+0x1f/0x30 kernel/pid.c:416
>> __unhash_process kernel/exit.c:74 [inline]
>> __exit_signal kernel/exit.c:155 [inline]
>> release_task+0xbb0/0x1d90 kernel/exit.c:199
>> wait_task_zombie kernel/exit.c:1230 [inline]
>> wait_consider_task+0x11fe/0x3410 kernel/exit.c:1458
>> do_wait_thread kernel/exit.c:1521 [inline]
>> do_wait+0x3ea/0x8e0 kernel/exit.c:1592
>> SYSC_wait4 kernel/exit.c:1720 [inline]
>> SyS_wait4+0x208/0x340 kernel/exit.c:1689
>> call_usermodehelper_exec_sync kernel/kmod.c:292 [inline]
>> call_usermodehelper_exec_work+0x1a7/0x2b0 kernel/kmod.c:329
>> process_one_work+0x9f7/0x1580 kernel/workqueue.c:2097
>> worker_thread+0x1df/0x14b0 kernel/workqueue.c:2231
>> kthread+0x31f/0x3f0 kernel/kthread.c:231
>> ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
>> Object at ffff88003b842018, in cache kmalloc-1024 size: 1024
>> Allocated:
>> PID = 1
>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>> set_track mm/kasan/kasan.c:525 [inline]
>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:616
>> kmem_cache_alloc_trace+0x61/0x170 mm/slub.c:2745
>> kmalloc include/linux/slab.h:490 [inline]
>> kzalloc include/linux/slab.h:663 [inline]
>> ipv6_add_dev+0x199/0x1380 net/ipv6/addrconf.c:380
>> addrconf_init+0xd0/0x29a net/ipv6/addrconf.c:6405
>> inet6_init+0x2f6/0x584 net/ipv6/af_inet6.c:962
>> do_one_initcall+0xf3/0x380 init/main.c:792
>> do_initcall_level init/main.c:858 [inline]
>> do_initcalls init/main.c:866 [inline]
>> do_basic_setup init/main.c:884 [inline]
>> kernel_init_freeable+0x54d/0x622 init/main.c:1035
>> kernel_init+0x13/0x180 init/main.c:959
>> ret_from_fork+0x2c/0x40 arch/x86/entry/entry_64.S:430
>> Freed:
>> PID = 6479
>> save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:513
>> set_track mm/kasan/kasan.c:525 [inline]
>> kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:589
>> slab_free_hook mm/slub.c:1357 [inline]
>> slab_free_freelist_hook mm/slub.c:1379 [inline]
>> slab_free mm/slub.c:2961 [inline]
>> kfree+0x91/0x190 mm/slub.c:3882
>> in6_dev_finish_destroy_rcu+0x97/0xc0 net/ipv6/addrconf_core.c:150
>> __rcu_reclaim kernel/rcu/rcu.h:118 [inline]
>> rcu_do_batch.isra.65+0x6de/0xbd0 kernel/rcu/tree.c:2879
>> invoke_rcu_callbacks kernel/rcu/tree.c:3142 [inline]
>> __rcu_process_callbacks kernel/rcu/tree.c:3109 [inline]
>> rcu_process_callbacks+0x23f/0x810 kernel/rcu/tree.c:3126
>> __do_softirq+0x253/0x78b kernel/softirq.c:284
>> Memory state around the buggy address:
>> ffff88003b842180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88003b842200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> >ffff88003b842280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ^
>> ffff88003b842300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff88003b842380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>>
>
^ permalink raw reply
* Re: [oss-drivers] Re: [RFC 3/4] nfp: make use of extended ack message reporting
From: David Miller @ 2017-04-26 14:44 UTC (permalink / raw)
To: simon.horman
Cc: jhs, jakub.kicinski, netdev, johannes, dsa, daniel,
alexei.starovoitov, bblanco, john.fastabend, kubakici,
oss-drivers
In-Reply-To: <20170426111315.GC28251@vergenet.net>
From: Simon Horman <simon.horman@netronome.com>
Date: Wed, 26 Apr 2017 13:13:16 +0200
> On Tue, Apr 25, 2017 at 10:20:22AM -0400, David Miller wrote:
>> From: Jamal Hadi Salim <jhs@mojatatu.com>
>> Date: Tue, 25 Apr 2017 08:42:32 -0400
>>
>> > So are we going to standardize these strings?
>>
>> No.
>>
>> > i.e what if some user has written a bash script that depends on this
>> > string and it gets changed later.
>>
>> They can't do that.
>>
>> It's free form extra information an application may or not provide
>> to the user when the kernel emits it.
>
> I don't feel strongly about this and perhaps it can be revisited at some
> point but perhaps it would be worth documenting that he strings do not
> form part of the UAPI as my expectation would have been that they do f.e. to
> facilitate internationalisation.
These two things are entirely separate.
We can maintain uptodate translations of the strings, yet document that
they can change at any time and are thus not UAPI.
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Honggang LI @ 2017-04-26 14:44 UTC (permalink / raw)
To: Doug Ledford
Cc: Paolo Abeni, Or Gerlitz, Erez Shitrit, Erez Shitrit,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List, David Miller
In-Reply-To: <1493216704.3041.115.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Apr 26, 2017 at 10:25:04AM -0400, Doug Ledford wrote:
> On Wed, 2017-04-26 at 22:11 +0800, Honggang LI wrote:
> > On Wed, Apr 26, 2017 at 09:50:38AM -0400, Doug Ledford wrote:
> > >
> > > On Wed, 2017-04-26 at 09:48 -0400, Doug Ledford wrote:
> > > >
> > > > On Wed, 2017-04-26 at 21:33 +0800, Honggang LI wrote:
> > > > >
> > > > >
> > > > > Yes, it is during the process of removing the final slave. The
> > > > > reproducer looks like this:
> > > > >
> > > > > ping remote_ip_over_bonding_interface &
> > > > > while 1; do
> > > > > ifdown bond0
> > > > > ifup bond0
> > > > > done
> > >
> > > BTW, rerunning your test as:
> > >
> > > ping remote_ip_over_bonding_interface &
> > > while 1; do
> > > echo -n "Downing interface..."
> > > ifdown bond0
> >
> > Confirmed panic in here.
>
> OK, this leads me to suspect that the bonding driver is possibly
> reconfiguring the skb setup to Ethernet mode before the last slave is
> fully dropped from the bond, and so the slave is seeing a packet to its
> hard header routine with the wrong headroom. I think Paolo's patch is
> probably the best way to go. The reason I say that is because we can't
> definitively say that this is the only pathway we will ever see that
> causes us to get a packet with Ethernet headroom on our IPoIB
> interface, and Paolo's patch gives us the possibility of recovering and
> sending the packet out. Even in this case, we are downing the
> interface, but it isn't down entirely yet, so sending the packet out
Sending packet out over a removing interface looks bad. I'd like to drop
backlog packet.
> isn't necessarily wrong. So a method of fix that allows us to
> recover/continue seems preferable to me. Can you test Paolo's patch
> and see if it resolves the problem?
Yes, Paolo's patch fixes the panic issue too. But it seems has side
effort. For example:
520 struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
.....
538 return NULL;
539
540 skb_reserve(skb, hlen);
541 skb_reset_network_header(skb); <-- it update skb->network_header
But skb_cow_head seems does not touch skb->network_header. I have to say
I did not test the network_header.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 net-next]smsc911x: Adding support for Micochip LAN9250 Ethernet controller
From: Andrew Lunn @ 2017-04-26 14:34 UTC (permalink / raw)
To: David.Cai; +Cc: netdev, davem, UNGLinuxDriver, steve.glendinning
In-Reply-To: <C3C28FB10418274EB7FD7C2B85C796A441247573@CHN-SV-EXMX02.mchp-main.com>
On Wed, Apr 26, 2017 at 01:55:52PM +0000, David.Cai@microchip.com wrote:
> From: David Cai <david.cai@microchip.com>
>
> Adding support for Microchip LAN9250 Ethernet controller.
>
> Signed-off-by: David Cai <david.cai@microchip.com>
> ---
> Changes
> V2
> - email format changed
> - remove unnecessary text in commit log Changes
> V3
> - defined all supported Ethernet controller chip ID.
> - removed pdata->sub_generation = 0;
> - changed 'if (pdata->sub_generation)' to
> if (pdata>generation == 4 && pdata->sub_generation)
>
> drivers/net/ethernet/smsc/smsc911x.c | 55 ++++++++++++++++++++++++------------
> drivers/net/ethernet/smsc/smsc911x.h | 19 +++++++++++++
> 2 files changed, 56 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
> index fa5ca09..e35fe96 100644
> --- a/drivers/net/ethernet/smsc/smsc911x.c
> +++ b/drivers/net/ethernet/smsc/smsc911x.c
> @@ -25,7 +25,7 @@
> * LAN9215, LAN9216, LAN9217, LAN9218
> * LAN9210, LAN9211
> * LAN9220, LAN9221
> - * LAN89218
> + * LAN89218,LAN9250
> *
> */
>
> @@ -104,6 +104,9 @@ struct smsc911x_data {
> /* used to decide which workarounds apply */
> unsigned int generation;
>
> + /* used to decide which sub generation product work arounds to apply */
> + unsigned int sub_generation;
> +
> /* device configuration (copied from platform_data during probe) */
> struct smsc911x_platform_config config;
>
> @@ -1450,6 +1453,8 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
> unsigned int timeout;
> unsigned int temp;
> int ret;
> + unsigned int reset_offset = HW_CFG;
> + unsigned int reset_mask = HW_CFG_SRST_;
>
> /*
> * Make sure to power-up the PHY chip before doing a reset, otherwise @@ -1476,15 +1481,23 @@ static int smsc911x_soft_reset(struct smsc911x_data *pdata)
> }
> }
>
> + if (pdata->generation == 4 && pdata->sub_generation) {
> + /* special reset for LAN9250 */
> + reset_offset = RESET_CTL;
> + reset_mask = RESET_CTL_DIGITAL_RST_;
> + }
Hi David
Thanks for adding the chip ID #defines. But the point of doing that is
that you can then change this above to:
if (pdata->idrev & 0xFFFF0000 == LAN9250) {
reset_offset = RESET_CTL;
reset_mask = RESET_CTL_DIGITAL_RST_;
}
which is much more readable.
Andrew
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Doug Ledford @ 2017-04-26 14:25 UTC (permalink / raw)
To: Honggang LI
Cc: Paolo Abeni, Or Gerlitz, Erez Shitrit, Erez Shitrit,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List, David Miller
In-Reply-To: <20170426141139.GA14635-Y5OA6DF/u0nid9cnFhDO8BcY2uh10dtjAL8bYrjMMd8@public.gmane.org>
On Wed, 2017-04-26 at 22:11 +0800, Honggang LI wrote:
> On Wed, Apr 26, 2017 at 09:50:38AM -0400, Doug Ledford wrote:
> >
> > On Wed, 2017-04-26 at 09:48 -0400, Doug Ledford wrote:
> > >
> > > On Wed, 2017-04-26 at 21:33 +0800, Honggang LI wrote:
> > > >
> > > >
> > > > Yes, it is during the process of removing the final slave. The
> > > > reproducer looks like this:
> > > >
> > > > ping remote_ip_over_bonding_interface &
> > > > while 1; do
> > > > ifdown bond0
> > > > ifup bond0
> > > > done
> >
> > BTW, rerunning your test as:
> >
> > ping remote_ip_over_bonding_interface &
> > while 1; do
> > echo -n "Downing interface..."
> > ifdown bond0
>
> Confirmed panic in here.
OK, this leads me to suspect that the bonding driver is possibly
reconfiguring the skb setup to Ethernet mode before the last slave is
fully dropped from the bond, and so the slave is seeing a packet to its
hard header routine with the wrong headroom. I think Paolo's patch is
probably the best way to go. The reason I say that is because we can't
definitively say that this is the only pathway we will ever see that
causes us to get a packet with Ethernet headroom on our IPoIB
interface, and Paolo's patch gives us the possibility of recovering and
sending the packet out. Even in this case, we are downing the
interface, but it isn't down entirely yet, so sending the packet out
isn't necessarily wrong. So a method of fix that allows us to
recover/continue seems preferable to me. Can you test Paolo's patch
and see if it resolves the problem?
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 net-next] bridge: add per-port broadcast flood flag
From: Nikolay Aleksandrov @ 2017-04-26 14:19 UTC (permalink / raw)
To: Mike Manning, netdev
In-Reply-To: <1493214489-9921-1-git-send-email-mmanning@brocade.com>
On 26/04/17 16:48, Mike Manning wrote:
> Support for l2 multicast flood control was added in commit b6cb5ac8331b
> ("net: bridge: add per-port multicast flood flag"). It allows broadcast
> as it was introduced specifically for unknown multicast flood control.
> But as broadcast is a special case of multicast, this may also need to
> be disabled. For this purpose, introduce a flag to disable the flooding
> of received l2 broadcasts. This approach is backwards compatible and
> provides flexibility in filtering for the desired packet types.
>
> Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: Mike Manning <mmanning@brocade.com>
> ---
> include/linux/if_bridge.h | 1 +
> include/uapi/linux/if_link.h | 1 +
> net/bridge/br_forward.c | 24 +++++++++++++++++-------
> net/bridge/br_if.c | 2 +-
> net/bridge/br_netlink.c | 3 +++
> net/bridge/br_sysfs_if.c | 2 ++
> 6 files changed, 25 insertions(+), 8 deletions(-)
>
Thank you, now we can control all types.
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: net/tcp: warning in tcp_try_coalesce/skb_try_coalesce
From: Eric Dumazet @ 2017-04-26 14:16 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, LKML, Dmitry Vyukov, Kostya Serebryany,
syzkaller
In-Reply-To: <CAAeHK+yQJUuuv2XM6tQuaE12Zo1htujz6A7Qd_h+E9qCVEwDSg@mail.gmail.com>
On Wed, Apr 26, 2017 at 5:08 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Tue, Jan 31, 2017 at 2:17 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer.
>>
>> On commit 566cf877a1fcb6d6dc0126b076aad062054c2637 (4.10-rc6).
>>
>> The fuzzer hits this issue quite often, but I don't have a working reproducer.
>
> I still see this on 5a7ad1146caa895ad718a534399e38bd2ba721b7 (4.11-rc8).
>
> I also have a reproducer now, attached.
>
> It takes around 10 seconds for the warning to trigger.
>
It does not trigger for me, but seeing that you use SO_ATTACH_FILTER,
I have a pretty good idea how to remove this splat.
A call to skb_condense() from ___pskb_trim() will likely help, I will
post a patch after my commute.
Thanks.
^ permalink raw reply
* Re: [PATCH] IB/IPoIB: Check the headroom size
From: Honggang LI @ 2017-04-26 14:11 UTC (permalink / raw)
To: Doug Ledford
Cc: Paolo Abeni, Or Gerlitz, Erez Shitrit, Erez Shitrit,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Netdev List, David Miller
In-Reply-To: <1493214638.3041.110.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wed, Apr 26, 2017 at 09:50:38AM -0400, Doug Ledford wrote:
> On Wed, 2017-04-26 at 09:48 -0400, Doug Ledford wrote:
> > On Wed, 2017-04-26 at 21:33 +0800, Honggang LI wrote:
> > >
> > > Yes, it is during the process of removing the final slave. The
> > > reproducer looks like this:
> > >
> > > ping remote_ip_over_bonding_interface &
> > > while 1; do
> > > ifdown bond0
> > > ifup bond0
> > > done
>
> BTW, rerunning your test as:
>
> ping remote_ip_over_bonding_interface &
> while 1; do
> echo -n "Downing interface..."
> ifdown bond0
Confirmed panic in here.
> echo "done."
> sleep 1
> echo -n "Bringing interface up..."
> ifup bond0
> echo "done."
> done
>
> will allow you to more precisely identify whether the failure is during
> the down or the up of the interface.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net v3 2/3] net: hns: support deferred probe when no mdio
From: Matthias Brugger @ 2017-04-26 14:07 UTC (permalink / raw)
To: Yankejian, davem, salil.mehta, yisen.zhuang, lipeng321, zhouhuiru,
huangdaode
Cc: netdev, linuxarm
In-Reply-To: <1493190022-91343-3-git-send-email-yankejian@huawei.com>
On 26/04/17 09:00, Yankejian wrote:
> From: lipeng <lipeng321@huawei.com>
>
> In the hip06 and hip07 SoCs, phy connect to mdio bus.The mdio
> module is probed with module_init, and, as such,
> is not guaranteed to probe before the HNS driver. So we need
> to support deferred probe.
>
> We check for probe deferral in the mac init, so we not init DSAF
> when there is no mdio, and free all resource, to later learn that
> we need to defer the probe.
>
> Signed-off-by: lipeng <lipeng321@huawei.com>
> Reviewed-by: Yisen Zhuang <yisen.zhuang@huawei.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
> ---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 39 +++++++++++++++++++----
> 1 file changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> index bdd8cdd..8c00e09 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> @@ -735,6 +735,8 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
> rc = phy_device_register(phy);
> if (rc) {
> phy_device_free(phy);
> + dev_err(&mdio->dev, "registered phy fail at address %i\n",
> + addr);
> return -ENODEV;
> }
>
> @@ -745,7 +747,7 @@ static int hns_mac_init_ex(struct hns_mac_cb *mac_cb)
> return 0;
> }
>
> -static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
> +static int hns_mac_register_phy(struct hns_mac_cb *mac_cb)
> {
> struct acpi_reference_args args;
> struct platform_device *pdev;
> @@ -755,24 +757,39 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
>
> /* Loop over the child nodes and register a phy_device for each one */
> if (!to_acpi_device_node(mac_cb->fw_port))
> - return;
> + return -ENODEV;
>
> rc = acpi_node_get_property_reference(
> mac_cb->fw_port, "mdio-node", 0, &args);
> if (rc)
> - return;
> + return rc;
>
> addr = hns_mac_phy_parse_addr(mac_cb->dev, mac_cb->fw_port);
> if (addr < 0)
> - return;
> + return addr;
>
> /* dev address in adev */
> pdev = hns_dsaf_find_platform_device(acpi_fwnode_handle(args.adev));
> + if (!pdev) {
> + dev_err(mac_cb->dev, "mac%d mdio pdev is NULL\n",
> + mac_cb->mac_id);
> + return -EINVAL;
> + }
> +
> mii_bus = platform_get_drvdata(pdev);
> + if (!mii_bus) {
> + dev_err(mac_cb->dev,
> + "mac%d mdio is NULL, dsaf will probe again later\n",
> + mac_cb->mac_id);
> + return -EPROBE_DEFER;
> + }
> +
> rc = hns_mac_register_phydev(mii_bus, mac_cb, addr);
> if (!rc)
> dev_dbg(mac_cb->dev, "mac%d register phy addr:%d\n",
> mac_cb->mac_id, addr);
> +
> + return rc;
> }
>
> #define MAC_MEDIA_TYPE_MAX_LEN 16
> @@ -793,7 +810,7 @@ static void hns_mac_register_phy(struct hns_mac_cb *mac_cb)
> *@np:device node
> * return: 0 --success, negative --fail
> */
> -static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
> +static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
> {
> struct device_node *np;
> struct regmap *syscon;
> @@ -903,7 +920,15 @@ static int hns_mac_get_info(struct hns_mac_cb *mac_cb)
> }
> }
> } else if (is_acpi_node(mac_cb->fw_port)) {
> - hns_mac_register_phy(mac_cb);
> + ret = hns_mac_register_phy(mac_cb);
> + /*
> + * Mac can work well if there is phy or not.If the port don't
> + * connect with phy, the return value will be ignored. Only
> + * when there is phy but can't find mdio bus, the return value
> + * will be handled.
> + */
> + if (ret == -EPROBE_DEFER)
> + return ret;
> } else {
> dev_err(mac_cb->dev, "mac%d cannot find phy node\n",
> mac_cb->mac_id);
> @@ -1065,6 +1090,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
> dsaf_dev->mac_cb[port_id] = mac_cb;
> }
> }
> +
> /* init mac_cb for all port */
> for (port_id = 0; port_id < max_port_num; port_id++) {
> mac_cb = dsaf_dev->mac_cb[port_id];
> @@ -1074,6 +1100,7 @@ int hns_mac_init(struct dsaf_device *dsaf_dev)
> ret = hns_mac_get_cfg(dsaf_dev, mac_cb);
> if (ret)
> return ret;
> +
> ret = hns_mac_init_ex(mac_cb);
> if (ret)
> return ret;
>
^ 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