Xen project Mailing List

On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-GÃrecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:

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 <david.vrabel@xxxxxxxxxx>
> 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 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 = 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() ?
> >
>
> 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...

Hm... Usually nobody expect regular files to be nonseekable, but ...

Yes, I am going to recheck it twice in the nearest future.

What about another idea: xenbus_file_open uses nonseekable_open - this
looks like a good place to clear FMODE_ATOMIC_POS if present?

It is wrong place to clear ÂFMODE_ATOMIC_POS but something in your idea is right.

It
doesn't make sense to get a lock for position on nonseekable file,
right?

Usually :)

--
Best Regards,
Marek Marczykowski-GÃrecki
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?

Vitaly Chernooky |ÂSenior Developer - Product Engineering and Development

GlobalLogic

P +380.44.4929695 ext.1136 M +380.63.6011802ÂS cvv_2k

www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt

Re: [Embedded-pv-devel] [Xen-devel] Deadlock in /proc/xen/xenbus watch+read on 3.17+ (maybe earlier)