On 7/8/19 7:14 AM, Mike Snitzer wrote:
On Fri, Jul 05 2019 at 4:24pm -0400,
Junxiao Bi <junxiao.bi@xxxxxxxxxx> wrote:
Hi Mike,
Do i make sense on this?
No, you haven't made your chase for this change. Sorry.
Please refine the patch header to _not_ get into context you have from
a vendor kernel. I know you say this is hard to reproduce, etc.
Thanks, I will refine it in v2.
But
you don't even get into ther usecase where the issue was seen. Was this
DM thinp? DM cache? Something else?
it's thin-provision target. Customer is using docker.
Please be as concise and precise as possible. Saying that shrinker is
the same context as loop doesn't imply a whole lot to me (relative to
why this is prone to deadlock).
To restate my concern: if __GFP_FS isn't set then why does your patch
help at all? If __GFP_FS is set, then that changes things..
If __GFP_FS isn't set, the behavior is the same with w/o this patch. If
it is set and the mutex was already hold by others, shrinker stop,
deadlock avoid.
Thanks,
Junxiao.
Mike
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
