lkml.org 
[lkml]   [2013]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Yet another page fault deadlock
Date
Thanks for the remarks.

On 05/14/2013 01:32 PM, Ming Lei wrote:
> If the user buffer passed to driver A is mapped against file on the block
> device, single thread 1 may still deadlock on the mutex A.

Good point, thanks. It is unlikely to ever be a use case for us, but
still worth considering for the driver robustness.

> It can't be avoided 100% with the memset() workaround since the user
> buffer might be swapped out.

Yep. We have swap disabled though, so this should be fine as a temporary
workaround.

> Looks there are some similar examples, one of them is b31ca3f5df( sysfs:
> fix deadlock).
>
> ...
>
> Maybe it is good to document the lock usage, but the rule isn't much
> complicated: if one lock may be held under mmap_sem, the lock can't be
> held before copy_to/from_user(), :-)

Ok. I see it is a known pitfall. Still, it would be nice if people could
discover it not via a posteriori deadlocks debugging and lurking in list
archives. :)



\
 
 \ /
  Last update: 2013-05-14 18:21    [W:0.519 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site