Thread (5 messages) flat view 5 messages, 3 authors, 2021-11-17

Re: [syzbot] WARNING: refcount bug in __linkwatch_run_queue

From: Willy Tarreau <w@1wt.eu>
Date: 2021-11-17 14:21:44
Also in: lkml

On Wed, Nov 17, 2021 at 06:15:48AM -0800, Jakub Kicinski wrote:
On Wed, 17 Nov 2021 09:19:07 +0100 Willy Tarreau wrote:
quoted
Thanks for the report. I'm seeing that linkwatch_do_dev() is also
called in linkwatch_forget_dev(), and am wondering if we're not
seeing a sequence like this one:

  linkwatch_forget_dev()
    list_del_init()
    linkwatch_do_dev()
      netdev_state_change()
        ... one of the notifiers
           ... linkwatch_add_event() => adds to watch list
      dev_put()
  ...
  
  __linkwatch_run_queue()
    linkwatch_do_dev()
      dev_put()
        => bang!  

Well, in theory, no, since linkwatch_add_event() will call dev_hold()
when adding to the list, so we ought to leave the first call with a
refcount still covering the list's presence, and I don't see how it
can reach zero before reaching dev_put() in linkwatch_do_dev() as this
function is only called when the event was picked from the list.

The only difference I'm seeing is that before the patch, a call to
linkwatch_forget_dev() on a non-present device would call dev_put()
without going through dev_activate(), dev_deactivate(), nor
netdev_state_change(), but I'm not seeing how that could make a
difference. linkwatch_forget_dev() is called from netdev_wait_allrefs()
which will wait for the refcnt to be exactly 1, thus even if we queue
an extra event we cant leave that function until the event has been
processed.
The ref leak could come from anywhere, tho. Like:

https://lore.kernel.org/all/87a6i3t2zg.fsf@nvidia.com/ (local)
OK thanks for the link, so better wait for this part to clarify itself
and see if the issue magically disappears ?

Willy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help