Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Jan 2017 02:31:39 +0000
From:      Anindya Mukherjee <anindya49@hotmail.com>
To:        Benjamin Kaduk <kaduk@mit.edu>
Cc:        "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   RE: New Lock Order Reversal in 12.0?
Message-ID:  <BN6PR22MB08029DEFE472EAC32C9788B3B6640@BN6PR22MB0802.namprd22.prod.outlook.com>
In-Reply-To: <20170109004717.GE8460@kduck.kaduk.org>
References:  <BN6PR22MB0802636EB33644849ED4E151B6640@BN6PR22MB0802.namprd22.prod.outlook.com>, <20170109004717.GE8460@kduck.kaduk.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ben,

Thanks for your reply, and yes, I did notice #238. I should say at this poi=
nt that I'm a newbie when it comes to kernel code and am trying to learn ab=
out it (hence current).

The entry you refer to does look a bit like the one I've got, but I'm not t=
otally sure if the same code path is being followed to arrive at this LOR. =
An inode is being created in my case, vs a directory creation (entry + inod=
e probably) in #238, and then a sync is being attempted, which causes locks=
 to activate in the softdep code. I've read a bit about this from McCusick'=
s book but the details are still fuzzy.

Perhaps you are trying to tell me that it's benign? I know that WITNESS has=
 false positives, an example being #236 where due to shared vs exclusive vn=
ode locks required on the two ways to lock bufwait and dirhash a deadlock n=
ever happens.=20

Best,
Anindya
________________________________________
From: Benjamin Kaduk [kaduk@mit.edu]
Sent: January 8, 2017 4:47 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: New Lock Order Reversal in 12.0?

On Mon, Jan 09, 2017 at 12:32:28AM +0000, Anindya Mukherjee wrote:
> Hi, I'm running 12.0-current and noticed a LOR message from WITNESS which=
 I couldn't find a report about. I looked at http://sources.zabbadoz.net/fr=
eebsd/lor.html, among other places.
>
> system details:
> root@triskelion:~ # uname -a
> FreeBSD triskelion 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan =
 5 22:46:38 UTC 2017     root@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/=
GENERIC  amd64
> root@triskelion:~ # freebsd-version
> 12.0-CURRENT
>
>
> WITNESS report:
> lock order reversal:
>  1st 0xfffff8002e8049a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
>  2nd 0xfffffe01e7ce9b40 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnop=
s.c:277
>  3rd 0xfffff8002ec7b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
> stack backtrace:
> #0 0xffffffff80aa6fd0 at witness_debugger+0x70
> #1 0xffffffff80aa6ed3 at witness_checkorder+0xde3
> #2 0xffffffff80a20c15 at __lockmgr_args+0x725
> #3 0xffffffff80d06fc5 at ffs_lock+0xa5
> #4 0xffffffff8101c0c0 at VOP_LOCK1_APV+0xe0
> #5 0xffffffff80b1a6aa at _vn_lock+0x9a
> #6 0xffffffff80b0ac94 at vget+0x64
> #7 0xffffffff80afd19c at vfs_hash_get+0xcc
> #8 0xffffffff80d02e5e at ffs_vgetf+0x3e
> #9 0xffffffff80cf9787 at softdep_sync_buf+0xc37
> #10 0xffffffff80d07c51 at ffs_syncvnode+0x2a1
> #11 0xffffffff80d06e60 at ffs_fsync+0x20
> #12 0xffffffff8101b110 at VOP_FSYNC_APV+0xe0
> #13 0xffffffff80d0f2f0 at ufs_direnter+0x870
> #14 0xffffffff80d18050 at ufs_makeinode+0x5c0
> #15 0xffffffff80d13d7a at ufs_create+0x3a
> #16 0xffffffff810199ca at VOP_CREATE_APV+0xda
> #17 0xffffffff80b19f77 at vn_open_cred+0x2c7
>
> This is based on the FreeBSD-12.0-CURRENT-amd64-20170105-r311461-memstick=
.img installer. Known issue?

You do not think it looks like http://sources.zabbadoz.net/freebsd/lor/238.=
html ?

-Ben



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BN6PR22MB08029DEFE472EAC32C9788B3B6640>