* UBSAN: Undefined behaviour in ./include/net/route.h:239:2: member access within null pointer of type 'struct rtable'
From: Paul Menzel @ 2018-07-20 7:46 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel
Dear Linux folks,
Enabling the undefined behavior sanitizer and building GNU/Linux
4.18-rc5+ (with some unrelated commits) with GCC 8.1.0 from Debian
Sid/unstable, the warning below is shown.
> [ 8.083532] ================================================================================
> [ 8.083781] UBSAN: Undefined behaviour in ./include/net/route.h:239:2
> [ 8.083953] member access within null pointer of type 'struct rtable'
> [ 8.084128] CPU: 1 PID: 239 Comm: sd-resolve Not tainted 4.18.0-rc5-00316-g4864b68cedf2 #104
> [ 8.084131] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
> [ 8.084133] Call Trace:
> [ 8.084147] dump_stack+0x55/0x89
> [ 8.084154] ubsan_epilogue+0xb/0x33
> [ 8.084158] handle_null_ptr_deref+0x7f/0x90
> [ 8.084163] __ubsan_handle_type_mismatch_v1+0x55/0x60
> [ 8.084170] udp_sendmsg+0xb05/0xf80
> [ 8.084176] ? ip_reply_glue_bits+0x80/0x80
> [ 8.084185] ? import_iovec+0x4a/0x160
> [ 8.084190] ? udp_lib_get_port+0x810/0x810
> [ 8.084194] inet_sendmsg+0x77/0x1d0
> [ 8.084198] ? inet_sk_set_state+0x110/0x110
> [ 8.084203] sock_sendmsg+0x5a/0xb0
> [ 8.084207] ___sys_sendmsg+0x102/0x390
> [ 8.084214] ? seccomp_run_filters+0x79/0x220
> [ 8.084218] ? ip4_datagram_release_cb+0x5f/0x2a0
> [ 8.084222] ? udp_lib_rehash+0x17c/0x300
> [ 8.084228] ? __fget_light+0x99/0x110
> [ 8.084230] ? __fdget+0x12/0x20
> [ 8.084234] ? sockfd_lookup_light+0x1e/0xc0
> [ 8.084238] __sys_sendmmsg+0xef/0x1d0
> [ 8.084244] ? alloc_file+0x9b/0x1e0
> [ 8.084249] ? __secure_computing+0x41/0x120
> [ 8.084253] ? syscall_trace_enter+0x1e5/0x470
> [ 8.084258] sys_sendmmsg+0x28/0x30
> [ 8.084262] do_fast_syscall_32+0xce/0x3e0
> [ 8.084267] entry_SYSENTER_32+0x4e/0x7c
> [ 8.084272] EIP: 0xb7fabbb5
> [ 8.084273] Code: 89 e5 8b 55 08 85 d2 8b 80 5c cd ff ff 74 02 89 02 5d c3 8b 04 24 c3 8b 1c 24 c3 8b 3c 24 c3 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
> [ 8.084339] EAX: ffffffda EBX: 0000000c ECX: b75d240c EDX: 00000002
> [ 8.084342] ESI: 00004000 EDI: 00000000 EBP: 03fdd1f0 ESP: b75d22f0
> [ 8.084345] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000282
> [ 8.084349] ================================================================================
Kind regards,
Paul
^ permalink raw reply
* Re: KASAN: use-after-free Read in l2tp_session_create
From: James Chapman @ 2018-07-20 7:53 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: David Miller, Reshetova, Elena, g.nault, Hans Liljestrand,
Kees Cook, LKML, netdev, syzkaller-bugs, Greg Hackmann, syzbot,
Guillaume Nault
In-Reply-To: <CACT4Y+Y1ZskrqsmhWoHWXOigMHX5eyG5nGGyuU6cZ0uNnChSiQ@mail.gmail.com>
On 18/07/18 12:00, Dmitry Vyukov wrote:
> On Tue, Jan 16, 2018 at 7:29 PM, syzbot
> <syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> a8750ddca918032d6349adbf9a4b6555e7db20da
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>
> James,
>
> Did you fix this? You asked syzbot to test a fix for this bug some time ago.
> If yes, did you include the Reported-by tag in the commit? This bug is
> still considered open by syzbot. But it stopped happening ~4 months
> ago:
Yes, I think this has been fixed now. I think it was fixed by
Guillaume's 6b9f34239b00e6956a267abed2bc559ede556ad6 that was actually
to fix another syzbot bug fbeeb5c3b538e8545644 which looks similar to
this one.
> https://syzkaller.appspot.com/bug?id=6fed0854381422329e78d7e16fb9cf4af8c9aef1
> We are also seeing these crashes in 4.4 and 4.9, it would be good to
> backport the fix.
It looks like 6b9f34239b00e6956a267abed2bc559ede556ad6 hasn't made it to
4.9 or 4.4.
>
> Thanks
>
>
>> ==================================================================
>> BUG: KASAN: use-after-free in l2tp_session_create+0xa6d/0xc60
>> net/l2tp/l2tp_core.c:1757
>> Read of size 4 at addr ffff8801d80ad868 by task syz-executor3/5462
>>
>> CPU: 0 PID: 5462 Comm: syz-executor3 Not tainted 4.15.0-rc8+ #263
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>> print_address_description+0x73/0x250 mm/kasan/report.c:252
>> kasan_report_error mm/kasan/report.c:351 [inline]
>> kasan_report+0x25b/0x340 mm/kasan/report.c:409
>> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
>> l2tp_session_create+0xa6d/0xc60 net/l2tp/l2tp_core.c:1757
>> pppol2tp_connect+0xed7/0x1dd0 net/l2tp/l2tp_ppp.c:748
>> SYSC_connect+0x213/0x4a0 net/socket.c:1621
>> SyS_connect+0x24/0x30 net/socket.c:1602
>> entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x452df9
>> RSP: 002b:00007f93ec47fc58 EFLAGS: 00000212 ORIG_RAX: 000000000000002a
>> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452df9
>> RDX: 000000000000002e RSI: 00000000205fafd2 RDI: 0000000000000018
>> RBP: 00000000000005a9 R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6878
>> R13: 00000000ffffffff R14: 00007f93ec4806d4 R15: 0000000000000000
>>
>> Allocated by task 5462:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>> set_track mm/kasan/kasan.c:459 [inline]
>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>> kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610
>> kmalloc include/linux/slab.h:499 [inline]
>> kzalloc include/linux/slab.h:688 [inline]
>> l2tp_tunnel_create+0x5e1/0x17f0 net/l2tp/l2tp_core.c:1554
>> pppol2tp_connect+0x14b7/0x1dd0 net/l2tp/l2tp_ppp.c:707
>> SYSC_connect+0x213/0x4a0 net/socket.c:1621
>> SyS_connect+0x24/0x30 net/socket.c:1602
>> entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 5484:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>> set_track mm/kasan/kasan.c:459 [inline]
>> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>> __cache_free mm/slab.c:3488 [inline]
>> kfree+0xd6/0x260 mm/slab.c:3803
>> __rcu_reclaim kernel/rcu/rcu.h:190 [inline]
>> rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>> invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>> __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>> rcu_process_callbacks+0xe94/0x17f0 kernel/rcu/tree.c:2996
>> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>
>> The buggy address belongs to the object at ffff8801d80ad780
>> which belongs to the cache kmalloc-512 of size 512
>> The buggy address is located 232 bytes inside of
>> 512-byte region [ffff8801d80ad780, ffff8801d80ad980)
>> The buggy address belongs to the page:
>> page:ffffea0007602b40 count:1 mapcount:0 mapping:ffff8801d80ad000 index:0x0
>> flags: 0x2fffc0000000100(slab)
>> raw: 02fffc0000000100 ffff8801d80ad000 0000000000000000 0000000100000006
>> raw: ffffea00070e8760 ffffea00070f8ca0 ffff8801dac00940 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff8801d80ad700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801d80ad780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>> ffff8801d80ad800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ^
>> ffff8801d80ad880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff8801d80ad900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> 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/001a11405130a984300562e8e7b3%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion.
From: Herbert Xu @ 2018-07-20 7:54 UTC (permalink / raw)
To: NeilBrown, Paul E. McKenney; +Cc: Thomas Graf, netdev, linux-kernel
In-Reply-To: <153086175009.24852.7782466383056542839.stgit@noble>
On Fri, Jul 06, 2018 at 05:22:30PM +1000, NeilBrown wrote:
> rhashtable_try_insert() currently hold a lock on the bucket in
> the first table, while also locking buckets in subsequent tables.
> This is unnecessary and looks like a hold-over from some earlier
> version of the implementation.
>
> As insert and remove always lock a bucket in each table in turn, and
> as insert only inserts in the final table, there cannot be any races
> that are not covered by simply locking a bucket in each table in turn.
>
> When an insert call reaches that last table it can be sure that there
> is no match entry in any other table as it has searched them all, and
> insertion never happens anywhere but in the last table. The fact that
> code tests for the existence of future_tbl while holding a lock on
> the relevant bucket ensures that two threads inserting the same key
> will make compatible decisions about which is the "last" table.
>
> This simplifies the code and allows the ->rehash field to be
> discarded.
>
> We still need a way to ensure that a dead bucket_table is never
> re-linked by rhashtable_walk_stop(). This can be achieved by
> calling call_rcu() inside the locked region, and checking
> ->rcu.func in rhashtable_walk_stop(). If it is not NULL, then
> the bucket table is empty and dead.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
...
> @@ -339,13 +338,16 @@ static int rhashtable_rehash_table(struct rhashtable *ht)
> spin_lock(&ht->lock);
> list_for_each_entry(walker, &old_tbl->walkers, list)
> walker->tbl = NULL;
> - spin_unlock(&ht->lock);
>
> /* Wait for readers. All new readers will see the new
> * table, and thus no references to the old table will
> * remain.
> + * We do this inside the locked region so that
> + * rhashtable_walk_stop() can check ->rcu.func and know
> + * not to re-link the table.
> */
> call_rcu(&old_tbl->rcu, bucket_table_free_rcu);
> + spin_unlock(&ht->lock);
>
> return rht_dereference(new_tbl->future_tbl, ht) ? -EAGAIN : 0;
> }
...
> @@ -964,7 +942,7 @@ void rhashtable_walk_stop(struct rhashtable_iter *iter)
> ht = iter->ht;
>
> spin_lock(&ht->lock);
> - if (tbl->rehash < tbl->size)
> + if (tbl->rcu.func == NULL)
> list_add(&iter->walker.list, &tbl->walkers);
> else
> iter->walker.tbl = NULL;
This appears to be relying on implementation details within RCU.
Paul, are you OK with rhashtable doing this trick?
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: KASAN: use-after-free Read in l2tp_session_create
From: Dmitry Vyukov @ 2018-07-20 8:00 UTC (permalink / raw)
To: James Chapman
Cc: David Miller, Reshetova, Elena, Hans Liljestrand, Kees Cook, LKML,
netdev, syzkaller-bugs, Greg Hackmann, syzbot, Guillaume Nault,
Greg Kroah-Hartman
In-Reply-To: <5308835b-b5ef-51e4-2e4f-05a9636dff55@katalix.com>
On Fri, Jul 20, 2018 at 9:53 AM, James Chapman <jchapman@katalix.com> wrote:
> On 18/07/18 12:00, Dmitry Vyukov wrote:
>> On Tue, Jan 16, 2018 at 7:29 PM, syzbot
>> <syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> a8750ddca918032d6349adbf9a4b6555e7db20da
>>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com
>>> It will help syzbot understand when the bug is fixed. See footer for
>>> details.
>>> If you forward the report, please keep this part and the footer.
>>
>> James,
>>
>> Did you fix this? You asked syzbot to test a fix for this bug some time ago.
>> If yes, did you include the Reported-by tag in the commit? This bug is
>> still considered open by syzbot. But it stopped happening ~4 months
>> ago:
>
> Yes, I think this has been fixed now. I think it was fixed by
> Guillaume's 6b9f34239b00e6956a267abed2bc559ede556ad6 that was actually
> to fix another syzbot bug fbeeb5c3b538e8545644 which looks similar to
> this one.
>
>> https://syzkaller.appspot.com/bug?id=6fed0854381422329e78d7e16fb9cf4af8c9aef1
>> We are also seeing these crashes in 4.4 and 4.9, it would be good to
>> backport the fix.
>
> It looks like 6b9f34239b00e6956a267abed2bc559ede556ad6 hasn't made it to
> 4.9 or 4.4.
Thanks for the update!
Let's tell syzbot that this is fixed:
#syz fix: l2tp: fix races in tunnel creation
Greg H: so this is probably the patch we need.
+Greg KH: I think we need this in stable, we hit this in both 4.4 and 4.9.
>>> ==================================================================
>>> BUG: KASAN: use-after-free in l2tp_session_create+0xa6d/0xc60
>>> net/l2tp/l2tp_core.c:1757
>>> Read of size 4 at addr ffff8801d80ad868 by task syz-executor3/5462
>>>
>>> CPU: 0 PID: 5462 Comm: syz-executor3 Not tainted 4.15.0-rc8+ #263
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>> __dump_stack lib/dump_stack.c:17 [inline]
>>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>>> print_address_description+0x73/0x250 mm/kasan/report.c:252
>>> kasan_report_error mm/kasan/report.c:351 [inline]
>>> kasan_report+0x25b/0x340 mm/kasan/report.c:409
>>> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
>>> l2tp_session_create+0xa6d/0xc60 net/l2tp/l2tp_core.c:1757
>>> pppol2tp_connect+0xed7/0x1dd0 net/l2tp/l2tp_ppp.c:748
>>> SYSC_connect+0x213/0x4a0 net/socket.c:1621
>>> SyS_connect+0x24/0x30 net/socket.c:1602
>>> entry_SYSCALL_64_fastpath+0x29/0xa0
>>> RIP: 0033:0x452df9
>>> RSP: 002b:00007f93ec47fc58 EFLAGS: 00000212 ORIG_RAX: 000000000000002a
>>> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452df9
>>> RDX: 000000000000002e RSI: 00000000205fafd2 RDI: 0000000000000018
>>> RBP: 00000000000005a9 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6878
>>> R13: 00000000ffffffff R14: 00007f93ec4806d4 R15: 0000000000000000
>>>
>>> Allocated by task 5462:
>>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>> set_track mm/kasan/kasan.c:459 [inline]
>>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>>> kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3610
>>> kmalloc include/linux/slab.h:499 [inline]
>>> kzalloc include/linux/slab.h:688 [inline]
>>> l2tp_tunnel_create+0x5e1/0x17f0 net/l2tp/l2tp_core.c:1554
>>> pppol2tp_connect+0x14b7/0x1dd0 net/l2tp/l2tp_ppp.c:707
>>> SYSC_connect+0x213/0x4a0 net/socket.c:1621
>>> SyS_connect+0x24/0x30 net/socket.c:1602
>>> entry_SYSCALL_64_fastpath+0x29/0xa0
>>>
>>> Freed by task 5484:
>>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>> set_track mm/kasan/kasan.c:459 [inline]
>>> kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>>> __cache_free mm/slab.c:3488 [inline]
>>> kfree+0xd6/0x260 mm/slab.c:3803
>>> __rcu_reclaim kernel/rcu/rcu.h:190 [inline]
>>> rcu_do_batch kernel/rcu/tree.c:2758 [inline]
>>> invoke_rcu_callbacks kernel/rcu/tree.c:3012 [inline]
>>> __rcu_process_callbacks kernel/rcu/tree.c:2979 [inline]
>>> rcu_process_callbacks+0xe94/0x17f0 kernel/rcu/tree.c:2996
>>> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>>
>>> The buggy address belongs to the object at ffff8801d80ad780
>>> which belongs to the cache kmalloc-512 of size 512
>>> The buggy address is located 232 bytes inside of
>>> 512-byte region [ffff8801d80ad780, ffff8801d80ad980)
>>> The buggy address belongs to the page:
>>> page:ffffea0007602b40 count:1 mapcount:0 mapping:ffff8801d80ad000 index:0x0
>>> flags: 0x2fffc0000000100(slab)
>>> raw: 02fffc0000000100 ffff8801d80ad000 0000000000000000 0000000100000006
>>> raw: ffffea00070e8760 ffffea00070f8ca0 ffff8801dac00940 0000000000000000
>>> page dumped because: kasan: bad access detected
>>>
>>> Memory state around the buggy address:
>>> ffff8801d80ad700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>> ffff8801d80ad780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>> ffff8801d80ad800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>> ^
>>> ffff8801d80ad880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>> ffff8801d80ad900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>> ==================================================================
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkaller@googlegroups.com.
>>>
>>> syzbot will keep track of this bug report.
>>> If you forgot to add the Reported-by tag, once the fix for this bug is
>>> merged
>>> into any tree, please reply to this email with:
>>> #syz fix: exact-commit-title
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report, please reply with:
>>> #syz invalid
>>> Note: if the crash happens again, it will cause creation of a new bug
>>> report.
>>> Note: all commands must start from beginning of the line in the email body.
>>>
>>> --
>>> 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/001a11405130a984300562e8e7b3%40google.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
>
^ permalink raw reply
* Re: [SPAM]Re: [PATCH] net: mediatek: use dma_zalloc_coherent instead of allocator/memset
From: Russell King - ARM Linux @ 2018-07-20 8:13 UTC (permalink / raw)
To: YueHaibing
Cc: nbd-p3rKhJxN3npAfugRpC6u6w, nelson.chang-NuS5LvNUpcJWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
john-Pj+rj9U5foFAfugRpC6u6w, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <9a4cdfc6-7487-5908-b584-f3bf6158c4d4-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Fri, Jul 20, 2018 at 02:30:53PM +0800, YueHaibing wrote:
> On 2018/7/20 1:02, Sean Wang wrote:
> > On Thu, 2018-07-19 at 15:17 +0100, Russell King - ARM Linux wrote:
> >> On Thu, Jul 19, 2018 at 10:09:55PM +0800, YueHaibing wrote:
> >>> Use dma_zalloc_coherent instead of dma_alloc_coherent
> >>> followed by memset 0.
> >>>
> >>> Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>> ---
> >>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-----
> >>> 1 file changed, 2 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> index d8ebf0a..fbdb3e3 100644
> >>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> >>> @@ -1221,14 +1221,11 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
> >>> if (!ring->buf)
> >>> goto no_tx_mem;
> >>>
> >>> - ring->dma = dma_alloc_coherent(eth->dev,
> >>> - MTK_DMA_SIZE * sz,
> >>> - &ring->phys,
> >>> - GFP_ATOMIC | __GFP_ZERO);
> >>> + ring->dma = dma_zalloc_coherent(eth->dev, MTK_DMA_SIZE * sz,
> >>> + &ring->phys, GFP_ATOMIC | __GFP_ZERO);
> >>> if (!ring->dma)
> >>> goto no_tx_mem;
> >>>
> >>> - memset(ring->dma, 0, MTK_DMA_SIZE * sz);
> >>
> >> I have to wonder whether this code needs two forms of zeroing... in
> >> the original code, __GFP_ZERO _and_ a call to memset() just in case
> >> __GFP_ZERO failed to do its job, and in the replacement code, just
> >> in case dma_zalloc_coherent() hasn't got the idea...
> >>
> >> I think you can drop the __GFP_ZERO. ;)
> >>
> >
> > Just now I did an experiment on 4.14.56 on armv7. I found that
> > dma_zalloc_coherent does not guarantee that the buffer we get
> > is all filled with 0.
> >
> >
> > I really think it's a little bit weird OR what was I missing something
> > for enabling dma_zalloc_coherent ? The result seems to tell that we
> > can't remove freely the memset with 0 at this moment until we get a
> > cause.
> >
>
> That means dma_zalloc_coherent doesn't work as expect on armv7?
Can someone work out which underlying allocator is being used - the
possibilities are:
- dma_alloc_from_dev_coherent
- cma
- simple
- remap
- pool
Looking at the code, I'd guess it's the pool allocator, as I don't see
anything which zeros memory there, and it doesn't honor the __GFP_ZERO
flag. This is definitely an allocator bug.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* Re: [PATCH v3 1/2] tools/bpftool: ignore build products
From: Daniel Borkmann @ 2018-07-20 8:23 UTC (permalink / raw)
To: Jakub Kicinski, Taeung Song; +Cc: Alexei Starovoitov, netdev, linux-kernel
In-Reply-To: <20180719112357.4fd6c6ce@cakuba.netronome.com>
On 07/19/2018 08:23 PM, Jakub Kicinski wrote:
> On Thu, 19 Jul 2018 21:10:04 +0900, Taeung Song wrote:
>> For untracked things of tools/bpf, add this.
>>
>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>> ---
>> tools/bpf/.gitignore | 5 +++++
>> tools/bpf/bpftool/.gitignore | 1 +
>> 2 files changed, 6 insertions(+)
>> create mode 100644 tools/bpf/.gitignore
>>
>> diff --git a/tools/bpf/.gitignore b/tools/bpf/.gitignore
>> new file mode 100644
>> index 000000000000..dfe2bd5a4b95
>> --- /dev/null
>> +++ b/tools/bpf/.gitignore
>> @@ -0,0 +1,5 @@
>> +FEATURE-DUMP.bpf
>> +bpf_asm
>> +bpf_dbg
>> +bpf_exp.yacc.*
>> +bpf_jit_disasm
>> diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
>> index d7e678c2d396..103cc5b5b446 100644
>> --- a/tools/bpf/bpftool/.gitignore
>> +++ b/tools/bpf/bpftool/.gitignore
>> @@ -1,3 +1,4 @@
>> *.d
>> bpftool
>> +bpftool*.8
>> FEATURE-DUMP.bpftool
>
> This patch is going to be merged to the bpf-next tree, I presume, and
> there is more man pages there:
>
> $ make -C tools/bpf/bpftool/ doc
> make: Entering directory 'linux/tools/bpf/bpftool'
> DESCEND Documentation
> make[1]: Entering directory '/linux/tools/bpf/bpftool/Documentation'
> GEN bpftool-perf.8
> GEN bpftool-map.8
> GEN bpftool.8
> GEN bpftool-prog.8
> GEN bpftool-cgroup.8
> GEN bpf-helpers.rst
> Parsed description of 80 helper function(s)
> GEN bpf-helpers.7
> make[1]: Leaving directory 'linux/tools/bpf/bpftool/Documentation'
> make: Leaving directory 'linux/tools/bpf/bpftool'
> $ git status
> On branch work
> Your branch is ahead of 'pending' by 10 commits.
> (use "git push" to publish your local commits)
>
> Untracked files:
> (use "git add <file>..." to include in what will be committed)
>
> tools/bpf/bpftool/Documentation/bpf-helpers.7
> tools/bpf/bpftool/Documentation/bpf-helpers.rst
> tools/bpf/bpftool/Documentation/bpftool-cgroup.8
> tools/bpf/bpftool/Documentation/bpftool-map.8
> tools/bpf/bpftool/Documentation/bpftool-perf.8
> tools/bpf/bpftool/Documentation/bpftool-prog.8
> tools/bpf/bpftool/Documentation/bpftool.8
>
> nothing added to commit but untracked files present (use "git add" to track)
>
> See the bpf-helpers.* files? Those are all auto-generated.
>
> If you respin for -next please split the series and put [PATCH bpf-next
> v4] as prefix of first patch, and [PATCH bpf v4] as prefix for the
> second, as one of them is an improvement, and second a bug fix.
I've just applied patch 2/2 to bpf tree, thanks Taeung! I think best for
patch 1/2 would be if you rebase this against bpf-next tree as Jakub
mentioned so wouldn't need an immediate follow-up due to incomplete
.gitignore then.
Thanks,
Daniel
^ permalink raw reply
* Re: [V9fs-developer] [PATCH] /net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()
From: jiangyiwen @ 2018-07-20 8:34 UTC (permalink / raw)
To: Tomas Bortoli, ericvh, rminnich, lucho
Cc: netdev, linux-kernel, syzkaller, v9fs-developer, davem
In-Reply-To: <20180719200607.30286-1-tomasbortoli@gmail.com>
On 2018/7/20 4:06, Tomas Bortoli wrote:
> The patch adds the flush in p9_mux_poll_stop() as it the function used by
> p9_conn_destroy(), in turn called by p9_fd_close() to stop the async
> polling associated with the data regarding the connection.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com
> ---
> As shown by Syzbot, it is possible to provoke a race between p9_fd_close()
> and p9_poll_workfn() that is called to take care of the async read/write work
> to do. To make sure p9_fd_close() frees "trans" when it is not used anymore,
> it has to explicitly call flush_scheduled_work() before the kfree().
>
> net/9p/trans_fd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index bf459ee0feab..76ae134c05d9 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -185,6 +185,8 @@ static void p9_mux_poll_stop(struct p9_conn *m)
> spin_lock_irqsave(&p9_poll_lock, flags);
> list_del_init(&m->poll_pending_link);
> spin_unlock_irqrestore(&p9_poll_lock, flags);
> +
> + flush_scheduled_work();
I suggest we should use flush_work(&p9_poll_work), flush_scheduled_work is not
suitable.
Thanks.
> }
>
> /**
>
^ permalink raw reply
* Re: [PATCH bpf] bpf: Use option "help" in the llvm-objcopy test
From: Daniel Borkmann @ 2018-07-20 8:37 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <20180720053410.3891870-1-kafai@fb.com>
On 07/20/2018 07:34 AM, Martin KaFai Lau wrote:
> I noticed the "--version" option of the llvm-objcopy command has recently
> disappeared from the master llvm branch. It is currently used as a BTF
> support test in tools/testing/selftests/bpf/Makefile.
>
> This patch replaces it with "--help" which should be
> less error prone in the future.
>
> Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Looks good, ran into the same recently as well from llvm git. Wondering whether
the "--version" removal there was by accident or on purpose. In any case, applied
to bpf tree, thanks! If we make another change to the Makefile in near future,
we should also make a comment there that the llvm-objcopy is used by pahole -J
internally to make it a bit more clear in case someone is wondering why it's not
used in the Makefile itself.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH bpf] bpf: btf: Clean up BTF_INT_BITS() in uapi btf.h
From: Daniel Borkmann @ 2018-07-20 8:37 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, kernel-team
In-Reply-To: <20180720051431.3840338-1-kafai@fb.com>
On 07/20/2018 07:14 AM, Martin KaFai Lau wrote:
> This patch shrinks the BTF_INT_BITS() mask. The current
> btf_int_check_meta() ensures the nr_bits of an integer
> cannot exceed 64. Hence, it is mostly an uapi cleanup.
>
> The actual btf usage (i.e. seq_show()) is also modified
> to use u8 instead of u16. The verification (e.g. btf_int_check_meta())
> path stays as is to deal with invalid BTF situation.
>
> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Applied to bpf, thanks Martin!
^ permalink raw reply
* Re: [SPAM]Re: [PATCH] net: mediatek: use dma_zalloc_coherent instead of allocator/memset
From: Russell King - ARM Linux @ 2018-07-20 9:25 UTC (permalink / raw)
To: Sean Wang
Cc: nbd, nelson.chang, netdev, YueHaibing, linux-kernel,
linux-mediatek, john, matthias.bgg, davem, linux-arm-kernel
In-Reply-To: <1532069663.8953.259.camel@mtkswgap22>
On Fri, Jul 20, 2018 at 02:54:23PM +0800, Sean Wang wrote:
> On Fri, 2018-07-20 at 14:30 +0800, YueHaibing wrote:
> > On 2018/7/20 1:02, Sean Wang wrote:
> > > On Thu, 2018-07-19 at 15:17 +0100, Russell King - ARM Linux wrote:
> > >> On Thu, Jul 19, 2018 at 10:09:55PM +0800, YueHaibing wrote:
> > >>> Use dma_zalloc_coherent instead of dma_alloc_coherent
> > >>> followed by memset 0.
> > >>>
> > >>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> > >>> ---
> > >>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-----
> > >>> 1 file changed, 2 insertions(+), 5 deletions(-)
> > >>>
> > >>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > >>> index d8ebf0a..fbdb3e3 100644
> > >>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > >>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > >>> @@ -1221,14 +1221,11 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
> > >>> if (!ring->buf)
> > >>> goto no_tx_mem;
> > >>>
> > >>> - ring->dma = dma_alloc_coherent(eth->dev,
> > >>> - MTK_DMA_SIZE * sz,
> > >>> - &ring->phys,
> > >>> - GFP_ATOMIC | __GFP_ZERO);
> > >>> + ring->dma = dma_zalloc_coherent(eth->dev, MTK_DMA_SIZE * sz,
> > >>> + &ring->phys, GFP_ATOMIC | __GFP_ZERO);
> > >>> if (!ring->dma)
> > >>> goto no_tx_mem;
> > >>>
> > >>> - memset(ring->dma, 0, MTK_DMA_SIZE * sz);
> > >>
> > >> I have to wonder whether this code needs two forms of zeroing... in
> > >> the original code, __GFP_ZERO _and_ a call to memset() just in case
> > >> __GFP_ZERO failed to do its job, and in the replacement code, just
> > >> in case dma_zalloc_coherent() hasn't got the idea...
> > >>
> > >> I think you can drop the __GFP_ZERO. ;)
> > >>
> > >
> > > Just now I did an experiment on 4.14.56 on armv7. I found that
> > > dma_zalloc_coherent does not guarantee that the buffer we get
> > > is all filled with 0.
> > >
> > >
> > > I really think it's a little bit weird OR what was I missing something
> > > for enabling dma_zalloc_coherent ? The result seems to tell that we
> > > can't remove freely the memset with 0 at this moment until we get a
> > > cause.
> > >
> >
> > That means dma_zalloc_coherent doesn't work as expect on armv7?
> >
>
> I'm not sure if it's true for every armv7. or it's only happening on my
> device.
>
> anyway, i think we can replace all occurrences in the driver for
> dma_alloc_coherent with __GFP_ZERO by dma_zalloc_coherent, and but
> keep the extra memset as is.
No, a bug in the allocator has been found that needs fixing. The
right solution is to fix the allocator and remove what should be
unnecessary memset()s.
This should have been reported when the __GFP_ZERO flag was not
being honoured and memset() was initially found to be required -
all that dma_zalloc_coherent() does is set the __GFP_ZERO flag
before calling dma_alloc_coherent().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
^ permalink raw reply
* [PATCH] [V9fs-developer] [PATCH] /net/9p/trans_fd.c: fix race-condition by flushing workqueue before the kfree()
From: Tomas Bortoli @ 2018-07-20 9:27 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: jiangyiwen, davem, v9fs-developer, netdev, linux-kernel,
syzkaller, Tomas Bortoli
The patch adds the flush in p9_mux_poll_stop() as it the function used by
p9_conn_destroy(), in turn called by p9_fd_close() to stop the async
polling associated with the data regarding the connection.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+39749ed7d9ef6dfb23f6@syzkaller.appspotmail.com
---
As shown by Syzbot, it is possible to provoke a race between p9_fd_close()
and p9_poll_workfn() that is called to take care of the async read/write work
to do. To make sure p9_fd_close() frees "trans" when it is not used anymore,
it has to explicitly flush p9_poll_work before the kfree().
net/9p/trans_fd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index bf459ee0feab..a64b01c56e30 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -185,6 +185,8 @@ static void p9_mux_poll_stop(struct p9_conn *m)
spin_lock_irqsave(&p9_poll_lock, flags);
list_del_init(&m->poll_pending_link);
spin_unlock_irqrestore(&p9_poll_lock, flags);
+
+ flush_work(&p9_poll_work);
}
/**
--
2.11.0
^ permalink raw reply related
* Re: KASAN: use-after-free Read in l2tp_session_create
From: Greg Kroah-Hartman @ 2018-07-20 9:49 UTC (permalink / raw)
To: Dmitry Vyukov, stable
Cc: James Chapman, David Miller, Reshetova, Elena, Hans Liljestrand,
Kees Cook, LKML, netdev, syzkaller-bugs, Greg Hackmann, syzbot,
Guillaume Nault
In-Reply-To: <CACT4Y+YRmX2ROxWZcT4w-NHR76cVV4_U6-Y0T=x4on67r8dNzQ@mail.gmail.com>
On Fri, Jul 20, 2018 at 10:00:34AM +0200, Dmitry Vyukov wrote:
> On Fri, Jul 20, 2018 at 9:53 AM, James Chapman <jchapman@katalix.com> wrote:
> > On 18/07/18 12:00, Dmitry Vyukov wrote:
> >> On Tue, Jan 16, 2018 at 7:29 PM, syzbot
> >> <syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com> wrote:
> >>> Hello,
> >>>
> >>> syzkaller hit the following crash on
> >>> a8750ddca918032d6349adbf9a4b6555e7db20da
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> >>> compiler: gcc (GCC) 7.1.1 20170620
> >>> .config is attached
> >>> Raw console output is attached.
> >>> Unfortunately, I don't have any reproducer for this bug yet.
> >>>
> >>>
> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >>> Reported-by: syzbot+065d0fc357520c8f6039@syzkaller.appspotmail.com
> >>> It will help syzbot understand when the bug is fixed. See footer for
> >>> details.
> >>> If you forward the report, please keep this part and the footer.
> >>
> >> James,
> >>
> >> Did you fix this? You asked syzbot to test a fix for this bug some time ago.
> >> If yes, did you include the Reported-by tag in the commit? This bug is
> >> still considered open by syzbot. But it stopped happening ~4 months
> >> ago:
> >
> > Yes, I think this has been fixed now. I think it was fixed by
> > Guillaume's 6b9f34239b00e6956a267abed2bc559ede556ad6 that was actually
> > to fix another syzbot bug fbeeb5c3b538e8545644 which looks similar to
> > this one.
> >
> >> https://syzkaller.appspot.com/bug?id=6fed0854381422329e78d7e16fb9cf4af8c9aef1
> >> We are also seeing these crashes in 4.4 and 4.9, it would be good to
> >> backport the fix.
> >
> > It looks like 6b9f34239b00e6956a267abed2bc559ede556ad6 hasn't made it to
> > 4.9 or 4.4.
>
> Thanks for the update!
>
> Let's tell syzbot that this is fixed:
>
> #syz fix: l2tp: fix races in tunnel creation
>
> Greg H: so this is probably the patch we need.
>
> +Greg KH: I think we need this in stable, we hit this in both 4.4 and 4.9.
It's also needed in 4.14.y. But it doesn't apply to any of those kernel
trees cleanly, can someone please provide a working backport?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 1/2] tools/bpftool: ignore build products
From: Taeung Song @ 2018-07-20 9:54 UTC (permalink / raw)
To: Daniel Borkmann, Jakub Kicinski; +Cc: Alexei Starovoitov, netdev, linux-kernel
In-Reply-To: <d6234684-03ff-ca7e-589f-458bf3b098b9@iogearbox.net>
On 07/20/2018 05:23 PM, Daniel Borkmann wrote:
> On 07/19/2018 08:23 PM, Jakub Kicinski wrote:
>> On Thu, 19 Jul 2018 21:10:04 +0900, Taeung Song wrote:
>>> For untracked things of tools/bpf, add this.
>>>
>>> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
>>> ---
>>> tools/bpf/.gitignore | 5 +++++
>>> tools/bpf/bpftool/.gitignore | 1 +
>>> 2 files changed, 6 insertions(+)
>>> create mode 100644 tools/bpf/.gitignore
>>>
>>> diff --git a/tools/bpf/.gitignore b/tools/bpf/.gitignore
>>> new file mode 100644
>>> index 000000000000..dfe2bd5a4b95
>>> --- /dev/null
>>> +++ b/tools/bpf/.gitignore
>>> @@ -0,0 +1,5 @@
>>> +FEATURE-DUMP.bpf
>>> +bpf_asm
>>> +bpf_dbg
>>> +bpf_exp.yacc.*
>>> +bpf_jit_disasm
>>> diff --git a/tools/bpf/bpftool/.gitignore b/tools/bpf/bpftool/.gitignore
>>> index d7e678c2d396..103cc5b5b446 100644
>>> --- a/tools/bpf/bpftool/.gitignore
>>> +++ b/tools/bpf/bpftool/.gitignore
>>> @@ -1,3 +1,4 @@
>>> *.d
>>> bpftool
>>> +bpftool*.8
>>> FEATURE-DUMP.bpftool
>>
>> This patch is going to be merged to the bpf-next tree, I presume, and
>> there is more man pages there:
>>
>> $ make -C tools/bpf/bpftool/ doc
>> make: Entering directory 'linux/tools/bpf/bpftool'
>> DESCEND Documentation
>> make[1]: Entering directory '/linux/tools/bpf/bpftool/Documentation'
>> GEN bpftool-perf.8
>> GEN bpftool-map.8
>> GEN bpftool.8
>> GEN bpftool-prog.8
>> GEN bpftool-cgroup.8
>> GEN bpf-helpers.rst
>> Parsed description of 80 helper function(s)
>> GEN bpf-helpers.7
>> make[1]: Leaving directory 'linux/tools/bpf/bpftool/Documentation'
>> make: Leaving directory 'linux/tools/bpf/bpftool'
>> $ git status
>> On branch work
>> Your branch is ahead of 'pending' by 10 commits.
>> (use "git push" to publish your local commits)
>>
>> Untracked files:
>> (use "git add <file>..." to include in what will be committed)
>>
>> tools/bpf/bpftool/Documentation/bpf-helpers.7
>> tools/bpf/bpftool/Documentation/bpf-helpers.rst
>> tools/bpf/bpftool/Documentation/bpftool-cgroup.8
>> tools/bpf/bpftool/Documentation/bpftool-map.8
>> tools/bpf/bpftool/Documentation/bpftool-perf.8
>> tools/bpf/bpftool/Documentation/bpftool-prog.8
>> tools/bpf/bpftool/Documentation/bpftool.8
>>
>> nothing added to commit but untracked files present (use "git add" to track)
>>
>> See the bpf-helpers.* files? Those are all auto-generated.
>>
>> If you respin for -next please split the series and put [PATCH bpf-next
>> v4] as prefix of first patch, and [PATCH bpf v4] as prefix for the
>> second, as one of them is an improvement, and second a bug fix.
>
> I've just applied patch 2/2 to bpf tree, thanks Taeung! I think best for
> patch 1/2 would be if you rebase this against bpf-next tree as Jakub
> mentioned so wouldn't need an immediate follow-up due to incomplete
> .gitignore then.
>
> Thanks,
> Daniel
>
OK, I'll follow-up it later!
--
Thanks,
Taeung
^ permalink raw reply
* Re: [PATCH net-next 6/7] net: systemport: Add support for WAKE_FILTER
From: Florian Fainelli @ 2018-07-20 9:34 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, linville, davem, vivien.didelot
In-Reply-To: <20180719222510.GG12150@lunn.ch>
On 07/19/2018 03:25 PM, Andrew Lunn wrote:
>> In both of your examples, only one bit is set, what will change is the
>> value being programmed to RXHCK_BRCM_TAG(i), which will be either 0, or
>> 1, but the value programmed to RXCHK_CONTROL as far as which filter is
>> enabled will be the same because we can use filter position 0.
>>
>> What the code basically does is look at how many bits are set in the
>> filters bitmap, and then it starts populating the filters from filter 0
>> up to filter 7 with the value of the bit.
>
> O.K. Now it get it. Sorry for being so slow.
No worries, thanks for reviewing these changes. I have made the
requested ethtool changes and will post them when I return from vacation
on July 29th.
Thanks Andrew!
--
Florian
^ permalink raw reply
* Re: [PATCH net] net: phy: consider PHY_IGNORE_INTERRUPT in phy_start_aneg_priv
From: Florian Fainelli @ 2018-07-20 9:36 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <e6770015-4b52-d0ff-fc98-9e0b8f34be6b@gmail.com>
On 07/18/2018 11:15 PM, Heiner Kallweit wrote:
> The situation described in the comment can occur also with
> PHY_IGNORE_INTERRUPT, therefore change the condition to include it.
Yes indeed! You might want to locate the offending commit to provide a
fixes tag so this could be backported to stable trees.
Also, for net-next, we may want to introduce a helper which checks for
phydev->irq != PHY_POLL that we can use consistently as a way to tell
that the conditions applies to either PHY_IGNORE_INTERRUPT or
phydev->irq is valid?
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index d2baedc4..914fe8e6 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -519,7 +519,7 @@ static int phy_start_aneg_priv(struct phy_device *phydev, bool sync)
> * negotiation may already be done and aneg interrupt may not be
> * generated.
> */
> - if (phy_interrupt_is_valid(phydev) && (phydev->state == PHY_AN)) {
> + if (phydev->irq != PHY_POLL && phydev->state == PHY_AN) {
> err = phy_aneg_done(phydev);
> if (err > 0) {
> trigger = true;
>
--
Florian
^ permalink raw reply
* [PATCH] net: dsa: mv88e6xxx: fix races between lock and irq freeing
From: Uwe Kleine-König @ 2018-07-20 9:53 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot
Cc: Florian Fainelli, David S. Miller, netdev, kernel
free_irq() waits until all handlers for this IRQ have completed. As the
relevant handler (mv88e6xxx_g1_irq_thread_fn()) takes the chip's reg_lock
it might never return if the thread calling free_irq() holds this lock.
For the same reason kthread_cancel_delayed_work_sync() in the polling case
must not hold this lock.
Also first free the irq (or stop the worker respectively) such that
mv88e6xxx_g1_irq_thread_work() isn't called any more before the irq
mappings are dropped in mv88e6xxx_g1_irq_free_common() to prevent the
worker thread to call handle_nested_irq(0) which results in a NULL-pointer
exception.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/net/dsa/mv88e6xxx/chip.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 437cd6eb4faa..9ef07a06aceb 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -343,6 +343,7 @@ static const struct irq_domain_ops mv88e6xxx_g1_irq_domain_ops = {
.xlate = irq_domain_xlate_twocell,
};
+/* To be called with reg_lock held */
static void mv88e6xxx_g1_irq_free_common(struct mv88e6xxx_chip *chip)
{
int irq, virq;
@@ -362,9 +363,15 @@ static void mv88e6xxx_g1_irq_free_common(struct mv88e6xxx_chip *chip)
static void mv88e6xxx_g1_irq_free(struct mv88e6xxx_chip *chip)
{
- mv88e6xxx_g1_irq_free_common(chip);
-
+ /*
+ * free_irq must be called without reg_lock taken because the irq
+ * handler takes this lock, too.
+ */
free_irq(chip->irq, chip);
+
+ mutex_lock(&chip->reg_lock);
+ mv88e6xxx_g1_irq_free_common(chip);
+ mutex_unlock(&chip->reg_lock);
}
static int mv88e6xxx_g1_irq_setup_common(struct mv88e6xxx_chip *chip)
@@ -469,10 +476,12 @@ static int mv88e6xxx_irq_poll_setup(struct mv88e6xxx_chip *chip)
static void mv88e6xxx_irq_poll_free(struct mv88e6xxx_chip *chip)
{
- mv88e6xxx_g1_irq_free_common(chip);
-
kthread_cancel_delayed_work_sync(&chip->irq_poll_work);
kthread_destroy_worker(chip->kworker);
+
+ mutex_lock(&chip->reg_lock);
+ mv88e6xxx_g1_irq_free_common(chip);
+ mutex_unlock(&chip->reg_lock);
}
int mv88e6xxx_wait(struct mv88e6xxx_chip *chip, int addr, int reg, u16 mask)
@@ -4506,12 +4515,10 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (chip->info->g2_irqs > 0)
mv88e6xxx_g2_irq_free(chip);
out_g1_irq:
- mutex_lock(&chip->reg_lock);
if (chip->irq > 0)
mv88e6xxx_g1_irq_free(chip);
else
mv88e6xxx_irq_poll_free(chip);
- mutex_unlock(&chip->reg_lock);
out:
if (pdata)
dev_put(pdata->netdev);
@@ -4539,12 +4546,10 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
if (chip->info->g2_irqs > 0)
mv88e6xxx_g2_irq_free(chip);
- mutex_lock(&chip->reg_lock);
if (chip->irq > 0)
mv88e6xxx_g1_irq_free(chip);
else
mv88e6xxx_irq_poll_free(chip);
- mutex_unlock(&chip->reg_lock);
}
static const struct of_device_id mv88e6xxx_of_match[] = {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH net-next 3/4] net/tc: introduce TC_ACT_MIRRED.
From: Paolo Abeni @ 2018-07-20 9:54 UTC (permalink / raw)
To: Cong Wang, Jiri Pirko
Cc: Linux Kernel Network Developers, Jamal Hadi Salim,
Daniel Borkmann, Marcelo Ricardo Leitner, Eyal Birger
In-Reply-To: <CAM_iQpXtRW-YaYL40SenDchouHfYBoQ5gJMknyv2BmtpRmFmmQ@mail.gmail.com>
Hi,
Jiri, Cong, thank you for the feedback. Please allow me to give a
single reply to both of you, as you rised similar concers.
On Thu, 2018-07-19 at 11:07 -0700, Cong Wang wrote:
> On Thu, Jul 19, 2018 at 6:03 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > This is similar TC_ACT_REDIRECT, but with a slightly different
> > semantic:
> > - on ingress the mirred skbs are passed to the target device
> > network stack without any additional check not scrubbing.
> > - the rcu-protected stats provided via the tcf_result struct
> > are updated on error conditions.
>
> At least its name sucks, it means to skip the skb_clone(),
> that is avoid a copy, but you still call it MIRRED...
>
> MIRRED means MIRror and REDirect.
I was not satified with the name, too, but I also wanted to collect
some feedback, as the different time zones are not helping here.
Would TC_ACT_REINJECT be a better choice? (renaming skb_tc_redirect as
skb_tc_reinject, too). Do you have some better name?
Thanks!
> Also, I don't understand why this new TC_ACT code needs
> to be visible to user-space, whether to clone or not is purely
> internal.
Note this is what already happens with TC_ACT_REDIRECT: currently the
user space uses it freely, even if only {cls,act}_bpf can return such
value in a meaningful way, and only from the ingress and the egress
hooks.
I think we can add a clear separation between the values accessible
from user-space, and the ones used interanally by the kernel, with
something like the code below (basically unknown actions are explicitly
mapped to TC_ACT_UNSPEC), WDYT?
Note: as TC_ACT_REDIRECT is already part of the uAPI, it will remain
accessible from user-space, so patch 1/4 would be still needed.
Cheers,
Paolo
---
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index e4252a176eec..9079e4ee2bbe 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -7,6 +7,9 @@
#include <net/sch_generic.h>
#include <net/act_api.h>
+/* TC action not accessible from user space */
+#define TC_ACT_REINJECT (TC_ACT_MAX + 1)
+
/* Basic packet classifier frontend definitions. */
struct tcf_walker {
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index c4262d911596..c8a24861d4c8 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -45,6 +45,7 @@ enum {
* the skb and act like everything
* is alright.
*/
+#define TC_ACT_VALUE_MAX TC_ACT_TRAP
/* There is a special kind of actions called "extended actions",
* which need a value parameter. These have a local opcode located in
@@ -55,11 +56,12 @@ enum {
#define __TC_ACT_EXT_SHIFT 28
#define __TC_ACT_EXT(local) ((local) << __TC_ACT_EXT_SHIFT)
#define TC_ACT_EXT_VAL_MASK ((1 << __TC_ACT_EXT_SHIFT) - 1)
-#define TC_ACT_EXT_CMP(combined, opcode) \
- (((combined) & (~TC_ACT_EXT_VAL_MASK)) == opcode)
+#define TC_ACT_EXT_OPCODE(combined) ((combined) & (~TC_ACT_EXT_VAL_MASK))
+#define TC_ACT_EXT_CMP(combined, opcode) (TC_ACT_EXT_OPCODE(combined) == opcode)
#define TC_ACT_JUMP __TC_ACT_EXT(1)
#define TC_ACT_GOTO_CHAIN __TC_ACT_EXT(2)
+#define TC_ACT_EXT_OPCODE_MAX TC_ACT_GOTO_CHAIN
/* Action type identifiers*/
enum {
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 148a89ab789b..657c3d99698d 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -798,6 +798,7 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
char act_name[IFNAMSIZ];
struct nlattr *tb[TCA_ACT_MAX + 1];
struct nlattr *kind;
+ int opcode;
int err;
if (name == NULL) {
@@ -895,6 +896,14 @@ struct tc_action *tcf_action_init_1(struct net *net, struct tcf_proto *tp,
}
}
+ opcode = TC_ACT_EXT_OPCODE(a->tcfa_action);
+ if ((!opcode && a->tcfa_action > TC_ACT_VALUE_MAX) ||
+ (opcode && opcode > TC_ACT_EXT_OPCODE_MAX)) {
+ net_warn_ratelimited("invalid %d action value",
+ a->tcfa_action);
+ a->tcfa_action = TC_ACT_UNSPEC;
+ }
+
return a;
err_mod:
^ permalink raw reply related
* Re: [PATCH net-next,v2] net: rename ndo_setup_tc to ndo_setup_offload
From: Pablo Neira Ayuso @ 2018-07-20 10:09 UTC (permalink / raw)
To: Alexander Duyck
Cc: Netdev, Jiri Pirko, Tom Lendacky, Florian Fainelli, Ariel Elior,
Michael Chan, Santosh Raspatur, madalin.bucur, yisen.zhuang,
salil.mehta, Jeff Kirsher, Tariq Toukan, Saeed Mahameed,
Jiri Pirko, Ido Schimmel, Ganesh Goudar, Jakub Kicinski,
linux-net-drivers, peppe.cavallaro, alexandre.torgue, joabreu,
grygorii.strashko, Andrew Lunn
In-Reply-To: <CAKgT0Udu5W14vs8ns_2e4doxEFpnP_h_7fQsp9ecnTvZ-F+kdg@mail.gmail.com>
On Thu, Jul 19, 2018 at 02:04:16PM -0700, Alexander Duyck wrote:
> On Thu, Jul 19, 2018 at 1:52 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Thu, Jul 19, 2018 at 08:18:20AM -0700, Alexander Duyck wrote:
> >> On Wed, Jul 18, 2018 at 5:11 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> >> > One of the recurring complaints is that we do not have, as a driver
> >> > writer, a central location from which we would be fed offloading rules
> >> > into a NIC. This was brought up again during Netconf'18 in Boston.
> >> >
> >> > This patch just renames ndo_setup_tc to ndo_setup_offload as a very
> >> > early initial work to prepare for follow up patch that discuss unified
> >> > flow representation for the existing offload programming APIs.
> >> >
> >> > Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> >> > Acked-by: Jiri Pirko <jiri@mellanox.com>
> >> > Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> >>
> >> One request I would have here is to not bother updating the individual
> >> driver function names. For now I would say we could leave the
> >> "_setup_tc" in the naming of the driver functions itself and just
> >> update the name of the net device operation. Renaming the driver
> >> functions just adds unnecessary overhead and complexity to the patch
> >> and will make it more difficult to maintain. When we get around to
> >> adding additional functionality that relates to the rename we could
> >> address renaming the function on a per driver basis in the future.
> >
> > Plan was to follow up patch will rename enum tc_setup_type too:
> >
> > https://marc.info/?l=linux-netdev&m=153193158512556&w=2
> >
> > that will result in more renames in the driver side.
> >
> > I would expect this will happen sooner or later, and out of tree
> > patches will end up needing a rebase sooner or later, if that is the
> > concern.
>
> I was just thinking that renaming the functions themselves adds noise
> and makes it harder to debug functions later when they get renamed. As
> far as the out-of-tree driver I agree we will still have to deal with
> it due to the enum and NDO function rename. I just figured that using
> things like LXR is a bit easier when the function name stays the same
> and you have to move between versions.
Semantic changes in this interface are expected in follow up patches.
Specifically, this interface will not be exclusively dedicated to 'tc'
anymore. The function rename will provide a hint on this semantic change
going on. I understand your concern, and I also tend to dislike renaming
for the sake of renaming, but in this case this rename coveys useful
information to developers.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 4/4] act_mirred: use ACT_REDIRECT when possible
From: Paolo Abeni @ 2018-07-20 10:16 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger
In-Reply-To: <CAM_iQpUdW765kzsbZfXpPLdtoxEtNWj38d7Ev=v0a-pJGMd-qQ@mail.gmail.com>
On Thu, 2018-07-19 at 10:56 -0700, Cong Wang wrote:
> On Wed, Jul 18, 2018 at 3:05 AM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > Hi,
> >
> > On Tue, 2018-07-17 at 10:24 -0700, Cong Wang wrote:
> > > If you goal is to get rid of skb_clone(), why not just do the following?
> > >
> > > if (tcf_mirred_is_act_redirect(m_eaction)) {
> > > skb2 = skb;
> > > } else {
> > > skb2 = skb_clone(skb, GFP_ATOMIC);
> > > if (!skb2)
> > > goto out;
> > > }
> > >
> > > For redirect, we return TC_ACT_SHOT, so upper layer should not
> > > touch the skb after that.
> > >
> > > What am I missing here?
> >
> > With ACT_SHOT caller/upper layer will free the skb, too. We will have
> > an use after free (from either the upper layer and the xmit device).
> > Similar issues with STOLEN, TRAP, etc.
> >
> > In the past, Changli Gao attempted to avoid the clone incrementing the
> > skb usage count:
> >
> > commit 210d6de78c5d7c785fc532556cea340e517955e1
> > Author: Changli Gao <xiaosuo@gmail.com>
> > Date: Thu Jun 24 16:25:12 2010 +0000
> >
> > act_mirred: don't clone skb when skb isn't shared
> >
> > but some/many device drivers expect an skb usage count of 1, and that
> > caused ooops and was revered.
>
> Interesting, I wasn't aware of the above commit and its revert.
>
> First, I didn't use skb_get() above.
>
> Second, I think the caller of dev_queue_xmit() should not
> touch the skb after it, the skb is either freed by dev_queue_xmit()
> or successfully transmitted, in either case, the ownership belongs
> to dev_queue_xmit(). So, I think we should skip the qdisc_drop()
> for this case.
>
> Not sure about netif_receive_skb() case, given veth calls in its
> xmit too, I speculate the rule is probably same.
>
> Not sure about other ACT_SHOT case than act_mirred...
I think any tc filter can be configured from user space to return
ACT_SHOT, so changing the ACT_SHOT handling would be quite invasive and
error prone, as all the tc filters (to free the skb on ACT_SHOT) and tc
schedulers (to avoid touching the skb) must be modified.
If there are no strong objection vs a new action value, I would opt for
such option.
Thanks,
Paolo
^ permalink raw reply
* HI
From: Mrs Suzara Maling Wan @ 2018-07-20 10:52 UTC (permalink / raw)
--
I am Mrs Suzara i have a pending project of fulfillment to put in your
hand, i will need your support to make this ream come through, could
you le me know your interest to enable me give you further information,
and I hereby advice that you send the below mentioned information I
decided to will/donate the sum of $4.5 Million US to you for the good
work of god, and also to help the motherless and less privilege and
also forth assistance of the widows.
At the moment I cannot take an telephone calls right now due to the
fact that my relatives (that have squandered the funds agave them for
this purpose before) are around me and my health status also. I have
adjusted my will and my lawyer is aware. I have willed those properties
to you by quoting my personal file routing and account information. And
I have also notified the bank that I am willing that properties to you
for a good, effective and prudent\work.
I know I don't know you but I have been directed to do this by god.ok
Please contact this woman for more details you might not get me on line
in time contact this email; mrs.suzaramalingwan1962@gmail.com
Your full name..........
Your private telephone number..........
Your passport or identity card........
Your country....................... ...
Your occupation..............
Thank you as i wait your reply.
Yoursfaithful friand,
Mrs Suzara Maling Wan
--
--
^ permalink raw reply
* Re: [SPAM]Re: [PATCH] net: mediatek: use dma_zalloc_coherent instead of allocator/memset
From: YueHaibing @ 2018-07-20 12:13 UTC (permalink / raw)
To: Russell King - ARM Linux, Sean Wang
Cc: nbd-p3rKhJxN3npAfugRpC6u6w, nelson.chang-NuS5LvNUpcJWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
john-Pj+rj9U5foFAfugRpC6u6w, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20180720092555.GA28941-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 2018/7/20 17:25, Russell King - ARM Linux wrote:
> On Fri, Jul 20, 2018 at 02:54:23PM +0800, Sean Wang wrote:
>> On Fri, 2018-07-20 at 14:30 +0800, YueHaibing wrote:
>>> On 2018/7/20 1:02, Sean Wang wrote:
>>>> On Thu, 2018-07-19 at 15:17 +0100, Russell King - ARM Linux wrote:
>>>>> On Thu, Jul 19, 2018 at 10:09:55PM +0800, YueHaibing wrote:
>>>>>> Use dma_zalloc_coherent instead of dma_alloc_coherent
>>>>>> followed by memset 0.
>>>>>>
>>>>>> Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>>>> ---
>>>>>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 7 ++-----
>>>>>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>>>>> index d8ebf0a..fbdb3e3 100644
>>>>>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>>>>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>>>>> @@ -1221,14 +1221,11 @@ static int mtk_tx_alloc(struct mtk_eth *eth)
>>>>>> if (!ring->buf)
>>>>>> goto no_tx_mem;
>>>>>>
>>>>>> - ring->dma = dma_alloc_coherent(eth->dev,
>>>>>> - MTK_DMA_SIZE * sz,
>>>>>> - &ring->phys,
>>>>>> - GFP_ATOMIC | __GFP_ZERO);
>>>>>> + ring->dma = dma_zalloc_coherent(eth->dev, MTK_DMA_SIZE * sz,
>>>>>> + &ring->phys, GFP_ATOMIC | __GFP_ZERO);
>>>>>> if (!ring->dma)
>>>>>> goto no_tx_mem;
>>>>>>
>>>>>> - memset(ring->dma, 0, MTK_DMA_SIZE * sz);
>>>>>
>>>>> I have to wonder whether this code needs two forms of zeroing... in
>>>>> the original code, __GFP_ZERO _and_ a call to memset() just in case
>>>>> __GFP_ZERO failed to do its job, and in the replacement code, just
>>>>> in case dma_zalloc_coherent() hasn't got the idea...
>>>>>
>>>>> I think you can drop the __GFP_ZERO. ;)
>>>>>
>>>>
>>>> Just now I did an experiment on 4.14.56 on armv7. I found that
>>>> dma_zalloc_coherent does not guarantee that the buffer we get
>>>> is all filled with 0.
>>>>
>>>>
>>>> I really think it's a little bit weird OR what was I missing something
>>>> for enabling dma_zalloc_coherent ? The result seems to tell that we
>>>> can't remove freely the memset with 0 at this moment until we get a
>>>> cause.
>>>>
>>>
>>> That means dma_zalloc_coherent doesn't work as expect on armv7?
>>>
>>
>> I'm not sure if it's true for every armv7. or it's only happening on my
>> device.
>>
>> anyway, i think we can replace all occurrences in the driver for
>> dma_alloc_coherent with __GFP_ZERO by dma_zalloc_coherent, and but
>> keep the extra memset as is.
>
> No, a bug in the allocator has been found that needs fixing. The
> right solution is to fix the allocator and remove what should be
> unnecessary memset()s.
Agree, will send v2.
>
> This should have been reported when the __GFP_ZERO flag was not
> being honoured and memset() was initially found to be required -
> all that dma_zalloc_coherent() does is set the __GFP_ZERO flag
> before calling dma_alloc_coherent().
>
^ permalink raw reply
* [PATCH 4.9 28/66] r8152: napi hangup fix after disconnect
From: Greg Kroah-Hartman @ 2018-07-20 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, linux-usb, netdev,
David S. Miller
In-Reply-To: <20180720121407.228772286@linuxfoundation.org>
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5 ]
When unplugging an r8152 adapter while the interface is UP, the NIC
becomes unusable. usb->disconnect (aka rtl8152_disconnect) deletes
napi. Then, rtl8152_disconnect calls unregister_netdev and that invokes
netdev->ndo_stop (aka rtl8152_close). rtl8152_close tries to
napi_disable, but the napi is already deleted by disconnect above. So
the first while loop in napi_disable never finishes. This results in
complete deadlock of the network layer as there is rtnl_mutex held by
unregister_netdev.
So avoid the call to napi_disable in rtl8152_close when the device is
already gone.
The other calls to usb_kill_urb, cancel_delayed_work_sync,
netif_stop_queue etc. seem to be fine. The urb and netdev is not
destroyed yet.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3327,7 +3327,8 @@ static int rtl8152_close(struct net_devi
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- napi_disable(&tp->napi);
+ if (!test_bit(RTL8152_UNPLUG, &tp->flags))
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
^ permalink raw reply
* [PATCH 4.14 42/92] r8152: napi hangup fix after disconnect
From: Greg Kroah-Hartman @ 2018-07-20 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, linux-usb, netdev,
David S. Miller
In-Reply-To: <20180720121417.206337808@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5 ]
When unplugging an r8152 adapter while the interface is UP, the NIC
becomes unusable. usb->disconnect (aka rtl8152_disconnect) deletes
napi. Then, rtl8152_disconnect calls unregister_netdev and that invokes
netdev->ndo_stop (aka rtl8152_close). rtl8152_close tries to
napi_disable, but the napi is already deleted by disconnect above. So
the first while loop in napi_disable never finishes. This results in
complete deadlock of the network layer as there is rtnl_mutex held by
unregister_netdev.
So avoid the call to napi_disable in rtl8152_close when the device is
already gone.
The other calls to usb_kill_urb, cancel_delayed_work_sync,
netif_stop_queue etc. seem to be fine. The urb and netdev is not
destroyed yet.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3959,7 +3959,8 @@ static int rtl8152_close(struct net_devi
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- napi_disable(&tp->napi);
+ if (!test_bit(RTL8152_UNPLUG, &tp->flags))
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
^ permalink raw reply
* [PATCH 4.4 18/31] r8152: napi hangup fix after disconnect
From: Greg Kroah-Hartman @ 2018-07-20 12:13 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jiri Slaby, linux-usb, netdev,
David S. Miller
In-Reply-To: <20180720121340.158484922@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
[ Upstream commit 0ee1f4734967af8321ecebaf9c74221ace34f2d5 ]
When unplugging an r8152 adapter while the interface is UP, the NIC
becomes unusable. usb->disconnect (aka rtl8152_disconnect) deletes
napi. Then, rtl8152_disconnect calls unregister_netdev and that invokes
netdev->ndo_stop (aka rtl8152_close). rtl8152_close tries to
napi_disable, but the napi is already deleted by disconnect above. So
the first while loop in napi_disable never finishes. This results in
complete deadlock of the network layer as there is rtnl_mutex held by
unregister_netdev.
So avoid the call to napi_disable in rtl8152_close when the device is
already gone.
The other calls to usb_kill_urb, cancel_delayed_work_sync,
netif_stop_queue etc. seem to be fine. The urb and netdev is not
destroyed yet.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linux-usb@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/usb/r8152.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3139,7 +3139,8 @@ static int rtl8152_close(struct net_devi
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(&tp->pm_notifier);
#endif
- napi_disable(&tp->napi);
+ if (!test_bit(RTL8152_UNPLUG, &tp->flags))
+ napi_disable(&tp->napi);
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(&tp->schedule);
^ permalink raw reply
* [PATCH] net/9p/trans_fd.c: fix double list_del() and race in access
From: Tomas Bortoli @ 2018-07-20 13:28 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: jiangyiwen, davem, v9fs-developer, netdev, linux-kernel,
syzkaller, Tomas Bortoli
This patch uses list_del_init() instead of list_del() to eliminate "req_list". This to prevent double list_del()'s calls to the same list from provoking a GPF. Furthermore, this patch fixes an access to "req_list" that was made without getting the relative lock.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
---
net/9p/trans_fd.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index a64b01c56e30..131bb1f059e6 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -223,7 +223,9 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
- list_del(&req->req_list);
+ spin_lock_irqsave(&m->client->lock, flags);
+ list_del_init(&req->req_list);
+ spin_unlock_irqrestore(&m->client->lock, flags);
if (!req->t_err)
req->t_err = err;
p9_client_cb(m->client, req, REQ_STATUS_ERROR);
@@ -369,7 +371,7 @@ static void p9_read_work(struct work_struct *work)
spin_lock(&m->client->lock);
if (m->req->status != REQ_STATUS_ERROR)
status = REQ_STATUS_RCVD;
- list_del(&m->req->req_list);
+ list_del_init(&m->req->req_list);
spin_unlock(&m->client->lock);
p9_client_cb(m->client, m->req, status);
m->rc.sdata = NULL;
@@ -684,7 +686,7 @@ static int p9_fd_cancel(struct p9_client *client, struct p9_req_t *req)
spin_lock(&client->lock);
if (req->status == REQ_STATUS_UNSENT) {
- list_del(&req->req_list);
+ list_del_init(&req->req_list);
req->status = REQ_STATUS_FLSHD;
ret = 0;
}
@@ -701,7 +703,7 @@ static int p9_fd_cancelled(struct p9_client *client, struct p9_req_t *req)
* remove it from the list.
*/
spin_lock(&client->lock);
- list_del(&req->req_list);
+ list_del_init(&req->req_list);
spin_unlock(&client->lock);
return 0;
--
2.11.0
^ 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