From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <viro@ftp.linux.org.uk>
X-Google-Smtp-Source: AG47ELvqY7VJSsYqDmeWNf4d8JmWXWROA2ceHB/MAlDkWzQNrBFVabFT9gOq5kZ413kR4WcOfiH4
ARC-Seal: i=1; a=rsa-sha256; t=1521299152; cv=none;
        d=google.com; s=arc-20160816;
        b=XGzzvy1+igxDxY6cqIqhVU3ob1aCdBbQAn03UTni/ih8g0oU5iNAddYfJjeIT3VNwc
         MS6JWzYxQLUbkiZt0jrznkEEjcDDtglyao+CnyId2xB5w13isIWSD0Eh5qC1+dmbn0wb
         VxxtqtlQ53ZTc8wzgQl3FH0R1Xkgj17Ap2x8fT1/v4UgzyT7dwArcXtAzLgKHM2zr7e3
         aybSWZsXXIYHMz/e5Szu3VubB4AS1j5rY2E0Zk0cNpHwWFdDuFtqsjVLBkV4AK83oxLF
         BU6jtzbQlAbdiKWB0FMyST4QDUuwT+1OLgdmVlhU50GEZgeMlOEVobYHtaPtq67z9VJp
         YZkQ==
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=b00DHk0Sk1M0gzFDjz/DkGnlT05Q+ixNa0D3IA5Fqlk=;
        b=AavDdvSxNzCliyxWXgNUgWoDL2F+1l5XEJ9C4aotpdUEkElIb/5zdeareqHiw2dihE
         dOmpukg6dCjFD51WDF/DOJ6fmYkEVHg86nf2dxwjhPY9L1H4A0BPqPkhqNJmspcmZ6J9
         DUFcFp+Za6I9nSfXCzoOpTWlVC2OsGOWjNbRUHCnVW6mj9yBr6W50nWIB67zj8LYLRCK
         pqh+QG/Iqz65/K0v2bVVqCo2i29IUXReWP+kEp9YXqyw08EV0TK+qS0eh4J0KHYzpkhg
         +I0qEURY1WfViLGqazQHFbY8AMKAyah+g/jPpa0tWpQjos1QECTblmZ7knDXKdSCuX1d
         Xk7Q==
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: Sat, 17 Mar 2018 15:05:34 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jeff Layton <jlayton@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Daniel P =?iso-8859-1?Q?=2E_Berrang=E9?= <berrange@redhat.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] locks: change POSIX lock ownership on execve when
 files_struct is displaced
Message-ID: <20180317150533.GM30522@ZenIV.linux.org.uk>
References: <20180317142520.30520-1-jlayton@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180317142520.30520-1-jlayton@kernel.org>
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?1595195233416759536?=
X-GMAIL-MSGID: =?utf-8?q?1595197779271285350?=
X-Mailing-List: linux-kernel@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>

On Sat, Mar 17, 2018 at 10:25:20AM -0400, Jeff Layton wrote:
> From: Jeff Layton <jlayton@redhat.com>
> 
> POSIX mandates that open fds and their associated file locks should be
> preserved across an execve. This works, unless the process is
> multithreaded at the time that execve is called.
> 
> In that case, we'll end up unsharing the files_struct but the locks will
> still have their fl_owner set to the address of the old one. Eventually,
> when the other threads die and the last reference to the old
> files_struct is put, any POSIX locks get torn down since it looks like
> a close occurred on them.
> 
> The result is that all of your open files will be intact with none of
> the locks you held before execve. The simple answer to this is "use OFD
> locks", but this is a nasty surprise and it violates the spec.
> 
> On a successful execve, change ownership of any POSIX file_locks
> associated with the old files_struct to the new one, if we ended up
> swapping it out.

TBH, I don't like the way you implement that.  Why not simply use
iterate_fd()?