From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [RFC] fs: add userspace critical mounts event support Date: Tue, 29 Nov 2016 22:54:28 +0100 Message-ID: <20161129215428.GK1402@wotan.suse.de> References: <20160825194133.GC3296@wotan.suse.de> <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@wotan.suse.de> <6332a54e-74c6-eafd-368e-71e87a3fa34e@landley.net> <20161005180017.GD3296@wotan.suse.de> <20161005194633.GE3296@wotan.suse.de> <20161108224726.GD13978@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: Andy Lutomirski Cc: Dmitry Torokhov , "open list:DOCUMENTATION" , Gilles.Muller@lip6.fr, Takashi Iwai , Daniel Wagner , Ming Lei , Stephen Boyd , Kay Sievers , Bjorn Andersson , Tom Gundersen , Alessandro Rubini , Christian Lamparter , Josh Boyer , Jonathan Corbet , Kevin Cernekee , Jacek Anaszewski , Thierry Martinez , linux-serial , Daniel Vetter , linuxppc-dev , Mimi Zohar , David Woodhouse , Jeff Mahoney List-Id: linux-serial@vger.kernel.org On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: > > [CC: added Harald] > > > > As Harald pointed out over a beer yesterday evening, there is at least > > one more reason why UMH isn't obsolete. The ordering of the firmware loading > > might be of important. Say you want to greet the user with a splash screen > > really early on, the graphic card firmware should be loaded first. Also the > > automotive world has this fancy requirement that rear camera must be on the > > screen within 2 seconds. So controlling the firmware loading order is of > > importance (e.g. also do not overcommit the I/O bandwith not so important > > firmwares). A user space helper is able to prioritize the request > > accordingly the use case. > > That seems like a valid problem, but I don't think that UMH adequately > solves it. Sure, loading firmware in the right order avoids a >2sec > delay due to firmware loading, but what happens when you have a slow > USB device that *doesn't* need firmware plugged in to your car's shiny > USB port when you start the car? > > It seems to me that this use case requires explicit control over > device probing and, if that gets added, you get your firmware ordering > for free (just probe the important devices first). In theory this is correct, the problem comes with the flexibility we have created with pivot_root() and friends (another is mount on /lib/firmware) which enables system integrators to pick and choose the "real rootfs" to be a few layers away from the first fs picked up by the kernel. In providing this flexibility we did not envision nor have devised signals to enable a deterministic lookup due to the requirements such lookups might have -- in this case the requirements are that direct fs is ready and kosher all the paths possible for firmware are ready. As you can imagine first race is not only an issue for firmware but a generic issue. The generic race on the fs lookup requires a fs availability event, and addressing fs suspend. I'll note that the race on init is addressed today *only* by the firmware UMH (its UMH is kobject uevent and optionally a custom binary) by using the UMH lock. During a cleanup by Daniel recently I realized it was bogus to use the UMH of the UMH was not used, turns out this would still expose the direct FS lookup to a race though. This begs the question if the UMH lock either be removed / shared with the other kernel UMHs or a generic solution provided for direct fs lookup with some requirements specified. This is all a mess so I've documented each component and issues / ideas we've discussed so far separately, the firmware UMH (which we should probably rebrand to firmware kobject uevent helper to avoid confusion) [0], the real kernel usermode helper [1], the new common kernel file loader [2] [0] https://kernelnewbies.org/KernelProjects/firmware-class-enhancements [1] https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements [2] https://kernelnewbies.org/KernelProjects/common-kernel-loader Luis From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3tSy4q2nTbzDt1n for ; Wed, 30 Nov 2016 08:54:34 +1100 (AEDT) Date: Tue, 29 Nov 2016 22:54:28 +0100 From: "Luis R. Rodriguez" To: Andy Lutomirski Cc: Daniel Wagner , "Luis R. Rodriguez" , Linus Torvalds , Jiri Kosina , Johannes Berg , Jouni Malinen , Seth Forshee , Tom Gundersen , Kay Sievers , Bjorn Andersson , Daniel Wagner , "Rafael J. Wysocki" , "Herbert, Marc" , Daniel Vetter , Rob Landley , Mimi Zohar , Felix Fietkau , David Woodhouse , Roman Pen , Ming Lei , Andrew Morton , Michal Marek , Greg KH , Linux Kernel Mailing List , Vikram Mulukutla , Stephen Boyd , Mark Brown , Takashi Iwai , Christian Lamparter , Hauke Mehrtens , Josh Boyer , Dmitry Torokhov , Jiri Slaby , Wu Fengguang , Richard Purdie , Jeff Mahoney , Jacek Anaszewski , Abhay_Salunke@dell.com, Julia Lawall , Gilles.Muller@lip6.fr, nicolas.palix@imag.fr, David Howells , Alessandro Rubini , Kevin Cernekee , Kees Cook , Jonathan Corbet , Thierry Martinez , linux-serial , "open list:DOCUMENTATION" , linuxppc-dev , Josh Triplett , Harald Hoyer Subject: Re: [RFC] fs: add userspace critical mounts event support Message-ID: <20161129215428.GK1402@wotan.suse.de> References: <20160825194133.GC3296@wotan.suse.de> <20160902235916.GO3296@wotan.suse.de> <20160903002014.GP3296@wotan.suse.de> <6332a54e-74c6-eafd-368e-71e87a3fa34e@landley.net> <20161005180017.GD3296@wotan.suse.de> <20161005194633.GE3296@wotan.suse.de> <20161108224726.GD13978@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Nov 09, 2016 at 03:21:07AM -0800, Andy Lutomirski wrote: > On Wed, Nov 9, 2016 at 1:13 AM, Daniel Wagner > wrote: > > [CC: added Harald] > > > > As Harald pointed out over a beer yesterday evening, there is at least > > one more reason why UMH isn't obsolete. The ordering of the firmware loading > > might be of important. Say you want to greet the user with a splash screen > > really early on, the graphic card firmware should be loaded first. Also the > > automotive world has this fancy requirement that rear camera must be on the > > screen within 2 seconds. So controlling the firmware loading order is of > > importance (e.g. also do not overcommit the I/O bandwith not so important > > firmwares). A user space helper is able to prioritize the request > > accordingly the use case. > > That seems like a valid problem, but I don't think that UMH adequately > solves it. Sure, loading firmware in the right order avoids a >2sec > delay due to firmware loading, but what happens when you have a slow > USB device that *doesn't* need firmware plugged in to your car's shiny > USB port when you start the car? > > It seems to me that this use case requires explicit control over > device probing and, if that gets added, you get your firmware ordering > for free (just probe the important devices first). In theory this is correct, the problem comes with the flexibility we have created with pivot_root() and friends (another is mount on /lib/firmware) which enables system integrators to pick and choose the "real rootfs" to be a few layers away from the first fs picked up by the kernel. In providing this flexibility we did not envision nor have devised signals to enable a deterministic lookup due to the requirements such lookups might have -- in this case the requirements are that direct fs is ready and kosher all the paths possible for firmware are ready. As you can imagine first race is not only an issue for firmware but a generic issue. The generic race on the fs lookup requires a fs availability event, and addressing fs suspend. I'll note that the race on init is addressed today *only* by the firmware UMH (its UMH is kobject uevent and optionally a custom binary) by using the UMH lock. During a cleanup by Daniel recently I realized it was bogus to use the UMH of the UMH was not used, turns out this would still expose the direct FS lookup to a race though. This begs the question if the UMH lock either be removed / shared with the other kernel UMHs or a generic solution provided for direct fs lookup with some requirements specified. This is all a mess so I've documented each component and issues / ideas we've discussed so far separately, the firmware UMH (which we should probably rebrand to firmware kobject uevent helper to avoid confusion) [0], the real kernel usermode helper [1], the new common kernel file loader [2] [0] https://kernelnewbies.org/KernelProjects/firmware-class-enhancements [1] https://kernelnewbies.org/KernelProjects/usermode-helper-enhancements [2] https://kernelnewbies.org/KernelProjects/common-kernel-loader Luis