From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier) Date: Fri, 20 Mar 2015 11:41:52 +0100 Message-ID: <20150320104152.GB2321@mail-itl> References: <20150319011911.GA29029@mail-itl> <1426761512.610.18.camel@citrix.com> <550AC883.40008@citrix.com> <20150320040454.GZ2321@mail-itl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3531640527853802307==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vitaly Chernooky Cc: Iurii Konovalenko , Ian Campbell , xen-devel , Embedded-pv-devel@lists.xenproject.org, David Vrabel , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org --===============3531640527853802307== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VKLB3BcClAS4nArB" Content-Disposition: inline --VKLB3BcClAS4nArB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 20, 2015 at 12:08:48PM +0200, Vitaly Chernooky wrote: > On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-G=C3=B3recki < > marmarek@invisiblethingslab.com> wrote: >=20 > > On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote: > > > David, > > > > > > On Thu, Mar 19, 2015 at 3:00 PM, David Vrabel > > > wrote: > > > > > > > On 19/03/15 12:10, Iurii Konovalenko wrote: > > > > > Hi, guys! > > > > > > > > > > When I read, that I am not alone and that issue depends on kernel > > > > > version, I decided to continue investigation. > > > > > And I found why our threads locks on read/write operations. > > > > > On Linux kernel 3.14+ syscalls of file read and write changed a b= it: > > > > > fdget() function was replaced by fdget_pos() - it is fdget() func= tion > > > > > plus additional position mutex lock for files with FMODE_ATOMIC_P= OS > > > > > (files for inodes with S_IFREG flag set - regular nodes). As I > > thought > > > > > our xen files are not regular and nonseekable, I hoped this flag = is > > > > > not set. But it is set. It is because our file system is created = by > > > > > function simple_fill_super(), and inside it this flag is hardly s= et: > > > > > inode->i_mode =3D S_IFREG | files->mode; > > > > > So, as a fast hack I made a patch: just made copy of this function > > for > > > > > xen, which does not set this flag. It works for me. Could you ple= ase > > > > > check if it works for you. > > > > > > > > I still can't get this to deadlock, but why not clear FMODE_ATOMIC_= POS > > > > in xenbus_file_open() ? > > > > > > > > > > Because it is not the root of issue. FMODE_ATOMIC_POS is just one of > > > results of bug. Iurii has fixed the root of issue but in suboptimal w= ay. > > So > > > we just need to have found optimal way. > > > > I can just confirm that: > > 1. (unsurprisingly) the bug is still present in 4.0-rc4 > > 2. both proposed fixes are effective > > > > I'm not sure if removing S_IFREG completely is a good idea, I guess > > there will be much more side effects... > > What about another idea: xenbus_file_open uses nonseekable_open - this > > looks like a good place to clear FMODE_ATOMIC_POS if present? It > > doesn't make sense to get a lock for position on nonseekable file, > > right? > > >=20 > The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition > requires from regular files to be seekable. But Linux kernel looks like > Linus has own opinion on it :((( Maybe the better idea would be to change filetype of xenbus (and others) to S_IFIFO or something like this (but keep the file type present, instead of removing it completely). Regarding the implementation, maybe simple_fill_super can be modified to not add S_IFREG if other file type is already present in files->mode? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --VKLB3BcClAS4nArB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVC/lwAAoJENuP0xzK19csH54H/jSO6xm6pY+bGiwJ9vnbh72p yd2oDsIqJrO6r25ym6rLvn8mmzCIDuutvdXCFJtT5nFERYbhvjVsdxGCLtXVh4KR /FOcGLyOE6KCdRYGvQft62CO7zWQuf6/iZGUqgGfJoJ9yHAbQ9N951dqKSh9AXUU Gslck1rHI+XmebOwampe9qCqehU2JvaPNzX1oYA3bhNmQ0Ril8OxGzJgqw6V1cof dnbAumDgA0BA1YSdUPCTiQF0vxDkRnsJm6Re3SF+olJrnJZyQVTtFMZyr/18F5Rg B19q7RoLtgUUq0tHKjEl24fym2Or+hSEaoTWHPNOqtVWhvi0bVHvVCPR7rowGQ4= =EZAN -----END PGP SIGNATURE----- --VKLB3BcClAS4nArB-- --===============3531640527853802307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3531640527853802307==--