mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Daniel Wagner <daniel.wagner@bmw-carit.de>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	Daniel Wagner <wagi@monom.org>,
	linux-kernel@vger.kernel.org, Ming Lei <ming.lei@canonical.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Srivatsa S . Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	"Rafael J . Wysocki" <rjw@sisk.pl>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Takashi Iwai <tiwai@suse.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Arend van Spriel <arend.vanspriel@broadcom.com>
Subject: Re: [PATCH v5 2/5] firmware: encapsulate firmware loading status
Date: Mon, 10 Oct 2016 22:37:52 +0200	[thread overview]
Message-ID: <20161010203752.GB8651@wotan.suse.de> (raw)
In-Reply-To: <1bbbe0a7-8dc5-3efe-9422-7c52a4f6cc3a@bmw-carit.de>

On Fri, Oct 07, 2016 at 01:41:21PM +0200, Daniel Wagner wrote:
> Hi Luis,
> 
> On 10/05/2016 10:27 PM, Luis R. Rodriguez wrote:
> > On Tue, Sep 13, 2016 at 11:47:08AM +0200, Daniel Wagner wrote:
> > > On 09/09/2016 02:12 PM, Daniel Wagner wrote:
> > > > The firmware user helper code tracks the current state of the loading
> > > > process via unsigned long status and a completion in struct
> > > > firmware_buf. We only need this for the usermode helper as such we can
> > > > encapsulate all this data into its own data structure.
> > > 
> > > I don't think we are able to move the completion code into a
> > > CONFIG_FW_LOADER_HELPER section. The direct loading path uses
> > > completion as well.
> > 
> > Where?
> 
> If you look at the current code (not these patches) you have dependency via
> the firmware_buf for two concurrent _request_firmware() calls:
> 
> 
> 1nd request (waker context)
> 
> _request_firmware()
>   _request_firmware_prepare()
>     fw_lookup_and_allocate_buf()   # no pendending request
>                                    # returns 0 -> load firmware

"no pending request" is an invalid association with what fw_lookup_and_allocate_buf()
does, its also why I have asked for this to be renamed, it looks for the firmware
in the fw cache, if it finds it it returns 1. Otherwise it creates a new buf
entry and adds it to the fw cache, and returns 0.

> 
>   fw_get_fileystem_firmware()
>     fw_finish_direct_load()
>       complete_all()
> 
> 
> 2nd request (waiter context)
> 
> _request_firmware()
>   _request_firmware_prepare()
>      fw_lookup_allocate_buf()      # finds previously allocated buf
>                                    # returns 1 -> wait for loading
>      sync_cached_firmware_buf()
>         wait_for_completion_interruptible_timeout()

No, that's wait_for_completion_interruptible() not
           wait_for_completion_interruptible_timeout()

Also note that we only call sync_cached_firmware_buf()
*iff* fw_lookup_and_allocate_buf() returned the 1 -- I mentioned
when this happens above. That happens only if we already had the entry on
the fw cache. As it stands -- concurrent calls against the same fw name
could cause a clash here, as such, the wait_for_completion_interruptible()
is indeed still needed.

Further optimizations can be considered later but for indeed, agreed
that completion is needed even for the direct fw load case. The timeout
though, I don't see a reason for it.

> > > > +#else /* CONFIG_FW_LOADER_USER_HELPER */
> > > > +
> > > > +#define fw_umh_wait_timeout(fw_st, long)	0
> > > > +
> > > > +#define fw_umh_done(fw_st)
> > > > +#define fw_umh_is_done(fw_st)			true
> > > > +#define fw_umh_is_aborted(fw_st)		false
> > > 
> > > We still need the implementation for fw_umh_wait_timeout() and
> > > fw_umh_start(), fw_umh_done() etc.
> > 
> > Why?
> 
> See above.

Sure, but note how the timeout is not used.

