So I have finished my investigation and suggest to discuss the simple
attaches patch.
With best regards,
On Fri, Mar 20, 2015 at 12:08 PM, Vitaly Chernooky <
vitalii.chernoo...@globallogic.com> wrote:
>
>
> On Fri, Mar 20, 2015 at 6:04 AM, Marek Marczykowski-Górecki <
> marma...@invisiblethingslab.com> 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.vra...@citrix.com>
>> > 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...
>> 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?
>>
>
> 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 :(((
>
> With best regards,
>
>
>> --
>> 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 <%2B380.44.4929695%20ext.1136>* M *+380.63.6011802
> <%2B380.63.6011802>* S cvv_2k
> www.globallogic.com
>
> http://www.globallogic.com/email_disclaimer.txt
>
--
*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
From f5f5922f389c0b6a2f0f912adf0c091ee97e0076 Mon Sep 17 00:00:00 2001
From: Vitaly Chernooky <vitaly.cherno...@globallogic.com>
Date: Fri, 20 Mar 2015 12:26:37 +0200
Subject: [PATCH] Fix deadlock on regular nonseekable files
It is actual for proc-like pseudo filesystems which mark their files as
regular but nonseekable.
Change-Id: I92f4da22a5835cc6b6396988c36b5906561ac741
Signed-off-by: Vitaly Chernooky <vitaly.cherno...@globallogic.com>
---
fs/open.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/open.c b/fs/open.c
index 2ed7325..b792784 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1100,7 +1100,7 @@ EXPORT_SYMBOL(generic_file_open);
*/
int nonseekable_open(struct inode *inode, struct file *filp)
{
- filp->f_mode &= ~(FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE);
+ filp->f_mode &= ~(FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE | FMODE_ATOMIC_POS);
return 0;
}
--
1.7.9.5
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
