linux-kernel - Re: Yet another page fault deadlock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <kmtlsf$bjf$1@ger.gmane.org>
Date:	Tue, 14 May 2013 18:38:02 +0300
From:	Dmitry Maluka <D.Maluka@...global.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-mm@...ck.org
Subject: Re: Yet another page fault deadlock

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. :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/