On Fri, Feb 28, 2014 at 08:14:45PM -0500, Sasha Levin wrote:
Hi all,
I've stumbled on the following while fuzzing with trinity inside a
KVM tools running the latest -next kernel.
We deal with files that have an mmap op by giving them a different
locking class than the files which don't due to mmap_sem nesting
being different for those files.
We assume that for mmap supporting files, of->mutex will be nested
inside mm->mmap_sem. However, this is not always the case. Consider
the following:
kernfs_fop_write()
copy_from_user()
might_fault()
might_fault() suggests that we may lock mm->mmap_sem, which causes a
reverse lock nesting of mm->mmap_sem inside of of->mutex.
I'll send a patch to fix it some time next week unless someone beats me to it :)
How are you planning to fix it? Prolly the right thing to do would be
caching atomic_write_len in open_file and copy data before grabbing
any locks.