Re: [PATCH] ashmem: Fix lockdep issue during llseek

From: Al Viro
Date: Thu Jan 25 2018 - 22:13:53 EST


On Thu, Jan 25, 2018 at 06:46:49PM -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
> during a syzcaller test, this patch fixes the issue by releasing the
> ashmem_mutex before the call to vfs_llseek, and reacquiring it after.

That looks odd. If this approach works, what the hell do you need
ashmem_mutex for in ashmem_llseek() in the first place? What is
it protecting there?