Re: [PATCH 1/2] bcache: ignore pending signals in bcache_device_init()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux