Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1730492
| From | Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: btusb "firmware request while host is not available" at resume |
| Date | 2017-09-11 21:40 +0200 |
| Message-ID | <uoCIO-7F7-15@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <uonTr-5wo-7@gated-at.bofh.it> <uoowa-67j-3@gated-at.bofh.it> <uopix-6K2-1@gated-at.bofh.it> <uoxg6-3Y7-9@gated-at.bofh.it> <uoAxj-6lq-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Sep 11, 2017 at 07:11:38PM +0200, Luis R. Rodriguez wrote:
> On Mon, Sep 11, 2017 at 06:46:47AM -0700, Greg Kroah-Hartman wrote:
> > To confirm, reverting this fixes the problem I was seeing in 4.13. I've
> > queued it up for the next 4.13-stable release as well.
>
> Commit 81f95076281f ("firmware: add sanity check on shutdown/suspend") may
> seem kludgy but the reason for it was to cleanup the horrible forced and
> required UMH lock even when the UMH lock was *not* even needed, which was later
> removed via commit 06a45a93e7d34aa ("firmware: move umh try locks into the umh
> code").
So what does this mean now that it is reverted?
> Removing the old UMH lock even when the UMH lock was *not* needed was the right
> thing to do but commit 81f95076281f (("firmware: add sanity check on
> shutdown/suspend") was put in place as a safe guard as the lock was also
> placing an implicit sanity check on the API. It ensures the API with the cache
> was used as designed, otherwise you do run the risk of *not getting the
> firmware you may need* -- Marcel seems to acknowledge this possibility.
>
> It may be possible for us to already have in place safeguards so that upon
> resume we are ensuring the path to the firmware *is* available, so IMHO we
> should remove this *iff* we can provide this guarantee. Otherwise the check is
> valid. You see, although the UMH lock was bogus, it did implicitly ask the
> question: is it safe for *any* helper to run and make assumptions on the
> filesystem then?
>
> In lieu of this question being answered the warning is valid given the design
> of the firmware API and the having the cache available as a measure to resolve
> this race.
I don't understand what you are trying to say here at all.
To be specific, what, if anything, is a problem with the current state
of Linus's tree (and the next 4.13-stable release)?
If something needs to be fixed, can you make a patch showing that? Or
do we also need to revert anything else as well to get back to a "better
working" state?
thanks,
greg k-h
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
btusb "firmware request while host is not available" at resume Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-10 21:30 +0200
Re: btusb "firmware request while host is not available" at resume Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-11 03:30 +0200
Re: btusb "firmware request while host is not available" at resume Gabriel C <nix.or.die@gmail.com> - 2017-09-11 05:20 +0200
Re: btusb "firmware request while host is not available" at resume Gabriel C <nix.or.die@gmail.com> - 2017-09-11 05:50 +0200
Re: btusb "firmware request while host is not available" at resume Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-11 06:30 +0200
Re: btusb "firmware request while host is not available" at resume Marcel Holtmann <marcel@holtmann.org> - 2017-09-11 07:20 +0200
Re: btusb "firmware request while host is not available" at resume Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-11 15:50 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-11 19:20 +0200
Re: btusb "firmware request while host is not available" at resume Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-11 21:40 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-11 22:10 +0200
Re: btusb "firmware request while host is not available" at resume Gabriel C <nix.or.die@gmail.com> - 2017-09-12 02:20 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-12 02:40 +0200
Re: btusb "firmware request while host is not available" at resume Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-12 02:50 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-12 19:00 +0200
Re: btusb "firmware request while host is not available" at resume Marcel Holtmann <marcel@holtmann.org> - 2017-09-12 07:20 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-12 18:30 +0200
Re: btusb "firmware request while host is not available" at resume Marcel Holtmann <marcel@holtmann.org> - 2017-09-13 09:00 +0200
Re: btusb "firmware request while host is not available" at resume "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-09-13 19:50 +0200
csiph-web