linux-kernel - Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 5 Jun 2014 14:10:06 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
cc:	Wei.Yang@...driver.com, Michal Nazarewicz <mina86@...a86.com>,
	Felipe Balbi <balbi@...com>, <gregkh@...uxfoundation.org>,
	USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage

On Thu, 5 Jun 2014, Andrzej Pietrasiewicz wrote:

> I think it is easier to tell the purpose of the two structures taking
> gadgets composed with configfs as example.
> 
> In each gadget there is "functions" directory. Function directories
> are created there:
> 
> $ cd $CONFIGFS_ROOT/usb_gadget/our_gadget
> $ mkdir functions/mass_storage.0
> 
> mass_storage.0 is internally represented as an instance of
> struct usb_function_instance, which has its associated
> struct fsg_common (the fsg_common is a member of
> container_of(struct usb_function_instance)).

Okay.

> It can be referenced from multiple configurations.
> 
> $ ln -s functions/mass_storage.0 configs/config.1
> $ ln -s functions/mass_storage.0 configs/config.2
> 
> Each reference (symbolic link) is internally represented as
> an instance of struct usb_function. The struct usb_function here
> has its associated struct fsg_dev (the fsg_dev is a
> container_of(struct usb_function)).

So in essence, a usb_function connects a particular function to a 
particular config.

> By the very nature of any file system one cannot do:
> 
> $ ln -s functions/mass_storage.0 configs/config.1
> $ ln -s functions/mass_storage.0 configs/config.1 => -EEXIST
> 
> By design of how configfs is applied to any usb gadget on cannot even do:
> 
> $ ln -s functions/mass_storage.0 configs/config.1/my_mass_storage.0
> $ ln -s functions/mass_storage.0 configs/config.1/the_same_mass_storage.0 => -EEXIST

So for any given usb_function_instance, only one usb_function will be
active at any time: the one connecting the function to the current
config.

And presumably the reasons why struct fsg_dev contains
interface_number, bulk_in, and bulk_out members are because these
values are determined when the config is originally set up, and they
can vary from one config to another.  Right?  Whereas the items in
struct fsg_common don't depend on the config.

> However, there should be no problem with this:
> 
> $ mkdir functions/mass_storage.0
> $ mkdir functions/mass_storage.1
> $ ln -s functions/mass_storage.0 configs/config.1
> $ ln -s functions/mass_storage.1 configs/config.1

That makes sense now.

> Legacy gadgets (g_mass_storage, g_acm_ms, g_multi) in fact operate in
> a somewhat similar manner, the difference is that instead of creating directories
> and making symbolic links, usb_get_function_instance() and usb_get_function()
> are called, respectively, and composing a gadget happens from beginning to end
> at module init.
> 
> I hope this clarifies things a bit.

Yes, it helps a lot.  Thank you.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/