> > > > @@ -309,8 +373,7 @@ static void fw_finish_direct_load(struct device *device,
> > > > 				  struct firmware_buf *buf)
> > > > {
> > > > 	mutex_lock(&fw_lock);
> > > > -	set_bit(FW_STATUS_DONE, &buf->status);
> > > > -	complete_all(&buf->completion);
> > > > +	fw_umh_done(&buf->fw_umh);
> > > > 	mutex_unlock(&fw_lock);
> > > > }
> > > 
> > > Here we signal that we have loaded the firmware
> > 
> > The struct firmware_buf is only used for the sysfs stuff no?
> 
> I don't know, I was looking at the code in firmware_class.c not any users.
> Why is that important?

Sorry I meant struct firmware_priv is used by sysfs stuff only, the sysfs stuff
is only used for the FW UMH.

> > > > /* wait until the shared firmware_buf becomes ready (or error) */
> > > > static int sync_cached_firmware_buf(struct firmware_buf *buf)
> > > > {
> > > > 	int ret = 0;
> > > > 
> > > > 	mutex_lock(&fw_lock);
> > > > -	while (!test_bit(FW_STATUS_DONE, &buf->status)) {
> > > > -		if (is_fw_load_aborted(buf)) {
> > > > +	while (!fw_umh_is_done(&buf->fw_umh)) {
> > > > +		if (fw_umh_is_aborted(&buf->fw_umh)) {
> > > > 			ret = -ENOENT;
> > > > 			break;
> > > > 		}
> > > > 		mutex_unlock(&fw_lock);
> > > > -		ret = wait_for_completion_interruptible(&buf->completion);
> > > > +		ret = fw_umh_wait_timeout(&buf->fw_umh, 0);
> > > > 		mutex_lock(&fw_lock);
> > > > 	}
> > > 
> > > and here we here we wait for it.
> > 
> > Likewise.
> 
> As I tried to explain above the buffering code is depending on completion.

OK sure agreed. The timeout, no though, unless I missed something?

  Luis

  reply	other threads:[~2016-10-10 20:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 12:12 [PATCH v5 0/5] " Daniel Wagner
2016-09-09 12:12 ` [PATCH v5 1/5] firmware: document user mode helper lock usage Daniel Wagner
2016-09-09 22:14   ` Luis R. Rodriguez
2016-09-22  2:36     ` Ming Lei
2016-10-05 20:41       ` Luis R. Rodriguez
     [not found]       ` <ab544ba0-2128-055f-3190-6a1a24e879e1@bmw-carit.de>
2016-10-05 20:46         ` Luis R. Rodriguez
     [not found]           ` <2ec51622-f727-e884-1a09-a595a31f4b21@bmw-carit.de>
2016-10-10 18:40             ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 2/5] firmware: encapsulate firmware loading status Daniel Wagner
2016-09-09 22:19   ` Luis R. Rodriguez
2016-09-09 22:24   ` Luis R. Rodriguez
2016-09-13  9:47   ` Daniel Wagner
2016-10-05 20:27     ` Luis R. Rodriguez
2016-10-07 11:41       ` Daniel Wagner
2016-10-10 20:37         ` Luis R. Rodriguez [this message]
2016-10-18 13:30           ` Daniel Wagner
2016-10-18 21:54             ` Luis R. Rodriguez
2016-10-19  8:05               ` Daniel Wagner
2016-09-09 12:12 ` [PATCH v5 3/5] firmware: rename fw_load_from_user_helper() and _request_firmware_load() Daniel Wagner
2016-09-09 22:17   ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 4/5] firmware: drop bit ops in favor of simple state machine Daniel Wagner
2016-09-09 22:30   ` Luis R. Rodriguez
2016-09-09 12:12 ` [PATCH v5 5/5] firmware: do not use fw_lock for fw_umh protection Daniel Wagner
2016-09-09 17:38 ` [PATCH v5 0/5] firmware: encapsulate firmware loading status Luis R. Rodriguez

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=20161010203752.GB8651@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel.vetter@intel.com \
    --cc=daniel.wagner@bmw-carit.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@canonical.com \
    --cc=rjw@sisk.pl \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tiwai@suse.com \
    --cc=wagi@monom.org \
    /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

all inboxes | Powered by JetHome®