Re: [GIT PULL] please pull file-locking related changes for v3.20

[Jeff Layton]

On Mon, 16 Feb 2015 15:32:00 +0200
"Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx> wrote:

> On Mon, Feb 09, 2015 at 05:55:40AM -0500, Jeff Layton wrote:
> > The following changes since commit cb59670870d90ff8bc31f5f2efc407c6fe4938c0:
> > 
> >   Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse (2015-01-16 14:58:16 +1300)
> > 
> > are available in the git repository at:
> > 
> >   git://git.samba.org/jlayton/linux.git tags/locks-v3.20-1
> > 
> > for you to fetch changes up to 8116bf4cb62d337c953cfa5369ef4cf83e73140c:
> > 
> >   locks: update comments that refer to inode->i_flock (2015-01-21 20:44:01 -0500)
> > 
> > ----------------------------------------------------------------
> > File locking related changes for v3.20 (pile #1)
> > 
> > This patchset contains a fairly major overhaul of how file locks are
> > tracked within the inode. Rather than a single list, we now create a
> > per-inode "lock context" that contains individual lists for the file
> > locks, and a new dedicated spinlock for them.
> > 
> > There are changes in other trees that are based on top of this set so
> > it may be easiest to pull this in early.
> 
> The warning below is triggered on exit from trinity by ctrl-c. I saw it
> few times.
> 
> [  733.480323] ------------[ cut here ]------------
> [  733.480985] WARNING: CPU: 1 PID: 24375 at /home/kas/git/public/linux-next/fs/locks.c:243 locks_free_lock_context+0x6a/0xd0()
> [  733.482393] Modules linked in:
> [  733.482807] CPU: 1 PID: 24375 Comm: trinity-main Not tainted 3.19.0-next-20150212-00024-g8d751e144a78-dirty #641
> [  733.484108] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
> [  733.485713]  ffffffff81c9c150 ffff88084b88bc88 ffffffff81883d17 0000000000000007
> [  733.486708]  0000000000000000 ffff88084b88bcc8 ffffffff81054eca ffff88007a31dc30
> [  733.487701]  ffff88007060fda0 ffff88007a31dc30 ffffffff81a27940 ffff88007a31dc30
> [  733.488695] Call Trace:
> [  733.489017]  [<ffffffff81883d17>] dump_stack+0x4f/0x7b
> [  733.489678]  [<ffffffff81054eca>] warn_slowpath_common+0x8a/0xc0
> [  733.490431]  [<ffffffff81054fba>] warn_slowpath_null+0x1a/0x20
> [  733.491165]  [<ffffffff8122d74a>] locks_free_lock_context+0x6a/0xd0
> [  733.491959]  [<ffffffff811f1ba2>] __destroy_inode+0x32/0xe0
> [  733.492715]  [<ffffffff811f3006>] destroy_inode+0x26/0x70
> [  733.493394]  [<ffffffff811f3162>] evict+0x112/0x1a0
> [  733.494026]  [<ffffffff811f3d1e>] iput+0x2be/0x3d0
> [  733.494635]  [<ffffffff811ee480>] __dentry_kill+0x190/0x200
> [  733.495341]  [<ffffffff811ee88b>] dput+0x39b/0x3d0
> [  733.495946]  [<ffffffff811ee519>] ? dput+0x29/0x3d0
> [  733.496581]  [<ffffffff811d618c>] __fput+0x14c/0x220
> [  733.497218]  [<ffffffff811d62ae>] ____fput+0xe/0x10
> [  733.497847]  [<ffffffff810785e4>] task_work_run+0xb4/0xe0
> [  733.498532]  [<ffffffff810586ce>] do_exit+0x36e/0xd60
> [  733.499175]  [<ffffffff8188e5d1>] ? retint_swapgs+0xe/0x44
> [  733.499868]  [<ffffffff8143ce13>] ? __this_cpu_preempt_check+0x13/0x20
> [  733.500695]  [<ffffffff81059164>] do_group_exit+0x54/0xe0
> [  733.501388]  [<ffffffff81059204>] SyS_exit_group+0x14/0x20
> [  733.502080]  [<ffffffff8188da12>] system_call_fastpath+0x12/0x17
> [  733.502874] ---[ end trace bcc1a9752062721f ]---
> 

Thanks Kirill.

This looks similar to the problem that Sasha Levin reported when I had
this in linux-next. Basically, we're tearing down the i_flctx when
tearing down the inode, but the i_flock list isn't empty.

Most likely what happened is that we had a flock lock race onto the
inode around the same time that locks_remove_file was called for the
file.  Moving the setting of i_flctx under the i_lock seemed to resolve
it before for Sasha, but I think that this shows that that's not 100%
sufficient.

So I suspect we have either a cache-coherency problem where the cpu
running locks_remove_file doesn't realize that the i_flctx was recently
set, or there's something wrong with the fget/fput machinery. Probably
the former.

I'll look at it  again and also see if I can reproduce it with trinity.
So far, I haven't been able to, but maybe I'll get lucky this time.

Thanks,
-- 
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/