lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMZ6Rq+EkE_wRh3-kv2ZRGyPHoonfR-cLApZPUb=3f2CRBeKFQ@mail.gmail.com>
Date:   Tue, 13 Dec 2022 23:19:26 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Johan Hovold <johan@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] USB: fix misleading usb_set_intfdata() kernel doc

On Tue. 13 Dec. 2022 at 00:20, Johan Hovold <johan@...nel.org> wrote:
> The struct device driver-data pointer is used for any data that a driver
> may need in various callbacks while bound to the device. For
> convenience, subsystems typically provide wrappers such as
> usb_set_intfdata() of the generic accessor functions for use in bus
> callbacks.
>
> There is generally no longer any need for a driver to clear the pointer,
> but since commit 0998d0631001 ("device-core: Ensure drvdata = NULL when
> no driver is bound") the driver-data pointer is set to NULL by driver
> core post unbind anyway.
>
> For historical reasons, USB core also clears this pointer when an
> explicitly claimed interface is released.
>
> Due to a misunderstanding, a misleading kernel doc comment for
> usb_set_intfdata() was recently added which claimed that the driver data
> pointer must not be cleared during disconnect before "all actions [are]
> completed", which is both imprecise and incorrect.
>
> Specifically, drivers like cdc-acm which claim additional interfaces use
> the driver-data pointer as a flag which is cleared when the first
> interface is unbound. As long as a driver does not do something odd like
> dereference the pointer in, for example, completion callbacks, this can
> be done at any time during disconnect. And in any case this is no
> different than for any other resource, like the driver data itself,
> which may be freed by the disconnect callback.
>
> Note that the comment actually also claimed that the interface itself
> was somehow being set to NULL by driver core.
>
> Fix the kernel doc by removing incorrect, overly specific and misleading
> details and adding a comment about why some drivers do clear the
> driver-data pointer.
>
> Fixes: 27ef17849779 ("usb: add usb_set_intfdata() documentation")
> Signed-off-by: Johan Hovold <johan@...nel.org>

Thank you for fixing my mess :)

Acked-by: Vincent Mailhol <mailhol.vincent@...adoo.fr>


Yours sincerely,
Vincent Mailhol

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