[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1512706738.18523.236.camel@codethink.co.uk>
Date: Fri, 08 Dec 2017 04:18:58 +0000
From: Ben Hutchings <ben.hutchings@...ethink.co.uk>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-kernel@...r.kernel.org
Cc: stable@...r.kernel.org, Benjamin Coddington <bcodding@...hat.com>,
Jeff Layton <jlayton@...hat.com>,
Trond Myklebust <trond.myklebust@...marydata.com>,
Sasha Levin <alexander.levin@...izon.com>
Subject: Re: [PATCH 4.4 29/49] nfs: Dont take a reference on fl->fl_file for
LOCK operation
On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Benjamin Coddington <bcodding@...hat.com>
>
>
> [ Upstream commit 4b09ec4b14a168bf2c687e1f598140c3c11e9222 ]
>
> I have reports of a crash that look like __fput() was called twice for
> a NFSv4.0 file. It seems possible that the state manager could try to
> reclaim a lock and take a reference on the fl->fl_file at the same time the
> file is being released if, during the close(), a signal interrupts the wait
> for outstanding IO while removing locks which then skips the removal
> of that lock.
>
> Since 83bfff23e9ed ("nfs4: have do_vfs_lock take an inode pointer") has
> removed the need to traverse fl->fl_file->f_inode in nfs4_lock_done(),
> taking that reference is no longer necessary.
[...]
No objection to this in 4.4, but that other commit only went into 4.2
so this fix doesn't look suitable for 3.18.
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
Powered by blists - more mailing lists