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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
