On 3/2/20 6:32 PM, Coly Li wrote: > On 2020/3/3 1:19 上午, Jens Axboe wrote: [ .. >> What if someone else tried to kill the startup? It'd be pretty >> frustrating that it was impossible, just because signals were blocked or >> flushed. The assumption that systemd is the ONLY task that would want to >> kill it is flawed. >> > > Indeed now the bcache registration can not be killed. I guess it is > because the mutex lock held during the metadata checking. > Sure I will look at how to extend udevd timeout value now, and ask for > help later. > Please check if the bcache registration really needs to be synchronous. What exactly do you gain from having a return value (which, seeing that's a simple write() to a sysfs attribute, is probably ignored anyway)? To my understanding, the bcache registration process creates the actual bcache device, which in itself will generate a udev event. So the existence of the bcache device will already signal a successful completion of the registration process. Hence it should be possible to shift the actual bcache registration to a kworker, and have the 'write()' call completed after schedule_work() (or equivalents) are called. That would circumvent the problem, no? Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@xxxxxxx +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
