Message-ID: <CANZZXhCjaKijvGUBP+UYC8_BkKsFiY_XoRgB873_VnPfuPA+2Q@mail.gmail.com>
Date:	Fri, 20 Mar 2015 19:37:58 +0200
From:	Vitaly Chernooky <vitalii.chernookyi@...ballogic.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Marek Marczykowski-Górecki 
	<marmarek@...isiblethingslab.com>,
	Iurii Konovalenko <iurii.konovalenko@...ballogic.com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Andrii Anisov <andrii.anisov@...ballogic.com>,
	Artem Mygaiev <artem.mygaiev@...ballogic.com>
Subject: Re: [PATCH] [RFC] Fix deadlock on regular nonseekable files

> What does it have to do with filesystem type involved?

Discussed trouble directly depends on is it used nonseekable_open() in
fs driver or not. Regular fss like ext4 does not use
nonseekable_open() so there is no troubles. But others like ubifs,
debugfs, fuse and xenfs use it and are affected by discussed
regression.

> Then basically they are asking to waive XSI 2.9.7 for that file - behaviour
> *is* required by POSIX.

Yes, but in steps to follow XSI 2.9.7 we were not enough meticulous
and had broken things which are *out of scope of XSI 2.9.7* and are
subject for other standards.

So, in steps to create files broken filesystems do something like it:

res = finish_open(file, dentry, nonseekable_open, &opened);

Let's to look what happen during this call:

1. we call do_dentry_open(file, open, current_cred())
2. f->f_mode = OPEN_FMODE(f->f_flags) | FMODE_LSEEK |
                FMODE_PREAD | FMODE_PWRITE;
3. Let's to mention FMODE_LSEEK above.
4. if (S_ISREG(inode->i_mode))
        f->f_mode |= FMODE_ATOMIC_POS;
5. Yes, above we do right things because our file is *regular* and we
want to follow XSI 2.9.7 for *regular* files.
6. error = open(inode, f);
7. In line above by fact we call nonseekable_open()
8. filp->f_mode &= ~(FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE);
9. Let's stop here and mention than in line above we clear FMODE_LSEEK
bit for *regular* files. So we have got *regular* file without
FMODE_LSEEK. But:

- IEEE Std 1003.1, 2013 Edition,
- ISO/IEC 9945-1: 1996 (E) and 1003.1, 1996 Edition,

and few other standards declare than files with cleared FMODE_LSEEK
*is not* regular. I do not know who, when and why has introduced this
mess. It is pre-git historical code. And now by introducing
FMODE_ATOMIC_POS we change behavior of this mature practice and affect
at least few filesystems. Yes, following standards is good, but I do
not accept than breaking mature code is good idea. So I have chosen to
clear FMODE_ATOMIC_POS in nonseekable_open() simultaneously with
FMODE_LSEEK because it returns that nonseekable semi-standard files
back to life. I guess, it is the best solution for now. And, also, XEN
guys are happy with this solution.

So what do you think about all this mess and may be it is possible to
have got better solution?

I apologize for this long and confuses explanation :(

With best regards,

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists