From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viro@ftp.linux.org.uk>
X-Google-Smtp-Source: AH8x224/qvohTDux/HUi6+t7cWpLsBdDtd1orTq/pbs12obOA5hX9JuJBh7oJH55KfoJlnDp6KzM
ARC-Seal: i=1; a=rsa-sha256; t=1516936429; cv=none;
        d=google.com; s=arc-20160816;
        b=CL3g6TPoly9BFtlUzHo3y+zRGIt1EYEJtminzhcflb+Fr24HnbHl2Cn25QT8UfKVD1
         pLc0xXeU3rzTKjpBcT3ig9Ag9C126yBvi2PmTRCp2TocWawVugNdloyiDIde57hNU+SU
         VuHZ1q4+q2Uzxasw0r6WI3W36LZa7sg+CKRgWCJl1Nn4TvUGZ5K5en/MJoMbW8yHTjtR
         zXUJekaQ7vRak5VxKLh0I+FepkF6XA4xpChgbwXEliKRnz9Lx70ssWDofSGyv5noo8RA
         2TVNhqZuBR2sNmUddo72UvbX1seMq7t3v7xaQwDGiHohgCkMllsoeEwI1RXM6WnZUeab
         gYbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=sender:user-agent:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date
         :arc-authentication-results;
        bh=S2QuTkAmQ9+qRbKr5R91mGjEcYog5jYttG/QRiqa2m0=;
        b=PeJsvMsiWTxA/2/GGrsFKeENDN78vDLsosRmuXtBxVu2HIbikjkgYZxwFS0gCnEyla
         zhbf4P+5ZwB/38qYoaG+qaXsiMzGVIdf6tVQcjrPYNIrwrTxtPRaXaqZo6pSUdCNIVVt
         HFKGhnUBS6J7UaWPZ3TMhajkA0NvF+nYrJNnxG5qYa+YcoEEUZOr+98dusovMiNT+EX/
         y7oo7hP1082jLtZsFgnEJE/dBIrpOcody13plmkU1Ci03ZI1X3hjw6Co6bNxFg3gq14y
         36qx4rORJGz7yH6CRmweZzOjxUh4b5lC4uDGeqqxRhs/CoSeJgjeXenggIvV45zKFQuO
         oBuw==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: best guess record for domain of viro@ftp.linux.org.uk designates 195.92.253.2 as permitted sender) smtp.mailfrom=viro@ftp.linux.org.uk
Authentication-Results: mx.google.com;
       spf=pass (google.com: best guess record for domain of viro@ftp.linux.org.uk designates 195.92.253.2 as permitted sender) smtp.mailfrom=viro@ftp.linux.org.uk
Date: Fri, 26 Jan 2018 03:13:46 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joel Fernandes <joelaf@google.com>
Cc: linux-kernel@vger.kernel.org, Todd Kjos <tkjos@google.com>,
	Arve Hjonnevag <arve@android.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] ashmem: Fix lockdep issue during llseek
Message-ID: <20180126031346.GW13338@ZenIV.linux.org.uk>
References: <20180126024649.200330-1-joelaf@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180126024649.200330-1-joelaf@google.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: Al Viro <viro@ftp.linux.org.uk>
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: =?utf-8?q?1590621447299099171?=
X-GMAIL-MSGID: =?utf-8?q?1590623133188406326?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

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?