From: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
To: Oliver Neukum <oneukum@suse.com>
Cc: "Marc Kleine-Budde" <mkl@pengutronix.de>,
linux-can@vger.kernel.org,
"Wolfgang Grandegger" <wg@grandegger.com>,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Frank Jungclaus" <frank.jungclaus@esd.eu>,
socketcan@esd.eu, "Yasushi SHOJI" <yashi@spacecubics.com>,
"Stefan Mätje" <stefan.maetje@esd.eu>,
"Hangyu Hua" <hbh25y@gmail.com>,
"Oliver Hartkopp" <socketcan@hartkopp.net>,
"Peter Fink" <pfink@christ-es.de>,
"Jeroen Hofstee" <jhofstee@victronenergy.com>,
"Christoph Möhring" <cmoehring@christ-es.de>,
"John Whittington" <git@jbrengineering.co.uk>,
"Vasanth Sadhasivan" <vasanth.sadhasivan@samsara.com>,
"Jimmy Assarsson" <extja@kvaser.com>,
"Anssi Hannula" <anssi.hannula@bitwise.fi>,
"Pavel Skripkin" <paskripkin@gmail.com>,
"Stephane Grosjean" <s.grosjean@peak-system.com>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Gustavo A . R . Silva" <gustavoars@kernel.org>,
"Julia Lawall" <Julia.Lawall@inria.fr>,
"Dongliang Mu" <dzm91@hust.edu.cn>,
"Sebastian Haas" <haas@ems-wuensche.com>,
"Maximilian Schneider" <max@schneidersoft.net>,
"Daniel Berglund" <db@kvaser.com>,
"Olivier Sobrie" <olivier@sobrie.be>,
"Remigiusz Kołłątaj" <remigiusz.kollataj@mobica.com>,
"Jakob Unterwurzacher"
<jakob.unterwurzacher@theobroma-systems.com>,
"Martin Elshuber" <martin.elshuber@theobroma-systems.com>,
"Bernd Krumboeck" <b.krumboeck@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Alan Stern" <stern@rowland.harvard.edu>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 0/8] can: usb: remove all usb_set_intfdata(intf, NULL) in drivers' disconnect()
Date: Fri, 9 Dec 2022 00:44:51 +0900 [thread overview]
Message-ID: <CAMZ6RqL9eKco+fAMZoQ6X9PNE7dDK3KnFZoMCXrjgvx_ZU8=Ew@mail.gmail.com> (raw)
In-Reply-To: <b5df2262-7a4f-0dcf-6460-793dad02401d@suse.com>
On Thu. 8 Dec. 2022 at 20:04, Oliver Neukum <oneukum@suse.com> wrote:
> On 08.12.22 10:00, Vincent MAILHOL wrote:
> > On Mon. 5 Dec. 2022 at 17:39, Oliver Neukum <oneukum@suse.com> wrote:
> >> On 03.12.22 14:31, Vincent Mailhol wrote:
>
> Good Morning!
Good night! (different time zone :))
> > ACK, but I do not see the connection.
> Well, useless checks are bad. In particular, we should always
> make it clear whether a pointer may or may not be NULL.
> That is, I have no problem with what you were trying to do
> with your patch set. It is a good idea and possibly slightly
> overdue. The problem is the method.
>
> > I can see that cdc-acm sets acm->control and acm->data to NULL in his
> > disconnect(), but it doesn't set its own usb_interface to NULL.
>
> You don't have to, but you can. I was explaining the two patterns for doing so.
>
> >> which claim secondary interfaces disconnect() will be called a second time
> >> for.
> >
> > Are you saying that the disconnect() of those CAN USB drivers is being
> > called twice? I do not see this in the source code. The only caller of
> > usb_driver::disconnect() I can see is:
> >
> > https://elixir.bootlin.com/linux/v6.0/source/drivers/usb/core/driver.c#L458
>
> If they use usb_claim_interface(), yes it is called twice. Once per
> interface. That is in the case of ACM once for the originally probed
> interface and a second time for the claimed interface.
> But not necessarily in that order, as you can be kicked off an interface
> via sysfs. Yet you need to cease operations as soon as you are disconnected
> from any interface. That is annoying because it means you cannot use a
> refcount. From that stems the widespread use of intfdata as a flag.
Thank you for the details! I better understand this part now.
> >> In addition, a driver can use setting intfdata to NULL as a flag
> >> for disconnect() having proceeded to a point where certain things
> >> can no longer be safely done.
> >
> > Any reference that a driver can do that? This pattern seems racy.
>
> Technically that is exactly what drivers that use usb_claim_interface()
> do. You free everything at the first call and use intfdata as a flag
> to prevent a double free.
> The race is prevented by usbcore locking, which guarantees that probe()
> and disconnect() have mutual exclusion.
> If you use intfdata in sysfs, yes additional locking is needed.
ACK for the mutual exclusion. My question was about what you said in
your previous message:
| In addition, a driver can use setting intfdata to NULL as a flag
| for *disconnect() having proceeded to a point* where certain things
| can no longer be safely done.
How do you check that disconnect() has proceeded *to a given point*
using intf without being racy? You can check if it has already
completed once but not check how far it has proceeded, right?
> > What makes you assume that I didn't check this in the first place? Or
> > do you see something I missed?
>
> That you did not put it into the changelogs.
> That reads like the drivers are doing something obsolete or stupid.
> They do not. They copied something that is necessary only under
> some circumstances.
>
> And that you did not remove the checks.
>
> >> which is likely, then please also remove checks like this:
> >>
> >> struct ems_usb *dev = usb_get_intfdata(intf);
> >>
> >> usb_set_intfdata(intf, NULL);
> >>
> >> if (dev) {
>
> Here. If you have a driver that uses usb_claim_interface().
> You need this check or you unregister an already unregistered
> netdev.
Sorry, but with all my best intentions, I still do not get it. During
the second iteration, inft is NULL and:
/* equivalent to dev = intf->dev.data. Because intf is NULL,
* this is a NULL pointer dereference */
struct ems_usb *dev = usb_get_intfdata(intf);
/* OK, intf is already NULL */
usb_set_intfdata(intf, NULL);
/* follows a NULL pointer dereference so this is undefined
* behaviour */
if (dev) {
How is this a valid check that you entered the function for the second
time? If intf is the flag, you should check intf, not dev? Something
like this:
struct ems_usb *dev;
if (!intf)
return;
dev = usb_get_intfdata(intf);
/* ... */
I just can not see the connection between intf being NULL and the if
(dev) check. All I see is some undefined behaviour, sorry.
> The way this disconnect() method is coded is extremely defensive.
> Most drivers do not need this check. But it is never
> wrong in the strict sense.
>
> Hence doing a mass removal with a change log that does
> not say that this driver is using only a single interface
> hence the check can be dropped to reduce code size
> is not good.
>
> Regards
> Oliver
next prev parent reply other threads:[~2022-12-08 15:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-03 13:31 [PATCH 0/8] can: usb: remove all usb_set_intfdata(intf, NULL) in drivers' disconnect() Vincent Mailhol
2022-12-03 13:31 ` [PATCH 1/8] can: ems_usb: ems_usb_disconnect(): fix NULL pointer dereference Vincent Mailhol
2022-12-03 13:31 ` [PATCH 2/8] can: esd_usb: esd_usb_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 3/8] can: gs_usb: gs_usb_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 4/8] can: kvaser_usb: kvaser_usb_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 5/8] can: mcba_usb: mcba_usb_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 6/8] can: ucan: ucan_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 7/8] can: usb_8dev: usb_8dev_disconnect(): " Vincent Mailhol
2022-12-03 13:31 ` [PATCH 8/8] can: etas_es58x and peak_usb: remove useless call to usb_set_intfdata() Vincent Mailhol
2022-12-05 8:35 ` [PATCH 0/8] can: usb: remove all usb_set_intfdata(intf, NULL) in drivers' disconnect() Oliver Neukum
2022-12-08 9:00 ` Vincent MAILHOL
2022-12-08 10:55 ` Oliver Neukum
2022-12-08 15:44 ` Vincent MAILHOL [this message]
2022-12-08 16:28 ` Alan Stern
2022-12-08 16:51 ` Oliver Neukum
2022-12-10 9:02 ` Vincent MAILHOL
2022-12-10 9:01 ` [PATCH v2 0/9] " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 1/9] can: ems_usb: ems_usb_disconnect(): fix NULL pointer dereference Vincent Mailhol
2022-12-10 10:59 ` Johan Hovold
2022-12-11 11:24 ` Vincent MAILHOL
2022-12-10 9:01 ` [PATCH v2 2/9] can: esd_usb: esd_usb_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 3/9] can: gs_usb: gs_usb_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 4/9] can: kvaser_usb: kvaser_usb_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 5/9] can: mcba_usb: mcba_usb_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 6/9] can: ucan: ucan_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 7/9] can: usb_8dev: usb_8dev_disconnect(): " Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 8/9] can: usb: remove useless check on driver data Vincent Mailhol
2022-12-10 9:01 ` [PATCH v2 9/9] can: etas_es58x and peak_usb: remove useless call to usb_set_intfdata() Vincent Mailhol
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='CAMZ6RqL9eKco+fAMZoQ6X9PNE7dDK3KnFZoMCXrjgvx_ZU8=Ew@mail.gmail.com' \
--to=mailhol.vincent@wanadoo.fr \
--cc=Julia.Lawall@inria.fr \
--cc=anssi.hannula@bitwise.fi \
--cc=b.krumboeck@gmail.com \
--cc=cmoehring@christ-es.de \
--cc=davem@davemloft.net \
--cc=db@kvaser.com \
--cc=dzm91@hust.edu.cn \
--cc=edumazet@google.com \
--cc=extja@kvaser.com \
--cc=frank.jungclaus@esd.eu \
--cc=git@jbrengineering.co.uk \
--cc=gustavoars@kernel.org \
--cc=haas@ems-wuensche.com \
--cc=hbh25y@gmail.com \
--cc=jakob.unterwurzacher@theobroma-systems.com \
--cc=jhofstee@victronenergy.com \
--cc=kuba@kernel.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=martin.elshuber@theobroma-systems.com \
--cc=max@schneidersoft.net \
--cc=mkl@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=olivier@sobrie.be \
--cc=oneukum@suse.com \
--cc=pabeni@redhat.com \
--cc=paskripkin@gmail.com \
--cc=pfink@christ-es.de \
--cc=remigiusz.kollataj@mobica.com \
--cc=s.grosjean@peak-system.com \
--cc=socketcan@esd.eu \
--cc=socketcan@hartkopp.net \
--cc=stefan.maetje@esd.eu \
--cc=stern@rowland.harvard.edu \
--cc=vasanth.sadhasivan@samsara.com \
--cc=wg@grandegger.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=yashi@spacecubics.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).