On 2019/11/09 1:22, Bart Van Assche wrote: > On 11/8/19 12:29 AM, Damien Le Moal wrote: >> Prevent recursion into the IO path under low memory conditions by using >> GFP_NOIO in place of GFP_KERNEL when allocating a new command with >> tcmu_alloc_cmd() and user ring space with tcmu_get_empty_block(). >> >> Reported-by: Masato Suzuki <masato.suzuki@xxxxxxx> >> Signed-off-by: Damien Le Moal <damien.lemoal@xxxxxxx> >> --- >> >> Changes from v1: >> * Added reported-by tag >> >> drivers/target/target_core_user.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) > > The patch subject is weird. Shouldn't the patch subject start with > "tcmu" instead of "target: core"? I was not sure what to put there since the file being touched is target_core_user.c (it has both core and user). May be "target: user" is better ? Martin, Please let me know if you want me to resend with a fixed header (and what that header should be). > Has the recursion mentioned in the patch description been observed or is > this a theoretical issue? I'm asking this because GFP_NOIO only prevents > recursion if it is used inside a block driver or filesystem. The tcmu > driver is neither - it submits block I/O or filesystem I/O instead of > implementing a block driver or filesystem. Should we really disallow > tcmu to use the swap subsystem? As Mike confirmed already, the problem was observed and actually fairly easy to recreate. Our go-to setup to test this is: fio->XFS->dm-zoned->tcmu-runner ZBC handler (emulated ZBC drive)->ext4->regular disk. Without this patch and Mike's proposed prctl() patch adding NOIO through prctl() in tcmu-runner context, memory reclaim recursions causing deadlocks are triggered very quickly. > > Thanks, > > Bart. > > -- Damien Le Moal Western Digital Research
