* Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers @ 2019-07-24 1:38 UTC (permalink / raw)
To: netdev, David S. Miller, Florian Westphal, Ilya Maximets,
Eric Dumazet, David Ahern
Cc: linux-kernel, syzkaller-bugs
[This email was generated by a script. Let me know if you have any suggestions
to make it better, or if you want it re-generated with the latest status.]
Of the currently open syzbot reports against the upstream kernel, I've manually
marked 99 of them as possibly being bugs in the net subsystem. This category
only includes the networking bugs that I couldn't assign to a more specific
component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've listed
these reports below, sorted by an algorithm that tries to list first the reports
most likely to be still valid, important, and actionable.
Of these 99 bugs, 17 were seen in mainline in the last week.
Of these 99 bugs, 4 were bisected to commits from the following people:
Florian Westphal <fw@strlen.de>
Ilya Maximets <i.maximets@samsung.com>
Eric Dumazet <edumazet@google.com>
David Ahern <dsahern@gmail.com>
If you believe a bug is no longer valid, please close the syzbot report by
sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
original thread, as explained at https://goo.gl/tpsmEJ#status
If you believe I misattributed a bug to the net subsystem, please let me know,
and if possible forward the report to the correct people or mailing list.
Here are the bugs:
--------------------------------------------------------------------------------
Title: unregister_netdevice: waiting for DEV to become free (2)
Last occurred: 0 days ago
Reported: 342 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=bae9a2236bfede42cf3d219e6bf6740c583568a4
Original thread: https://lkml.kernel.org/lkml/00000000000056268e05737dcb95@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 27 replies; the last was 80 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+30209ea299c09d8785c9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000056268e05737dcb95@google.com
--------------------------------------------------------------------------------
Title: kernel BUG at net/core/skbuff.c:LINE! (3)
Last occurred: 1 day ago
Reported: 537 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00
Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/001a114372a6074e6505642b7f72%40google.com
This bug has a C reproducer.
For some reason the original report email for this bug is missing from the LKML
archive at lore.kernel.org, so my script couldn't check whether anyone has
replied to it or not. The Google Groups link above should still work, though.
Also try searching for the bug title.
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in __netif_receive_skb_core
Last occurred: 0 days ago
Reported: 467 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=0c8e5c99b3db338c8956fcb7231eb1f7e2d707f9
Original thread: https://lkml.kernel.org/lkml/94eb2c059ce01f643c0569a228ee@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 3 replies; the last was 466 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/94eb2c059ce01f643c0569a228ee@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in ip6_parse_tlv
Last occurred: 0 days ago
Reported: 306 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=a446d3718ee6322911a0c6d34db57909e1838fe7
Original thread: https://lkml.kernel.org/lkml/00000000000030779c057653b9ef@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f08ac29f2ac8aea19826@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000030779c057653b9ef@google.com
--------------------------------------------------------------------------------
Title: WARNING in xt_compat_add_offset
Last occurred: 1 day ago
Reported: 151 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=28b6bf730a5e8d288db5c794d5c6ccc49f746d74
Original thread: https://lkml.kernel.org/lkml/00000000000081994205827ea9a0@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 2035f3ff8eaa29cfb5c8e2160b0f6e85eeb21a95
Author: Florian Westphal <fw@strlen.de>
Date: Mon Jan 21 20:54:36 2019 +0000
netfilter: ebtables: compat: un-break 32bit setsockopt when no rules are present
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+276ddebab3382bbf72db@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000081994205827ea9a0@google.com
--------------------------------------------------------------------------------
Title: WARNING in rollback_registered_many (2)
Last occurred: 0 days ago
Reported: 258 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d39aca7a05a76d146ba96cddbb3242075d9171a7
Original thread: https://lkml.kernel.org/lkml/000000000000d9f094057a17b97b@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 1 reply, 102 days ago.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+40918e4d826fb2ff9b96@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000d9f094057a17b97b@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in bcmp
Last occurred: 0 days ago
Reported: 45 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=38933ca8abb1b8f0ee10c430f3a6c1f6a68a2519
Original thread: https://lkml.kernel.org/lkml/0000000000008f00f7058ad13ec8@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d8b02c920ae8f3e0be75@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008f00f7058ad13ec8@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in mii_nway_restart
Last occurred: 0 days ago
Reported: 49 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=835562bfa4dd92c72f323f29ad388c9cb4b0e63f
Original thread: https://lkml.kernel.org/lkml/000000000000f71859058a7cfdc8@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1f53a30781af65d2c955@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f71859058a7cfdc8@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in r871xu_drv_init
Last occurred: 2 days ago
Reported: 47 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8
Original thread: https://lkml.kernel.org/lkml/000000000000417702058aa80506@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6f5ecd144854c0d8580b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000417702058aa80506@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in ax88178_bind
Last occurred: 1 day ago
Reported: 46 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=d601416c178e3d67888024bdf7774477a034840b
Original thread: https://lkml.kernel.org/lkml/000000000000cba2b6058ac09eeb@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+abd25d675d47f23f188c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000cba2b6058ac09eeb@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in rtnl_lock (6)
Last occurred: 4 days ago
Reported: 15 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5dcc2956e8737c91083930c55796c5b98750f1d2
Original thread: https://lkml.kernel.org/lkml/000000000000ba542e058d309136@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 455302d1c9ae9318660aaeb9748a01ff414c9741
Author: Ilya Maximets <i.maximets@samsung.com>
Date: Fri Jun 28 08:04:07 2019 +0000
xdp: fix hang while unregistering device bound to xdp socket
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+174ce29c2308dec5bc68@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ba542e058d309136@google.com
--------------------------------------------------------------------------------
Title: INFO: task hung in unregister_netdevice_notifier (3)
Last occurred: 2 days ago
Reported: 156 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1724d278c83ca6e6df100a2e320c10d991cf2bce
Original thread: https://lkml.kernel.org/lkml/0000000000009d787a0582128cbe@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug received 2 replies; the last was 8 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0f1827363a305f74996f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread, which had activity only 8 days ago. For the git send-email command to
use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
instructions" at https://lkml.kernel.org/r/0000000000009d787a0582128cbe@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in gre_parse_header
Last occurred: 0 days ago
Reported: 30 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=af9d9384bbda6732044cf6335966df874a40cff1
Original thread: https://lkml.kernel.org/lkml/000000000000dc4531058bfb4605@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f583ce3d4ddf9836b27a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000dc4531058bfb4605@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in ila_nf_input
Last occurred: 1 day ago
Reported: 189 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=6911f9daa3f3c89b595884f30b212e60e889d384
Original thread: https://lkml.kernel.org/lkml/0000000000003036f4057f81e98e@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+03a25358f4cba0bc4cb6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003036f4057f81e98e@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in smsc95xx_read_eeprom (2)
Last occurred: 0 days ago
Reported: 13 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=0629febb76ae17ff78874aa68991e542506b1351
Original thread: https://lkml.kernel.org/lkml/000000000000e38991058d54c35f@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0dfe788c0e7be7c95931@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e38991058d54c35f@google.com
--------------------------------------------------------------------------------
Title: general protection fault in tcf_ife_init
Last occurred: 3 days ago
Reported: 1 day ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=ae313e1903160aebaac974b675db644baa44f581
Original thread: https://lkml.kernel.org/lkml/000000000000772876058e46063f@google.com/T/#u
This bug has a C reproducer.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+fbb5b288c9cb6a2eeac4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000772876058e46063f@google.com
--------------------------------------------------------------------------------
Title: memory leak in kobject_set_name_vargs (2)
Last occurred: 1 day ago
Reported: 0 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=f5f4af9fb9ffb3112ad6e30f717f769decdccdfc
Original thread: https://lkml.kernel.org/lkml/000000000000edcb3c058e6143d5@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ad8ca40ecd77896d51e2@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000edcb3c058e6143d5@google.com
--------------------------------------------------------------------------------
Title: WARNING in mcba_usb_probe/usb_submit_urb
Last occurred: 1 day ago
Reported: 13 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=6daf4bbae6c9c761ac2863d6d23be4cbdaebde7d
Original thread: https://lkml.kernel.org/lkml/000000000000996786058d52cb39@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3bc1dce0cc0052d60fde@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000996786058d52cb39@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in usb_kill_anchored_urbs
Last occurred: 17 days ago
Reported: 42 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=18b605fd212e6e477e038c699430b44ca5946eac
Original thread: https://lkml.kernel.org/lkml/000000000000e84a3a058b0f9307@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+eb6ab607626fd1dac0f1@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e84a3a058b0f9307@google.com
--------------------------------------------------------------------------------
Title: memory leak in __nf_hook_entries_try_shrink
Last occurred: 16 days ago
Reported: 40 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=a00ae6ea26b62609c1df4d7f0d21e4a7635d8203
Original thread: https://lkml.kernel.org/lkml/0000000000005718ef058b3a0fcf@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c51f73e78e7e2ce3a31e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005718ef058b3a0fcf@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in do_ip_vs_set_ctl
Last occurred: 29 days ago
Reported: 312 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=46ebfb92a8a812621a001ef04d90dfa459520fe2
Original thread: https://lkml.kernel.org/lkml/00000000000015a13b0575d8eae8@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+23b5f9e7caf61d9a3898@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000015a13b0575d8eae8@google.com
--------------------------------------------------------------------------------
Title: kernel panic: stack is corrupted in __lock_acquire (4)
Last occurred: 5 days ago
Reported: 43 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=b75c6f861ac07fc8410957c22e74802b4313ec3d
Original thread: https://lkml.kernel.org/lkml/0000000000009b3b80058af452ae@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000009b3b80058af452ae@google.com
--------------------------------------------------------------------------------
Title: memory leak in fdb_create
Last occurred: 29 days ago
Reported: 29 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=7ca7d71ade3608a7f92ac4b8c9c499cf130e68a9
Original thread: https://lkml.kernel.org/lkml/0000000000005e6124058c0cbdbe@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+88533dc8b582309bf3ee@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005e6124058c0cbdbe@google.com
--------------------------------------------------------------------------------
Title: memory leak in rawv6_sendmsg
Last occurred: 30 days ago
Reported: 47 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=4b6cb10258f6d4c0f37be902f90849a02749a333
Original thread: https://lkml.kernel.org/lkml/000000000000fa6b60058aa0559b@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0210b383c62bb2a35e32@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa6b60058aa0559b@google.com
--------------------------------------------------------------------------------
Title: general protection fault in drain_workqueue
Last occurred: 12 days ago
Reported: 71 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=4a4b04b94b33e7d1de6f1213355499ab529a3018
Original thread: https://lkml.kernel.org/lkml/000000000000caab290588c4083e@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+09139d1a5ed6b898e29d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000caab290588c4083e@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in ip_rcv_core
Last occurred: 36 days ago
Reported: 310 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f29ecad95c6f106f
Original thread: https://lkml.kernel.org/lkml/0000000000002407700575fb00f4@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+2e406a9ac75bb71d4b7a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002407700575fb00f4@google.com
--------------------------------------------------------------------------------
Title: WARNING in wa_nep_create/usb_submit_urb
Last occurred: 13 days ago
Reported: 13 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=a07f49ea1871dcb4a34ff5aff5a46b0fcd8b3523
Original thread: https://lkml.kernel.org/lkml/000000000000acb38c058d51ad4f@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5da93055dfbb6bc54963@syzkaller.appspotmail.com
If you send any email or patch for this bug, please reply to the original
thread. For the git send-email command to use, or tips on how to reply if the
thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000acb38c058d51ad4f@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Write in skb_release_data (2)
Last occurred: 117 days ago
Reported: 281 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=8340d4b8c7304ff0b43490a1b69ab3833dd7ad20
Original thread: https://lkml.kernel.org/lkml/0000000000003ba80905783e9189@google.com/T/#u
This bug has a C reproducer.
This bug was bisected to:
commit 472c2e07eef045145bc1493cc94a01c87140780a
Author: Eric Dumazet <edumazet@google.com>
Date: Fri Mar 22 15:56:39 2019 +0000
tcp: add one skb cache for tx
The original thread for this bug received 3 replies; the last was 119 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+580be3953ed99133804f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003ba80905783e9189@google.com
--------------------------------------------------------------------------------
Title: general protection fault in ip6_dst_lookup_tail (2)
Last occurred: 34 days ago
Reported: 85 days ago
Branches: bpf-next, linux-next, net, and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=079bd8408abd95b492f127edf0df44ddc09d9405
Original thread: https://lkml.kernel.org/lkml/0000000000006b30f30587a5b569@google.com/T/#u
This bug has a syzkaller reproducer only.
This bug was bisected to:
commit f40b6ae2b612446dc970d7b51eeec47bd1619f82
Author: David Ahern <dsahern@gmail.com>
Date: Thu May 23 03:27:55 2019 +0000
ipv6: Move pcpu cached routes to fib6_nh
The original thread for this bug has received 1 reply, 85 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+58d8f704b86e4e3fb4d3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006b30f30587a5b569@google.com
--------------------------------------------------------------------------------
Title: general protection fault in cdev_del
Last occurred: 47 days ago
Reported: 56 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=dc0ead75c30e6aa27153b6cab86194e55e290a98
Original thread: https://lkml.kernel.org/lkml/000000000000532b860589f0669a@google.com/T/#u
This bug has a C reproducer.
No one has replied to the original thread for this bug yet.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000532b860589f0669a@google.com
--------------------------------------------------------------------------------
Title: INFO: task hung in addrconf_dad_work
Last occurred: 23 days ago
Reported: 157 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=7293d6f37a448b017658dc1001452ff193cdb566
Original thread: https://lkml.kernel.org/lkml/0000000000001d37cd0582003c53@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f4290c15a8ab6dee87c9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001d37cd0582003c53@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in netdev_freemem (2)
Last occurred: 0 days ago
Reported: 29 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=96a64fde216dca408a5c25db4e57838c51e435aa
Original thread: https://lkml.kernel.org/lkml/000000000000d6a8ba058c0df076@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug has received 6 replies; the last was 29 days
ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c4521ac872a4ccc3afec@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000d6a8ba058c0df076@google.com
--------------------------------------------------------------------------------
Title: memory leak in genl_register_family
Last occurred: 28 days ago
Reported: 28 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=e30aad348314bcaacef4466bbce33be5933e08cf
Original thread: https://lkml.kernel.org/lkml/000000000000f5d536058c23ed60@google.com/T/#u
This bug has a syzkaller reproducer only.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+fc577f12f25f2ac3b211@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f5d536058c23ed60@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in __dev_mc_del
Last occurred: 86 days ago
Reported: 309 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=a84ac404cf07db753e289b918981964b540359bd
Original thread: https://lkml.kernel.org/lkml/00000000000011d524057617eb4a@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0ffee94c5c059dbbc2a9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000011d524057617eb4a@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in __dev_queue_xmit (2)
Last occurred: 1 day ago
Reported: 117 days ago
Branches: bpf-next and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=f9e1abb5bf1d75834c1906398efab4601265cad5
Original thread: https://lkml.kernel.org/lkml/000000000000ee01ef058529d74c@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f8c40b4da41f3e8049c4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ee01ef058529d74c@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in udpv6_pre_connect
Last occurred: 2 days ago
Reported: 68 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=360cc28d22ff388dcda1dd642c5c77aa4b8b3e2d
Original thread: https://lkml.kernel.org/lkml/0000000000003028060588fac869@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+65f10c5aadc049eb5ef5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003028060588fac869@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in do_ipv6_getsockopt
Last occurred: 21 days ago
Reported: 21 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=e97be0bf4d30813e951bcc6249e72c592a790164
Original thread: https://lkml.kernel.org/lkml/000000000000607bf4058cb5135c@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 21 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+babfdd7368c72aac3875@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000607bf4058cb5135c@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in IP6_ECN_decapsulate
Last occurred: 401 days ago
Reported: 306 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=ca4ff394c64aec3684d0034896290c72a83b7077
Original thread: https://lkml.kernel.org/lkml/000000000000336563057653b9aa@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+bf7e6250c7ce248f3ec9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000336563057653b9aa@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in tick_sched_handle (3)
Last occurred: 190 days ago
Reported: 246 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=fce6ae4655ae3133b8b7410c3370bb2167c6324d
Original thread: https://lkml.kernel.org/lkml/0000000000007829c8057b0b58ed@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 2 replies; the last was 245 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+999bca54de2ee169c021@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007829c8057b0b58ed@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in strlcpy (2)
Last occurred: 321 days ago
Reported: 312 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=ab0817a1599dd2fbbda6af5d5645ef92596fcb8e
Original thread: https://lkml.kernel.org/lkml/00000000000012463d0575d8eace@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c86cf7903306a6c201ba@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000012463d0575d8eace@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in __icmp_send
Last occurred: 42 days ago
Reported: 139 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=8375400c5f4e129bf049227adce14e4698a4bc33
Original thread: https://lkml.kernel.org/lkml/000000000000de803205836436dd@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f09d845ad631ed93737b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000de803205836436dd@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in vhci_hub_control
Last occurred: 278 days ago
Reported: 323 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=00aa2c9aba775f0761d3dabd7fb176964685051a
Original thread: https://lkml.kernel.org/lkml/00000000000075c8d70574f40fbc@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+600b03e0cf1b73bb23c4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000075c8d70574f40fbc@google.com
--------------------------------------------------------------------------------
Title: WARNING: refcount bug in igmp_start_timer
Last occurred: 100 days ago
Reported: 339 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=667f1bd0ab632a49ca3daaa6967cc023b1c5b0c6
Original thread: https://lkml.kernel.org/lkml/0000000000002b42040573b8495a@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e28037ac1c96d2a86e89@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000002b42040573b8495a@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in sit_tunnel_xmit
Last occurred: 230 days ago
Reported: 361 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=66bbedf52134d2359166806349088d36a6b6a254
Original thread: https://lkml.kernel.org/lkml/00000000000082e3a90571fadb4c@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+782ee96f9147673d8822@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000082e3a90571fadb4c@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in gre_rcv (2)
Last occurred: 140 days ago
Reported: 300 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=cf4a7c5922ce5ad229f97ed1eac213a12d427d1d
Original thread: https://lkml.kernel.org/lkml/0000000000007ce3ae0576c788e5@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+841c053d026900055032@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007ce3ae0576c788e5@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in lock_sock_nested
Last occurred: 81 days ago
Reported: 100 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=a9f61ee7d10b848190610b0fe298bd9030a8288c
Original thread: https://lkml.kernel.org/lkml/000000000000e8cf3805867bd715@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+605a69fff339d9cc221e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e8cf3805867bd715@google.com
--------------------------------------------------------------------------------
Title: KMSAN: uninit-value in __dev_mc_add
Last occurred: 104 days ago
Reported: 300 days ago
Branches: Mainline (with KMSAN patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51
Original thread: https://lkml.kernel.org/lkml/0000000000005e2e530576c6f9ce@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 3 replies; the last was 299 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005e2e530576c6f9ce@google.com
--------------------------------------------------------------------------------
Title: INFO: task hung in do_ip_vs_set_ctl (2)
Last occurred: 457 days ago
Reported: 472 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=26aa22915f5e3b7ca2cfca76a939f12c25d624db
Original thread: https://lkml.kernel.org/lkml/94eb2c059ce0bca273056940d77d@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7810ed2e0cb359580c17@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/94eb2c059ce0bca273056940d77d@google.com
--------------------------------------------------------------------------------
Title: KASAN: null-ptr-deref Read in ip6_hold_safe
Last occurred: 35 days ago
Reported: 190 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=9b5576748203154c7b7703aac19d0a5adc8f987e
Original thread: https://lkml.kernel.org/lkml/00000000000075c0ef057f657b8d@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 1 reply, 190 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8433ca0841e308ef4cc7@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000075c0ef057f657b8d@google.com
--------------------------------------------------------------------------------
Title: INFO: task hung in rtnetlink_rcv_msg
Last occurred: 156 days ago
Reported: 151 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=788ed2c7e973b69fd551ba6b5e21848dba2c1670
Original thread: https://lkml.kernel.org/lkml/000000000000c07a5805827e85d5@google.com/T/#u
This bug has a C reproducer.
The original thread for this bug received 7 replies; the last was 148 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+8218a8a0ff60c19b8eae@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000c07a5805827e85d5@google.com
--------------------------------------------------------------------------------
Title: general protection fault in dev_get_by_index_rcu
Last occurred: 30 days ago
Reported: 152 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=e9d52597e9cbdd22621b6790702c9fefe071af25
Original thread: https://lkml.kernel.org/lkml/00000000000095c8f005826888fd@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+48127bec5a5cd81411e3@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000095c8f005826888fd@google.com
--------------------------------------------------------------------------------
Title: general protection fault in gro_cells_destroy
Last occurred: 30 days ago
Reported: 194 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1e493023b2e9f4b6738977af63ed5b521201e74a
Original thread: https://lkml.kernel.org/lkml/00000000000029bf02057f1e1596@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6fe674089f9deb9f7726@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000029bf02057f1e1596@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in device_del
Last occurred: 51 days ago
Reported: 50 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=2aa2f730c9d353ad29bb92acf8fd0b426ce1b393
Original thread: https://lkml.kernel.org/lkml/000000000000fa11f3058a69d67b@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug has received 2 replies; the last was 47 days
ago.
This looks like a bug in a net USB driver.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+93f2f45b19519b289613@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000fa11f3058a69d67b@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in tcp_sk_exit
Last occurred: 36 days ago
Reported: 167 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=24c7faa7497a843d2c714efffcc747853c55b669
Original thread: https://lkml.kernel.org/lkml/000000000000ddb37c0581329cc5@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f797267da5e5012d0920@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ddb37c0581329cc5@google.com
--------------------------------------------------------------------------------
Title: WARNING in tcp_enter_loss (2)
Last occurred: 448 days ago
Reported: 498 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b0bacf5645b1e60bbb14015bc0e23b9019621fc4
Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/001a113f39820d16d50567379661%40google.com
This bug has a C reproducer.
For some reason the original report email for this bug is missing from the LKML
archive at lore.kernel.org, so my script couldn't check whether anyone has
replied to it or not. The Google Groups link above should still work, though.
Also try searching for the bug title.
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in ip6_tnl_parse_tlv_enc_lim
Last occurred: 240 days ago
Reported: 309 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b321cffb2022132bac9c54cbe0adcab20cfdd911
Original thread: https://lkml.kernel.org/lkml/0000000000005175bf057617c71d@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+68dce7caebd8543121de@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005175bf057617c71d@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in ip_send_unicast_reply
Last occurred: 31 days ago
Reported: 167 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=b2fcf1ea1f7f874f9ae3ede65e0f47e82a02b3a1
Original thread: https://lkml.kernel.org/lkml/0000000000005e6094058132a09a@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f1741fbf71635c029556@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000005e6094058132a09a@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in page_get_anon_vma
Last occurred: 26 days ago
Reported: 77 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=c275ff8b0b025c8a9baf06c3799d5c2efb919b56
Original thread: https://lkml.kernel.org/lkml/0000000000008aa0e4058849190e@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ed3e5c9a6a1e30a1bd2a@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008aa0e4058849190e@google.com
--------------------------------------------------------------------------------
Title: WARNING: ODEBUG bug in del_timer (3)
Last occurred: 64 days ago
Reported: 77 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d1853700c9f62752d8498e05189f5d0f21a55631
Original thread: https://lkml.kernel.org/lkml/000000000000dace5e0588529558@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug has received 1 reply, 77 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+13d91ed9bbcd7dc13230@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000dace5e0588529558@google.com
--------------------------------------------------------------------------------
Title: kernel BUG at net/ipv6/route.c:LINE! (2)
Last occurred: 31 days ago
Reported: 197 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=5789609f5b68813f3bf496c9786b9df683dbaa2f
Original thread: https://lkml.kernel.org/lkml/000000000000114562057edb528d@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+be0943c590bb47aefb9e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000114562057edb528d@google.com
--------------------------------------------------------------------------------
Title: INFO: trying to register non-static key in icmp_send
Last occurred: 154 days ago
Reported: 175 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=ea46a31df5253b18deb1e18c429c1483b111cbce
Original thread: https://lkml.kernel.org/lkml/0000000000007cd20e05809c2f96@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 1 reply, 121 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+e1628a5e87492e6f1b76@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000007cd20e05809c2f96@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in ip6_hold_safe
Last occurred: 37 days ago
Reported: 152 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=16a5da76273f5052f30015161c9bd05153bc1172
Original thread: https://lkml.kernel.org/lkml/0000000000003209980582688c5b@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ec03ae3a032901d10434@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003209980582688c5b@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in tcp_sk_exit
Last occurred: 53 days ago
Reported: 138 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3901fe419ff5f17d6a1607b7d6d79c629a571946
Original thread: https://lkml.kernel.org/lkml/000000000000071b3c05838536b8@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+dfc9db054bca3a83f4a0@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000071b3c05838536b8@google.com
--------------------------------------------------------------------------------
Title: KASAN: user-memory-access Write in dst_release
Last occurred: 39 days ago
Reported: 197 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=c6269996e9feee38b279462027a03d4e49df1162
Original thread: https://lkml.kernel.org/lkml/000000000000a06f21057edc53c0@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+29ffc731816e0995ad54@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000a06f21057edc53c0@google.com
--------------------------------------------------------------------------------
Title: WARNING in csum_and_copy_to_iter
Last occurred: 243 days ago
Reported: 241 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=602b1f5d93c8e231d50a1424c2fbc3318bcc6833
Original thread: https://lkml.kernel.org/lkml/0000000000001ecaa1057b6e4489@google.com/T/#u
This bug has a syzkaller reproducer only.
The original thread for this bug received 5 replies; the last was 239 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+ce18da013d76d837144d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001ecaa1057b6e4489@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in sch_direct_xmit
Last occurred: 476 days ago
Reported: 553 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3b9ee8a71fc404315ece5d56076775a2ed19ce1d
Original thread: https://lkml.kernel.org/lkml/089e0825d4a4d2cb2a0562e878f1@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+29cc278357da941e304e@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/089e0825d4a4d2cb2a0562e878f1@google.com
--------------------------------------------------------------------------------
Title: WARNING: bad unlock balance detected! (3)
Last occurred: 119 days ago
Reported: 149 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=342beb2b368a43cbb6533c00d758759b10fbc8d8
Original thread: https://lkml.kernel.org/lkml/000000000000685dc805829e835c@google.com/T/#u
This bug has a syzkaller reproducer only.
syzbot has bisected this bug, but I think the bisection result is incorrect.
The original thread for this bug received 2 replies; the last was 119 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f3e3434787332dfc1c47@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000685dc805829e835c@google.com
--------------------------------------------------------------------------------
Title: inconsistent lock state in ila_xlat_nl_cmd_del_mapping
Last occurred: 337 days ago
Reported: 343 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=be943a4399dcf3ed43bac2694a3b8957c6980409
Original thread: https://lkml.kernel.org/lkml/000000000000ae453e05735dcdb8@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3db64bd48b29a825d2db@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ae453e05735dcdb8@google.com
--------------------------------------------------------------------------------
Title: kernel BUG at net/ipv4/ip_output.c:LINE!
Last occurred: 184 days ago
Reported: 375 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=d582be84c0efa34f4936e12227905b2c18989a25
Original thread: https://lkml.kernel.org/lkml/000000000000f68d660570dcddd8@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+90d5ec0c05e708f3b66d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000f68d660570dcddd8@google.com
--------------------------------------------------------------------------------
Title: KASAN: null-ptr-deref Write in dst_release
Last occurred: 35 days ago
Reported: 197 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=e25580ce7d7f1e6c3bed77954ec56dfd7ce89805
Original thread: https://lkml.kernel.org/lkml/00000000000012073a057edb3996@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1f4f4025b8564c8da9d4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000012073a057edb3996@google.com
--------------------------------------------------------------------------------
Title: general protection fault in fib6_nh_init
Last occurred: 34 days ago
Reported: 49 days ago
Branches: bpf-next and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=29b9955ae85cdd2f20baf5d975763a446f2783df
Original thread: https://lkml.kernel.org/lkml/0000000000008ee293058a787e2d@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug has received 1 reply, 48 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+1b2927fda48c5bf2e931@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000008ee293058a787e2d@google.com
--------------------------------------------------------------------------------
Title: general protection fault in tcp_v6_connect
Last occurred: 35 days ago
Reported: 52 days ago
Branches: bpf-next and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=71eb43337087b631994f0811b2d84dfbc4bfcfc4
Original thread: https://lkml.kernel.org/lkml/000000000000aa7a27058a3ce9aa@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+5ee26b4e30c45930bd3c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000aa7a27058a3ce9aa@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in icmp_sk_exit
Last occurred: 140 days ago
Reported: 153 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=0cbaf5f5094157a8d563c6c1cbe5ee20028a8902
Original thread: https://lkml.kernel.org/lkml/000000000000b436ad058255c528@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3d7fa0f0de0f86d0eb4f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b436ad058255c528@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in bond_get_stats (2)
Last occurred: 64 days ago
Reported: 232 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=ea28d585e25ade2dde266036c70df752bb3a0fcb
Original thread: https://lkml.kernel.org/lkml/000000000000dd0b51057c263f7f@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+de40a1dd58ea38aa9317@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000dd0b51057c263f7f@google.com
--------------------------------------------------------------------------------
Title: inconsistent lock state in ila_xlat_nl_cmd_add_mapping
Last occurred: 337 days ago
Reported: 343 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=481b4913494f0dcabc2e06e3158a3d042abdf985
Original thread: https://lkml.kernel.org/lkml/000000000000b14d8c05735dcdf8@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+eaaf6c4a6a8cb1869d86@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b14d8c05735dcdf8@google.com
--------------------------------------------------------------------------------
Title: general protection fault in __queue_work
Last occurred: 139 days ago
Reported: 138 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=1401c87c1eac8167422bcdb28cf81647d894e8d2
Original thread: https://lkml.kernel.org/lkml/000000000000aec29a0583853924@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+b26e643d0aa2822e9c87@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000aec29a0583853924@google.com
--------------------------------------------------------------------------------
Title: WARNING in remove_proc_entry (2)
Last occurred: 90 days ago
Reported: 244 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=fab7eb1ff4259eb5e6cb9067cba63ec7b1568b4d
Original thread: https://lkml.kernel.org/lkml/00000000000061c4cf057b306863@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+46d1fec9e51890edb1a6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000061c4cf057b306863@google.com
--------------------------------------------------------------------------------
Title: general protection fault in __sock_release (2)
Last occurred: 36 days ago
Reported: 174 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=6997b9812b85ed88863bddecad772e8d3659e358
Original thread: https://lkml.kernel.org/lkml/000000000000559d460580ad5eeb@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+38b29941610a1cc735dc@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000559d460580ad5eeb@google.com
--------------------------------------------------------------------------------
Title: WARNING in __static_key_slow_dec_cpuslocked
Last occurred: 80 days ago
Reported: 77 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=753aa2e459553231bb71e1602b2cd27171a06d32
Original thread: https://lkml.kernel.org/lkml/000000000000759a89058848e747@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+a65e6ce239e4afe6c5e7@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000759a89058848e747@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in sk_diag_fill
Last occurred: 65 days ago
Reported: 444 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=3968882ac771e7458b15f8086477f42d7ca6dec0
Original thread: https://lkml.kernel.org/lkml/000000000000169606056b793179@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 6 replies; the last was 434 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+c1872be62e587eae9669@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000169606056b793179@google.com
--------------------------------------------------------------------------------
Title: general protection fault in fib6_purge_rt (2)
Last occurred: 43 days ago
Reported: 91 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=e017f309864dbdc2a6926d235e0ce85b6272dcfd
Original thread: https://lkml.kernel.org/lkml/000000000000caeb1c058734c654@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+d53d5d9b6793dc70eb9d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000caeb1c058734c654@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in icmpv6_xrlim_allow
Last occurred: 38 days ago
Reported: 49 days ago
Branches: bpf-next
Dashboard link: https://syzkaller.appspot.com/bug?id=d22f32efcb9496c8fa450f963bcce4d3e4cdf09d
Original thread: https://lkml.kernel.org/lkml/000000000000ae08b2058a785a4c@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+14536436e78408172703@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ae08b2058a785a4c@google.com
--------------------------------------------------------------------------------
Title: KASAN: user-memory-access Write in fib6_purge_rt (2)
Last occurred: 42 days ago
Reported: 49 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=29ea3db1b7655bdcf69bc0e3d8e5901623444640
Original thread: https://lkml.kernel.org/lkml/0000000000003f73d9058a785eec@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+420d3f70afb5d69d5a96@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003f73d9058a785eec@google.com
--------------------------------------------------------------------------------
Title: BUG: spinlock bad magic in __queue_work
Last occurred: 119 days ago
Reported: 167 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=27ee7c254659d57dd99215715f3db0ed20339941
Original thread: https://lkml.kernel.org/lkml/000000000000e063bb0581329cc0@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+636bcaf4b481f6b7343c@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e063bb0581329cc0@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in genl_rcv (2)
Last occurred: 133 days ago
Reported: 193 days ago
Branches: Mainline
Dashboard link: https://syzkaller.appspot.com/bug?id=f8a6b7d881874def4c37657fac2453f7551a7664
Original thread: https://lkml.kernel.org/lkml/000000000000827dbb057f2b85bb@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+cf29f8ae16ca7ceb483d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000827dbb057f2b85bb@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in fib6_purge_rt (2)
Last occurred: 50 days ago
Reported: 49 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=4174cd9494cb4571668f34ab96fcb2382554e6fb
Original thread: https://lkml.kernel.org/lkml/000000000000b6a7d2058a78736d@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+f4812f31edd866494c9f@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000b6a7d2058a78736d@google.com
--------------------------------------------------------------------------------
Title: KASAN: slab-out-of-bounds Read in fib6_rule_lookup (2)
Last occurred: 52 days ago
Reported: 116 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=148148cb145574b07580d9e34877b4eef587ed31
Original thread: https://lkml.kernel.org/lkml/00000000000021ef3505853f988e@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+49f38f33f3c5d76cb19b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000021ef3505853f988e@google.com
--------------------------------------------------------------------------------
Title: KASAN: wild-memory-access Write in fib6_purge_rt
Last occurred: 86 days ago
Reported: 165 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=e3ed1520f5d50c003569cc69066d780ef2ee9f18
Original thread: https://lkml.kernel.org/lkml/000000000000ca08dd0581649889@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+3dbea54db3674c0d57d6@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ca08dd0581649889@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in try_to_grab_pending
Last occurred: 161 days ago
Reported: 160 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=86c7f0dd3bfa4cd651bb37a04da2cfcabd860225
Original thread: https://lkml.kernel.org/lkml/0000000000006dc0290581ca413e@google.com/T/#u
This bug has a syzkaller reproducer only.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+2b713236b28823cd4dff@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000006dc0290581ca413e@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in skb_queue_tail
Last occurred: 125 days ago
Reported: 477 days ago
Branches: Mainline and others
Dashboard link: https://syzkaller.appspot.com/bug?id=ab5525a0b79efd6a5dbb4deb3ccd3e93d9c03321
Original thread: https://lkml.kernel.org/lkml/0000000000003584570568da18dd@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 5 replies; the last was 475 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6b495100f17ca8554ab9@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000003584570568da18dd@google.com
--------------------------------------------------------------------------------
Title: WARNING: locking bug in icmp6_send (2)
Last occurred: 44 days ago
Reported: 42 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=2ccdf5f785fdb1087d9dc106dd8bc71ea9a1fb58
Original thread: https://lkml.kernel.org/lkml/000000000000e64753058b06f83f@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+0ee50f3d30ce6a28b3cd@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e64753058b06f83f@google.com
--------------------------------------------------------------------------------
Title: general protection fault in ipv6_rcv
Last occurred: 73 days ago
Reported: 136 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=6a14da2954543d26e61aeaefa0098d445854c5c1
Original thread: https://lkml.kernel.org/lkml/0000000000001b05b40583a46fd7@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6c54e67cc0b0c896aa4b@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000001b05b40583a46fd7@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in neigh_change_state
Last occurred: 211 days ago
Reported: 223 days ago
Branches: bpf-next, linux-next, and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=9a91353fc2af7d4f3085766dadc9105304c7e7c4
Original thread: https://lkml.kernel.org/lkml/000000000000029056057cd141cb@google.com/T/#u
This bug has a C reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+6a3c02010a025ac7b7cf@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000029056057cd141cb@google.com
--------------------------------------------------------------------------------
Title: KASAN: use-after-free Read in ip_tunnel_lookup
Last occurred: 114 days ago
Reported: 190 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=0a2ec3432ccfbd144e44c746f5b7b04f7e12c989
Original thread: https://lkml.kernel.org/lkml/00000000000075901d057f6e5a97@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4a0034797afb7e908ab4@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000075901d057f6e5a97@google.com
--------------------------------------------------------------------------------
Title: general protection fault in ip6_dst_hoplimit
Last occurred: 131 days ago
Reported: 126 days ago
Branches: net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=e310a1a3031be03dae5de35cc6dd9782232fdfea
Original thread: https://lkml.kernel.org/lkml/000000000000df93f705846f0963@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
The original thread for this bug received 1 reply, 85 days ago.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+4c869fc20129562c53fa@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000df93f705846f0963@google.com
--------------------------------------------------------------------------------
Title: INFO: rcu detected stall in gc_worker
Last occurred: 97 days ago
Reported: 182 days ago
Branches: net and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=298ba9ab760957e0ead590f868a922d7d74bf59a
Original thread: https://lkml.kernel.org/lkml/000000000000ada99c058010d943@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+655174276c47216abab5@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000ada99c058010d943@google.com
--------------------------------------------------------------------------------
Title: WARNING in fib6_add (2)
Last occurred: 94 days ago
Reported: 235 days ago
Branches: bpf and net-next
Dashboard link: https://syzkaller.appspot.com/bug?id=757f2e8c1748d9d3b453b0ae3c33b1fbfe222d48
Original thread: https://lkml.kernel.org/lkml/0000000000000874de057be144e8@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+60cc5bc1296c8afcf739@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/0000000000000874de057be144e8@google.com
--------------------------------------------------------------------------------
Title: BUG: corrupted list in proto_register
Last occurred: 66 days ago
Reported: 66 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=a56a4bec03bf7561b1ec51fe929cba4018081b92
Original thread: https://lkml.kernel.org/lkml/000000000000e76a90058923eff3@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one has replied to the original thread for this bug yet.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+7bc2817ec0ed18de9079@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/000000000000e76a90058923eff3@google.com
--------------------------------------------------------------------------------
Title: possible deadlock in dev_uc_sync_multiple
Last occurred: 130 days ago
Reported: 130 days ago
Branches: net
Dashboard link: https://syzkaller.appspot.com/bug?id=43071175d7c477c40dd1044a2ce30779a40ca4c0
Original thread: https://lkml.kernel.org/lkml/00000000000019ca8105842a9660@google.com/T/#u
Unfortunately, this bug does not have a reproducer.
No one replied to the original thread for this bug.
If you fix this bug, please add the following tag to the commit:
Reported-by: syzbot+829513abde137358d25d@syzkaller.appspotmail.com
If you send any email or patch for this bug, please consider replying to the
original thread. For the git send-email command to use, or tips on how to reply
if the thread isn't in your mailbox, see the "Reply instructions" at
https://lkml.kernel.org/r/00000000000019ca8105842a9660@google.com
^ permalink raw reply
* Re: [PATCH v2 1/3] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: John Hubbard @ 2019-07-24 1:31 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: Alexander Viro, Björn Töpel, Boaz Harrosh,
Christoph Hellwig, Daniel Vetter, Dan Williams, Dave Chinner,
David Airlie, David S . Miller, Ilya Dryomov, Jan Kara,
Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, Ira Weiny
In-Reply-To: <20190724012606.25844-2-jhubbard@nvidia.com>
On 7/23/19 6:26 PM, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
...
> + * 2) This code sees the page as clean, so it calls
> + * set_page_dirty(). The page stays dirty, despite being
> + * written back, so it gets written back again in the
> + * next writeback cycle. This is harmless.
> + */
> + if (!PageDirty(page))
> + set_page_dirty_lock(page);
> + break;
ahem, the above "break" should not be there, it's an artifact, sorry about
that. Will correct on the next iteration.
thanks,
--
John Hubbard
NVIDIA
> + put_user_page(page);
> + }
> }
> EXPORT_SYMBOL(put_user_pages_dirty_lock);
>
>
^ permalink raw reply
* Re: [PATCH v3 6/7] net: Rename skb_frag_t size to bv_len
From: Matthew Wilcox @ 2019-07-24 1:30 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: davem@davemloft.net, hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <267e43638c85447a5251ce9ca33356da4a8aa3f3.camel@mellanox.com>
On Tue, Jul 23, 2019 at 10:33:59PM +0000, Saeed Mahameed wrote:
> > struct skb_frag_struct {
> > struct page *bv_page;
> > - __u32 size;
> > + unsigned int bv_len;
> > __u32 page_offset;
>
> Why do you keep page_offset name and type as is ? it will make the last
> patch much cleaner if you change it to "unsigned int bv_offset".
We don't have an accessor for page_offset, so there are about 280
occurrences of '>page_offset' in drivers/net/
Feel free to be the hero who does that cleanup.
^ permalink raw reply
* Re: [PATCH v3 4/7] net: Reorder the contents of skb_frag_t
From: Matthew Wilcox @ 2019-07-24 1:28 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: davem@davemloft.net, hch@lst.de, netdev@vger.kernel.org
In-Reply-To: <2b45504e005f88a033405225b04fba0b5dcf2e92.camel@mellanox.com>
On Tue, Jul 23, 2019 at 10:29:06PM +0000, Saeed Mahameed wrote:
> On Fri, 2019-07-12 at 06:43 -0700, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Match the layout of bio_vec.
> >
> > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > ---
> > include/linux/skbuff.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 7910935410e6..b9dc8b4f24b1 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -314,8 +314,8 @@ struct skb_frag_struct {
> > struct {
> > struct page *p;
> > } page;
> > - __u32 page_offset;
> > __u32 size;
> > + __u32 page_offset;
> > };
> >
>
> Why do you need this patch? this struct is going to be removed
> downstream eventually ..
If there's a performance regression, this is the perfect patch to include
as part of the bisection. You'd think that this change could have no
effect, but I've seen weirder things.
^ permalink raw reply
* [PATCH v2 3/3] net/xdp: convert put_page() to put_user_page*()
From: john.hubbard @ 2019-07-24 1:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Alexander Viro, Björn Töpel, Boaz Harrosh,
Christoph Hellwig, Daniel Vetter, Dan Williams, Dave Chinner,
David Airlie, David S . Miller, Ilya Dryomov, Jan Kara,
Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190724012606.25844-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Cc: Björn Töpel <bjorn.topel@intel.com>
Cc: Magnus Karlsson <magnus.karlsson@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
net/xdp/xdp_umem.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 83de74ca729a..17c4b3d3dc34 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -166,14 +166,7 @@ void xdp_umem_clear_dev(struct xdp_umem *umem)
static void xdp_umem_unpin_pages(struct xdp_umem *umem)
{
- unsigned int i;
-
- for (i = 0; i < umem->npgs; i++) {
- struct page *page = umem->pgs[i];
-
- set_page_dirty_lock(page);
- put_page(page);
- }
+ put_user_pages_dirty_lock(umem->pgs, umem->npgs, true);
kfree(umem->pgs);
umem->pgs = NULL;
--
2.22.0
^ permalink raw reply related
* [PATCH v2 2/3] drivers/gpu/drm/via: convert put_page() to put_user_page*()
From: john.hubbard @ 2019-07-24 1:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Alexander Viro, Björn Töpel, Boaz Harrosh,
Christoph Hellwig, Daniel Vetter, Dan Williams, Dave Chinner,
David Airlie, David S . Miller, Ilya Dryomov, Jan Kara,
Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190724012606.25844-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
For pages that were retained via get_user_pages*(), release those pages
via the new put_user_page*() routines, instead of via put_page() or
release_pages().
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
Also reverse the order of a comparison, in order to placate
checkpatch.pl.
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/gpu/drm/via/via_dmablit.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/via/via_dmablit.c b/drivers/gpu/drm/via/via_dmablit.c
index 062067438f1d..b5b5bf0ba65e 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -171,7 +171,6 @@ via_map_blit_for_device(struct pci_dev *pdev,
static void
via_free_sg_info(struct pci_dev *pdev, drm_via_sg_info_t *vsg)
{
- struct page *page;
int i;
switch (vsg->state) {
@@ -186,13 +185,8 @@ via_free_sg_info(struct pci_dev *pdev, drm_via_sg_info_t *vsg)
kfree(vsg->desc_pages);
/* fall through */
case dr_via_pages_locked:
- for (i = 0; i < vsg->num_pages; ++i) {
- if (NULL != (page = vsg->pages[i])) {
- if (!PageReserved(page) && (DMA_FROM_DEVICE == vsg->direction))
- SetPageDirty(page);
- put_page(page);
- }
- }
+ put_user_pages_dirty_lock(vsg->pages, vsg->num_pages,
+ (vsg->direction == DMA_FROM_DEVICE));
/* fall through */
case dr_via_pages_alloc:
vfree(vsg->pages);
--
2.22.0
^ permalink raw reply related
* [PATCH v2 1/3] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: john.hubbard @ 2019-07-24 1:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Alexander Viro, Björn Töpel, Boaz Harrosh,
Christoph Hellwig, Daniel Vetter, Dan Williams, Dave Chinner,
David Airlie, David S . Miller, Ilya Dryomov, Jan Kara,
Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard,
Ira Weiny
In-Reply-To: <20190724012606.25844-1-jhubbard@nvidia.com>
From: John Hubbard <jhubbard@nvidia.com>
Provide more capable variation of put_user_pages_dirty_lock(),
and delete put_user_pages_dirty(). This is based on the
following:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*() variant to call.
2. Christoph Hellwig's observation that set_page_dirty_lock()
is usually correct, and set_page_dirty() is usually a
bug, or at least questionable, within a put_user_page*()
calling chain.
This leads to the following API choices:
* put_user_pages_dirty_lock(page, npages, make_dirty)
* There is no put_user_pages_dirty(). You have to
hand code that, in the rare case that it's
required.
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
---
drivers/infiniband/core/umem.c | 5 +-
drivers/infiniband/hw/hfi1/user_pages.c | 5 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 5 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 5 +-
drivers/infiniband/sw/siw/siw_mem.c | 8 +-
include/linux/mm.h | 5 +-
mm/gup.c | 116 +++++++++------------
7 files changed, 59 insertions(+), 90 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 08da840ed7ee..965cf9dea71a 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -54,10 +54,7 @@ static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int d
for_each_sg_page(umem->sg_head.sgl, &sg_iter, umem->sg_nents, 0) {
page = sg_page_iter_page(&sg_iter);
- if (umem->writable && dirty)
- put_user_pages_dirty_lock(&page, 1);
- else
- put_user_page(page);
+ put_user_pages_dirty_lock(&page, 1, umem->writable && dirty);
}
sg_free_table(&umem->sg_head);
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c b/drivers/infiniband/hw/hfi1/user_pages.c
index b89a9b9aef7a..469acb961fbd 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -118,10 +118,7 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned long vaddr, size_t np
void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
size_t npages, bool dirty)
{
- if (dirty)
- put_user_pages_dirty_lock(p, npages);
- else
- put_user_pages(p, npages);
+ put_user_pages_dirty_lock(p, npages, dirty);
if (mm) { /* during close after signal, mm can be NULL */
atomic64_sub(npages, &mm->pinned_vm);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c b/drivers/infiniband/hw/qib/qib_user_pages.c
index bfbfbb7e0ff4..6bf764e41891 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,10 +40,7 @@
static void __qib_release_user_pages(struct page **p, size_t num_pages,
int dirty)
{
- if (dirty)
- put_user_pages_dirty_lock(p, num_pages);
- else
- put_user_pages(p, num_pages);
+ put_user_pages_dirty_lock(p, num_pages, dirty);
}
/**
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 0b0237d41613..62e6ffa9ad78 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -75,10 +75,7 @@ static void usnic_uiom_put_pages(struct list_head *chunk_list, int dirty)
for_each_sg(chunk->page_list, sg, chunk->nents, i) {
page = sg_page(sg);
pa = sg_phys(sg);
- if (dirty)
- put_user_pages_dirty_lock(&page, 1);
- else
- put_user_page(page);
+ put_user_pages_dirty_lock(&page, 1, dirty);
usnic_dbg("pa: %pa\n", &pa);
}
kfree(chunk);
diff --git a/drivers/infiniband/sw/siw/siw_mem.c b/drivers/infiniband/sw/siw/siw_mem.c
index 67171c82b0c4..358d440efa11 100644
--- a/drivers/infiniband/sw/siw/siw_mem.c
+++ b/drivers/infiniband/sw/siw/siw_mem.c
@@ -65,13 +65,7 @@ static void siw_free_plist(struct siw_page_chunk *chunk, int num_pages,
{
struct page **p = chunk->plist;
- while (num_pages--) {
- if (!PageDirty(*p) && dirty)
- put_user_pages_dirty_lock(p, 1);
- else
- put_user_page(*p);
- p++;
- }
+ put_user_pages_dirty_lock(chunk->plist, num_pages, dirty);
}
void siw_umem_release(struct siw_umem *umem, bool dirty)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0334ca97c584..9759b6a24420 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1057,8 +1057,9 @@ static inline void put_user_page(struct page *page)
put_page(page);
}
-void put_user_pages_dirty(struct page **pages, unsigned long npages);
-void put_user_pages_dirty_lock(struct page **pages, unsigned long npages);
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages,
+ bool make_dirty);
+
void put_user_pages(struct page **pages, unsigned long npages);
#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
diff --git a/mm/gup.c b/mm/gup.c
index 98f13ab37bac..d14bd362ec28 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -29,85 +29,71 @@ struct follow_page_context {
unsigned int page_mask;
};
-typedef int (*set_dirty_func_t)(struct page *page);
-
-static void __put_user_pages_dirty(struct page **pages,
- unsigned long npages,
- set_dirty_func_t sdf)
-{
- unsigned long index;
-
- for (index = 0; index < npages; index++) {
- struct page *page = compound_head(pages[index]);
-
- /*
- * Checking PageDirty at this point may race with
- * clear_page_dirty_for_io(), but that's OK. Two key cases:
- *
- * 1) This code sees the page as already dirty, so it skips
- * the call to sdf(). That could happen because
- * clear_page_dirty_for_io() called page_mkclean(),
- * followed by set_page_dirty(). However, now the page is
- * going to get written back, which meets the original
- * intention of setting it dirty, so all is well:
- * clear_page_dirty_for_io() goes on to call
- * TestClearPageDirty(), and write the page back.
- *
- * 2) This code sees the page as clean, so it calls sdf().
- * The page stays dirty, despite being written back, so it
- * gets written back again in the next writeback cycle.
- * This is harmless.
- */
- if (!PageDirty(page))
- sdf(page);
-
- put_user_page(page);
- }
-}
-
/**
- * put_user_pages_dirty() - release and dirty an array of gup-pinned pages
- * @pages: array of pages to be marked dirty and released.
+ * put_user_pages_dirty_lock() - release and optionally dirty gup-pinned pages
+ * @pages: array of pages to be maybe marked dirty, and definitely released.
* @npages: number of pages in the @pages array.
+ * @make_dirty: whether to mark the pages dirty
*
* "gup-pinned page" refers to a page that has had one of the get_user_pages()
* variants called on that page.
*
* For each page in the @pages array, make that page (or its head page, if a
- * compound page) dirty, if it was previously listed as clean. Then, release
- * the page using put_user_page().
+ * compound page) dirty, if @make_dirty is true, and if the page was previously
+ * listed as clean. In any case, releases all pages using put_user_page(),
+ * possibly via put_user_pages(), for the non-dirty case.
*
* Please see the put_user_page() documentation for details.
*
- * set_page_dirty(), which does not lock the page, is used here.
- * Therefore, it is the caller's responsibility to ensure that this is
- * safe. If not, then put_user_pages_dirty_lock() should be called instead.
+ * set_page_dirty_lock() is used internally. If instead, set_page_dirty() is
+ * required, then the caller should a) verify that this is really correct,
+ * because _lock() is usually required, and b) hand code it:
+ * set_page_dirty_lock(), put_user_page().
*
*/
-void put_user_pages_dirty(struct page **pages, unsigned long npages)
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages,
+ bool make_dirty)
{
- __put_user_pages_dirty(pages, npages, set_page_dirty);
-}
-EXPORT_SYMBOL(put_user_pages_dirty);
+ unsigned long index;
-/**
- * put_user_pages_dirty_lock() - release and dirty an array of gup-pinned pages
- * @pages: array of pages to be marked dirty and released.
- * @npages: number of pages in the @pages array.
- *
- * For each page in the @pages array, make that page (or its head page, if a
- * compound page) dirty, if it was previously listed as clean. Then, release
- * the page using put_user_page().
- *
- * Please see the put_user_page() documentation for details.
- *
- * This is just like put_user_pages_dirty(), except that it invokes
- * set_page_dirty_lock(), instead of set_page_dirty().
- *
- */
-void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
-{
- __put_user_pages_dirty(pages, npages, set_page_dirty_lock);
+ /*
+ * TODO: this can be optimized for huge pages: if a series of pages is
+ * physically contiguous and part of the same compound page, then a
+ * single operation to the head page should suffice.
+ */
+
+ if (!make_dirty) {
+ put_user_pages(pages, npages);
+ return;
+ }
+
+ for (index = 0; index < npages; index++) {
+ struct page *page = compound_head(pages[index]);
+ /*
+ * Checking PageDirty at this point may race with
+ * clear_page_dirty_for_io(), but that's OK. Two key
+ * cases:
+ *
+ * 1) This code sees the page as already dirty, so it
+ * skips the call to set_page_dirty(). That could happen
+ * because clear_page_dirty_for_io() called
+ * page_mkclean(), followed by set_page_dirty().
+ * However, now the page is going to get written back,
+ * which meets the original intention of setting it
+ * dirty, so all is well: clear_page_dirty_for_io() goes
+ * on to call TestClearPageDirty(), and write the page
+ * back.
+ *
+ * 2) This code sees the page as clean, so it calls
+ * set_page_dirty(). The page stays dirty, despite being
+ * written back, so it gets written back again in the
+ * next writeback cycle. This is harmless.
+ */
+ if (!PageDirty(page))
+ set_page_dirty_lock(page);
+ break;
+ put_user_page(page);
+ }
}
EXPORT_SYMBOL(put_user_pages_dirty_lock);
--
2.22.0
^ permalink raw reply related
* [PATCH v2 0/3] mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
From: john.hubbard @ 2019-07-24 1:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Alexander Viro, Björn Töpel, Boaz Harrosh,
Christoph Hellwig, Daniel Vetter, Dan Williams, Dave Chinner,
David Airlie, David S . Miller, Ilya Dryomov, Jan Kara,
Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
From: John Hubbard <jhubbard@nvidia.com>
Changes since v1:
* Instead of providing __put_user_pages(), add an argument to
put_user_pages_dirty_lock(), and delete put_user_pages_dirty().
This is based on the following points:
1. Lots of call sites become simpler if a bool is passed
into put_user_page*(), instead of making the call site
choose which put_user_page*() variant to call.
2. Christoph Hellwig's observation that set_page_dirty_lock()
is usually correct, and set_page_dirty() is usually a
bug, or at least questionable, within a put_user_page*()
calling chain.
* Added the Infiniband driver back to the patch series, because it is
a caller of put_user_pages_dirty_lock().
Unchanged parts from the v1 cover letter (except for the diffstat):
Notes about the remaining patches to come:
There are about 50+ patches in my tree [2], and I'll be sending out the
remaining ones in a few more groups:
* The block/bio related changes (Jerome mostly wrote those, but I've
had to move stuff around extensively, and add a little code)
* mm/ changes
* other subsystem patches
* an RFC that shows the current state of the tracking patch set. That
can only be applied after all call sites are converted, but it's
good to get an early look at it.
This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
("mm: introduce put_user_page*(), placeholder versions").
John Hubbard (3):
mm/gup: add make_dirty arg to put_user_pages_dirty_lock()
drivers/gpu/drm/via: convert put_page() to put_user_page*()
net/xdp: convert put_page() to put_user_page*()
drivers/gpu/drm/via/via_dmablit.c | 10 +-
drivers/infiniband/core/umem.c | 5 +-
drivers/infiniband/hw/hfi1/user_pages.c | 5 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 5 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 5 +-
drivers/infiniband/sw/siw/siw_mem.c | 8 +-
include/linux/mm.h | 5 +-
mm/gup.c | 116 +++++++++------------
net/xdp/xdp_umem.c | 9 +-
9 files changed, 62 insertions(+), 106 deletions(-)
--
2.22.0
^ permalink raw reply
* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: Shannon Nelson @ 2019-07-24 0:25 UTC (permalink / raw)
To: Saeed Mahameed, netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <a402ea5d2badda79cf205e790d3eb967f2cb7084.camel@mellanox.com>
On 7/23/19 4:47 PM, Saeed Mahameed wrote:
> On Mon, 2019-07-22 at 14:40 -0700, Shannon Nelson wrote:
>> The ionic device has a small set of PCI registers, including a
>> device control and data space, and a large set of message
>> commands.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> ---
>> drivers/net/ethernet/pensando/ionic/Makefile | 2 +-
>> drivers/net/ethernet/pensando/ionic/ionic.h | 20 +
>> .../net/ethernet/pensando/ionic/ionic_bus.h | 1 +
>> .../ethernet/pensando/ionic/ionic_bus_pci.c | 140 +-
>> .../ethernet/pensando/ionic/ionic_debugfs.c | 67 +
>> .../ethernet/pensando/ionic/ionic_debugfs.h | 28 +
>> .../net/ethernet/pensando/ionic/ionic_dev.c | 132 +
>> .../net/ethernet/pensando/ionic/ionic_dev.h | 144 +
>> .../net/ethernet/pensando/ionic/ionic_if.h | 2552
>> +++++++++++++++++
>> .../net/ethernet/pensando/ionic/ionic_main.c | 296 ++
>> .../net/ethernet/pensando/ionic/ionic_regs.h | 133 +
>> 11 files changed, 3512 insertions(+), 3 deletions(-)
>> create mode 100644
>> drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
>> create mode 100644
>> drivers/net/ethernet/pensando/ionic/ionic_debugfs.h
>> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.c
>> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.h
>> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_if.h
>> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_regs.h
>>
> [...]
>
>> static void ionic_remove(struct pci_dev *pdev)
>> {
>> struct ionic *ionic = pci_get_drvdata(pdev);
>>
>> - devm_kfree(&pdev->dev, ionic);
>> + if (ionic) {
> nit, in case you are doing another re-spin maybe early return here:
> if (!ionic)
> return;
> //do stuff
Sure
>
>> + ionic_reset(ionic);
>> + ionic_dev_teardown(ionic);
>> + ionic_unmap_bars(ionic);
>> + pci_release_regions(pdev);
>> + pci_clear_master(pdev);
>> + pci_disable_sriov(pdev);
>> + pci_disable_device(pdev);
>> + ionic_debugfs_del_dev(ionic);
>> + mutex_destroy(&ionic->dev_cmd_lock);
>> +
>> + devm_kfree(&pdev->dev, ionic);
>> + }
>> }
>>
> [...]
>
>>
>> +
>> +/* Devcmd Interface */
>> +u8 ionic_dev_cmd_status(struct ionic_dev *idev)
>> +{
>> + return ioread8(&idev->dev_cmd_regs->comp.comp.status);
>> +}
>> +
>> +bool ionic_dev_cmd_done(struct ionic_dev *idev)
>> +{
>> + return ioread32(&idev->dev_cmd_regs->done) & DEV_CMD_DONE;
>> +}
>> +
>> +void ionic_dev_cmd_comp(struct ionic_dev *idev, union dev_cmd_comp
>> *comp)
>> +{
>> + memcpy_fromio(comp, &idev->dev_cmd_regs->comp, sizeof(*comp));
>> +}
>> +
>> +void ionic_dev_cmd_go(struct ionic_dev *idev, union dev_cmd *cmd)
>> +{
>> + memcpy_toio(&idev->dev_cmd_regs->cmd, cmd, sizeof(*cmd));
>> + iowrite32(0, &idev->dev_cmd_regs->done);
>> + iowrite32(1, &idev->dev_cmd_regs->doorbell);
>> +}
>> +
>> +/* Device commands */
>> +void ionic_dev_cmd_identify(struct ionic_dev *idev, u8 ver)
>> +{
>> + union dev_cmd cmd = {
>> + .identify.opcode = CMD_OPCODE_IDENTIFY,
>> + .identify.ver = ver,
>> + };
>> +
>> + ionic_dev_cmd_go(idev, &cmd);
>> +}
>> +
>> +void ionic_dev_cmd_init(struct ionic_dev *idev)
>> +{
>> + union dev_cmd cmd = {
>> + .init.opcode = CMD_OPCODE_INIT,
>> + .init.type = 0,
>> + };
>> +
>> + ionic_dev_cmd_go(idev, &cmd);
>> +}
>> +
>> +void ionic_dev_cmd_reset(struct ionic_dev *idev)
>> +{
>> + union dev_cmd cmd = {
>> + .reset.opcode = CMD_OPCODE_RESET,
>> + };
>> +
>> + ionic_dev_cmd_go(idev, &cmd);
>> +}
> [...]
>
>> +int ionic_dev_cmd_wait(struct ionic *ionic, unsigned long
>> max_seconds)
>> +{
>> + struct ionic_dev *idev = &ionic->idev;
>> + unsigned long max_wait, start_time, duration;
>> + int opcode;
>> + int done;
>> + int err;
>> +
>> + WARN_ON(in_interrupt());
>> +
>> + /* Wait for dev cmd to complete, retrying if we get EAGAIN,
>> + * but don't wait any longer than max_seconds.
>> + */
>> + max_wait = jiffies + (max_seconds * HZ);
>> +try_again:
>> + start_time = jiffies;
>> + do {
>> + done = ionic_dev_cmd_done(idev);
> READ_ONCE required here ? to read from coherent memory modified
> by the device and read by the driver ?
Good idea, I'll add that in.
>
>> + if (done)
>> + break;
>> + msleep(20);
>> + } while (!done && time_before(jiffies, max_wait));
> so your command interface is busy polling based, i am relating here to
> Dave's comment regarding async command completion, is it possible to
> have interrupt (MSIX?) based command completion in this hw ?
As I wrote elsewhere, this is only the low-level dev_cmd that does
polling; the adminq does a wait that is completed by an MSI-x handler.
sln
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: Shannon Nelson @ 2019-07-24 0:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20190723.160628.20093803405793483.davem@davemloft.net>
On 7/23/19 4:06 PM, David Miller wrote:
> From: Shannon Nelson <snelson@pensando.io>
> Date: Tue, 23 Jul 2019 15:50:43 -0700
>
>> On 7/23/19 2:33 PM, David Miller wrote:
>>> Generally interface address changes are expected to be synchronous.
>> Yeah, this bothers me a bit as well, but the address change calls come
>> in under spin_lock_bh(), and I'm reluctant to make an AdminQ call
>> under the _bh that could block for a few seconds.
> So it's not about memory allocation but rather the fact that the device
> might take a while to complete?
Memory allocation may or may not be involved, but yes, mainly we're
doing another spin_lock on a firmware command that waits for an ACK or
ERROR answer, and in extreme cases could possibly timeout on a dead
firmware. I know that i40e and ice do much the same thing, and I
believe mlx5 as well, for the same reasons. I suspect others do as well.
> Can you start the operation synchronously yet complete it async?
This could be possible, but would likely require a bunch more messy
logic to track async AdminQ requests, that otherwise is unnecessary.
sln
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: Shannon Nelson @ 2019-07-24 0:19 UTC (permalink / raw)
To: Saeed Mahameed, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <ba8349adaea24d955be3e98abf9ade59b0a9f580.camel@mellanox.com>
On 7/23/19 4:54 PM, Saeed Mahameed wrote:
> On Tue, 2019-07-23 at 16:06 -0700, David Miller wrote:
>> From: Shannon Nelson <snelson@pensando.io>
>> Date: Tue, 23 Jul 2019 15:50:43 -0700
>>
>>> On 7/23/19 2:33 PM, David Miller wrote:
>>>> Generally interface address changes are expected to be
>>>> synchronous.
>>> Yeah, this bothers me a bit as well, but the address change calls
>>> come
>>> in under spin_lock_bh(), and I'm reluctant to make an AdminQ call
>>> under the _bh that could block for a few seconds.
>> So it's not about memory allocation but rather the fact that the
>> device
>> might take a while to complete?
>>
>> Can you start the operation synchronously yet complete it async?
> The driver is doing busy polling on command completion, doing only busy
> polling on completion status in the deferred work will not be much
> different than what they have now..
>
> async completion will only make since if the hardware supports
> interrupt based (MSI-x) command completion.
Actually, there are two different command paths - one for basic
low-level setup, and one for more advanced work:
- dev_cmd does indeed do polling on PCI register space, and we try to
keep this to a minimum
- adminq does a wait_for_completion_timeout() which gets completed in an
MSI-x handler
The rx_mode related work goes through adminq.
Yes, it could be made async, but would the extra logic needed buy us
that much? We already know this model works in other drivers. We
wouldn't get the address into the hardware any quicker, and we still
wouldn't get any errors from the request back to the original call.
sln
^ permalink raw reply
* Re: [bpf-next 3/6] bpf: add bpf_tcp_gen_syncookie helper
From: Petar Penkov @ 2019-07-24 0:15 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Petar Penkov, Networking, bpf, David S . Miller,
Alexei Starovoitov, Daniel Borkmann, Eric Dumazet, lmb,
Stanislav Fomichev
In-Reply-To: <8736ix3p8h.fsf@toke.dk>
On Tue, Jul 23, 2019 at 5:33 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Petar Penkov <ppenkov.kernel@gmail.com> writes:
>
> > From: Petar Penkov <ppenkov@google.com>
> >
> > This helper function allows BPF programs to try to generate SYN
> > cookies, given a reference to a listener socket. The function works
> > from XDP and with an skb context since bpf_skc_lookup_tcp can lookup a
> > socket in both cases.
> >
> > Signed-off-by: Petar Penkov <ppenkov@google.com>
> > Suggested-by: Eric Dumazet <edumazet@google.com>
> > ---
> > include/uapi/linux/bpf.h | 30 ++++++++++++++++-
> > net/core/filter.c | 73 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 102 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > index 6f68438aa4ed..20baee7b2219 100644
> > --- a/include/uapi/linux/bpf.h
> > +++ b/include/uapi/linux/bpf.h
> > @@ -2713,6 +2713,33 @@ union bpf_attr {
> > * **-EPERM** if no permission to send the *sig*.
> > *
> > * **-EAGAIN** if bpf program can try again.
> > + *
> > + * s64 bpf_tcp_gen_syncookie(struct bpf_sock *sk, void *iph, u32 iph_len, struct tcphdr *th, u32 th_len)
> > + * Description
> > + * Try to issue a SYN cookie for the packet with corresponding
> > + * IP/TCP headers, *iph* and *th*, on the listening socket in *sk*.
> > + *
> > + * *iph* points to the start of the IPv4 or IPv6 header, while
> > + * *iph_len* contains **sizeof**\ (**struct iphdr**) or
> > + * **sizeof**\ (**struct ip6hdr**).
> > + *
> > + * *th* points to the start of the TCP header, while *th_len*
> > + * contains the length of the TCP header.
> > + *
> > + * Return
> > + * On success, lower 32 bits hold the generated SYN cookie in
> > + * followed by 16 bits which hold the MSS value for that cookie,
> > + * and the top 16 bits are unused.
> > + *
> > + * On failure, the returned value is one of the following:
> > + *
> > + * **-EINVAL** SYN cookie cannot be issued due to error
> > + *
> > + * **-ENOENT** SYN cookie should not be issued (no SYN flood)
> > + *
> > + * **-ENOTSUPP** kernel configuration does not enable SYN
> > cookies
>
> nit: This should be EOPNOTSUPP - the other one is for NFS...
Will correct this in a v2, thanks for catching that!
>
> > + *
> > + * **-EPROTONOSUPPORT** IP packet version is not 4 or 6
> > */
> > #define __BPF_FUNC_MAPPER(FN) \
> > FN(unspec), \
> > @@ -2824,7 +2851,8 @@ union bpf_attr {
> > FN(strtoul), \
> > FN(sk_storage_get), \
> > FN(sk_storage_delete), \
> > - FN(send_signal),
> > + FN(send_signal), \
> > + FN(tcp_gen_syncookie),
> >
> > /* integer value in 'imm' field of BPF_CALL instruction selects which helper
> > * function eBPF program intends to call
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 47f6386fb17a..92114271eff6 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -5850,6 +5850,75 @@ static const struct bpf_func_proto bpf_tcp_check_syncookie_proto = {
> > .arg5_type = ARG_CONST_SIZE,
> > };
> >
> > +BPF_CALL_5(bpf_tcp_gen_syncookie, struct sock *, sk, void *, iph, u32, iph_len,
> > + struct tcphdr *, th, u32, th_len)
> > +{
> > +#ifdef CONFIG_SYN_COOKIES
> > + u32 cookie;
> > + u16 mss;
> > +
> > + if (unlikely(th_len < sizeof(*th) || th_len != th->doff * 4))
> > + return -EINVAL;
> > +
> > + if (sk->sk_protocol != IPPROTO_TCP || sk->sk_state != TCP_LISTEN)
> > + return -EINVAL;
> > +
> > + if (!sock_net(sk)->ipv4.sysctl_tcp_syncookies)
> > + return -ENOENT;
> > +
> > + if (!th->syn || th->ack || th->fin || th->rst)
> > + return -EINVAL;
> > +
> > + if (unlikely(iph_len < sizeof(struct iphdr)))
> > + return -EINVAL;
> > +
> > + /* Both struct iphdr and struct ipv6hdr have the version field at the
> > + * same offset so we can cast to the shorter header (struct iphdr).
> > + */
> > + switch (((struct iphdr *)iph)->version) {
> > + case 4:
> > + if (sk->sk_family == AF_INET6 && sk->sk_ipv6only)
> > + return -EINVAL;
> > +
> > + mss = tcp_v4_get_syncookie(sk, iph, th, &cookie);
> > + break;
> > +
> > +#if IS_BUILTIN(CONFIG_IPV6)
> > + case 6:
> > + if (unlikely(iph_len < sizeof(struct ipv6hdr)))
> > + return -EINVAL;
> > +
> > + if (sk->sk_family != AF_INET6)
> > + return -EINVAL;
> > +
> > + mss = tcp_v6_get_syncookie(sk, iph, th, &cookie);
> > + break;
> > +#endif /* CONFIG_IPV6 */
> > +
> > + default:
> > + return -EPROTONOSUPPORT;
> > + }
> > + if (mss <= 0)
> > + return -ENOENT;
> > +
> > + return cookie | ((u64)mss << 32);
> > +#else
> > + return -ENOTSUPP;
>
> See above
>
> > +#endif /* CONFIG_SYN_COOKIES */
> > +}
> > +
> > +static const struct bpf_func_proto bpf_tcp_gen_syncookie_proto = {
> > + .func = bpf_tcp_gen_syncookie,
> > + .gpl_only = true, /* __cookie_v*_init_sequence() is GPL */
> > + .pkt_access = true,
> > + .ret_type = RET_INTEGER,
> > + .arg1_type = ARG_PTR_TO_SOCK_COMMON,
> > + .arg2_type = ARG_PTR_TO_MEM,
> > + .arg3_type = ARG_CONST_SIZE,
> > + .arg4_type = ARG_PTR_TO_MEM,
> > + .arg5_type = ARG_CONST_SIZE,
> > +};
> > +
> > #endif /* CONFIG_INET */
> >
> > bool bpf_helper_changes_pkt_data(void *func)
> > @@ -6135,6 +6204,8 @@ tc_cls_act_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > return &bpf_tcp_check_syncookie_proto;
> > case BPF_FUNC_skb_ecn_set_ce:
> > return &bpf_skb_ecn_set_ce_proto;
> > + case BPF_FUNC_tcp_gen_syncookie:
> > + return &bpf_tcp_gen_syncookie_proto;
> > #endif
> > default:
> > return bpf_base_func_proto(func_id);
> > @@ -6174,6 +6245,8 @@ xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
> > return &bpf_xdp_skc_lookup_tcp_proto;
> > case BPF_FUNC_tcp_check_syncookie:
> > return &bpf_tcp_check_syncookie_proto;
> > + case BPF_FUNC_tcp_gen_syncookie:
> > + return &bpf_tcp_gen_syncookie_proto;
> > #endif
> > default:
> > return bpf_base_func_proto(func_id);
> > --
> > 2.22.0.657.g960e92d24f-goog
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: Shannon Nelson @ 2019-07-24 0:07 UTC (permalink / raw)
To: Saeed Mahameed, netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1ce8b25ccb5632a33be6d18714aadfdabd4105ce.camel@mellanox.com>
On 7/23/19 4:20 PM, Saeed Mahameed wrote:
> On Mon, 2019-07-22 at 14:40 -0700, Shannon Nelson wrote:
>>
>> @@ -607,6 +947,8 @@ static void ionic_lif_free(struct lif *lif)
>> ionic_qcqs_free(lif);
>> ionic_lif_reset(lif);
>>
> I don't think you want deferred.work running while reset is executing..
> cancel_work_sync should happen as early as you close the netdevice.
Given the current implementation, it doesn't actually hurt anything, but
yes it makes sense to move it up in the sequence.
> I assume ionic_lif_reset will flush all configurations and you don't
> need to cleanup anything manually? or any data structure stored in
> driver ?
Most of the driver data structure cleaning has happened in
ionic_lif_deinit() before getting here.
sln
^ permalink raw reply
* [PATCH bpf-next v10 2/2] selftests/bpf: Add selftests for bpf_perf_event_output
From: Allan Zhang @ 2019-07-24 0:07 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel, andrii.nakryiko; +Cc: ast, Allan Zhang
In-Reply-To: <20190724000725.15634-1-allanzhang@google.com>
Software event output is only enabled by a few prog types.
This test is to ensure that all supported types are enabled for
bpf_perf_event_output successfully.
Signed-off-by: Allan Zhang <allanzhang@google.com>
Acked-by: Song Liu <songliubraving@fb.com>
---
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
2 files changed, 105 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index 84135d5f4b35..44e2d640b088 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -50,7 +50,7 @@
#define MAX_INSNS BPF_MAXINSNS
#define MAX_TEST_INSNS 1000000
#define MAX_FIXUPS 8
-#define MAX_NR_MAPS 18
+#define MAX_NR_MAPS 19
#define MAX_TEST_RUNS 8
#define POINTER_VALUE 0xcafe4all
#define TEST_DATA_LEN 64
@@ -84,6 +84,7 @@ struct bpf_test {
int fixup_map_array_wo[MAX_FIXUPS];
int fixup_map_array_small[MAX_FIXUPS];
int fixup_sk_storage_map[MAX_FIXUPS];
+ int fixup_map_event_output[MAX_FIXUPS];
const char *errstr;
const char *errstr_unpriv;
uint32_t insn_processed;
@@ -632,6 +633,7 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
int *fixup_map_array_wo = test->fixup_map_array_wo;
int *fixup_map_array_small = test->fixup_map_array_small;
int *fixup_sk_storage_map = test->fixup_sk_storage_map;
+ int *fixup_map_event_output = test->fixup_map_event_output;
if (test->fill_helper) {
test->fill_insns = calloc(MAX_TEST_INSNS, sizeof(struct bpf_insn));
@@ -793,6 +795,14 @@ static void do_test_fixup(struct bpf_test *test, enum bpf_prog_type prog_type,
fixup_sk_storage_map++;
} while (*fixup_sk_storage_map);
}
+ if (*fixup_map_event_output) {
+ map_fds[18] = __create_map(BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+ sizeof(int), sizeof(int), 1, 0);
+ do {
+ prog[*fixup_map_event_output].imm = map_fds[18];
+ fixup_map_event_output++;
+ } while (*fixup_map_event_output);
+ }
}
static int set_admin(bool admin)
diff --git a/tools/testing/selftests/bpf/verifier/event_output.c b/tools/testing/selftests/bpf/verifier/event_output.c
new file mode 100644
index 000000000000..130553e19eca
--- /dev/null
+++ b/tools/testing/selftests/bpf/verifier/event_output.c
@@ -0,0 +1,94 @@
+/* instructions used to output a skb based software event, produced
+ * from code snippet:
+ * struct TMP {
+ * uint64_t tmp;
+ * } tt;
+ * tt.tmp = 5;
+ * bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
+ * &tt, sizeof(tt));
+ * return 1;
+ *
+ * the bpf assembly from llvm is:
+ * 0: b7 02 00 00 05 00 00 00 r2 = 5
+ * 1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
+ * 2: bf a4 00 00 00 00 00 00 r4 = r10
+ * 3: 07 04 00 00 f8 ff ff ff r4 += -8
+ * 4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
+ * 6: b7 03 00 00 00 00 00 00 r3 = 0
+ * 7: b7 05 00 00 08 00 00 00 r5 = 8
+ * 8: 85 00 00 00 19 00 00 00 call 25
+ * 9: b7 00 00 00 01 00 00 00 r0 = 1
+ * 10: 95 00 00 00 00 00 00 00 exit
+ *
+ * The reason I put the code here instead of fill_helpers is that map fixup
+ * is against the insns, instead of filled prog.
+ */
+
+#define __PERF_EVENT_INSNS__ \
+ BPF_MOV64_IMM(BPF_REG_2, 5), \
+ BPF_STX_MEM(BPF_DW, BPF_REG_10, BPF_REG_2, -8), \
+ BPF_MOV64_REG(BPF_REG_4, BPF_REG_10), \
+ BPF_ALU64_IMM(BPF_ADD, BPF_REG_4, -8), \
+ BPF_LD_MAP_FD(BPF_REG_2, 0), \
+ BPF_MOV64_IMM(BPF_REG_3, 0), \
+ BPF_MOV64_IMM(BPF_REG_5, 8), \
+ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, \
+ BPF_FUNC_perf_event_output), \
+ BPF_MOV64_IMM(BPF_REG_0, 1), \
+ BPF_EXIT_INSN(),
+{
+ "perfevent for sockops",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCK_OPS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for tc",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SCHED_CLS,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for lwt out",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_LWT_OUT,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for xdp",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_XDP,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for socket filter",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SOCKET_FILTER,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for sk_skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_SK_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
+{
+ "perfevent for cgroup skb",
+ .insns = { __PERF_EVENT_INSNS__ },
+ .prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+ .fixup_map_event_output = { 4 },
+ .result = ACCEPT,
+ .retval = 1,
+},
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* [PATCH bpf-next v10 1/2] bpf: Allow bpf_skb_event_output for a few prog types
From: Allan Zhang @ 2019-07-24 0:07 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel, andrii.nakryiko; +Cc: ast, Allan Zhang
In-Reply-To: <20190724000725.15634-1-allanzhang@google.com>
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
Added socket_filter, cg_skb, sk_skb prog types to generate sw event.
Test bpf code is generated from code snippet:
struct TMP {
uint64_t tmp;
} tt;
tt.tmp = 5;
bpf_perf_event_output(skb, &connection_tracking_event_map, 0,
&tt, sizeof(tt));
return 1;
the bpf assembly from llvm is:
0: b7 02 00 00 05 00 00 00 r2 = 5
1: 7b 2a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r2
2: bf a4 00 00 00 00 00 00 r4 = r10
3: 07 04 00 00 f8 ff ff ff r4 += -8
4: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0ll
6: b7 03 00 00 00 00 00 00 r3 = 0
7: b7 05 00 00 08 00 00 00 r5 = 8
8: 85 00 00 00 19 00 00 00 call 25
9: b7 00 00 00 01 00 00 00 r0 = 1
10: 95 00 00 00 00 00 00 00 exit
Signed-off-by: Allan Zhang <allanzhang@google.com>
Acked-by: Song Liu <songliubraving@fb.com>
---
net/core/filter.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 4e2a79b2fd77..3961437ccc50 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -5999,6 +5999,8 @@ sk_filter_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_get_socket_cookie_proto;
case BPF_FUNC_get_socket_uid:
return &bpf_get_socket_uid_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
default:
return bpf_base_func_proto(func_id);
}
@@ -6019,6 +6021,8 @@ cg_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_storage_get_proto;
case BPF_FUNC_sk_storage_delete:
return &bpf_sk_storage_delete_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_SOCK_CGROUP_DATA
case BPF_FUNC_skb_cgroup_id:
return &bpf_skb_cgroup_id_proto;
@@ -6267,6 +6271,8 @@ sk_skb_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
return &bpf_sk_redirect_map_proto;
case BPF_FUNC_sk_redirect_hash:
return &bpf_sk_redirect_hash_proto;
+ case BPF_FUNC_perf_event_output:
+ return &bpf_skb_event_output_proto;
#ifdef CONFIG_INET
case BPF_FUNC_sk_lookup_tcp:
return &bpf_sk_lookup_tcp_proto;
--
2.22.0.709.g102302147b-goog
^ permalink raw reply related
* [PATCH bpf-next v10 0/2] bpf: Allow bpf_skb_event_output for more prog types
From: Allan Zhang @ 2019-07-24 0:07 UTC (permalink / raw)
To: netdev, bpf, songliubraving, daniel, andrii.nakryiko; +Cc: ast, Allan Zhang
Software event output is only enabled by a few prog types right now (TC,
LWT out, XDP, sockops). Many other skb based prog types need
bpf_skb_event_output to produce software event.
More prog types are enabled to access bpf_skb_event_output in this
patch.
v10 changes:
Resubmit (v9 is submitted when bpf branch is closed).
v9 changes:
add "Acked-by" field.
v8 changes:
No actual change, just cc to netdev@vger.kernel.org and
bpf@vger.kernel.org.
v7 patches are acked by Song Liu.
v7 changes:
Reformat from hints by scripts/checkpatch.pl, including Song's comment
on signed-off-by name to captical case in cover letter.
3 of hints are ignored:
1. new file mode.
2. SPDX-License-Identifier for event_output.c since all files under
this dir have no such line.
3. "Macros ... enclosed in parentheses" for macro in event_output.c
due to code's nature.
Change patch 02 subject "bpf:..." to "selftests/bpf:..."
v6 changes:
Fix Signed-off-by, fix fixup map creation.
v5 changes:
Fix typos, reformat comments in event_output.c, move revision history to
cover letter.
v4 changes:
Reformating log message.
v3 changes:
Reformating log message.
v2 changes:
Reformating log message.
Allan Zhang (2):
bpf: Allow bpf_skb_event_output for a few prog types
selftests/bpf: Add selftests for bpf_perf_event_output
net/core/filter.c | 6 ++
tools/testing/selftests/bpf/test_verifier.c | 12 ++-
.../selftests/bpf/verifier/event_output.c | 94 +++++++++++++++++++
3 files changed, 111 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/verifier/event_output.c
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: Saeed Mahameed @ 2019-07-23 23:54 UTC (permalink / raw)
To: snelson@pensando.io, davem@davemloft.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190723.160628.20093803405793483.davem@davemloft.net>
On Tue, 2019-07-23 at 16:06 -0700, David Miller wrote:
> From: Shannon Nelson <snelson@pensando.io>
> Date: Tue, 23 Jul 2019 15:50:43 -0700
>
> > On 7/23/19 2:33 PM, David Miller wrote:
> > > Generally interface address changes are expected to be
> > > synchronous.
> > Yeah, this bothers me a bit as well, but the address change calls
> > come
> > in under spin_lock_bh(), and I'm reluctant to make an AdminQ call
> > under the _bh that could block for a few seconds.
>
> So it's not about memory allocation but rather the fact that the
> device
> might take a while to complete?
>
> Can you start the operation synchronously yet complete it async?
The driver is doing busy polling on command completion, doing only busy
polling on completion status in the deferred work will not be much
different than what they have now..
async completion will only make since if the hardware supports
interrupt based (MSI-x) command completion.
^ permalink raw reply
* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: Saeed Mahameed @ 2019-07-23 23:47 UTC (permalink / raw)
To: snelson@pensando.io, netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20190722214023.9513-3-snelson@pensando.io>
On Mon, 2019-07-22 at 14:40 -0700, Shannon Nelson wrote:
> The ionic device has a small set of PCI registers, including a
> device control and data space, and a large set of message
> commands.
>
> Signed-off-by: Shannon Nelson <snelson@pensando.io>
> ---
> drivers/net/ethernet/pensando/ionic/Makefile | 2 +-
> drivers/net/ethernet/pensando/ionic/ionic.h | 20 +
> .../net/ethernet/pensando/ionic/ionic_bus.h | 1 +
> .../ethernet/pensando/ionic/ionic_bus_pci.c | 140 +-
> .../ethernet/pensando/ionic/ionic_debugfs.c | 67 +
> .../ethernet/pensando/ionic/ionic_debugfs.h | 28 +
> .../net/ethernet/pensando/ionic/ionic_dev.c | 132 +
> .../net/ethernet/pensando/ionic/ionic_dev.h | 144 +
> .../net/ethernet/pensando/ionic/ionic_if.h | 2552
> +++++++++++++++++
> .../net/ethernet/pensando/ionic/ionic_main.c | 296 ++
> .../net/ethernet/pensando/ionic/ionic_regs.h | 133 +
> 11 files changed, 3512 insertions(+), 3 deletions(-)
> create mode 100644
> drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
> create mode 100644
> drivers/net/ethernet/pensando/ionic/ionic_debugfs.h
> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.c
> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.h
> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_if.h
> create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_regs.h
>
[...]
> static void ionic_remove(struct pci_dev *pdev)
> {
> struct ionic *ionic = pci_get_drvdata(pdev);
>
> - devm_kfree(&pdev->dev, ionic);
> + if (ionic) {
nit, in case you are doing another re-spin maybe early return here:
if (!ionic)
return;
//do stuff
> + ionic_reset(ionic);
> + ionic_dev_teardown(ionic);
> + ionic_unmap_bars(ionic);
> + pci_release_regions(pdev);
> + pci_clear_master(pdev);
> + pci_disable_sriov(pdev);
> + pci_disable_device(pdev);
> + ionic_debugfs_del_dev(ionic);
> + mutex_destroy(&ionic->dev_cmd_lock);
> +
> + devm_kfree(&pdev->dev, ionic);
> + }
> }
>
[...]
>
> +
> +/* Devcmd Interface */
> +u8 ionic_dev_cmd_status(struct ionic_dev *idev)
> +{
> + return ioread8(&idev->dev_cmd_regs->comp.comp.status);
> +}
> +
> +bool ionic_dev_cmd_done(struct ionic_dev *idev)
> +{
> + return ioread32(&idev->dev_cmd_regs->done) & DEV_CMD_DONE;
> +}
> +
> +void ionic_dev_cmd_comp(struct ionic_dev *idev, union dev_cmd_comp
> *comp)
> +{
> + memcpy_fromio(comp, &idev->dev_cmd_regs->comp, sizeof(*comp));
> +}
> +
> +void ionic_dev_cmd_go(struct ionic_dev *idev, union dev_cmd *cmd)
> +{
> + memcpy_toio(&idev->dev_cmd_regs->cmd, cmd, sizeof(*cmd));
> + iowrite32(0, &idev->dev_cmd_regs->done);
> + iowrite32(1, &idev->dev_cmd_regs->doorbell);
> +}
> +
> +/* Device commands */
> +void ionic_dev_cmd_identify(struct ionic_dev *idev, u8 ver)
> +{
> + union dev_cmd cmd = {
> + .identify.opcode = CMD_OPCODE_IDENTIFY,
> + .identify.ver = ver,
> + };
> +
> + ionic_dev_cmd_go(idev, &cmd);
> +}
> +
> +void ionic_dev_cmd_init(struct ionic_dev *idev)
> +{
> + union dev_cmd cmd = {
> + .init.opcode = CMD_OPCODE_INIT,
> + .init.type = 0,
> + };
> +
> + ionic_dev_cmd_go(idev, &cmd);
> +}
> +
> +void ionic_dev_cmd_reset(struct ionic_dev *idev)
> +{
> + union dev_cmd cmd = {
> + .reset.opcode = CMD_OPCODE_RESET,
> + };
> +
> + ionic_dev_cmd_go(idev, &cmd);
> +}
[...]
> +int ionic_dev_cmd_wait(struct ionic *ionic, unsigned long
> max_seconds)
> +{
> + struct ionic_dev *idev = &ionic->idev;
> + unsigned long max_wait, start_time, duration;
> + int opcode;
> + int done;
> + int err;
> +
> + WARN_ON(in_interrupt());
> +
> + /* Wait for dev cmd to complete, retrying if we get EAGAIN,
> + * but don't wait any longer than max_seconds.
> + */
> + max_wait = jiffies + (max_seconds * HZ);
> +try_again:
> + start_time = jiffies;
> + do {
> + done = ionic_dev_cmd_done(idev);
READ_ONCE required here ? to read from coherent memory modified
by the device and read by the driver ?
> + if (done)
> + break;
> + msleep(20);
> + } while (!done && time_before(jiffies, max_wait));
so your command interface is busy polling based, i am relating here to
Dave's comment regarding async command completion, is it possible to
have interrupt (MSIX?) based command completion in this hw ?
> + duration = jiffies - start_time;
> +
> + opcode = idev->dev_cmd_regs->cmd.cmd.opcode;
> + dev_dbg(ionic->dev, "DEVCMD %s (%d) done=%d took %ld secs (%ld
> jiffies)\n",
> + ionic_opcode_to_str(opcode), opcode,
> + done, duration / HZ, duration);
> +
> + if (!done && !time_before(jiffies, max_wait)) {
> + dev_warn(ionic->dev, "DEVCMD %s (%d) timeout after %ld
> secs\n",
> + ionic_opcode_to_str(opcode), opcode,
> max_seconds);
> + return -ETIMEDOUT;
> + }
> +
> + err = ionic_dev_cmd_status(&ionic->idev);
> + if (err) {
> + if (err == IONIC_RC_EAGAIN && !time_after(jiffies,
> max_wait)) {
> + dev_err(ionic->dev, "DEV_CMD %s (%d) error, %s
> (%d) retrying...\n",
> + ionic_opcode_to_str(opcode), opcode,
> + ionic_error_to_str(err), err);
> +
> + msleep(1000);
> + iowrite32(0, &idev->dev_cmd_regs->done);
> + iowrite32(1, &idev->dev_cmd_regs->doorbell);
> + goto try_again;
> + }
> +
> + dev_err(ionic->dev, "DEV_CMD %s (%d) error, %s (%d)
> failed\n",
> + ionic_opcode_to_str(opcode), opcode,
> + ionic_error_to_str(err), err);
> +
> + return ionic_error_to_errno(err);
> + }
> +
> + return 0;
> +}
> +
>
[...]
^ permalink raw reply
* [PATCH] fsl/fman: Remove comment referring to non-existent function
From: Chris Packham @ 2019-07-23 23:35 UTC (permalink / raw)
To: madalin.bucur, davem; +Cc: netdev, linux-kernel, Chris Packham
fm_set_max_frm() existed in the Freescale SDK as a callback for an
early_param. When this code was ported to the upstream kernel the
early_param was converted to a module_param making the reference to the
function incorrect. The rest of the comment already does a good job of
explaining the parameter so removing the reference to the non-existent
function seems like the best thing to do.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
drivers/net/ethernet/freescale/fman/fman.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
index e80fedb27cee..210749bf1eac 100644
--- a/drivers/net/ethernet/freescale/fman/fman.c
+++ b/drivers/net/ethernet/freescale/fman/fman.c
@@ -2439,9 +2439,6 @@ MODULE_PARM_DESC(fsl_fm_rx_extra_headroom, "Extra headroom for Rx buffers");
* buffers when not using jumbo frames.
* Must be large enough to accommodate the network MTU, but small enough
* to avoid wasting skb memory.
- *
- * Could be overridden once, at boot-time, via the
- * fm_set_max_frm() callback.
*/
static int fsl_fm_max_frm = FSL_FM_MAX_FRAME_SIZE;
module_param(fsl_fm_max_frm, int, 0);
--
2.22.0
^ permalink raw reply related
* Re: memory leak in rds_send_probe
From: Eric Biggers @ 2019-07-23 23:25 UTC (permalink / raw)
To: Andrew Morton
Cc: syzbot, catalin.marinas, davem, dvyukov, jack, kirill.shutemov,
koct9i, linux-kernel, linux-mm, linux-rdma, neilb, netdev,
rds-devel, ross.zwisler, santosh.shilimkar, syzkaller-bugs,
torvalds, willy
In-Reply-To: <20190723152336.29ed51551d8c9600bb316b52@linux-foundation.org>
On Tue, Jul 23, 2019 at 03:23:36PM -0700, Andrew Morton wrote:
> On Tue, 23 Jul 2019 15:17:00 -0700 syzbot <syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com> wrote:
>
> > syzbot has bisected this bug to:
> >
> > commit af49a63e101eb62376cc1d6bd25b97eb8c691d54
> > Author: Matthew Wilcox <willy@linux.intel.com>
> > Date: Sat May 21 00:03:33 2016 +0000
> >
> > radix-tree: change naming conventions in radix_tree_shrink
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=176528c8600000
> > start commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
> > git tree: upstream
> > final crash: https://syzkaller.appspot.com/x/report.txt?x=14e528c8600000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10e528c8600000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=8de7d700ea5ac607
> > dashboard link: https://syzkaller.appspot.com/bug?extid=5134cdf021c4ed5aaa5f
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=145df0c8600000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=170001f4600000
> >
> > Reported-by: syzbot+5134cdf021c4ed5aaa5f@syzkaller.appspotmail.com
> > Fixes: af49a63e101e ("radix-tree: change naming conventions in
> > radix_tree_shrink")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> That's rather hard to believe. af49a63e101eb6237 simply renames a
> couple of local variables.
>
It's been known for months (basically ever since bisection was added) that about
50% of syzbot bisection results are obviously incorrect, often a commit selected
at random. Unfortunately, the people actually funded to work on syzbot
apparently don't consider fixing this to be high priority issue, so we have to
live with it for now. Or until someone volunteers to fix it themselves; source
is at https://github.com/google/syzkaller.
So for now, please don't waste much time on bisection results that look wonky.
But please do pay attention to any bisection results in reminders I've been
sending like "Reminder: 10 open syzbot bugs in foo subsystem", since I've
manually reviewed those to exclude the obviously wrong results...
- Eric
^ permalink raw reply
* Re: [PATCH 3/3] net/xdp: convert put_page() to put_user_page*()
From: John Hubbard @ 2019-07-23 23:24 UTC (permalink / raw)
To: Ira Weiny
Cc: john.hubbard, Andrew Morton, Alexander Viro,
Björn Töpel, Boaz Harrosh, Christoph Hellwig,
Daniel Vetter, Dan Williams, Dave Chinner, David Airlie,
David S . Miller, Ilya Dryomov, Jan Kara, Jason Gunthorpe,
Jens Axboe, Jérôme Glisse, Johannes Thumshirn,
Magnus Karlsson, Matthew Wilcox, Miklos Szeredi, Ming Lei,
Sage Weil, Santosh Shilimkar, Yan Zheng, netdev, dri-devel,
linux-mm, linux-rdma, bpf, LKML
In-Reply-To: <20190723180612.GB29729@iweiny-DESK2.sc.intel.com>
On 7/23/19 11:06 AM, Ira Weiny wrote:
> On Mon, Jul 22, 2019 at 09:41:34PM -0700, John Hubbard wrote:
>> On 7/22/19 5:25 PM, Ira Weiny wrote:
>>> On Mon, Jul 22, 2019 at 03:34:15PM -0700, john.hubbard@gmail.com wrote:
...
>> Obviously, this stuff is all subject to a certain amount of opinion, but I
>> think I'm on really solid ground as far as precedent goes. So I'm pushing
>> back on the NAK... :)
>
> Fair enough... However, we have discussed in the past how GUP can be a
> confusing interface to use.
>
> So I'd like to see it be more directed. Only using the __put_user_pages()
> version allows us to ID callers easier through a grep of PUP_FLAGS_DIRTY_LOCK
> in addition to directing users to use that interface rather than having to read
> the GUP code to figure out that the 2 calls above are equal. It is not a huge
> deal but...
>
OK, combining all the feedback to date, which is:
* the leading double underscore is unloved,
* set_page_dirty() is under investigation, but likely guilty of incitement
to cause bugs,
...we end up with this:
void put_user_pages_dirty_lock(struct page **pages, unsigned long npages,
bool make_dirty)
...which I have a v2 patchset for, ready to send out. It makes IB all pretty
too. :)
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH iproute2] etf: make printing of variable JSON friendly
From: Stephen Hemminger @ 2019-07-23 23:23 UTC (permalink / raw)
To: Patel, Vedang
Cc: David Ahern, netdev@vger.kernel.org, Jamal Hadi Salim, Cong Wang,
Jiri Pirko, Gomes, Vinicius, Dorileo, Leandro
In-Reply-To: <8BC34CA3-C500-4188-BDBA-4B2B7E9F1EE2@intel.com>
On Tue, 23 Jul 2019 21:34:46 +0000
"Patel, Vedang" <vedang.patel@intel.com> wrote:
> > On Jul 22, 2019, at 5:11 PM, David Ahern <dsahern@gmail.com> wrote:
> >
> > On 7/22/19 1:11 PM, Patel, Vedang wrote:
> >>
> >>
> >>> On Jul 22, 2019, at 11:21 AM, David Ahern <dsahern@gmail.com> wrote:
> >>>
> >>> On 7/19/19 3:40 PM, Vedang Patel wrote:
> >>>> In iproute2 txtime-assist series, it was pointed out that print_bool()
> >>>> should be used to print binary values. This is to make it JSON friendly.
> >>>>
> >>>> So, make the corresponding changes in ETF.
> >>>>
> >>>> Fixes: 8ccd49383cdc ("etf: Add skip_sock_check")
> >>>> Reported-by: Stephen Hemminger <stephen@networkplumber.org>
> >>>> Signed-off-by: Vedang Patel <vedang.patel@intel.com>
> >>>> ---
> >>>> tc/q_etf.c | 12 ++++++------
> >>>> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>>>
> >>>> diff --git a/tc/q_etf.c b/tc/q_etf.c
> >>>> index c2090589bc64..307c50eed48b 100644
> >>>> --- a/tc/q_etf.c
> >>>> +++ b/tc/q_etf.c
> >>>> @@ -176,12 +176,12 @@ static int etf_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
> >>>> get_clock_name(qopt->clockid));
> >>>>
> >>>> print_uint(PRINT_ANY, "delta", "delta %d ", qopt->delta);
> >>>> - print_string(PRINT_ANY, "offload", "offload %s ",
> >>>> - (qopt->flags & TC_ETF_OFFLOAD_ON) ? "on" : "off");
> >>>> - print_string(PRINT_ANY, "deadline_mode", "deadline_mode %s ",
> >>>> - (qopt->flags & TC_ETF_DEADLINE_MODE_ON) ? "on" : "off");
> >>>> - print_string(PRINT_ANY, "skip_sock_check", "skip_sock_check %s",
> >>>> - (qopt->flags & TC_ETF_SKIP_SOCK_CHECK) ? "on" : "off");
> >>>> + if (qopt->flags & TC_ETF_OFFLOAD_ON)
> >>>> + print_bool(PRINT_ANY, "offload", "offload ", true);
> >>>> + if (qopt->flags & TC_ETF_DEADLINE_MODE_ON)
> >>>> + print_bool(PRINT_ANY, "deadline_mode", "deadline_mode ", true);
> >>>> + if (qopt->flags & TC_ETF_SKIP_SOCK_CHECK)
> >>>> + print_bool(PRINT_ANY, "skip_sock_check", "skip_sock_check", true);
> >>>>
> >>>> return 0;
> >>>> }
> >>>>
> >>>
> >>> This changes existing output for TC_ETF_OFFLOAD_ON and
> >>> TC_ETF_DEADLINE_MODE_ON which were added a year ago.
> >> Yes, this is a good point. I missed that.
> >>
> >> Another idea is to use is_json_context() and call print_bool() there. But, that will still change values corresponding to the json output for the above flags from “on”/“off” to “true”/“false”. I am not sure if this is a big issue.
> >>
> >> My suggestion is to keep the code as is. what do you think?
> >>
> >
> > I think we need automated checkers for new code. ;-)
> >
> > The first 2 should not change for backward compatibility - unless there
> > is agreement that this feature is too new and long term it is better to
> > print as above.
> >
> > Then the new one should follow context of the other 2 - consistency IMHO
> > takes precedence.
> Thanks for the inputs.
>
> Let’s keep whatever is currently present upstream and you can ignore this patch.
>
> Thanks,
> Vedang
Agreed. At this point consistency is better.
Maybe at some future point, all the JSON will be reviewed and fixed (yes it would be a breaking flag day).
But for now inconsistent usage across ip, tc, and devlink is a fact of life.
^ permalink raw reply
* Re: [PATCH v4 net-next 02/19] ionic: Add hardware init and device commands
From: Shannon Nelson @ 2019-07-23 23:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20190723.160538.2065000079755912945.davem@davemloft.net>
On 7/23/19 4:05 PM, David Miller wrote:
> From: Shannon Nelson <snelson@pensando.io>
> Date: Tue, 23 Jul 2019 15:50:22 -0700
>
>> On 7/23/19 2:18 PM, David Miller wrote:
>>> From: Shannon Nelson <snelson@pensando.io>
>>> Date: Mon, 22 Jul 2019 14:40:06 -0700
>>>
>>>> +void ionic_init_devinfo(struct ionic_dev *idev)
>>>> +{
>>>> + idev->dev_info.asic_type = ioread8(&idev->dev_info_regs->asic_type);
>>>> + idev->dev_info.asic_rev = ioread8(&idev->dev_info_regs->asic_rev);
>>>> +
>>>> + memcpy_fromio(idev->dev_info.fw_version,
>>>> + idev->dev_info_regs->fw_version,
>>>> + IONIC_DEVINFO_FWVERS_BUFLEN);
>>>> +
>>>> + memcpy_fromio(idev->dev_info.serial_num,
>>>> + idev->dev_info_regs->serial_num,
>>>> + IONIC_DEVINFO_SERIAL_BUFLEN);
>>> ...
>>>> + sig = ioread32(&idev->dev_info_regs->signature);
>>> I think if you are going to use the io{read,write}{8,16,32,64}()
>>> interfaces then you should use io{read,write}{8,16,32,64}_rep()
>>> instead of memcpy_{to,from}io().
>>>
>> Sure.
> Note, I could be wrong. Please test.
>
> I think the operation of the two things might be different.
It seems to me that memcpy() usually just does the right thing in most
cases, so that's what I went with. Looking into some of the
definitions, and at how I used memcpy_...(), I think there are some
appropriate ways to use ioread32_rep() in a couple of my cases, and
another case or two where the memcpy variant may not make much
difference with ioread8_rep(). It's also possible that sparse may have
an opinion. I'll look at them.
sln
^ permalink raw reply
* Re: [PATCH] fix noderef.cocci warnings
From: Nikolay Aleksandrov @ 2019-07-23 23:21 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Martin Weinelt, bridge, Roopa Prabhu, netdev
In-Reply-To: <20190723225458.GA3376@lkp-kbuild04>
On 7/24/19 1:54 AM, kbuild test robot wrote:
> From: kbuild test robot <lkp@intel.com>
>
> net/bridge/br_multicast.c:999:8-14: ERROR: application of sizeof to pointer
>
> sizeof when applied to a pointer typed expression gives the size of
> the pointer
>
> Generated by: scripts/coccinelle/misc/noderef.cocci
>
> Fixes: 17c91348ed8b ("Use-after-free in br_multicast_rcv")
> CC: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> Signed-off-by: kbuild test robot <lkp@intel.com>
> ---
>
> url: https://github.com/0day-ci/linux/commits/Nikolay-Aleksandrov/net-bridge-mcast-fix-possible-uses-of-stale-pointers/20190702-083354
>
> br_multicast.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -996,7 +996,7 @@ static int br_ip6_multicast_mld2_report(
> return -EINVAL;
>
> _nsrcs = skb_header_pointer(skb, nsrcs_offset,
> - sizeof(_nsrcs), &__nsrcs);
> + sizeof(*_nsrcs), &__nsrcs);
> if (!_nsrcs)
> return -EINVAL;
>
>
This must be quite old, I already sent a proper patch without this error.
This one was sent just for testing, hence the TEST in $subject.
[PATCH TEST] net: bridge: mcast: fix possible uses of stale pointers
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo support
From: Saeed Mahameed @ 2019-07-23 23:20 UTC (permalink / raw)
To: snelson@pensando.io, netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <20190722214023.9513-12-snelson@pensando.io>
On Mon, 2019-07-22 at 14:40 -0700, Shannon Nelson wrote:
> Add the Rx filtering and rx_mode NDO callbacks. Also add
> the deferred work thread handling needed to manage the filter
> requests otuside of the netif_addr_lock spinlock.
>
> Signed-off-by: Shannon Nelson <snelson@pensando.io>
> ---
> .../net/ethernet/pensando/ionic/ionic_lif.c | 389
> +++++++++++++++++-
> .../net/ethernet/pensando/ionic/ionic_lif.h | 29 ++
> 2 files changed, 412 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> index 72ac0fd56b69..efcda1337f91 100644
> --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.c
> @@ -12,9 +12,55 @@
> #include "ionic_lif.h"
> #include "ionic_debugfs.h"
>
> +static void ionic_lif_rx_mode(struct lif *lif, unsigned int
> rx_mode);
> +static int ionic_lif_addr_add(struct lif *lif, const u8 *addr);
> +static int ionic_lif_addr_del(struct lif *lif, const u8 *addr);
> +
> static int ionic_set_nic_features(struct lif *lif, netdev_features_t
> features);
> static int ionic_notifyq_clean(struct lif *lif, int budget);
>
> +static void ionic_lif_deferred_work(struct work_struct *work)
> +{
> + struct lif *lif = container_of(work, struct lif,
> deferred.work);
> + struct ionic_deferred *def = &lif->deferred;
> + struct ionic_deferred_work *w = NULL;
> +
> + spin_lock_bh(&def->lock);
> + if (!list_empty(&def->list)) {
> + w = list_first_entry(&def->list,
> + struct ionic_deferred_work, list);
> + list_del(&w->list);
> + }
> + spin_unlock_bh(&def->lock);
> +
> + if (w) {
> + switch (w->type) {
> + case DW_TYPE_RX_MODE:
> + ionic_lif_rx_mode(lif, w->rx_mode);
> + break;
> + case DW_TYPE_RX_ADDR_ADD:
> + ionic_lif_addr_add(lif, w->addr);
> + break;
> + case DW_TYPE_RX_ADDR_DEL:
> + ionic_lif_addr_del(lif, w->addr);
> + break;
> + default:
> + break;
> + }
> + kfree(w);
> + schedule_work(&def->work);
> + }
> +}
> +
> +static void ionic_lif_deferred_enqueue(struct ionic_deferred *def,
> + struct ionic_deferred_work
> *work)
> +{
> + spin_lock_bh(&def->lock);
> + list_add_tail(&work->list, &def->list);
> + spin_unlock_bh(&def->lock);
> + schedule_work(&def->work);
> +}
> +
> int ionic_open(struct net_device *netdev)
> {
> struct lif *lif = netdev_priv(netdev);
> @@ -180,6 +226,235 @@ static int ionic_notifyq_clean(struct lif *lif,
> int budget)
> return work_done;
> }
>
> +static int ionic_lif_addr_add(struct lif *lif, const u8 *addr)
> +{
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.rx_filter_add = {
> + .opcode = CMD_OPCODE_RX_FILTER_ADD,
> + .lif_index = cpu_to_le16(lif->index),
> + .match = cpu_to_le16(RX_FILTER_MATCH_MAC),
> + },
> + };
> + struct rx_filter *f;
> + int err;
> +
> + /* don't bother if we already have it */
> + spin_lock_bh(&lif->rx_filters.lock);
> + f = ionic_rx_filter_by_addr(lif, addr);
> + spin_unlock_bh(&lif->rx_filters.lock);
> + if (f)
> + return 0;
> +
> + netdev_dbg(lif->netdev, "rx_filter add ADDR %pM (id %d)\n",
> addr,
> + ctx.comp.rx_filter_add.filter_id);
> +
> + memcpy(ctx.cmd.rx_filter_add.mac.addr, addr, ETH_ALEN);
> + err = ionic_adminq_post_wait(lif, &ctx);
> + if (err)
> + return err;
> +
> + return ionic_rx_filter_save(lif, 0, RXQ_INDEX_ANY, 0, &ctx);
> +}
> +
> +static int ionic_lif_addr_del(struct lif *lif, const u8 *addr)
> +{
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.rx_filter_del = {
> + .opcode = CMD_OPCODE_RX_FILTER_DEL,
> + .lif_index = cpu_to_le16(lif->index),
> + },
> + };
> + struct rx_filter *f;
> + int err;
> +
> + spin_lock_bh(&lif->rx_filters.lock);
> + f = ionic_rx_filter_by_addr(lif, addr);
> + if (!f) {
> + spin_unlock_bh(&lif->rx_filters.lock);
> + return -ENOENT;
> + }
> +
> + ctx.cmd.rx_filter_del.filter_id = cpu_to_le32(f->filter_id);
> + ionic_rx_filter_free(lif, f);
> + spin_unlock_bh(&lif->rx_filters.lock);
> +
> + err = ionic_adminq_post_wait(lif, &ctx);
> + if (err)
> + return err;
> +
> + netdev_dbg(lif->netdev, "rx_filter del ADDR %pM (id %d)\n",
> addr,
> + ctx.cmd.rx_filter_del.filter_id);
> +
> + return 0;
> +}
> +
> +static int ionic_lif_addr(struct lif *lif, const u8 *addr, bool add)
> +{
> + struct ionic *ionic = lif->ionic;
> + struct ionic_deferred_work *work;
> + unsigned int nmfilters;
> + unsigned int nufilters;
> +
> + if (add) {
> + /* Do we have space for this filter? We test the
> counters
> + * here before checking the need for deferral so that
> we
> + * can return an overflow error to the stack.
> + */
> + nmfilters = le32_to_cpu(ionic-
> >ident.lif.eth.max_mcast_filters);
> + nufilters = le32_to_cpu(ionic-
> >ident.lif.eth.max_ucast_filters);
> +
> + if ((is_multicast_ether_addr(addr) && lif->nmcast <
> nmfilters))
> + lif->nmcast++;
> + else if (!is_multicast_ether_addr(addr) &&
> + lif->nucast < nufilters)
> + lif->nucast++;
> + else
> + return -ENOSPC;
> + } else {
> + if (is_multicast_ether_addr(addr) && lif->nmcast)
> + lif->nmcast--;
> + else if (!is_multicast_ether_addr(addr) && lif->nucast)
> + lif->nucast--;
> + }
> +
> + if (in_interrupt()) {
> + work = kzalloc(sizeof(*work), GFP_ATOMIC);
> + if (!work) {
> + netdev_err(lif->netdev, "%s OOM\n", __func__);
> + return -ENOMEM;
> + }
> + work->type = add ? DW_TYPE_RX_ADDR_ADD :
> DW_TYPE_RX_ADDR_DEL;
> + memcpy(work->addr, addr, ETH_ALEN);
> + netdev_dbg(lif->netdev, "deferred: rx_filter %s %pM\n",
> + add ? "add" : "del", addr);
> + ionic_lif_deferred_enqueue(&lif->deferred, work);
> + } else {
> + netdev_dbg(lif->netdev, "rx_filter %s %pM\n",
> + add ? "add" : "del", addr);
> + if (add)
> + return ionic_lif_addr_add(lif, addr);
> + else
> + return ionic_lif_addr_del(lif, addr);
> + }
> +
> + return 0;
> +}
> +
> +static int ionic_addr_add(struct net_device *netdev, const u8 *addr)
> +{
> + return ionic_lif_addr(netdev_priv(netdev), addr, true);
> +}
> +
> +static int ionic_addr_del(struct net_device *netdev, const u8 *addr)
> +{
> + return ionic_lif_addr(netdev_priv(netdev), addr, false);
> +}
> +
> +static void ionic_lif_rx_mode(struct lif *lif, unsigned int rx_mode)
> +{
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.rx_mode_set = {
> + .opcode = CMD_OPCODE_RX_MODE_SET,
> + .lif_index = cpu_to_le16(lif->index),
> + .rx_mode = cpu_to_le16(rx_mode),
> + },
> + };
> + char buf[128];
> + int err;
> + int i;
> +#define REMAIN(__x) (sizeof(buf) - (__x))
> +
> + i = snprintf(buf, sizeof(buf), "rx_mode 0x%04x -> 0x%04x:",
> + lif->rx_mode, rx_mode);
> + if (rx_mode & RX_MODE_F_UNICAST)
> + i += snprintf(&buf[i], REMAIN(i), "
> RX_MODE_F_UNICAST");
> + if (rx_mode & RX_MODE_F_MULTICAST)
> + i += snprintf(&buf[i], REMAIN(i), "
> RX_MODE_F_MULTICAST");
> + if (rx_mode & RX_MODE_F_BROADCAST)
> + i += snprintf(&buf[i], REMAIN(i), "
> RX_MODE_F_BROADCAST");
> + if (rx_mode & RX_MODE_F_PROMISC)
> + i += snprintf(&buf[i], REMAIN(i), "
> RX_MODE_F_PROMISC");
> + if (rx_mode & RX_MODE_F_ALLMULTI)
> + i += snprintf(&buf[i], REMAIN(i), "
> RX_MODE_F_ALLMULTI");
> + netdev_dbg(lif->netdev, "lif%d %s\n", lif->index, buf);
> +
> + err = ionic_adminq_post_wait(lif, &ctx);
> + if (err)
> + netdev_warn(lif->netdev, "set rx_mode 0x%04x failed:
> %d\n",
> + rx_mode, err);
> + else
> + lif->rx_mode = rx_mode;
> +}
> +
> +static void _ionic_lif_rx_mode(struct lif *lif, unsigned int
> rx_mode)
> +{
> + struct ionic_deferred_work *work;
> +
> + if (in_interrupt()) {
> + work = kzalloc(sizeof(*work), GFP_ATOMIC);
> + if (!work) {
> + netdev_err(lif->netdev, "%s OOM\n", __func__);
> + return;
> + }
> + work->type = DW_TYPE_RX_MODE;
> + work->rx_mode = rx_mode;
> + netdev_dbg(lif->netdev, "deferred: rx_mode\n");
> + ionic_lif_deferred_enqueue(&lif->deferred, work);
> + } else {
> + ionic_lif_rx_mode(lif, rx_mode);
> + }
> +}
> +
> +static void ionic_set_rx_mode(struct net_device *netdev)
> +{
> + struct lif *lif = netdev_priv(netdev);
> + struct identity *ident = &lif->ionic->ident;
> + unsigned int nfilters;
> + unsigned int rx_mode;
> +
> + rx_mode = RX_MODE_F_UNICAST;
> + rx_mode |= (netdev->flags & IFF_MULTICAST) ?
> RX_MODE_F_MULTICAST : 0;
> + rx_mode |= (netdev->flags & IFF_BROADCAST) ?
> RX_MODE_F_BROADCAST : 0;
> + rx_mode |= (netdev->flags & IFF_PROMISC) ? RX_MODE_F_PROMISC :
> 0;
> + rx_mode |= (netdev->flags & IFF_ALLMULTI) ? RX_MODE_F_ALLMULTI
> : 0;
> +
> + /* sync unicast addresses
> + * next check to see if we're in an overflow state
> + * if so, we track that we overflowed and enable NIC PROMISC
> + * else if the overflow is set and not needed
> + * we remove our overflow flag and check the netdev flags
> + * to see if we can disable NIC PROMISC
> + */
> + __dev_uc_sync(netdev, ionic_addr_add, ionic_addr_del);
> + nfilters = le32_to_cpu(ident->lif.eth.max_ucast_filters);
> + if (netdev_uc_count(netdev) + 1 > nfilters) {
> + rx_mode |= RX_MODE_F_PROMISC;
> + lif->uc_overflow = true;
> + } else if (lif->uc_overflow) {
> + lif->uc_overflow = false;
> + if (!(netdev->flags & IFF_PROMISC))
> + rx_mode &= ~RX_MODE_F_PROMISC;
> + }
> +
> + /* same for multicast */
> + __dev_mc_sync(netdev, ionic_addr_add, ionic_addr_del);
> + nfilters = le32_to_cpu(ident->lif.eth.max_mcast_filters);
> + if (netdev_mc_count(netdev) > nfilters) {
> + rx_mode |= RX_MODE_F_ALLMULTI;
> + lif->mc_overflow = true;
> + } else if (lif->mc_overflow) {
> + lif->mc_overflow = false;
> + if (!(netdev->flags & IFF_ALLMULTI))
> + rx_mode &= ~RX_MODE_F_ALLMULTI;
> + }
> +
> + if (lif->rx_mode != rx_mode)
> + _ionic_lif_rx_mode(lif, rx_mode);
> +}
> +
> static int ionic_set_features(struct net_device *netdev,
> netdev_features_t features)
> {
> @@ -196,8 +471,26 @@ static int ionic_set_features(struct net_device
> *netdev,
>
> static int ionic_set_mac_address(struct net_device *netdev, void
> *sa)
> {
> - netdev_info(netdev, "%s: stubbed\n", __func__);
> - return 0;
> + struct sockaddr *addr = sa;
> + u8 *mac;
> +
> + mac = (u8 *)addr->sa_data;
> + if (ether_addr_equal(netdev->dev_addr, mac))
> + return 0;
> +
> + if (!is_valid_ether_addr(mac))
> + return -EADDRNOTAVAIL;
> +
> + if (!is_zero_ether_addr(netdev->dev_addr)) {
> + netdev_info(netdev, "deleting mac addr %pM\n",
> + netdev->dev_addr);
> + ionic_addr_del(netdev, netdev->dev_addr);
> + }
> +
> + memcpy(netdev->dev_addr, mac, netdev->addr_len);
> + netdev_info(netdev, "updating mac addr %pM\n", mac);
> +
> + return ionic_addr_add(netdev, mac);
> }
>
> static int ionic_change_mtu(struct net_device *netdev, int new_mtu)
> @@ -232,20 +525,63 @@ static void ionic_tx_timeout(struct net_device
> *netdev)
> static int ionic_vlan_rx_add_vid(struct net_device *netdev, __be16
> proto,
> u16 vid)
> {
> - netdev_info(netdev, "%s: stubbed\n", __func__);
> - return 0;
> + struct lif *lif = netdev_priv(netdev);
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.rx_filter_add = {
> + .opcode = CMD_OPCODE_RX_FILTER_ADD,
> + .lif_index = cpu_to_le16(lif->index),
> + .match = cpu_to_le16(RX_FILTER_MATCH_VLAN),
> + .vlan.vlan = cpu_to_le16(vid),
> + },
> + };
> + int err;
> +
> + err = ionic_adminq_post_wait(lif, &ctx);
> + if (err)
> + return err;
> +
> + netdev_dbg(netdev, "rx_filter add VLAN %d (id %d)\n", vid,
> + ctx.comp.rx_filter_add.filter_id);
> +
> + return ionic_rx_filter_save(lif, 0, RXQ_INDEX_ANY, 0, &ctx);
> }
>
> static int ionic_vlan_rx_kill_vid(struct net_device *netdev, __be16
> proto,
> u16 vid)
> {
> - netdev_info(netdev, "%s: stubbed\n", __func__);
> - return 0;
> + struct lif *lif = netdev_priv(netdev);
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.rx_filter_del = {
> + .opcode = CMD_OPCODE_RX_FILTER_DEL,
> + .lif_index = cpu_to_le16(lif->index),
> + },
> + };
> + struct rx_filter *f;
> +
> + spin_lock_bh(&lif->rx_filters.lock);
> +
> + f = ionic_rx_filter_by_vlan(lif, vid);
> + if (!f) {
> + spin_unlock_bh(&lif->rx_filters.lock);
> + return -ENOENT;
> + }
> +
> + netdev_dbg(netdev, "rx_filter del VLAN %d (id %d)\n", vid,
> + le32_to_cpu(ctx.cmd.rx_filter_del.filter_id));
> +
> + ctx.cmd.rx_filter_del.filter_id = cpu_to_le32(f->filter_id);
> + ionic_rx_filter_free(lif, f);
> + spin_unlock_bh(&lif->rx_filters.lock);
> +
> + return ionic_adminq_post_wait(lif, &ctx);
> }
>
> static const struct net_device_ops ionic_netdev_ops = {
> .ndo_open = ionic_open,
> .ndo_stop = ionic_stop,
> + .ndo_set_rx_mode = ionic_set_rx_mode,
> .ndo_set_features = ionic_set_features,
> .ndo_set_mac_address = ionic_set_mac_address,
> .ndo_validate_addr = eth_validate_addr,
> @@ -546,6 +882,10 @@ static struct lif *ionic_lif_alloc(struct ionic
> *ionic, unsigned int index)
>
> spin_lock_init(&lif->adminq_lock);
>
> + spin_lock_init(&lif->deferred.lock);
> + INIT_LIST_HEAD(&lif->deferred.list);
> + INIT_WORK(&lif->deferred.work, ionic_lif_deferred_work);
> +
> /* allocate lif info */
> lif->info_sz = ALIGN(sizeof(*lif->info), PAGE_SIZE);
> lif->info = dma_alloc_coherent(dev, lif->info_sz,
> @@ -607,6 +947,8 @@ static void ionic_lif_free(struct lif *lif)
> ionic_qcqs_free(lif);
> ionic_lif_reset(lif);
>
I don't think you want deferred.work running while reset is executing..
cancel_work_sync should happen as early as you close the netdevice.
I assume ionic_lif_reset will flush all configurations and you don't
need to cleanup anything manually? or any data structure stored in
driver ?
> + cancel_work_sync(&lif->deferred.work);
> +
> /* free lif info */
> dma_free_coherent(dev, lif->info_sz, lif->info, lif->info_pa);
> lif->info = NULL;
> @@ -975,6 +1317,37 @@ static int ionic_init_nic_features(struct lif
> *lif)
> return 0;
> }
>
> +static int ionic_station_set(struct lif *lif)
> +{
> + struct net_device *netdev = lif->netdev;
> + struct ionic_admin_ctx ctx = {
> + .work = COMPLETION_INITIALIZER_ONSTACK(ctx.work),
> + .cmd.lif_getattr = {
> + .opcode = CMD_OPCODE_LIF_GETATTR,
> + .index = cpu_to_le16(lif->index),
> + .attr = IONIC_LIF_ATTR_MAC,
> + },
> + };
> + int err;
> +
> + err = ionic_adminq_post_wait(lif, &ctx);
> + if (err)
> + return err;
> +
> + if (!is_zero_ether_addr(netdev->dev_addr)) {
> + netdev_dbg(lif->netdev, "deleting station MAC addr
> %pM\n",
> + netdev->dev_addr);
> + ionic_lif_addr(lif, netdev->dev_addr, false);
> + }
> + memcpy(netdev->dev_addr, ctx.comp.lif_getattr.mac,
> + netdev->addr_len);
> + netdev_dbg(lif->netdev, "adding station MAC addr %pM\n",
> + netdev->dev_addr);
> + ionic_lif_addr(lif, netdev->dev_addr, true);
> +
> + return 0;
> +}
> +
> static int ionic_lif_init(struct lif *lif)
> {
> struct ionic_dev *idev = &lif->ionic->idev;
> @@ -1039,6 +1412,10 @@ static int ionic_lif_init(struct lif *lif)
> if (err)
> goto err_out_notifyq_deinit;
>
> + err = ionic_station_set(lif);
> + if (err)
> + goto err_out_notifyq_deinit;
> +
> set_bit(LIF_INITED, lif->state);
>
> return 0;
> diff --git a/drivers/net/ethernet/pensando/ionic/ionic_lif.h
> b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
> index 9f112aa69033..20b4fa573f77 100644
> --- a/drivers/net/ethernet/pensando/ionic/ionic_lif.h
> +++ b/drivers/net/ethernet/pensando/ionic/ionic_lif.h
> @@ -60,6 +60,29 @@ struct qcq {
> #define napi_to_qcq(napi) container_of(napi, struct qcq, napi)
> #define napi_to_cq(napi) (&napi_to_qcq(napi)->cq)
>
> +enum ionic_deferred_work_type {
> + DW_TYPE_RX_MODE,
> + DW_TYPE_RX_ADDR_ADD,
> + DW_TYPE_RX_ADDR_DEL,
> + DW_TYPE_LINK_STATUS,
> + DW_TYPE_LIF_RESET,
> +};
> +
> +struct ionic_deferred_work {
> + struct list_head list;
> + enum ionic_deferred_work_type type;
> + union {
> + unsigned int rx_mode;
> + u8 addr[ETH_ALEN];
> + };
> +};
> +
> +struct ionic_deferred {
> + spinlock_t lock; /* lock for deferred work list */
> + struct list_head list;
> + struct work_struct work;
> +};
> +
> enum lif_state_flags {
> LIF_INITED,
> LIF_UP,
> @@ -87,13 +110,19 @@ struct lif {
> u64 last_eid;
> unsigned int neqs;
> unsigned int nxqs;
> + unsigned int rx_mode;
> u64 hw_features;
> + bool mc_overflow;
> + unsigned int nmcast;
> + bool uc_overflow;
> + unsigned int nucast;
>
> struct lif_info *info;
> dma_addr_t info_pa;
> u32 info_sz;
>
> struct rx_filters rx_filters;
> + struct ionic_deferred deferred;
> unsigned long *dbid_inuse;
> unsigned int dbid_count;
> struct dentry *dentry;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox