On 11/08/2019 10:22 AM, 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"? > > 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 Observed. > 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? A common use is tcm loop on the frontend and tcmu on the backend. You see this with virt and containers, where some app is used to interacting SCSI devices, but then the storage is backed by something that people didn't want to put in the kernel. It's similar to nbd when you use AF_UNIX sockets with a local running daemon.
