From: Jakub Kicinski <kuba@kernel.org>
To: Eric Dumazet <edumazet@google.com>
Cc: Jann Horn <jannh@google.com>, Lukas Wunner <lukas@wunner.de>,
Paolo Abeni <pabeni@redhat.com>, Oliver Neukum <oneukum@suse.com>,
"David S. Miller" <davem@davemloft.net>,
Oleksij Rempel <o.rempel@pengutronix.de>,
netdev <netdev@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
Andrew Lunn <andrew@lunn.ch>, Jacky Chou <jackychou@asix.com.tw>,
Willy Tarreau <w@1wt.eu>, Lino Sanfilippo <LinoSanfilippo@gmx.de>,
Philipp Rosenberger <p.rosenberger@kunbus.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] net: linkwatch: ignore events for unregistered netdevs
Date: Mon, 25 Apr 2022 08:28:04 -0700 [thread overview]
Message-ID: <20220425082804.209e3676@kernel.org> (raw)
In-Reply-To: <CANn89iLwvqUJHBNifLESJyBQ85qjK42sK85Fs=QV4M7HqUXmxQ@mail.gmail.com>
On Mon, 25 Apr 2022 08:13:40 -0700 Eric Dumazet wrote:
> dev_hold() has been an increment of a refcount, and dev_put() a decrement.
>
> Not sure why it is fundamentally broken.
Jann described a case where someone does
CPU 0 CPU 1 CPU 2
dev_hold()
------ #unregister -------
dev_hold()
dev_put()
Our check for refcount == 0 goes over the CPUs one by one,
so if it sums up CPUs 0 and 1 at the "unregister" point above
and CPU2 after the CPU1 hold and CPU2 release it will "miss"
one refcount.
That's a problem unless doing a dev_hold() on a netdev we only have
a reference on is illegal.
> There are specific steps at device dismantles making sure no more
> users can dev_hold()
>
> It is a contract. Any buggy layer can overwrite any piece of memory,
> including a refcount_t.
>
> Traditionally we could not add a test in dev_hold() to prevent an
> increment if the device is in dismantle phase.
> Maybe the situation is better nowadays.
next prev parent reply other threads:[~2022-04-25 15:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-17 7:04 [PATCH] net: linkwatch: ignore events for unregistered netdevs Lukas Wunner
2022-04-21 8:02 ` Paolo Abeni
2022-04-23 16:07 ` Lukas Wunner
2022-04-23 19:35 ` Lukas Wunner
2022-04-25 14:41 ` Jakub Kicinski
2022-04-25 14:49 ` Jann Horn
2022-04-25 15:00 ` Jakub Kicinski
2022-04-25 15:13 ` Eric Dumazet
2022-04-25 15:18 ` Jann Horn
2022-04-25 15:23 ` Eric Dumazet
2022-04-25 17:20 ` Lukas Wunner
2022-04-25 17:24 ` Eric Dumazet
2022-04-25 15:28 ` Jakub Kicinski [this message]
2022-04-25 15:31 ` Eric Dumazet
2022-04-25 15:36 ` Jakub Kicinski
2022-04-25 21:18 ` Lukas Wunner
2022-04-25 21:39 ` Eric Dumazet
2022-04-30 10:05 ` Lukas Wunner
2022-04-30 10:09 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220425082804.209e3676@kernel.org \
--to=kuba@kernel.org \
--cc=LinoSanfilippo@gmx.de \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=jackychou@asix.com.tw \
--cc=jannh@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=oneukum@suse.com \
--cc=p.rosenberger@kunbus.com \
--cc=pabeni@redhat.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.