[git pull] vfs.git part 2

2017-07-05 Thread Al Viro
Consolidating sys_wait* and compat counterparts. Gets rid of set_fs()/double-copy mess, simplifies the whole thing (lifting the copyouts to the syscalls means less headache in the part that does actual work - fewer failure exits, to start with), gets rid of the overhead of field-by-field _

Re: [git pull] vfs.git part 2

2013-07-15 Thread Rasmus Villemoes
Linus Torvalds writes: > On Fri, Jul 12, 2013 at 12:39 PM, Al Viro wrote: >> >> [suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE; >> that will fail on old kernels in a lot more cases than what I came up with. > > So see earlier about why I'm not convinced about O_RDWR.

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 01:21:07PM -0700, Linus Torvalds wrote: > So you could have something like > > #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY | O_RDWR) > #define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT | O_ACCMODE) > > and then use > >if ((flags & O_TMPFILE_MASK) != O_T

Re: [git pull] vfs.git part 2

2013-07-12 Thread Linus Torvalds
On Fri, Jul 12, 2013 at 12:39 PM, Al Viro wrote: > > I mean something like this: > > Safer ABI for O_TMPFILE > > [suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE; > that will fail on old kernels in a lot more cases than what I came up with. So see earlier about why I'm

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 12:42:15PM -0700, Linus Torvalds wrote: > As to the mode argument: we should encourage people to have it, since > the inode *may* become visible afterwards. See above (can you do > linkat() to just turn an fd into a name? I didn't really check, but I > think you can do it a

Re: [git pull] vfs.git part 2

2013-07-12 Thread Linus Torvalds
On Fri, Jul 12, 2013 at 12:13 PM, Al Viro wrote: > On Fri, Jul 12, 2013 at 04:30:45PM +, Rasmus Villemoes wrote: >> >> How about simply making O_TMPFILE == O_DIRECTORY | O_RDWR | >> O_TMPFILE_INTERNAL, and letting the correct use be >> >> open("/some/dir", O_TMPFILE) [with or without a mode ar

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 08:13:21PM +0100, Al Viro wrote: > > Using O_DIRECTORY when we don't want to open a directory, and omitting > > O_CREAT when we do want to create something new, is somewhat > > counter-intuitive, but I think this would solve the problem with old > > kernels. > > Hrm... I

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 04:30:45PM +, Rasmus Villemoes wrote: > >> Just thinking out loud, and please tell me to shut up if it doesn't make > >> sense: The documentation for O_DIRECTORY seems to imply that one could > >> require O_DIRECTORY to be given when using O_TMPFILE. The "If pathname > >

Re: [git pull] vfs.git part 2

2013-07-12 Thread Rasmus Villemoes
Al Viro writes: > On Fri, Jul 12, 2013 at 12:02:45PM +, Rasmus Villemoes wrote: > >> But isn't the problem the case where dirname does not exist? I.e., the >> application has to make sure that "/some/where" exists and is a directory >> before open("/some/where", O_CREAT | O_TMPFILE | O_RDWR,

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 12:02:45PM +, Rasmus Villemoes wrote: > But isn't the problem the case where dirname does not exist? I.e., the > application has to make sure that "/some/where" exists and is a directory > before open("/some/where", O_CREAT | O_TMPFILE | O_RDWR, 0666) can be > relied up

Re: [git pull] vfs.git part 2

2013-07-12 Thread Rasmus Villemoes
Al Viro writes: > On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote: >> But with an *old* kernel, O_TMPFILE will just silently be ignored as >> an unrecognized flag, and things won't work. If you do >> >> fd = open("dirname", O_CREAT | O_TMPFILE | O_RDWR, 0666); >> >> it may be t

Re: [git pull] vfs.git part 2

2013-07-12 Thread Al Viro
On Fri, Jul 12, 2013 at 06:48:17AM +0100, Al Viro wrote: > It's slightly less painful than that - if dirname exists, the old kernels > will fail; O_CREAT for existing directory means an error. So in practice > you can use it safely. I'm not too happy about that situation, but I > hadn't been able

Re: [git pull] vfs.git part 2

2013-07-11 Thread Al Viro
On Thu, Jul 11, 2013 at 02:42:54PM -0700, Linus Torvalds wrote: > On Wed, Jul 3, 2013 at 5:29 AM, Al Viro wrote: > > Assorted f_pos race fixes, making do_splice_direct() safe to > > call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series, > > ->d_hash/->d_compare calling conv

Re: [git pull] vfs.git part 2

2013-07-11 Thread Linus Torvalds
On Wed, Jul 3, 2013 at 5:29 AM, Al Viro wrote: > Assorted f_pos race fixes, making do_splice_direct() safe to > call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series, > ->d_hash/->d_compare calling conventions changes from Linus, misc stuff > all over the place. Please, pu

[git pull] vfs.git part 2

2013-07-03 Thread Al Viro
Assorted f_pos race fixes, making do_splice_direct() safe to call with i_mutex on parent, O_TMPFILE support, Jeff's locks.c series, ->d_hash/->d_compare calling conventions changes from Linus, misc stuff all over the place. Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/vi