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 05:04:54 +0100 Message-ID: <20150320040454.GZ2321@mail-itl> References: <20150319011911.GA29029@mail-itl> <1426761512.610.18.camel@citrix.com> <550AC883.40008@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3448224351784865257==" 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 --===============3448224351784865257== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U7PH6YjyT5379uVx" Content-Disposition: inline --U7PH6YjyT5379uVx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 19, 2015 at 03:10:49PM +0200, Vitaly Chernooky wrote: > David, >=20 > On Thu, Mar 19, 2015 at 3:00 PM, David Vrabel > wrote: >=20 > > 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 bit: > > > fdget() function was replaced by fdget_pos() - it is fdget() function > > > plus additional position mutex lock for files with FMODE_ATOMIC_POS > > > (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 set: > > > 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 please > > > 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() ? > > >=20 > 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 way. = 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 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? --U7PH6YjyT5379uVx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVC5xmAAoJENuP0xzK19csXZAH/0oPeVaIGttKOc9FGz8lfxZK 6QCRQgzdsXtwq8QKbZnkrQel4eWQ/nT7TJNa8nAT7sYDG+TvOFx0dXu0E8KBerR2 rwW0GtkXgLy9tX5nOFryEqG6A91W+ExeKfYkVe4qa3XXYX2poJgHGhhLGNO7qMrz K/Njd2m4tHPoGottA6idTGSw5zIrx2mZldDANx9luV78YWYidGI6JNI8EqxNQCt+ fwm+2Xke86oyapDfHTLGLILM7D0inZ0QeIa4+eyzwiXupi/JlfZ2aBPKICnt7PM+ 2gIMDpK+/JGOlp3/Dhl4Bw5K2mnVWZRQErmSSWxg1KUUxfLSWGOhvwWvqrhy8sU= =SDgX -----END PGP SIGNATURE----- --U7PH6YjyT5379uVx-- --===============3448224351784865257== 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 --===============3448224351784865257==--