[dm-devel] dm: use noio when sending kobject event

Mike Snitzer snitzer at redhat.com
Wed Jul 8 17:33:56 UTC 2020


On Wed, Jul 08 2020 at  2:26pm -0400,
Gabriel Krisman Bertazi <krisman at collabora.com> wrote:

> Mikulas Patocka <mpatocka at redhat.com> writes:
> 
> > kobject_uevent may allocate memory and it may be called while there are dm
> > devices suspended. The allocation may recurse into a suspended device,
> > causing a deadlock. We must set the noio flag when sending a uevent.
> 
> If I understand it correctly, considering the deadlock you shared, this
> doesn't solve the entire issue. For instance, kobject_uevent_env on the
> GFP_NOIO thread waits on uevent_sock_mutex, and another thread with
> GFP_IO holding the mutex might have triggered the shrinker from inside
> kobject_uevent_net_broadcast.  I believe 7e7cd796f277 ("scsi: iscsi: Fix
> deadlock on recovery path during GFP_IO reclaim") solved the one you
> shared and other similar cases for iSCSI in a different way.

I staged a different fix, from Mikulas, for 5.9 that is meant to address
the original report, please see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.9&id=e5bfe9baf23dca211f4b794b651e871032c427ec

I'd appreciate it if you could try this commit to se if it fixes the
original issue you reported.

> I know this is similar to the log I shared on an earlier patch. Are you
> able to reproduce the deadlock with the above patch applied?

Mikulas seized on the fact that the backtrace shows the uevent upcall
to have occurred while suspending.  I know he didn't reproduce your
issue.

> That said, I think this patch is an improvement as we shouldn't be using
> GFP_IO in this path to begin with, so please add:
> 
> Reviewed-by: Gabriel Krisman Bertazi <krisman at collabora.com>

FYI, whilee I do appreciate your Reviewed-by I already staged this for
5.8 so I'd rather not rebase to add your Reviewed-by, see:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.8&id=6958c1c640af8c3f40fa8a2eee3b5b905d95b677

Thanks,
Mike




More information about the dm-devel mailing list