On Mon, Feb 12, 2018 at 05:01:25PM -0800, Joel Fernandes wrote: > ashmem_mutex create a chain of dependencies like so: > > (1) > mmap syscall -> > mmap_sem -> (acquired) > ashmem_mmap > ashmem_mutex (try to acquire) > (block) > > (2) > llseek syscall -> > ashmem_llseek -> > ashmem_mutex -> (acquired) > inode_lock -> > inode->i_rwsem (try to acquire) > (block) > > (3) > getdents -> > iterate_dir -> > inode_lock -> > inode->i_rwsem (acquired) > copy_to_user -> > mmap_sem (try to acquire) > > There is a lock ordering created between mmap_sem and inode->i_rwsem > causing a lockdep splat [2] during a syzcaller test, this patch fixes > the issue by unlocking the mutex earlier. Functionally that's Ok since > we don't need to protect vfs_llseek. > > [1] https://patchwork.kernel.org/patch/10185031/ > [2] https://lkml.org/lkml/2018/1/10/48 > > Cc: Todd Kjos <[email protected]> > Cc: Arve Hjonnevag <[email protected]> > Cc: Greg Hackmann <[email protected]> > Cc: Greg Kroah-Hartman <[email protected]> > Cc: [email protected] > Reported-by: [email protected] > Signed-off-by: Joel Fernandes <[email protected]> > --- > drivers/staging/android/ashmem.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-)
Please always properly version your patches, and put what changed below the --- line, so I have a hint as to which patch to apply. Documentation/SubmittingPatches has the full details of how to do this. Can you resend me the "latest" version of this patch, so I have a chance of getting it right? :) thanks, greg k-h
