On 2020/11/05 16:59, Damien Le Moal wrote:
> On 2020/11/05 16:54, Christoph Hellwig wrote:
>> On Thu, Nov 05, 2020 at 03:50:08PM +0900, Damien Le Moal wrote:
>>> Commit aa1c09cb65e2 ("null_blk: Fix locking in zoned mode") changed zone
>>> locking to using the potentially sleeping wait_on_bit_io() function. A
>>> zoned null_blk device must thus be marked as blocking to avoid calls to
>>> queue_rq() from invalid contexts triggering might_sleep() warnings.
>>
>> That's going to have a fair amount of overhead. Can't you change the
>> locking to avoid blocking?
>>
>
> I know, but the GFP_NOIO allocation with memory backing prevents any sort of
> spinlock. So unless we change that to GFP_NOWAIT I do not see a way out of it.
> I am fine with GFP_NOWAIT, but not sure if that is not going to break some test
> setups out there.
>
> The other solution would be to "do writes" (memory allocation and copy) first,
> regardless of zone state, wp etc, then do the zone checking under a spinlock,
> with that eventually failing the IO despite the copy already done. But for a
> test device, I think that is acceptable.
This idea is garbage. That obviously would break data if invalid IOs are
requested (e.g. a non aligned write).
But doing the data copy (which may trigger allocation) *after* the locked zone
checks may actually work fine. Still scratching my head thinking potential problems.
>
> Any other idea ?
>
>
--
Damien Le Moal
Western Digital Research
