On Mon, 2012-07-23 at 21:26 +0900, sf...@users.sourceforge.net wrote: > Ben Hutchings: > > do_mmap_pgoff() /* The caller must hold down_write(¤t->mm->mmap_sem) = > > */ > > -> get_unmapped_area() -> security_mmap_addr() > ::: > > Thanks. > And I am sorry. I was confused. > I have to correct the orders of security_mmap_addr() and ..._file() and > mmap_sem, which is > ..._file() is called BEFORE mmap_sem > and .._addr() is AFTER. > > But the conclusion about the ..._file() call in aufs_mmap() is > unchanged. As long as ..._file() should be called out of mmap_sem, > delegating to kworker is necessary I think.
If the LSM mmap_addr callback needs to acquire mmap_sem then it will be
using the wrong mm context, so this doesn't fix the problem. If it
needs to acquire a lock that's higher in the lock hierarchy than
mmap_sem then I think an AB-BA deadlock is still possible. Given two
threads in the same process:
Thread 1 Thread 2 kworker
---------------------------------------------------------
mmap()
acquire L
acquire mmap_sem
acquire mmap_sem
[blocked]
schedule work
wait for work
[blocked]
security_mmap_file()
acquire L [blocked]
If there is no lock higher than mmap_sem that might be used in this way,
then there is no problem and there is also no need for using the
workqueue.
> Do you have any other better approach?
> Or do you think it is good to modify mm/*.c?
Ugh...
Ben.
--
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
