Messages in this thread | | | Date | Thu, 22 Feb 2018 14:48:32 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH v2] staging: android: ashmem: Fix lockdep issue during llseek |
| |
On Fri, Feb 16, 2018 at 11:02:01AM -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 <tkjos@google.com> > Cc: Arve Hjonnevag <arve@android.com> > Cc: Greg Hackmann <ghackmann@google.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: stable@vger.kernel.org > Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com > Signed-off-by: Joel Fernandes <joelaf@google.com> > --- > Changes since first version: > Don't relock after vfs call since its not needed. Only reason we lock is > to protect races with asma->file. > https://patchwork.kernel.org/patch/10185031/
I'd like some acks from others before I take this patch.
Joel, did the original reporter say this patch solved their issue or not? For some reason I didn't think it worked properly...
thanks,
greg k-h
| |