linux-kernel - Re: [PATCH] usb: gadget: f_acm: make bInterfaceProtocol configurable

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: <D33ZXDVKL33Z.1SDI3XDBGZIO8@kernel.org>
Date: Wed, 31 Jul 2024 22:11:00 +0200
From: "Michael Walle" <mwalle@...nel.org>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: gadget: f_acm: make bInterfaceProtocol
 configurable

Hi Greg,

On Wed Jul 31, 2024 at 11:16 AM CEST, Greg Kroah-Hartman wrote:
> On Wed, Jul 31, 2024 at 10:57:04AM +0200, Michael Walle wrote:
> > Hi Greg,
> > 
> > On Wed Jul 31, 2024 at 10:32 AM CEST, Greg Kroah-Hartman wrote:
> > > On Tue, Jul 30, 2024 at 09:43:37PM +0200, Michael Walle wrote:
> > > >  struct f_serial_opts {
> > > >  	struct usb_function_instance func_inst;
> > > >  	u8 port_num;
> > > > +	u8 protocol;
> > > > +
> > > > +	struct mutex lock;
> > > > +	int refcnt;
> > >
> > > Attempting to "roll your own" reference count is almost never a good
> > > idea.  If you really need one, please use the proper in-kernel apis for
> > > this.  But you need to justify it as well, I didn't see why this was
> > > needed at all.
> > 
> > Honestly, I couldn't grok all that usb gadget magic, so I've looked
> > at similar gadgets and took that from there:
> >   grep refcnt drivers/usb/gadget/function/ -r
> > 
> > They are all doing the same, so maybe that code is old or didn't use
> > the proper APIs back then.
>
> It's old code, please do things properly.

Sorry, I have to come back to this. What do you have in mind?

The mutex is needed in any case to protect the members of
f_serial_ops from concurrent access between the .bind() and the
configfs write.

Which leaves us with refcnt. I don't think refcount_t is suitable
here. For example, refcount_inc() will warn if you increment from
0; which makes sense for resource reference counting. But doesn't
make sense in this case; there is no resource handling or freeing if
the refcnt is 0. It just prohibits the write to the configfs
attribute if refcnt != 0, that is, there is at least one instance of
the gadget function.

Maybe I should just rename "refcnt" to "users" and add a comment to
the mutex what it will protect.

What do you think?

-michael