* Re: KASAN: slab-out-of-bounds Read in tls_push_record
From: Dmitry Vyukov @ 2019-02-20 16:55 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <000000000000ccb25d0576c17446@google.com>
On Wed, Sep 26, 2018 at 9:49 AM syzbot
<syzbot+942a1909765f0413329b@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 739d0def85ca Merge branch 'hv_netvsc-Support-LRO-RSC-in-th..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13aa179e400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e79b9299baeb2298
> dashboard link: https://syzkaller.appspot.com/bug?extid=942a1909765f0413329b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+942a1909765f0413329b@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in sg_mark_end
> include/linux/scatterlist.h:195 [inline]
> BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1243/0x1330
> net/tls/tls_sw.c:521
> Read of size 8 at addr ffff8801a4d235f8 by task syz-executor1/7668
This is probably:
#syz dup: KASAN: out-of-bounds Write in tls_push_record
> CPU: 1 PID: 7668 Comm: syz-executor1 Not tainted 4.19.0-rc4+ #228
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c4/0x2b4 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> sg_mark_end include/linux/scatterlist.h:195 [inline]
> tls_push_record+0x1243/0x1330 net/tls/tls_sw.c:521
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:558
> tls_handle_open_record net/tls/tls_main.c:155 [inline]
> tls_sk_proto_close+0x439/0x750 net/tls/tls_main.c:272
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:428
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:458
> __sock_release+0xd7/0x250 net/socket.c:579
> sock_close+0x19/0x20 net/socket.c:1141
> __fput+0x385/0xa30 fs/file_table.c:278
> ____fput+0x15/0x20 fs/file_table.c:309
> task_work_run+0x1e8/0x2a0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:193 [inline]
> exit_to_usermode_loop+0x318/0x380 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x411151
> Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
> 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
> 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:00007fff8ba9e200 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000411151
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
> R10: 00007fff8ba9e130 R11: 0000000000000293 R12: 000000000000000f
> R13: 0000000000086e3d R14: 0000000000000412 R15: badc0ffeebadface
>
> Allocated by task 0:
> (stack is not available)
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8801a4d22d80
> which belongs to the cache kmalloc-2048 of size 2048
> The buggy address is located 120 bytes to the right of
> 2048-byte region [ffff8801a4d22d80, ffff8801a4d23580)
> The buggy address belongs to the page:
> page:ffffea0006934880 count:1 mapcount:0 mapping:ffff8801da800c40 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea000717fd08 ffff8801da801948 ffff8801da800c40
> raw: 0000000000000000 ffff8801a4d22500 0000000100000003 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801a4d23480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801a4d23500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff8801a4d23580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff8801a4d23600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff8801a4d23680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/000000000000ccb25d0576c17446%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [RFC v1 15/19] RDMA/irdma: Add miscellaneous utility definitions
From: Jason Gunthorpe @ 2019-02-20 16:53 UTC (permalink / raw)
To: Saleem, Shiraz
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7A5A460B3@fmsmsx124.amr.corp.intel.com>
On Wed, Feb 20, 2019 at 02:53:18PM +0000, Saleem, Shiraz wrote:
> >Subject: Re: [RFC v1 15/19] RDMA/irdma: Add miscellaneous utility definitions
> >
> >On Fri, Feb 15, 2019 at 11:11:02AM -0600, Shiraz Saleem wrote:
> >> From: Mustafa Ismail <mustafa.ismail@intel.com>
> >>
> >> Add miscellaneous utility functions and headers.
> >>
>
> [....]
>
> >
> >> +#define to_device(ptr) \
> >> + (&((struct pci_dev *)((ptr)->hw->dev_context))->dev)
> >
> >?? Seems like this wants to be container_of??
>
> Yes.
>
> >
> >> +/**
> >> + * irdma_insert_wqe_hdr - write wqe header
> >> + * @wqe: cqp wqe for header
> >> + * @header: header for the cqp wqe
> >> + */
> >> +static inline void irdma_insert_wqe_hdr(__le64 *wqe, u64 hdr) {
> >> + wmb(); /* make sure WQE is populated before polarity is set */
> >> + set_64bit_val(wqe, 24, hdr);
> >
> >Generally don't like seeing wmbs in drivers.. Are you sure this isn't supposed to
> >be smp_store_release(), or dma_wmb() perhaps?
>
> Why is wmb() an issue in drivers?
There are many ways to get a barrier that are much clearer and
maintainable then some random wmb. Rarely do drivers actually need
wmb.
> >> +/**
> >> + * irdma_allocate_dma_mem - Memory alloc helper fn
> >> + * @hw: pointer to the HW structure
> >> + * @mem: ptr to mem struct to fill out
> >> + * @size: size of memory requested
> >> + * @alignment: what to align the allocation to */ enum
> >> +irdma_status_code irdma_allocate_dma_mem(struct irdma_hw *hw,
> >> + struct irdma_dma_mem *mem,
> >> + u64 size,
> >> + u32 alignment)
> >> +{
> >> + struct pci_dev *pcidev = (struct pci_dev *)hw->dev_context;
> >> +
> >> + if (!mem)
> >> + return IRDMA_ERR_PARAM;
> >> +
> >> + mem->size = ALIGN(size, alignment);
> >> + mem->va = dma_alloc_coherent(&pcidev->dev, mem->size,
> >> + (dma_addr_t *)&mem->pa, GFP_KERNEL);
> >> + if (!mem->va)
> >> + return IRDMA_ERR_NO_MEMORY;
> >> +
> >> + return 0;
> >> +}
> >
> >More wrappers? Why?
>
> I agree on your previous comment on wrapper for usecnt tracking but this does
> consolidate some common code and avoid duplication.
IRDMA_ERR_PARAM seems like an nonsense thing to do, and why does this
driver have its own custom error codes anyhow? Don't like it, it is
very stange. Once you strip that away there is no code to share.
Jason
^ permalink raw reply
* Re: [RFC v1 12/19] RDMA/irdma: Implement device supported verb APIs
From: Jason Gunthorpe @ 2019-02-20 16:51 UTC (permalink / raw)
To: Saleem, Shiraz
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7A5A460A0@fmsmsx124.amr.corp.intel.com>
On Wed, Feb 20, 2019 at 02:52:31PM +0000, Saleem, Shiraz wrote:
> >All lists of things should be sorted. I saw many examples of unsorted lists.
>
> OK. We weren't aware of this rule in kernel drivers. Is this subsystem specific?
It is a general kernel preference - it helps avoid unnecessary merge
conflicts. Lists in kconfig, makefiles, etc should all be
sorted. Other order-independent lists, like ops, and what not should
be sorted for the same reasons.
> >> + iwibdev->ibdev.iwcm->add_ref = irdma_add_ref;
> >> + iwibdev->ibdev.iwcm->rem_ref = irdma_rem_ref;
> >> + iwibdev->ibdev.iwcm->get_qp = irdma_get_qp;
> >> + iwibdev->ibdev.iwcm->connect = irdma_connect;
> >> + iwibdev->ibdev.iwcm->accept = irdma_accept;
> >> + iwibdev->ibdev.iwcm->reject = irdma_reject;
> >> + iwibdev->ibdev.iwcm->create_listen = irdma_create_listen;
> >> + iwibdev->ibdev.iwcm->destroy_listen = irdma_destroy_listen;
> >
> >Huh. These should probably be moved into the ops structure too.
>
> Not sure. It looks cleaner this way. These are iWARP CM
> specific. Why allocate them for all devices?
Not sure a few bytes really matter.
Jason
^ permalink raw reply
* Re: [RFC v1 17/19] RDMA/irdma: Add ABI definitions
From: Jason Gunthorpe @ 2019-02-20 16:50 UTC (permalink / raw)
To: Saleem, Shiraz
Cc: dledford@redhat.com, davem@davemloft.net,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Ismail, Mustafa, Kirsher, Jeffrey T
In-Reply-To: <9DD61F30A802C4429A01CA4200E302A7A5A46077@fmsmsx124.amr.corp.intel.com>
On Wed, Feb 20, 2019 at 02:52:03PM +0000, Saleem, Shiraz wrote:
> >Subject: Re: [RFC v1 17/19] RDMA/irdma: Add ABI definitions
> >
> >On Fri, Feb 15, 2019 at 11:11:04AM -0600, Shiraz Saleem wrote:
> >> From: Mustafa Ismail <mustafa.ismail@intel.com>
> >>
> >> Add ABI definitions for irdma.
>
> [....]
> >>
> >> +
> >> +#include <linux/types.h>
> >> +
> >> +#define IRDMA_ABI_VER 6
> >
> >Starting with high numbers?
>
> It's a bump on the current i40iw ABI ver. of 5 since we
> want to be compatible and support current rdma-core's libi40iw
> for Gen1 (X722) device.
i40iw is one of the drivers that doesn't do ABI versions right, so
this is all meaningless. You should probably fix it:
static const struct verbs_device_ops i40iw_udev_ops = {
.name = "i40iw",
.match_min_abi_version = 0,
.match_max_abi_version = INT_MAX,
0 and INT_MAX need to be something sensible.
> >This won't even compile like this - don't forget you have to send the rdma-core
> >PR along with the kernel patches. You should already be running the travis
> >checks yourself. rdma-core should detect malformed user space headers..
>
> Yes. We will be sending the rdma-core patches soon.
> Maybe we are missing something here, but this did compile with libirdma
> in rdma-core-v22, but we havent run travis checks yet.
travis does the tests.
Jason
^ permalink raw reply
* PROBLEM: dev_hard_start_xmit general protection fault on 4.19.18
From: Jesse Hathaway @ 2019-02-20 16:48 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
After an uptime of 2-4 days our routers are hitting a general protection fault
in dev_hard_start_xmit. We are going to try the latest 4.19.24 release to see
if the bug has been resolved, but I didn't see any obvious commits in the logs.
We are also going to test with a much older 4.9.159 kernel as starting point to
finding when this problem was introduced. Please let me know if there is any
additional information I can provide or any test patches you would like me to
try. Thanks, Jesse Hathaway
Decoded stacktrace:
decode_stacktrace.sh was unable to decode the RIP line, but gdb was able to, if
someone knows why that failed I would love to know.
(gdb) l *dev_hard_start_xmit+0x38
0xffffffff815e7488 is in dev_hard_start_xmit (net/core/dev.c:3256).
3251 {
3252 struct sk_buff *skb = first;
3253 int rc = NETDEV_TX_OK;
3254
3255 while (skb) {
3256 struct sk_buff *next = skb->next;
3257
3258 skb->next = NULL;
3259 rc = xmit_one(skb, dev, txq, next != NULL);
3260 if (unlikely(!dev_xmit_complete(rc))) {
(gdb)
[423866.182835] general protection fault: 0000 [#1] SMP PTI
[423866.188774] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G E
4.19.18-bt7u1-amd64 #1
[423866.198308] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS
2.8.0 005/17/2018
[423866.206874] RIP: 0010:dev_hard_start_xmit (??:?)
[423866.212522] Code: 53 48 83 ec 28 48 85 ff 48 89 54 24 08 48 89 4c
24 18 0f 84 b9 01 00 00 48 8d 86 90 00 00 00 48 89 f5 48 89 fb 48 89
44 24 10 <4c> 8b 33 48 c7 03 00 00 00 00 48 8b 05 77 46 b4 00 4d 85 f6
0f 95
All code
========
0: 53 push %rbx
1: 48 83 ec 28 sub $0x28,%rsp
5: 48 85 ff test %rdi,%rdi
8: 48 89 54 24 08 mov %rdx,0x8(%rsp)
d: 48 89 4c 24 18 mov %rcx,0x18(%rsp)
12: 0f 84 b9 01 00 00 je 0x1d1
18: 48 8d 86 90 00 00 00 lea 0x90(%rsi),%rax
1f: 48 89 f5 mov %rsi,%rbp
22: 48 89 fb mov %rdi,%rbx
25: 48 89 44 24 10 mov %rax,0x10(%rsp)
2a:* 4c 8b 33 mov (%rbx),%r14 <-- trapping instruction
2d: 48 c7 03 00 00 00 00 movq $0x0,(%rbx)
34: 48 8b 05 77 46 b4 00 mov 0xb44677(%rip),%rax # 0xb446b2
3b: 4d 85 f6 test %r14,%r14
3e: 0f .byte 0xf
3f: 95 xchg %eax,%ebp
Code starting with the faulting instruction
===========================================
0: 4c 8b 33 mov (%rbx),%r14
3: 48 c7 03 00 00 00 00 movq $0x0,(%rbx)
a: 48 8b 05 77 46 b4 00 mov 0xb44677(%rip),%rax # 0xb44688
11: 4d 85 f6 test %r14,%r14
14: 0f .byte 0xf
15: 95 xchg %eax,%ebp
[423866.233612] RSP: 0018:ffff96f4af483b18 EFLAGS: 00010202
[423866.239550] RAX: ffff96f3f72b6600 RBX: 2e5903fe657c2d03 RCX:
0000000000000003
[423866.247627] RDX: ffffcc02bf687600 RSI: 00000000fffffe01 RDI:
ffffffffb69e864d
[423866.255703] RBP: ffff96f4a802a000 R08: 0000000000000001 R09:
00000000000003e8
[423866.263779] R10: 00000000000002f5 R11: ffff96f4a86ff940 R12:
ffff96f4a802a000
[423866.271854] R13: 0000000000000032 R14: 2e5903fe657c2d03 R15:
0000000000000000
[423866.279931] FS: 0000000000000000(0000) GS:ffff96f4af480000(0000)
knlGS:0000000000000000
[423866.289075] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[423866.295596] CR2: 00007fb3c351f000 CR3: 000000074080a001 CR4:
00000000001606e0
[423866.303671] Call Trace:
[423866.306501] <IRQ>
[423866.308847] __dev_queue_xmit (/source/linux-4.19.18/net/core/dev.c:3830)
[423866.313427] ip_finish_output2
(/source/linux-4.19.18/./include/net/neighbour.h:501
/source/linux-4.19.18/net/ipv4/ip_output.c:229)
[423866.318105] ip_output (/source/linux-4.19.18/net/ipv4/ip_output.c:409)
[423866.321810] ? ip_fragment.constprop.49
(/source/linux-4.19.18/net/ipv4/ip_output.c:293)
[423866.327166] ip_forward (/source/linux-4.19.18/net/ipv4/ip_forward.c:150)
[423866.331161] ? ip_check_defrag
(/source/linux-4.19.18/net/ipv4/ip_forward.c:66)
[423866.335837] ip_rcv (/source/linux-4.19.18/net/ipv4/ip_input.c:527)
[423866.339250] ? ip_rcv_core.isra.15
(/source/linux-4.19.18/net/ipv4/ip_input.c:403)
[423866.344314] __netif_receive_skb_one_core
(/source/linux-4.19.18/net/core/dev.c:4920)
[423866.349866] netif_receive_skb_internal
(/source/linux-4.19.18/net/core/dev.c:5134)
[423866.355222] napi_gro_receive
(/source/linux-4.19.18/net/core/dev.c:5591
/source/linux-4.19.18/net/core/dev.c:5622)
[423866.359615] ixgbe_poll
(/source/linux-4.19.18/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2404
/source/linux-4.19.18/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3186)
ixgbe
[423866.364488] ? load_balance (/source/linux-4.19.18/kernel/sched/fair.c:8578)
[423866.368875] net_rx_action
(/source/linux-4.19.18/net/core/dev.c:6262
/source/linux-4.19.18/net/core/dev.c:6328)
[423866.373164] __do_softirq
(/source/linux-4.19.18/kernel/softirq.c:292
/source/linux-4.19.18/./include/linux/jump_label.h:142
/source/linux-4.19.18/./include/trace/events/irq.h:142
/source/linux-4.19.18/kernel/softirq.c:293)
[423866.377260] irq_exit (/source/linux-4.19.18/kernel/softirq.c:372
/source/linux-4.19.18/kernel/softirq.c:412)
[423866.380867] do_IRQ
(/source/linux-4.19.18/./arch/x86/include/asm/irq_regs.h:19
/source/linux-4.19.18/./arch/x86/include/asm/irq_regs.h:26
/source/linux-4.19.18/arch/x86/kernel/irq.c:260)
[423866.384378] common_interrupt
(/source/linux-4.19.18/arch/x86/entry/entry_64.S:646)
[423866.388567] </IRQ>
[423866.391587] RIP: 0010:mwait_idle (??:?)
[423866.396925] Code: 01 00 0f ae 38 0f ae f0 31 d2 65 48 8b 04 25 40
5c 01 00 48 89 d1 0f 01 c8 48 8b 00 a8 08 0f 85 30 01 00 00 31 c0 fb
0f 01 c9 <65> 8b 2d a3 13 53 49 0f 1f 44 00 00 eb 07 fb 66 0f 1f 44 00
00 65
All code
========
0: 01 00 add %eax,(%rax)
2: 0f ae 38 clflush (%rax)
5: 0f ae f0 mfence
8: 31 d2 xor %edx,%edx
a: 65 48 8b 04 25 40 5c mov %gs:0x15c40,%rax
11: 01 00
13: 48 89 d1 mov %rdx,%rcx
16: 0f 01 c8 monitor %rax,%rcx,%rdx
19: 48 8b 00 mov (%rax),%rax
1c: a8 08 test $0x8,%al
1e: 0f 85 30 01 00 00 jne 0x154
24: 31 c0 xor %eax,%eax
26: fb sti
27: 0f 01 c9 mwait %rax,%rcx
2a: 65 8b 2d a3 13 53 49 mov %gs:*0x495313a3(%rip),%ebp #
0x495313d4 <-- trapping instruction
31: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
36: eb 07 jmp 0x3f
38: fb sti
39: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
3f: 65 gs
Code starting with the faulting instruction
===========================================
0: 65 8b 2d a3 13 53 49 mov %gs:0x495313a3(%rip),%ebp # 0x495313aa
7: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
c: eb 07 jmp 0x15
e: fb sti
f: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
15: 65 gs
[423866.419176] RSP: 0018:ffffac06c01ebe98 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffffdb
[423866.428304] RAX: 0000000000000000 RBX: 0000000000000004 RCX:
0000000000000000
[423866.436944] RDX: 0000000000000000 RSI: ffff96f4af49a760 RDI:
0000000000000004
[423866.445569] RBP: 0000000000000004 R08: 0000000000000000 R09:
0000000000000000
[423866.454198] R10: 0000000000000000 R11: 0000000000000000 R12:
0000000000000000
[423866.462825] R13: ffff96f4ad1aac40 R14: ffff96f4ad1aac40 R15:
ffff96f4ad1aac40
[423866.471446] do_idle (/source/linux-4.19.18/kernel/sched/idle.c:153
/source/linux-4.19.18/kernel/sched/idle.c:262)
[423866.475681] cpu_startup_entry
(/source/linux-4.19.18/kernel/sched/idle.c:368 (discriminator 1))
[423866.480690] start_secondary
(/source/linux-4.19.18/arch/x86/kernel/smpboot.c:272)
[423866.485693] secondary_startup_64
(/source/linux-4.19.18/arch/x86/kernel/head_64.S:243)
[423866.490976] Modules linked in: drbg(E) ansi_cprng(E) echainiv(E)
esp4(E) xfrm4_mode_transport(E) tcp_diag(E) inet_diag(E)
nf_conntrack_netlink(E) xt_nat(E) xt_policy(E) nfnetlink_log(E)
xt_NFLOG(E) xt_limit(E) ipt_REJECT(E) nf_)
[423866.575127] serpent_avx2(E) serpent_avx_x86_64(E)
serpent_sse2_x86_64(E) serpent_generic(E) glue_helper(E)
blowfish_generic(E) blowfish_x86_64(E) blowfish_common(E)
cast5_avx_x86_64(E) cast5_generic(E) cast_common(E) crypto_si)
[423866.658693] crc32c_generic(E) crc32c_intel(E) ext4(E) crc16(E)
mbcache(E) jbd2(E) fscrypto(E) sg(E) sd_mod(E) ehci_pci(E) ahci(E)
ehci_hcd(E) libahci(E) ixgbe(E) libata(E) megaraid_sas(E) dca(E)
usbcore(E) mdio(E) i40e(E) scsi)
[423866.683437] ---[ end trace e0abd70b6f85b1fd ]---
# awk -f scripts/ver_linux
Linux rtr1 4.19.18-bt7u1-amd64 #1 SMP Mon Feb 11 20:09:59 UTC 2019
x86_64 GNU/Linux
GNU C 4.7
GNU Make 3.81
Binutils 2.22
Util-linux 2.20.1
Mount 2.20.1
E2fsprogs 1.42.5
Linux C Library 2.13
Dynamic linker (ldd) 2.13
Linux C++ Library 6.0.17
Procps 3.3.3
Net-tools 1.60
Sh-utils 8.13
Udev 175
Modules Loaded 8021q acpi_power_meter aesni_intel aes_x86_64
af_key ahci ansi_cprng authenc blowfish_common blowfish_generic
blowfish_x86_64 bonding button camellia_aesni_avx2
camellia_aesni_avx_x86_64 camellia_generic camellia_x86_64
cast5_avx_x86_64 cast5_generic cast_common cbc cmac crc16
crc32c_generic crc32c_intel cryptd crypto_simd ctr dca dcdbas
des_generic drbg drm drm_kms_helper dummy echainiv ehci_hcd ehci_pci
esp4 evdev ext4 fscrypto garp glue_helper gre i2c_algo_bit i2c_dev
i2c_i801 i40e inet_diag ioatdma ip_gre ipmi_devintf ipmi_msghandler
ipmi_si ip_set ip_set_hash_net ip_set_hash_netiface
ip_set_hash_netport iptable_filter iptable_mangle iptable_nat
iptable_raw ip_tables ipt_REJECT ip_tunnel iTCO_vendor_support
iTCO_wdt ixgbe jbd2 libahci libata libcrc32c llc loop lpc_ich mbcache
mdio megaraid_sas mei mei_me mgag200 mrp mxm_wmi nf_conntrack
nf_conntrack_netlink nf_conntrack_proto_gre nf_defrag_ipv4 nf_nat
nf_nat_ipv4 nfnetlink nfnetlink_log nf_reject_ipv4 pcbc pcrypt pcspkr
rmd160 scsi_mod sd_mod serpent_avx2 serpent_avx_x86_64 serpent_generic
serpent_sse2_x86_64 sg sha512_generic sha512_ssse3 snd snd_pcm
snd_timer soundcore stp tcp_diag ttm twofish_avx_x86_64 twofish_common
twofish_generic twofish_x86_64 twofish_x86_64_3way usbcore wmi xcbc
xfrm4_mode_transport xfrm_algo x_tables xt_addrtype xt_connmark
xt_conntrack xt_CT xt_limit xt_mark xt_nat xt_NFLOG xt_policy xt_set
xt_tcpudp
^ permalink raw reply
* Re: [PATCH net] net: dsa: fix unintended change of bridge interface STP state
From: Vivien Didelot @ 2019-02-20 16:38 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Lunn, Florian Fainelli, David S. Miller, netdev
In-Reply-To: <E1gwPBM-0008SQ-CM@rmk-PC.armlinux.org.uk>
On Wed, 20 Feb 2019 10:32:52 +0000, Russell King <rmk+kernel@armlinux.org.uk> wrote:
> When a DSA port is added to a bridge and brought up, the resulting STP
> state programmed into the hardware depends on the order that these
> operations are performed. However, the Linux bridge code believes that
> the port is in disabled mode.
>
> If the DSA port is first added to a bridge and then brought up, it will
> be in blocking mode. If it is brought up and then added to the bridge,
> it will be in disabled mode.
>
> This difference is caused by DSA always setting the STP mode in
> dsa_port_enable() whether or not this port is part of a bridge. Since
> bridge always sets the STP state when the port is added, brought up or
> taken down, it is unnecessary for us to manipulate the STP state.
>
> Apparently, this code was copied from Rocker, and the very next day a
> similar fix for Rocker was merged but was not propagated to DSA. See
> e47172ab7e41 ("rocker: put port in FORWADING state after leaving bridge")
>
> Fixes: b73adef67765 ("net: dsa: integrate with SWITCHDEV for HW bridging")
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: [PATCH iproute2] bridge: make mcast_flood description consistent
From: Vivien Didelot @ 2019-02-20 16:35 UTC (permalink / raw)
To: Russell King - ARM Linux admin; +Cc: netdev, stephen
In-Reply-To: <20190220000528.pl6uc2w3hcxiwb7v@shell.armlinux.org.uk>
Hi Russell,
On Wed, 20 Feb 2019 00:05:29 +0000, Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> I'm not sure if it's in the current iproute2, but there is a
> discrepency between the arguments for 'bridge' stated in the man page
> and the description thereof:
>
> bridge link set dev DEV [ cost COST ] [ priority PRIO ] [ state STATE
> ...
> } ] [ learning_sync { on | off } ] [ flood { on | off } ] [
> ^^^^^^^^^^^^^^^^^^
>
> vs
>
> flooding on or flooding off
> Controls whether a given port will flood unicast traffic for
> which there is no FDB entry. By default this flag is on.
>
> vs the command actually accepting "flood" not "flooding". I spotted
> that in iproute2-4.20.0. I haven't had a chance to generate a patch
> that yet and work out how to submit it, but thanks for leading the
> way!
You are correct! I've sent a v2.
Thank you,
Vivien
^ permalink raw reply
* Re: skb_can_coalesce() merges tcp frags with XFS-related slab objects
From: Eric Dumazet @ 2019-02-20 16:35 UTC (permalink / raw)
To: Vasily Averin, Eric Dumazet, David S. Miller
Cc: Linux Kernel Network Developers, Ilya Dryomov
In-Reply-To: <ed413bee-796e-1c3f-4829-4871c032e1ff@virtuozzo.com>
On 02/20/2019 08:19 AM, Vasily Averin wrote:
> Thank you for explanation,
> though this happen in real life and triggers BUG_ON only if receiving side is located on the same host.
> Is it probably makes sense to add WARN_ON into skb_can_coalesce to detect such cases?
Yes, but please do it only in the sendpage() path, or only in CONFIG_DEBUG_PAGEALLOC / CONFIG_DEBUG_VM cases.
tcp_sendmsg() uses a per task page (look at sk_page_frag()), and it seems
strange to recheck what we already know (it is a page not backed/used by SLAB)
^ permalink raw reply
* [PATCH iproute2 v2] bridge: make mcast_flood description consistent
From: Vivien Didelot @ 2019-02-20 16:33 UTC (permalink / raw)
To: netdev; +Cc: stephen, Russell King, Vivien Didelot
This patch simply changes the description of the mcast_flood flag
with "flood" instead of "be flooded with" to avoid confusion, and be
consistent with the description of the flooding flag, which "Controls
whether a given port will *flood* unicast traffic for which there is
no FDB entry."
At the same time, fix the documentation for the "flood" flag which
is incorrectly described as "flooding on" or "flooding off".
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
---
man/man8/bridge.8 | 4 ++--
man/man8/ip-link.8.in | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index 72210f62..13c46386 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -344,7 +344,7 @@ Controls whether a given port will sync MAC addresses learned on device port to
bridge FDB.
.TP
-.BR "flooding on " or " flooding off "
+.BR "flood on " or " flood off "
Controls whether a given port will flood unicast traffic for which there is no FDB entry. By default this flag is on.
.TP
@@ -361,7 +361,7 @@ switch.
.TP
.BR "mcast_flood on " or " mcast_flood off "
-Controls whether a given port will be flooded with multicast traffic for which there is no MDB entry. By default this flag is on.
+Controls whether a given port will flood multicast traffic for which there is no MDB entry. By default this flag is on.
.TP
.BR "neigh_suppress on " or " neigh_suppress off "
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 5132f514..cef489a4 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -2155,7 +2155,7 @@ queries.
option above.
.BR mcast_flood " { " on " | " off " }"
-- controls whether a given port will be flooded with multicast traffic for which there is no MDB entry.
+- controls whether a given port will flood multicast traffic for which there is no MDB entry.
.BI group_fwd_mask " MASK "
- set the group forward mask. This is the bitmask that is applied to decide whether to forward incoming frames destined to link-local addresses, ie addresses of the form 01:80:C2:00:00:0X (defaults to 0, ie the bridge does not forward any link-local frames coming on this port).
--
2.20.1
^ permalink raw reply related
* KASAN: use-after-free Read in icmp_sk_exit
From: syzbot @ 2019-02-20 16:23 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 1f43f400a2cb net: netcp: Fix ethss driver probe issue
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=1276fea2c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
dashboard link: https://syzkaller.appspot.com/bug?extid=3d7fa0f0de0f86d0eb4f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3d7fa0f0de0f86d0eb4f@syzkaller.appspotmail.com
IPVS: set_ctl: invalid protocol: 63 172.20.20.187:20002
kernel msg: ebtables bug: please report to author: entries_size too small
kernel msg: ebtables bug: please report to author: entries_size too small
==================================================================
BUG: KASAN: use-after-free in inet_ctl_sock_destroy
include/net/inet_common.h:56 [inline]
BUG: KASAN: use-after-free in icmp_sk_exit+0x1ce/0x1f0 net/ipv4/icmp.c:1187
Read of size 8 at addr ffff8880847adc50 by task kworker/u4:1/21
CPU: 0 PID: 21 Comm: kworker/u4:1 Not tainted 5.0.0-rc6+ #85
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: netns cleanup_net
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
inet_ctl_sock_destroy include/net/inet_common.h:56 [inline]
icmp_sk_exit+0x1ce/0x1f0 net/ipv4/icmp.c:1187
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Allocated by task 25570:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_kmalloc mm/kasan/common.c:496 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:469
kasan_kmalloc mm/kasan/common.c:504 [inline]
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:411
kmem_cache_alloc+0x12d/0x710 mm/slab.c:3543
sk_prot_alloc+0x67/0x2e0 net/core/sock.c:1471
sk_alloc+0x39/0xf70 net/core/sock.c:1531
inet_create net/ipv4/af_inet.c:321 [inline]
inet_create+0x36a/0xe10 net/ipv4/af_inet.c:247
__sock_create+0x3e6/0x750 net/socket.c:1275
sock_create_kern+0x3b/0x50 net/socket.c:1321
inet_ctl_sock_create+0x9d/0x1f0 net/ipv4/af_inet.c:1614
icmp_sk_init net/ipv4/icmp.c:1203 [inline]
icmp_sk_init+0x120/0x680 net/ipv4/icmp.c:1192
ops_init+0xb6/0x410 net/core/net_namespace.c:129
setup_net+0x2c5/0x730 net/core/net_namespace.c:314
copy_net_ns+0x1d9/0x340 net/core/net_namespace.c:437
create_new_namespaces+0x400/0x7b0 kernel/nsproxy.c:107
unshare_nsproxy_namespaces+0xc2/0x200 kernel/nsproxy.c:206
ksys_unshare+0x440/0x980 kernel/fork.c:2550
__do_sys_unshare kernel/fork.c:2618 [inline]
__se_sys_unshare kernel/fork.c:2616 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:2616
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 21:
save_stack+0x45/0xd0 mm/kasan/common.c:73
set_track mm/kasan/common.c:85 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:458
kasan_slab_free+0xe/0x10 mm/kasan/common.c:466
__cache_free mm/slab.c:3487 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3749
sk_prot_free net/core/sock.c:1512 [inline]
__sk_destruct+0x4b6/0x6d0 net/core/sock.c:1596
sk_destruct+0x7b/0x90 net/core/sock.c:1604
__sk_free+0xce/0x300 net/core/sock.c:1615
sk_free+0x42/0x50 net/core/sock.c:1626
sock_put include/net/sock.h:1707 [inline]
sk_common_release+0x224/0x330 net/core/sock.c:3042
raw_close+0x22/0x30 net/ipv4/raw.c:708
inet_release+0x105/0x1f0 net/ipv4/af_inet.c:428
__sock_release+0x1d3/0x250 net/socket.c:579
sock_release+0x18/0x20 net/socket.c:598
inet_ctl_sock_destroy include/net/inet_common.h:56 [inline]
icmp_sk_exit+0x11f/0x1f0 net/ipv4/icmp.c:1187
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551
process_one_work+0x98e/0x1790 kernel/workqueue.c:2173
worker_thread+0x98/0xe40 kernel/workqueue.c:2319
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at ffff8880847ad840
which belongs to the cache RAW(97:syz4) of size 1320
The buggy address is located 1040 bytes inside of
1320-byte region [ffff8880847ad840, ffff8880847add68)
The buggy address belongs to the page:
page:ffffea000211eb00 count:1 mapcount:0 mapping:ffff8880a84bf1c0
index:0xffff8880847ac140 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffff8880a4cd5b38 ffff8880a4cd5b38 ffff8880a84bf1c0
raw: ffff8880847ac140 ffff8880847ac140 0000000100000003 ffff888067b1a1c0
page dumped because: kasan: bad access detected
page->mem_cgroup:ffff888067b1a1c0
Memory state around the buggy address:
ffff8880847adb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880847adb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8880847adc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880847adc80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880847add00: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: skb_can_coalesce() merges tcp frags with XFS-related slab objects
From: Vasily Averin @ 2019-02-20 16:19 UTC (permalink / raw)
To: Eric Dumazet, David S. Miller
Cc: Linux Kernel Network Developers, Ilya Dryomov
In-Reply-To: <2dc88af7-3d29-58e1-00e0-127d1f798c28@gmail.com>
On 2/20/19 6:53 PM, Eric Dumazet wrote:
> On 02/20/2019 05:34 AM, Vasily Averin wrote:
>> Dear David,
>>
>> currently do_tcp_sendpages() calls skb_can_coalesce() to merge proper tcp fragments.
>> If these fragments are slab objects and the data is not transferred out of the local host
>> then tcp_recvmsg() can crash host on BUG_ON (see [2] below).
>>
>> There is known usecase when slab objects are provided to tcp_sendpage:
>> XFS over locally landed network blockdevice.
>>
>> I found few such cases:
>> - _drbd_send_page() had PageSlab() check log time ago.
>> - recently Ilya Dryomov fixed it in ceph
>> by commit 7e241f647dc7 "libceph: fall back to sendmsg for slab pages"
>>
>> Recently OpenVZ team noticed this problem during experiments with
>> XFS over locally-landed iscsi target.
>>
>> I would note: triggered BUG is not a real problem but false alert,
>> that though crashes host.
>>
>> I can fix last problem by adding PageSlab() into iscsi_tcp_segment_map(),
>> however it does not fix the problem completely,
>> there are chances that the problem will be reproduced again with some other filesystems
>> or with some other kind of network blockdevice.
>>
>> David, what do you think, is it probably better to add PageSlab() check
>> directly into skb_can_coalesce()? (see [1] below)
>>
>
> No, this would be wrong.
>
> There is no way a page fragment can be backed by slab object,
> since a page fragment can be shared (the page refcount needs to be manipulated, without slab/slub
> being aware of this)
Thank you for explanation,
though this happen in real life and triggers BUG_ON only if receiving side is located on the same host.
Is it probably makes sense to add WARN_ON into skb_can_coalesce to detect such cases?
> Please fix the callers.
Ok, will do it.
^ permalink raw reply
* Re: [PATCH v2] kcm: remove any offset before parsing messages
From: Tom Herbert @ 2019-02-20 16:18 UTC (permalink / raw)
To: Dominique Martinet
Cc: Tom Herbert, David Miller, Doron Roberts-Kedes, Dave Watson,
Linux Kernel Network Developers, LKML
In-Reply-To: <20190220041151.GA13520@nautica>
On Tue, Feb 19, 2019 at 8:12 PM Dominique Martinet
<asmadeus@codewreck.org> wrote:
>
> Dominique Martinet wrote on Fri, Feb 15, 2019:
> > With all that said I guess my patch should work correctly then, I'll try
> > to find some time to check the error does come back up the tcp socket in
> > my reproducer but I have no reason to believe it doesn't.
>
> Ok, so I can confirm this part - the 'csock' does come back up with
> POLLERR if the parse function returns ENOMEM in the current code.
>
Good.
> It also comes back up with POLLERR when the remote side closes the
> connection, which is expected, but I'm having a very hard time
> understanding how an application is supposed to deal with these
> POLLERR after having read the documentation and a bit of
> experimentation.
> I'm not sure how much it would matter for real life (if the other end
> closes the connection most servers would not care about what they said
> just before closing, but I can imagine some clients doing that in real
> life e.g. a POST request they don't care if it succeeds or not)...
> My test program works like this:
> - client connects, sends 10k messages and close()s the socket
> - server loops recving and close()s after 10k messages; it used to be
> recvmsg() directly but it's now using poll then recvmsg.
>
>
> When the client closes the socket, some messages are obviously still "in
> flight", and the server will recv a POLLERR notification on the csock at
> some point with many messages left.
> The documentation says to unattach the csock when you get POLLER. If I
> do that, the kcm socket will no longer give me any message, so all the
> messages still in flight at the time are lost.
So basically it sounds like you're interested in supporting TCP
connections that are half closed. I believe that the error in half
closed is EPIPE, so if the TCP socket returns that it can be ignored
and the socket can continue being attached and used to send data.
Another possibility is to add some linger semantics to an attached
socket. For instance, a large message might be sent so that part of
the messge is queued in TCP and part is queued in the KCM socket.
Unattach would probably break that message. We probably want to linger
option similar to SO_LINGER (or maybe just use the option on the TCP
socket) that means don't complete the detach until any message being
transmitted on the lower socket has been queued.
>
> If I just ignore the csock like I used to, all the messages do come just
> fine, but as said previously on a real error this will just make recvmsg
> or the polling hang forever and I see no way to distinguish a "real"
> error vs. a connection shut down from the remote side with data left in
> the pipe.
> I thought of checking POLLERR on csock and POLLIN not set on kcmsock,
> but even that seems to happen fairly regularily - the kcm sock hasn't
> been filled up, it's still reading from the csock.
>
>
> On the other hand, checking POLLIN on the csock does say there is still
> data left, so I know there is data left on the csock, but this is also
> the case on a real error (e.g. if parser returns -ENOMEM)
> ... And this made me try to read from the csock after detaching it and I
> can resume manual tcp parsing for a few messages until read() fails with
> EPROTO ?! and I cannot seem to be able to get anything out of attaching
> it back to kcm (for e.g. an ENOMEM error that was transient)...
>
>
>
> I'm honestly not sure how the POLLERR notification mechanism works but I
> think it would be much easier to use KCM if we could somehow delay that
> error until KCM is done feeding from the csock (when netparser really
> stops reading from it like on real error, e.g. abort callback maybe?)
> I think it's fine if the csock is closed before the kcm sock message is
> read, but we should not lose messages like this.
Sounds like linger semantics is needed then.
>
>
>
> > I'd like to see some retry on ENOMEM before this is merged though, so
> > while I'm there I'll resend this with a second patch doing that
> > retry,.. I think just not setting strp->interrupted and not reporting
> > the error up might be enough? Will have to try either way.
>
> I also tried playing with that without much success.
> I had assumed just not calling strp_parser_err() (which calls the
> abort_parser cb) would be enough, eventually calling strp_start_timer()
> like the !len case, but no can do.
I think you need to ignore the ENOMEM and have a timer or other
callback to retry the operation in the future.
> With that said, returning 0 from the parse function also raises POLLERR
> on the csock and hangs netparser, so things aren't that simple...
Can you point to where this is happening. If the parse_msg callback
returns 0 that is suppose to indicate that more bytes are needed.
>
>
> I could use a bit of help again.
>
> Thanks,
> --
> Dominique
^ permalink raw reply
* Re: [PATCH 6/6] net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
From: Tony Lindgren @ 2019-02-20 16:18 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, Kishon Vijay Abraham I, Rob Herring, netdev,
Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel
In-Reply-To: <1550676319-6440-7-git-send-email-grygorii.strashko@ti.com>
Hi,
* Grygorii Strashko <grygorii.strashko@ti.com> [190220 15:26]:
> Deprecate cpsw-phy-sel driver as it's been replaced with new
> TI phy-gmii-sel PHY driver.
I'm not going to pick up this one, seems that Dave can merge
this later on? That is unless Dave wants to ack this one.
Regards,
Tony
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/net/ethernet/ti/Kconfig | 6 +++---
> drivers/net/ethernet/ti/cpsw.h | 6 ++++++
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
> index bb126be1eb72..8b21b40a9fe5 100644
> --- a/drivers/net/ethernet/ti/Kconfig
> +++ b/drivers/net/ethernet/ti/Kconfig
> @@ -49,10 +49,11 @@ config TI_DAVINCI_CPDMA
> will be called davinci_cpdma. This is recommended.
>
> config TI_CPSW_PHY_SEL
> - bool
> + bool "TI CPSW Phy mode Selection (DEPRECATED)"
> + default n
> ---help---
> This driver supports configuring of the phy mode connected to
> - the CPSW.
> + the CPSW. DEPRECATED: use PHY_TI_GMII_SEL.
>
> config TI_CPSW_ALE
> tristate "TI CPSW ALE Support"
> @@ -64,7 +65,6 @@ config TI_CPSW
> depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || COMPILE_TEST
> select TI_DAVINCI_CPDMA
> select TI_DAVINCI_MDIO
> - select TI_CPSW_PHY_SEL
> select TI_CPSW_ALE
> select MFD_SYSCON
> select REGMAP
> diff --git a/drivers/net/ethernet/ti/cpsw.h b/drivers/net/ethernet/ti/cpsw.h
> index cf111db3dc27..907e05fc22e4 100644
> --- a/drivers/net/ethernet/ti/cpsw.h
> +++ b/drivers/net/ethernet/ti/cpsw.h
> @@ -21,7 +21,13 @@
> ((mac)[2] << 16) | ((mac)[3] << 24))
> #define mac_lo(mac) (((mac)[4] << 0) | ((mac)[5] << 8))
>
> +#if IS_ENABLED(CONFIG_TI_CPSW_PHY_SEL)
> void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave);
> +#else
> +static inline
> +void cpsw_phy_sel(struct device *dev, phy_interface_t phy_mode, int slave)
> +{}
> +#endif
> int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr);
>
> #endif /* __CPSW_H__ */
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net] ipv6: route: purge exception on removal
From: Paolo Abeni @ 2019-02-20 16:00 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, David S. Miller
In-Reply-To: <460ef555bb02ec46d8a6108aa0d7b0095e11afd1.1550662037.git.pabeni@redhat.com>
On Wed, 2019-02-20 at 15:08 +0100, Paolo Abeni wrote:
> When a netdevice is unregistered, we flush the relevant exception
> via rt6_sync_down_dev() -> fib6_ifdown() -> fib6_del() -> fib6_del_route().
>
> Finally, we end-up calling rt6_remove_exception(), where we release
> the relevant dst, while we keep the references to the related fib6_info and
> dev. Such references should be released later when the dst will be
> destroyed.
>
> There are a number of caches that can keep the exception around for an
> unlimited amount of time - namely dst_cache, possibly even socket cache.
> As a result device registration may hang, as demonstrated by this script:
>
> ip netns add cl
> ip netns add rt
> ip netns add srv
> ip netns exec rt sysctl -w net.ipv6.conf.all.forwarding=1
>
> ip link add name cl_veth type veth peer name cl_rt_veth
> ip link set dev cl_veth netns cl
> ip -n cl link set dev cl_veth up
> ip -n cl addr add dev cl_veth 2001::2/64
> ip -n cl route add default via 2001::1
>
> ip -n cl link add tunv6 type ip6tnl mode ip6ip6 local 2001::2 remote 2002::1 hoplimit 64 dev cl_veth
> ip -n cl link set tunv6 up
> ip -n cl addr add 2013::2/64 dev tunv6
>
> ip link set dev cl_rt_veth netns rt
> ip -n rt link set dev cl_rt_veth up
> ip -n rt addr add dev cl_rt_veth 2001::1/64
>
> ip link add name rt_srv_veth type veth peer name srv_veth
> ip link set dev srv_veth netns srv
> ip -n srv link set dev srv_veth up
> ip -n srv addr add dev srv_veth 2002::1/64
> ip -n srv route add default via 2002::2
>
> ip -n srv link add tunv6 type ip6tnl mode ip6ip6 local 2002::1 remote 2001::2 hoplimit 64 dev srv_veth
> ip -n srv link set tunv6 up
> ip -n srv addr add 2013::1/64 dev tunv6
>
> ip link set dev rt_srv_veth netns rt
> ip -n rt link set dev rt_srv_veth up
> ip -n rt addr add dev rt_srv_veth 2002::2/64
>
> ip netns exec srv netserver & sleep 0.1
> ip netns exec cl ping6 -c 4 2013::1
> ip netns exec cl netperf -H 2013::1 -t TCP_STREAM -l 3 & sleep 1
> ip -n rt link set dev rt_srv_veth mtu 1400
> wait %2
>
> ip -n cl link del cl_veth
>
> This commit addresses the issue purging all the references held by the
> exception at time, as we currently do for e.g. ipv6 pcpu dst entries.
>
> Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> ---
> net/ipv6/route.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 964491cf3672..43a819ae46c2 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1274,11 +1274,21 @@ static DEFINE_SPINLOCK(rt6_exception_lock);
> static void rt6_remove_exception(struct rt6_exception_bucket *bucket,
> struct rt6_exception *rt6_ex)
> {
> + struct fib6_info *from;
> struct net *net;
>
> if (!bucket || !rt6_ex)
> return;
>
> + /* purge completely the exception to allow releasing the held resources:
> + * some [sk] cache may keep the dst around for unlimited time
> + */
> + from = rcu_dereference_protected(rt6_ex->rt6i->from,
> + lockdep_is_held(&rt6_exception_lock));
> + rcu_assign_pointer(rt6_ex->rt6i->from, NULL);
> + fib6_info_release(from);
> + dst_dev_put(&rt6_ex->rt6i->dst);
> +
> net = dev_net(rt6_ex->rt6i->dst.dev);
uhm... This is possibly racy, if dev goes away on dst_dev_put(). I'll
send a v2 reordering the operation so that we don't access dev (and net
) after dst_dev_put().
Sorry for the noise,
Paolo
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Write in tls_push_record (2)
From: Dmitry Vyukov @ 2019-02-20 15:54 UTC (permalink / raw)
To: syzbot
Cc: aviadye, borisp, davejwatson, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <00000000000087c36f05727375d2@google.com>
On Thu, Aug 2, 2018 at 3:05 PM syzbot
<syzbot+3d650eba9d63b8de7478@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 44960f2a7b63 staging: ashmem: Fix SIGBUS crash when traver..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f7ea72400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
> dashboard link: https://syzkaller.appspot.com/bug?extid=3d650eba9d63b8de7478
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3d650eba9d63b8de7478@syzkaller.appspotmail.com
This is probably:
#syz dup: KASAN: out-of-bounds Write in tls_push_record
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in tls_fill_prepend include/net/tls.h:339
> [inline]
> BUG: KASAN: slab-out-of-bounds in tls_push_record+0x1091/0x1400
> net/tls/tls_sw.c:239
> Write of size 1 at addr ffff88019c5d8000 by task syz-executor2/11760
>
> CPU: 0 PID: 11760 Comm: syz-executor2 Not tainted 4.18.0-rc7+ #172
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_store1_noabort+0x17/0x20 mm/kasan/report.c:435
> tls_fill_prepend include/net/tls.h:339 [inline]
> tls_push_record+0x1091/0x1400 net/tls/tls_sw.c:239
> tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
> tls_handle_open_record net/tls/tls_main.c:164 [inline]
> tls_sk_proto_close+0x74c/0xae0 net/tls/tls_main.c:264
> inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
> __sock_release+0xd7/0x260 net/socket.c:600
> sock_close+0x19/0x20 net/socket.c:1151
> __fput+0x355/0x8b0 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:192 [inline]
> exit_to_usermode_loop+0x313/0x370 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4105c1
> Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 34 19 00 00 c3 48
> 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
> 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
> RSP: 002b:0000000000a3feb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 0000000000000014 RCX: 00000000004105c1
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000013
> RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000a3fde0 R11: 0000000000000293 R12: 0000000000000000
> R13: 000000000002fd87 R14: 0000000000000094 R15: badc0ffeebadface
>
> Allocated by task 2597:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
> getname_flags+0xd0/0x5a0 fs/namei.c:140
> user_path_at_empty+0x2d/0x50 fs/namei.c:2584
> user_path_at include/linux/namei.h:57 [inline]
> vfs_statx+0x129/0x210 fs/stat.c:185
> vfs_stat include/linux/fs.h:3102 [inline]
> __do_sys_newstat+0x8f/0x110 fs/stat.c:337
> __se_sys_newstat fs/stat.c:333 [inline]
> __x64_sys_newstat+0x54/0x80 fs/stat.c:333
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 2597:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
> putname+0xf2/0x130 fs/namei.c:261
> filename_lookup+0x397/0x510 fs/namei.c:2330
> user_path_at_empty+0x40/0x50 fs/namei.c:2584
> user_path_at include/linux/namei.h:57 [inline]
> vfs_statx+0x129/0x210 fs/stat.c:185
> vfs_stat include/linux/fs.h:3102 [inline]
> __do_sys_newstat+0x8f/0x110 fs/stat.c:337
> __se_sys_newstat fs/stat.c:333 [inline]
> __x64_sys_newstat+0x54/0x80 fs/stat.c:333
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88019c5d8980
> which belongs to the cache names_cache of size 4096
> The buggy address is located 2432 bytes to the left of
> 4096-byte region [ffff88019c5d8980, ffff88019c5d9980)
> The buggy address belongs to the page:
> page:ffffea0006717600 count:1 mapcount:0 mapping:ffff8801dad85dc0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea0006470d88 ffffea0006717688 ffff8801dad85dc0
> raw: 0000000000000000 ffff88019c5d8980 0000000100000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88019c5d7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff88019c5d7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ffff88019c5d8000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff88019c5d8080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff88019c5d8100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000087c36f05727375d2%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH net] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: Anders Roxell @ 2019-02-20 15:54 UTC (permalink / raw)
To: Alan Maguire
Cc: Networking, David Miller, kuznet, yoshfuji, Alexei Starovoitov,
Daniel Borkmann, kafai, songliubraving, yhs
In-Reply-To: <alpine.LRH.2.20.1902181230310.25660@dhcp-10-175-210-25.vpn.oracle.com>
On Mon, 18 Feb 2019 at 13:37, Alan Maguire <alan.maguire@oracle.com> wrote:
>
> Naresh Kamboju noted the following oops during execution of selftest
> tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
>
> [ 274.120445] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000000
> [ 274.128285] #PF error: [INSTR]
> [ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
> [ 274.138241] Oops: 0010 [#1] SMP PTI
> [ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
> 5.0.0-rc4-next-20190129 #1
> [ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 274.156526] RIP: 0010: (null)
> [ 274.160280] Code: Bad RIP value.
> [ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.239541] Call Trace:
> [ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
> [ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
> [ 274.250176] gre_fb_xmit+0x330/0x390
> [ 274.253754] gre_tap_xmit+0x128/0x180
> [ 274.257414] dev_hard_start_xmit+0xb7/0x300
> [ 274.261598] sch_direct_xmit+0xf6/0x290
> [ 274.265430] __qdisc_run+0x15d/0x5e0
> [ 274.269007] __dev_queue_xmit+0x2c5/0xc00
> [ 274.273011] ? dev_queue_xmit+0x10/0x20
> [ 274.276842] ? eth_header+0x2b/0xc0
> [ 274.280326] dev_queue_xmit+0x10/0x20
> [ 274.283984] ? dev_queue_xmit+0x10/0x20
> [ 274.287813] arp_xmit+0x1a/0xf0
> [ 274.290952] arp_send_dst.part.19+0x46/0x60
> [ 274.295138] arp_solicit+0x177/0x6b0
> [ 274.298708] ? mod_timer+0x18e/0x440
> [ 274.302281] neigh_probe+0x57/0x70
> [ 274.305684] __neigh_event_send+0x197/0x2d0
> [ 274.309862] neigh_resolve_output+0x18c/0x210
> [ 274.314212] ip_finish_output2+0x257/0x690
> [ 274.318304] ip_finish_output+0x219/0x340
> [ 274.322314] ? ip_finish_output+0x219/0x340
> [ 274.326493] ip_output+0x76/0x240
> [ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
> [ 274.334510] ip_local_out+0x3f/0x70
> [ 274.337992] ip_send_skb+0x19/0x40
> [ 274.341391] ip_push_pending_frames+0x33/0x40
> [ 274.345740] raw_sendmsg+0xc15/0x11d0
> [ 274.349403] ? __might_fault+0x85/0x90
> [ 274.353151] ? _copy_from_user+0x6b/0xa0
> [ 274.357070] ? rw_copy_check_uvector+0x54/0x130
> [ 274.361604] inet_sendmsg+0x42/0x1c0
> [ 274.365179] ? inet_sendmsg+0x42/0x1c0
> [ 274.368937] sock_sendmsg+0x3e/0x50
> [ 274.372460] ___sys_sendmsg+0x26f/0x2d0
> [ 274.376293] ? lock_acquire+0x95/0x190
> [ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
> [ 274.384307] ? lock_acquire+0x95/0x190
> [ 274.388053] ? __audit_syscall_entry+0xdd/0x130
> [ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
> [ 274.397461] ? __audit_syscall_entry+0xdd/0x130
> [ 274.401989] ? trace_hardirqs_on+0x4c/0x100
> [ 274.406173] __sys_sendmsg+0x63/0xa0
> [ 274.409744] ? __sys_sendmsg+0x63/0xa0
> [ 274.413488] __x64_sys_sendmsg+0x1f/0x30
> [ 274.417405] do_syscall_64+0x55/0x190
> [ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 274.426113] RIP: 0033:0x7ff4ae0e6e87
> [ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
> 00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
> 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
> 24 08
> [ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002e
> [ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
> [ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
> [ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
> [ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
> [ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
> [ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
> ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
> test_bpf]
> [ 274.504634] CR2: 0000000000000000
> [ 274.507976] ---[ end trace 196d18386545eae1 ]---
> [ 274.512588] RIP: 0010: (null)
> [ 274.516334] Code: Bad RIP value.
> [ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
> [ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
> (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
> [ 274.620387] ------------[ cut here ]------------
>
> I'm also seeing the same failure on x86_64, and it reproduces
> consistently.
>
> From poking around it looks like the skb's dst entry is being used
> to calculate the mtu in:
>
> mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> ...but because that dst_entry has an "ops" value set to md_dst_ops,
> the various ops (including mtu) are not set:
>
> crash> struct sk_buff._skb_refdst ffff928f87447700 -x
> _skb_refdst = 0xffffcd6fbf5ea590
> crash> struct dst_entry.ops 0xffffcd6fbf5ea590
> ops = 0xffffffffa0193800
> crash> struct dst_ops.mtu 0xffffffffa0193800
> mtu = 0x0
> crash>
>
> I confirmed that the dst entry also has dst->input set to
> dst_md_discard, so it looks like it's an entry that's been
> initialized via __metadata_dst_init alright.
>
> I think the fix here is to use skb_valid_dst(skb) - it checks
> for DST_METADATA also, and with that fix in place, the
> problem - which was previously 100% reproducible - disappears.
>
> The below patch resolves the panic and all bpf tunnel tests pass
> without incident.
>
> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
I saw the failure on hikey (arm64) also, with this patch test bpf
test_tunnel.sh passed.
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Cheers,
Anders
> ---
> net/ipv4/ip_tunnel.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 893f013..5dcf50c 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -515,9 +515,10 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len
> - sizeof(struct iphdr) - tunnel_hlen;
> else
> - mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
> + mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> - skb_dst_update_pmtu(skb, mtu);
> + if (skb_valid_dst(skb))
> + skb_dst_update_pmtu(skb, mtu);
>
> if (skb->protocol == htons(ETH_P_IP)) {
> if (!skb_is_gso(skb) &&
> @@ -530,9 +531,11 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> }
> #if IS_ENABLED(CONFIG_IPV6)
> else if (skb->protocol == htons(ETH_P_IPV6)) {
> - struct rt6_info *rt6 = (struct rt6_info *)skb_dst(skb);
> + struct rt6_info *rt6;
> __be32 daddr;
>
> + rt6 = skb_valid_dst(skb) ? (struct rt6_info *)skb_dst(skb) :
> + NULL;
> daddr = md ? dst : tunnel->parms.iph.daddr;
>
> if (rt6 && mtu < dst_mtu(skb_dst(skb)) &&
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: skb_can_coalesce() merges tcp frags with XFS-related slab objects
From: Eric Dumazet @ 2019-02-20 15:53 UTC (permalink / raw)
To: Vasily Averin, David S. Miller
Cc: Linux Kernel Network Developers, Ilya Dryomov
In-Reply-To: <f8fde7da-9402-4e17-1bcc-cba08f1ec18b@virtuozzo.com>
On 02/20/2019 05:34 AM, Vasily Averin wrote:
> Dear David,
>
> currently do_tcp_sendpages() calls skb_can_coalesce() to merge proper tcp fragments.
> If these fragments are slab objects and the data is not transferred out of the local host
> then tcp_recvmsg() can crash host on BUG_ON (see [2] below).
>
> There is known usecase when slab objects are provided to tcp_sendpage:
> XFS over locally landed network blockdevice.
>
> I found few such cases:
> - _drbd_send_page() had PageSlab() check log time ago.
> - recently Ilya Dryomov fixed it in ceph
> by commit 7e241f647dc7 "libceph: fall back to sendmsg for slab pages"
>
> Recently OpenVZ team noticed this problem during experiments with
> XFS over locally-landed iscsi target.
>
> I would note: triggered BUG is not a real problem but false alert,
> that though crashes host.
>
> I can fix last problem by adding PageSlab() into iscsi_tcp_segment_map(),
> however it does not fix the problem completely,
> there are chances that the problem will be reproduced again with some other filesystems
> or with some other kind of network blockdevice.
>
> David, what do you think, is it probably better to add PageSlab() check
> directly into skb_can_coalesce()? (see [1] below)
>
No, this would be wrong.
There is no way a page fragment can be backed by slab object,
since a page fragment can be shared (the page refcount needs to be manipulated, without slab/slub
being aware of this)
Please fix the callers.
> Thank you,
> Vasily Averin
>
> [1] The patch preventing the merge of the Slab-based tcp fragments
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 95d25b010a25..e1d200ba1fef 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -3089,7 +3089,7 @@ static inline bool skb_can_coalesce(struct sk_buff *skb, int i,
> if (i) {
> const struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i - 1];
>
> - return page == skb_frag_page(frag) &&
> + return page == skb_frag_page(frag) && !PageSlab(page) &&
> off == frag->page_offset + skb_frag_size(frag);
> }
> return false;
>
> [2] oops example, RHEL7-based OpenVZ node, XFS over locally-landed iscsi target
>
> [ 4902.545219] usercopy: kernel memory exposure attempt detected from ffff8c1497c92200 (kmalloc-512) (1024 bytes)
> [ 4902.550585] ------------[ cut here ]------------
> [ 4902.552472] kernel BUG at mm/usercopy.c:72!
> [ 4902.554148] invalid opcode: 0000 [#1] SMP
> [ 4902.555906] Modules linked in: nf_conntrack_netlink xt_mark raw_diag udp_diag netlink_diag af_packet_diag unix_diag dm_service_time iscsi_tcp libiscsi_tcp libiscsi xfs xt_CHECKSUM ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables binfmt_misc tun devlink tcp_diag inet_diag ip_set nfnetlink fuse kvm_intel ppdev kvm i2c_piix4 irqbypass sg virtio_balloon parport_pc parport joydev pcspkr libcrc32c br_netfilter veth overlay ip6_vzprivnet ip6_vznetstat
> [ 4903.413397] ip_vznetstat ip_vzprivnet vziolimit vzevent vzlist vzstat vznetstat vznetdev vzmon vzdev bridge pio_kaio pio_nfs pio_direct pfmt_raw pfmt_ploop1 ploop ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod crct10dif_generic cdrom crct10dif_common ata_generic pata_acpi 8021q garp mrp stp llc virtio_net virtio_console virtio_scsi bochs_drm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ata_piix scsi_transport_iscsi drm libata crc32c_intel serio_raw virtio_pci virtio_ring dm_multipath virtio drm_panel_orientation_quirks floppy sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ip_tables]
> [ 4903.433902] CPU: 0 PID: 13793 Comm: tgtd ve: 0 Kdump: loaded Not tainted 3.10.0-957.1.3.vz7.83.4 #1 83.4
> [ 4903.436975] Hardware name: Virtuozzo KVM, BIOS 1.10.2-3.1.vz7.3 04/01/2014
> [ 4903.439474] task: ffff8c14f898c740 ti: ffff8c14f8a94000 task.ti: ffff8c14f8a94000
> [ 4903.442278] RIP: 0010:[<ffffffff9ce59427>] [<ffffffff9ce59427>] __check_object_size+0x87/0x250
> [ 4903.445370] RSP: 0018:ffff8c14f8a97b58 EFLAGS: 00010246
> [ 4903.447547] RAX: 0000000000000062 RBX: ffff8c1497c92200 RCX: 0000000000000000
> [ 4903.450108] RDX: 0000000000000000 RSI: ffff8c167fc138d8 RDI: ffff8c167fc138d8
> [ 4903.452753] RBP: ffff8c14f8a97b78 R08: 0000000000000004 R09: ffff8c166d14af00
> [ 4903.455451] R10: 0000000000000080 R11: ffff97b6016ffff8 R12: 0000000000000400
> [ 4903.458142] R13: 0000000000000001 R14: ffff8c1497c92600 R15: 0000000000000400
> [ 4903.460759] FS: 00007fd59b2b7740(0000) GS:ffff8c167fc00000(0000) knlGS:0000000000000000
> [ 4903.463776] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 4903.466111] CR2: 0000000002701b58 CR3: 00000000b8a98000 CR4: 00000000000006f0
> [ 4903.468860] Call Trace:
> [ 4903.470483] [<ffffffff9cfb310d>] memcpy_toiovec+0x4d/0xb0
> [ 4903.472780] [<ffffffff9d2589e8>] skb_copy_datagram_iovec+0x128/0x280
> [ 4903.475388] [<ffffffff9d2c0646>] tcp_recvmsg+0x246/0xbb0
> [ 4903.477884] [<ffffffff9cdd42cd>] ? __alloc_pages_nodemask+0x26d/0x610
> [ 4903.480432] [<ffffffff9d2ef1d0>] inet_recvmsg+0x80/0xb0
> [ 4903.482718] [<ffffffff9d2467bc>] sock_aio_read.part.12+0x14c/0x170
> [ 4903.485255] [<ffffffff9d246801>] sock_aio_read+0x21/0x30
> [ 4903.487495] [<ffffffff9ce5edd6>] do_sync_read+0x96/0xe0
> [ 4903.489710] [<ffffffff9ce5f8b5>] vfs_read+0x145/0x170
> [ 4903.491975] [<ffffffff9ce606cf>] SyS_read+0x7f/0xf0
> [ 4903.494179] [<ffffffff9d3a4de1>] ? system_call_after_swapgs+0xae/0x146
> [ 4903.496684] [<ffffffff9d3a4e9b>] system_call_fastpath+0x22/0x27
> [ 4903.499143] [<ffffffff9d3a4de1>] ? system_call_after_swapgs+0xae/0x146
> [ 4903.501748] Code: 45 d1 48 c7 c6 f8 c3 68 9d 48 c7 c1 93 5e 69 9d 48 0f 45 f1 49 89 c0 4d 89 e1 48 89 d9 48 c7 c7 68 2b 69 9d 31 c0 e8 4f 1e 53 00 <0f> 0b 0f 1f 80 00 00 00 00 48 c7 c0 00 00 c0 9c 4c 39 f0 73 0d
> [ 4903.510508] RIP [<ffffffff9ce59427>] __check_object_size+0x87/0x250
> [ 4903.513149] RSP <ffff8c14f8a97b58>
>
^ permalink raw reply
* [PATCH net-next] gso: validate gso_type on ipip style tunnels
From: Willem de Bruijn @ 2019-02-20 15:52 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
Commit 121d57af308d ("gso: validate gso_type in GSO handlers") added
gso_type validation to existing gso_segment callback functions, to
filter out illegal and potentially dangerous SKB_GSO_DODGY packets.
Convert tunnels that now call inet_gso_segment and ipv6_gso_segment
directly to have their own callbacks and extend validation to these.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/af_inet.c | 11 ++++++++++-
net/ipv6/ip6_offload.c | 33 ++++++++++++++++++++++++++++++---
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 0dfb72c46671..eab3ebde981e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1385,6 +1385,15 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb,
}
EXPORT_SYMBOL(inet_gso_segment);
+static struct sk_buff *ipip_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP4))
+ return ERR_PTR(-EINVAL);
+
+ return inet_gso_segment(skb, features);
+}
+
INDIRECT_CALLABLE_DECLARE(struct sk_buff *tcp4_gro_receive(struct list_head *,
struct sk_buff *));
INDIRECT_CALLABLE_DECLARE(struct sk_buff *udp4_gro_receive(struct list_head *,
@@ -1861,7 +1870,7 @@ static struct packet_offload ip_packet_offload __read_mostly = {
static const struct net_offload ipip_offload = {
.callbacks = {
- .gso_segment = inet_gso_segment,
+ .gso_segment = ipip_gso_segment,
.gro_receive = ipip_gro_receive,
.gro_complete = ipip_gro_complete,
},
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 5c045691c302..345882d9c061 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -383,9 +383,36 @@ static struct packet_offload ipv6_packet_offload __read_mostly = {
},
};
+static struct sk_buff *sit_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP4))
+ return ERR_PTR(-EINVAL);
+
+ return ipv6_gso_segment(skb, features);
+}
+
+static struct sk_buff *ip4ip6_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP6))
+ return ERR_PTR(-EINVAL);
+
+ return inet_gso_segment(skb, features);
+}
+
+static struct sk_buff *ip6ip6_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+{
+ if (!(skb_shinfo(skb)->gso_type & SKB_GSO_IPXIP6))
+ return ERR_PTR(-EINVAL);
+
+ return ipv6_gso_segment(skb, features);
+}
+
static const struct net_offload sit_offload = {
.callbacks = {
- .gso_segment = ipv6_gso_segment,
+ .gso_segment = sit_gso_segment,
.gro_receive = sit_ip6ip6_gro_receive,
.gro_complete = sit_gro_complete,
},
@@ -393,7 +420,7 @@ static const struct net_offload sit_offload = {
static const struct net_offload ip4ip6_offload = {
.callbacks = {
- .gso_segment = inet_gso_segment,
+ .gso_segment = ip4ip6_gso_segment,
.gro_receive = ip4ip6_gro_receive,
.gro_complete = ip4ip6_gro_complete,
},
@@ -401,7 +428,7 @@ static const struct net_offload ip4ip6_offload = {
static const struct net_offload ip6ip6_offload = {
.callbacks = {
- .gso_segment = ipv6_gso_segment,
+ .gso_segment = ip6ip6_gso_segment,
.gro_receive = sit_ip6ip6_gro_receive,
.gro_complete = ip6ip6_gro_complete,
},
--
2.21.0.rc0.258.g878e2cd30e-goog
^ permalink raw reply related
* Re: [PATCH 0/6] ARM: dts: ti: cpsw: switch to phy-gmii-sel phy driver
From: Tony Lindgren @ 2019-02-20 15:48 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, Kishon Vijay Abraham I, Rob Herring, netdev,
Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [190220 07:26]:
> Hi Tony,
>
> Hence prerequisite patches [1] have been merged already I'm sending final set
> of DT patches to complete conversation of TI CPSW driver to use phy-gmii-sel
> phy driver instead of cpsw-phy-sel.
>
> [1] https://lkml.org/lkml/2018/11/26/154
Great, I was wondering about update of that series, will
apply.
Thanks and welcome back!
Tony
^ permalink raw reply
* Re: [PATCH] tcp: Reset tcp connections in SYN-SENT state
From: Eric Dumazet @ 2019-02-20 15:47 UTC (permalink / raw)
To: Devi Sandeep Endluri V V; +Cc: netdev, subashab, sharathv, ssaha, strenche
In-Reply-To: <20190220142754.GA5073@dendluri-linux.qualcomm.com>
On Wed, Feb 20, 2019 at 6:28 AM Devi Sandeep Endluri V V
<dendluri@codeaurora.org> wrote:
>
> Userspace sends tcp connection (sock) destroy on network permission
> change. Kernel though doesn't send reset for the connections in
> SYN-SENT state and these connections continue to remain. Even as
> per RFC 793, there is no hard rule to not send RST on ABORT in
> this state. Change to make sure RST are send for connections in
> syn-sent state to avoid lingering connections on network switch.
>
> References from RFC 793
>
> ABORT Call
>
> SYN-SENT STATE
>
> All queued SENDs and RECEIVEs should be given "connection reset"
> notification, delete the TCB, enter CLOSED state, and return.
>
> SEGMENT ARRIVES
>
> If the state is SYN-SENT then
> If the RST bit is set
>
> If the ACK was acceptable then signal the user "error:
> connection reset", drop the segment, enter CLOSED state,
> delete TCB, and return. Otherwise (no ACK) drop the segment
> and return.
>
> Signed-off-by: Devi Sandeep Endluri V V <dendluri@codeaurora.org>
> ---
> net/ipv4/tcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git net/ipv4/tcp.c net/ipv4/tcp.c
> index cf3c509..8569dc5e 100644
> --- net/ipv4/tcp.c
> +++ net/ipv4/tcp.c
> @@ -2495,7 +2495,7 @@ static inline bool tcp_need_reset(int state)
> {
> return (1 << state) &
> (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT | TCPF_FIN_WAIT1 |
> - TCPF_FIN_WAIT2 | TCPF_SYN_RECV);
> + TCPF_FIN_WAIT2 | TCPF_SYN_RECV | TCPF_SYN_SENT);
> }
>
> static void tcp_rtx_queue_purge(struct sock *sk)
Hi
1) I do not believe this patch is complete :
You have not changed tcp_disconnect() which seems to have dead code
if we apply your patch.
2) I am not sure we want to send yet another packet if the prior SYN
packets elect no answer.
(It is not clear if your patch applies to this case)
3) If we do not RESET, the other side has not seen the 3rd packet and
should eventually exit from SYN_RECV state and die.
4) A RESET can be lost on the network, and nothing will retransmit it.
Can you describe the use case more precisely, because it seems in
contradiction of a feature that we plan to upstream.
(TCP_SILENT_CLOSE : do not send flood of RST/FIN when a gigantic
server process prematurely dies)
Thanks.
^ permalink raw reply
* [PATCH net-next 2/2] ixgbe: remove umem from adapter
From: Jan Sokolowski @ 2019-02-20 15:28 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, intel-wired-lan, Jan Sokolowski
In-Reply-To: <20190220152826.14083-1-jan.sokolowski@intel.com>
As current implementation of netdev already contains and provides
umems for us, we no longer have the need to contain these
structures in ixgbe_adapter.
Refactor the code to operate on netdev-provided umems.
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 11 +--
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 77 ++++----------------
2 files changed, 19 insertions(+), 69 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 5f5db6eb261e..aa923d6d596b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -775,11 +775,6 @@ struct ixgbe_adapter {
#ifdef CONFIG_IXGBE_IPSEC
struct ixgbe_ipsec *ipsec;
#endif /* CONFIG_IXGBE_IPSEC */
-
- /* AF_XDP zero-copy */
- struct xdp_umem **xsk_umems;
- u16 num_xsk_umems_used;
- u16 num_xsk_umems;
};
static inline u8 ixgbe_max_rss_indices(struct ixgbe_adapter *adapter)
@@ -1040,4 +1035,10 @@ static inline int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter,
static inline int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter,
u32 *mbuf, u32 vf) { return -EACCES; }
#endif /* CONFIG_IXGBE_IPSEC */
+
+static inline bool ixgbe_enabled_xdp_adapter(struct ixgbe_adapter *adapter)
+{
+ return !!adapter->xdp_prog;
+}
+
#endif /* _IXGBE_H_ */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index fccfb422e45c..6587a583c8c7 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -14,58 +14,10 @@ struct xdp_umem *ixgbe_xsk_umem(struct ixgbe_adapter *adapter,
bool xdp_on = READ_ONCE(adapter->xdp_prog);
int qid = ring->ring_idx;
- if (!adapter->xsk_umems || !adapter->xsk_umems[qid] ||
- qid >= adapter->num_xsk_umems || !xdp_on ||
- !test_bit(qid, adapter->af_xdp_zc_qps))
+ if (!xdp_on || !test_bit(qid, adapter->af_xdp_zc_qps))
return NULL;
- return adapter->xsk_umems[qid];
-}
-
-static int ixgbe_alloc_xsk_umems(struct ixgbe_adapter *adapter)
-{
- if (adapter->xsk_umems)
- return 0;
-
- adapter->num_xsk_umems_used = 0;
- adapter->num_xsk_umems = adapter->num_rx_queues;
- adapter->xsk_umems = kcalloc(adapter->num_xsk_umems,
- sizeof(*adapter->xsk_umems),
- GFP_KERNEL);
- if (!adapter->xsk_umems) {
- adapter->num_xsk_umems = 0;
- return -ENOMEM;
- }
-
- return 0;
-}
-
-static int ixgbe_add_xsk_umem(struct ixgbe_adapter *adapter,
- struct xdp_umem *umem,
- u16 qid)
-{
- int err;
-
- err = ixgbe_alloc_xsk_umems(adapter);
- if (err)
- return err;
-
- adapter->xsk_umems[qid] = umem;
- adapter->num_xsk_umems_used++;
-
- return 0;
-}
-
-static void ixgbe_remove_xsk_umem(struct ixgbe_adapter *adapter, u16 qid)
-{
- adapter->xsk_umems[qid] = NULL;
- adapter->num_xsk_umems_used--;
-
- if (adapter->num_xsk_umems == 0) {
- kfree(adapter->xsk_umems);
- adapter->xsk_umems = NULL;
- adapter->num_xsk_umems = 0;
- }
+ return xdp_get_umem_from_qid(adapter->netdev, qid);
}
static int ixgbe_xsk_umem_dma_map(struct ixgbe_adapter *adapter,
@@ -114,6 +66,7 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
struct xdp_umem *umem,
u16 qid)
{
+ struct net_device *netdev = adapter->netdev;
struct xdp_umem_fq_reuse *reuseq;
bool if_running;
int err;
@@ -121,12 +74,9 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
if (qid >= adapter->num_rx_queues)
return -EINVAL;
- if (adapter->xsk_umems) {
- if (qid >= adapter->num_xsk_umems)
- return -EINVAL;
- if (adapter->xsk_umems[qid])
- return -EBUSY;
- }
+ if (qid >= netdev->real_num_rx_queues ||
+ qid >= netdev->real_num_tx_queues)
+ return -EINVAL;
reuseq = xsk_reuseq_prepare(adapter->rx_ring[0]->count);
if (!reuseq)
@@ -139,13 +89,12 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
return err;
if_running = netif_running(adapter->netdev) &&
- READ_ONCE(adapter->xdp_prog);
+ ixgbe_enabled_xdp_adapter(adapter);
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
set_bit(qid, adapter->af_xdp_zc_qps);
- err = ixgbe_add_xsk_umem(adapter, umem, qid);
if (if_running)
ixgbe_txrx_ring_enable(adapter, qid);
@@ -155,21 +104,21 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
static int ixgbe_xsk_umem_disable(struct ixgbe_adapter *adapter, u16 qid)
{
+ struct xdp_umem *umem;
bool if_running;
- if (!adapter->xsk_umems || qid >= adapter->num_xsk_umems ||
- !adapter->xsk_umems[qid])
+ umem = xdp_get_umem_from_qid(adapter->netdev, qid);
+ if (!umem)
return -EINVAL;
if_running = netif_running(adapter->netdev) &&
- READ_ONCE(adapter->xdp_prog);
+ ixgbe_enabled_xdp_adapter(adapter);
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
clear_bit(qid, adapter->af_xdp_zc_qps);
- ixgbe_xsk_umem_dma_unmap(adapter, adapter->xsk_umems[qid]);
- ixgbe_remove_xsk_umem(adapter, qid);
+ ixgbe_xsk_umem_dma_unmap(adapter, umem);
if (if_running)
ixgbe_txrx_ring_enable(adapter, qid);
@@ -748,7 +697,7 @@ int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
if (qid >= adapter->num_xdp_queues)
return -ENXIO;
- if (!adapter->xsk_umems || !adapter->xsk_umems[qid])
+ if (!adapter->xdp_ring[qid]->xsk_umem)
return -ENXIO;
ring = adapter->xdp_ring[qid];
--
2.18.1
^ permalink raw reply related
* [PATCH net-next 1/2] ixgbe: add tracking of AF_XDP zero-copy state for each queue pair
From: Jan Sokolowski @ 2019-02-20 15:28 UTC (permalink / raw)
To: intel-wired-lan; +Cc: netdev, intel-wired-lan, Jan Sokolowski
Here, we add a bitmap to the ixgbe_adapter that tracks if a
certain queue pair has been "zero-copy enabled" via the ndo_bpf.
The bitmap is used in ixgbe_xsk_umem, and enables zero-copy if
and only if XDP is enabled, the corresponding qid in the bitmap
is set, and the umem is non-NULL;
Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 5 ++++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 08d85e336bd4..5f5db6eb261e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -635,6 +635,7 @@ struct ixgbe_adapter {
/* XDP */
int num_xdp_queues;
struct ixgbe_ring *xdp_ring[MAX_XDP_QUEUES];
+ unsigned long *af_xdp_zc_qps; /* tracks AF_XDP ZC enabled rings */
/* TX */
struct ixgbe_ring *tx_ring[MAX_TX_QUEUES] ____cacheline_aligned_in_smp;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 38c430b94ae3..46fc6fb8bb1b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6284,6 +6284,10 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter,
if (ixgbe_init_rss_key(adapter))
return -ENOMEM;
+ adapter->af_xdp_zc_qps = bitmap_zalloc(MAX_XDP_QUEUES, GFP_KERNEL);
+ if (!adapter->af_xdp_zc_qps)
+ return -ENOMEM;
+
/* Set MAC specific capability flags and exceptions */
switch (hw->mac.type) {
case ixgbe_mac_82598EB:
@@ -11153,6 +11157,7 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
kfree(adapter->jump_tables[0]);
kfree(adapter->mac_table);
kfree(adapter->rss_key);
+ bitmap_free(adapter->af_xdp_zc_qps);
err_ioremap:
disable_dev = !test_and_set_bit(__IXGBE_DISABLED, &adapter->state);
free_netdev(netdev);
@@ -11241,6 +11246,7 @@ static void ixgbe_remove(struct pci_dev *pdev)
kfree(adapter->mac_table);
kfree(adapter->rss_key);
+ bitmap_free(adapter->af_xdp_zc_qps);
disable_dev = !test_and_set_bit(__IXGBE_DISABLED, &adapter->state);
free_netdev(netdev);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
index 51c29358c2a9..fccfb422e45c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
@@ -15,7 +15,8 @@ struct xdp_umem *ixgbe_xsk_umem(struct ixgbe_adapter *adapter,
int qid = ring->ring_idx;
if (!adapter->xsk_umems || !adapter->xsk_umems[qid] ||
- qid >= adapter->num_xsk_umems || !xdp_on)
+ qid >= adapter->num_xsk_umems || !xdp_on ||
+ !test_bit(qid, adapter->af_xdp_zc_qps))
return NULL;
return adapter->xsk_umems[qid];
@@ -143,6 +144,7 @@ static int ixgbe_xsk_umem_enable(struct ixgbe_adapter *adapter,
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
+ set_bit(qid, adapter->af_xdp_zc_qps);
err = ixgbe_add_xsk_umem(adapter, umem, qid);
if (if_running)
@@ -165,6 +167,7 @@ static int ixgbe_xsk_umem_disable(struct ixgbe_adapter *adapter, u16 qid)
if (if_running)
ixgbe_txrx_ring_disable(adapter, qid);
+ clear_bit(qid, adapter->af_xdp_zc_qps);
ixgbe_xsk_umem_dma_unmap(adapter, adapter->xsk_umems[qid]);
ixgbe_remove_xsk_umem(adapter, qid);
--
2.18.1
^ permalink raw reply related
* [PATCH 0/6] ARM: dts: ti: cpsw: switch to phy-gmii-sel phy driver
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
Hi Tony,
Hence prerequisite patches [1] have been merged already I'm sending final set
of DT patches to complete conversation of TI CPSW driver to use phy-gmii-sel
phy driver instead of cpsw-phy-sel.
[1] https://lkml.org/lkml/2018/11/26/154
Grygorii Strashko (6):
ARM: dts: dra7: switch to use phy-gmii-sel
ARM: dts: dm814x: switch to use phy-gmii-sel
ARM: dts: am4372: switch to use phy-gmii-sel
ARM: dts: am335x: switch to use phy-gmii-sel
dt-bindings: net: ti: deprecate cpsw-phy-sel bindings
net: ethernet: ti: cpsw: deprecate cpsw-phy-sel driver
.../devicetree/bindings/net/cpsw-phy-sel.txt | 2 +-
arch/arm/boot/dts/am335x-baltos-ir2110.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir3220.dts | 4 ----
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 4 ----
arch/arm/boot/dts/am335x-chiliboard.dts | 4 ----
arch/arm/boot/dts/am335x-icev2.dts | 4 ----
arch/arm/boot/dts/am335x-igep0033.dtsi | 4 ----
arch/arm/boot/dts/am335x-lxm.dts | 4 ----
.../boot/dts/am335x-moxa-uc-2100-common.dtsi | 5 -----
arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts | 5 -----
arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ----
arch/arm/boot/dts/am33xx-l4.dtsi | 15 ++++++++-------
arch/arm/boot/dts/am437x-l4.dtsi | 17 +++++++++--------
arch/arm/boot/dts/am43x-epos-evm.dts | 5 +----
arch/arm/boot/dts/dm814x.dtsi | 15 +++++++++------
arch/arm/boot/dts/dra7-l4.dtsi | 15 ++++++++-------
drivers/net/ethernet/ti/Kconfig | 6 +++---
drivers/net/ethernet/ti/cpsw.h | 6 ++++++
18 files changed, 45 insertions(+), 78 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 3/6] ARM: dts: am4372: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/am437x-l4.dtsi | 17 +++++++++--------
arch/arm/boot/dts/am43x-epos-evm.dts | 5 +----
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
index ca0896f80248..85c6f4ff1824 100644
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -280,12 +280,6 @@
#size-cells = <1>;
ranges = <0 0 0x4000>;
- phy_sel: cpsw-phy-sel@650 {
- compatible = "ti,am43xx-cpsw-phy-sel";
- reg= <0x650 0x4>;
- reg-names = "gmii-sel";
- };
-
am43xx_pinmux: pinmux@800 {
compatible = "ti,am437-padconf",
"pinctrl-single";
@@ -300,11 +294,17 @@
};
scm_conf: scm_conf@0 {
- compatible = "syscon";
+ compatible = "syscon", "simple-bus";
reg = <0x0 0x800>;
#address-cells = <1>;
#size-cells = <1>;
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,am43xx-phy-gmii-sel";
+ reg = <0x650 0x4>;
+ #phy-cells = <2>;
+ };
+
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
@@ -555,7 +555,6 @@
cpts_clock_shift = <29>;
ranges = <0 0 0x8000>;
syscon = <&scm_conf>;
- cpsw-phy-sel = <&phy_sel>;
davinci_mdio: mdio@1000 {
compatible = "ti,am4372-mdio","ti,cpsw-mdio","ti,davinci_mdio";
@@ -572,11 +571,13 @@
cpsw_emac0: slave@200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1 0>;
};
cpsw_emac1: slave@300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 2 0>;
};
};
};
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 4ea753b3ee43..9dfd80e3b76e 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -584,10 +584,7 @@
&cpsw_emac0 {
phy-handle = <ðphy0>;
phy-mode = "rmii";
-};
-
-&phy_sel {
- rmii-clock-ext;
+ phys = <&phy_gmii_sel 1 1>;
};
&i2c0 {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/6] ARM: dts: dm814x: switch to use phy-gmii-sel
From: Grygorii Strashko @ 2019-02-20 15:25 UTC (permalink / raw)
To: David S. Miller, Kishon Vijay Abraham I, Rob Herring,
Tony Lindgren
Cc: netdev, Sekhar Nori, linux-kernel, linux-omap, devicetree,
linux-arm-kernel, Grygorii Strashko
In-Reply-To: <1550676319-6440-1-git-send-email-grygorii.strashko@ti.com>
Switch to use phy-gmii-sel PHY instead of cpsw-phy-sel.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/dm814x.dtsi | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dm814x.dtsi b/arch/arm/boot/dts/dm814x.dtsi
index 601c57afd4fe..413ae19dd5f0 100644
--- a/arch/arm/boot/dts/dm814x.dtsi
+++ b/arch/arm/boot/dts/dm814x.dtsi
@@ -343,6 +343,12 @@
#size-cells = <1>;
ranges = <0 0 0x800>;
+ phy_gmii_sel: phy-gmii-sel {
+ compatible = "ti,dm814-phy-gmii-sel";
+ reg = <0x650 0x4>;
+ #phy-cells = <1>;
+ };
+
scm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
@@ -549,17 +555,14 @@
cpsw_emac0: slave@4a100200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
+ phys = <&phy_gmii_sel 1>;
+
};
cpsw_emac1: slave@4a100300 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
- };
-
- phy_sel: cpsw-phy-sel@48140650 {
- compatible = "ti,am3352-cpsw-phy-sel";
- reg= <0x48140650 0x4>;
- reg-names = "gmii-sel";
+ phys = <&phy_gmii_sel 2>;
};
};
--
2.17.1
^ 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