public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
	Tony Lindgren <tony@atomide.com>,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	Felipe Balbi <felipe.balbi@linux.intel.com>,
	Bin Liu <b-liu@ti.com>,
	pali.rohar@gmail.com
Subject: Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another
Date: Tue, 05 Apr 2016 20:07:45 +0200	[thread overview]
Message-ID: <xa1ty48svsi6.fsf@mina86.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1604051340030.2233-100000@iolanthe.rowland.org>

> On Tue, 5 Apr 2016, Michal Nazarewicz wrote:
>> When binding the function to usb_configuration, check whether the thread
>> is running before starting another one.  Without that, when function
>> instance is added to multiple configurations, fsg_bing starts multiple
>> threads with all but the latest one being forgotten by the driver.  This
>> leads to obvious thread leaks, possible lockups when trying to halt the
>> machine and possible more issues.
>> 
>> This fixes issues with legacy/multi¹ gadget as well as configfs gadgets
>> when mass_storage function is added to multiple configurations.
>> 
>> This change also simplifies API since the legacy gadgets no longer need
>> to worry about starting the thread by themselves (which was where bug
>> in legacy/multi was in the first place).
>> 
>> ¹ I have no example failure though.  Conclusion that legacy/multi has
>>   a bug is based purely on me reading the code.
>> 
>> Signed-off-by: Michal Nazarewicz <mina86@mina86.com>

On Tue, Apr 05 2016, Alan Stern wrote:
> This doesn't address the problem I raised in a previous email.  
> Sharing one thread among several function instances in the same config
> will not work if one of them encounters an error.

Each usb_function_instance has its own fsg_common and its own thread.
This was true in the past and is true with this patch as well.

And unless I’m missing something, sharing a thread among multiple
usb_function’s does not prevent the driver from working correctly.

Having the thread run even when it’s not used may be considered wasteful
but that’s an orthogonal issue to the configfs failure.

-- 
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»

  reply	other threads:[~2016-04-05 18:07 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05 17:28 [PATCH] usb: f_mass_storage: test whether thread is running before starting another Michal Nazarewicz
2016-04-05 17:42 ` Alan Stern
2016-04-05 18:07   ` Michal Nazarewicz [this message]
2016-04-05 18:35     ` Alan Stern
2016-04-05 22:26       ` Michal Nazarewicz
2016-04-06 15:05         ` Alan Stern
2016-04-07  9:57           ` Michal Nazarewicz
2016-04-07 14:25             ` Alan Stern
2016-04-07 14:46               ` Ivaylo Dimitrov
2016-04-07 20:50                 ` Ivaylo Dimitrov
2016-04-07 16:40               ` Michal Nazarewicz
2016-04-18  9:26                 ` Andrzej Pietrasiewicz
2016-04-19 14:38                   ` Michal Nazarewicz

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=xa1ty48svsi6.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=b-liu@ti.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tony@atomide.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