On Fri, Sep 9, 2016 at 11:39 AM, Luis R. Rodriguez <mcg...@kernel.org> wrote: > On Sep 8, 2016 6:22 PM, "Ming Lei" <ming....@canonical.com> wrote: >> >> On Fri, Sep 9, 2016 at 4:11 AM, Luis R. Rodriguez <mcg...@kernel.org> >> wrote: >> > On Thu, Sep 08, 2016 at 11:37:54PM +0800, Ming Lei wrote: >> >> On Wed, Sep 7, 2016 at 4:45 PM, Daniel Wagner <w...@monom.org> wrote: >> >> > From: Daniel Wagner <daniel.wag...@bmw-carit.de> >> >> > >> >> > When we load the firmware directly we don't need to take the umh >> >> > lock. >> >> >> >> I am wondering if it can be wrong. >> > >> > If you disable the firmware UMH why would we need to lock if the lock is >> > being >> > shown only used for the firmare UMH ? >> > >> >> Actually in case of firmware loading, the usermode helper lock doesn't >> >> only mean the user helper is usable, and it also may serve to mark the >> >> filesystem/block device is ready for firmware loading, and of couse >> >> direct >> >> loading need fs/block to be ready too. >> > >> > Yes but that's a race I've identified a while ago present even if you >> > use initramfs *and* >> > use kernel_read_file_from_path() on any part of the kernel [0], I >> > proposed a possible >> >> Actualy I mean the situation of suspend vs. resume, and some drivers >> still may not benefit from firmware loading cache when requesting loading >> in .resume(), at that time it is still too early for direct loading. >> With UMH lock, >> we can get a warning or avoid the issue. > > Agreed, but that would seem odd and perhaps misleading to have a try lock > for UMH when no firmware UMH code is enabled. This should probably made > clear in comments for now as to why we have it then and we should just mark
That is very helpful, :-) > a TODO item to generalize this to a common freezer check. Surprised we don't > have one yet. Rafael ? > > Luis
