[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