From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viro@ftp.linux.org.uk>
X-Google-Smtp-Source: AH8x226TKn3FSXhjTltMKmifnN3NxKRxhPpixlLCLhUI1rVHACLoyLF7k/jWw4YOeTc2YprFg4hW
ARC-Seal: i=1; a=rsa-sha256; t=1516995597; cv=none;
        d=google.com; s=arc-20160816;
        b=vn8WgTSm2p5J5OdZtWm30zneuq5AxLuzBAUTty86oiGMLzv/rJRO+p+mBhe9/jUYNF
         RkUORHT4X+6g9PApCrk5NKXogaOrzzVOnl9NPZRaLfsJu6kOB9Df168oUL7KkKHgcrIg
         28N1HeFKvu53QnuwbBF310f4Hj1OWv26lDNiBHGPPhtPOZGGUij72vDkW7qdnXZOeAiI
         MIRfsCX0gsSg6nr1ifZUVnG3Qx9nMNZJSbQ1DJV/BT0C4jS4EA5sdQvAGTqc5MhynuR2
         9Uo0nHznRO7B4dQun/PQUX6r7ozmqGrzU+ZsmEUX688AhE0gBTMc2LGznBgqnSylQkpH
         77Eg==
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=ZW2TMCUWVHqFwEbXC2C6FtFRu5XjC57/qGPRqsce1+I=;
        b=sLSu3uczcxntr1NUspJeWpd9KX8YQi2JnQ5oOPIwlsjYXjVLO/B2Hx7Nh5ZulhXcVy
         hKObBzNkxhIdeiVWuvLin2aF6Brl6I+dAhsql1pOdo1Ijkk4lRHjFt3H7VYs25cNtc7E
         x0Mf68HTRdRnrpDMrq9t32eG5AnT7L9WmMG4v4AwITgEImUnYOgOv0BkQc9041cR3tUc
         gRFeN8mUWIurD4VvrsP1CQUxt7TAMDQP9jhDD67NldvMjvSK2h3ezTJZFYaYTp4jMEcE
         /Z4K4Fzqk5ETJSYLmPiqA5juu0i4fdR/oeyYpMBrfT3+CX8rjaDf1bxK45WMwTBEypQB
         k6FQ==
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 19:39:55 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Joel Fernandes <joelaf@google.com>
Cc: LKML <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: <20180126193954.GB13338@ZenIV.linux.org.uk>
References: <20180126024649.200330-1-joelaf@google.com>
 <20180126031346.GW13338@ZenIV.linux.org.uk>
 <CAJWu+oo+Y4eNTX+vMceYTB-FF5A190OHP7yPKkDGYH-jTqSsmQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJWu+oo+Y4eNTX+vMceYTB-FF5A190OHP7yPKkDGYH-jTqSsmQ@mail.gmail.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?1590685175109156734?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On Fri, Jan 26, 2018 at 11:23:47AM -0800, Joel Fernandes wrote:

> I was just trying to be careful with the least intrusive solution
> since I'm not the original author of the driver.

Sure, but that needs a proof that it *is* a solution...

> But one usecase for the mutex is with concurrent lseeks, you can end
> up with a file->f_pos that is different from the latest update to
> asma->file->f_pos. A barrier could fix this it too though. Any
> thoughts?

lseek(2) is serialized against lseek(2) and read(2) on the same struct
file - see fdget_pos() for details.

ashmem_mutex really does look like an overkill - something much lighter
should serve just fine...