[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <FAB6FB68-5B65-41D1-BD5B-78D8553BA601@amacapital.net>
Date: Fri, 24 Aug 2018 07:54:57 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: David Howells <dhowells@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Linux API <linux-api@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 30/33] vfs: syscall: Add fspick() to select a superblock for reconfiguration [ver #11]
> On Aug 24, 2018, at 7:51 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
>
>> On Wed, Aug 1, 2018 at 5:29 PM David Howells <dhowells@...hat.com> wrote:
>>
>> --- a/include/uapi/linux/fs.h
>> +++ b/include/uapi/linux/fs.h
>> @@ -351,6 +351,11 @@ typedef int __bitwise __kernel_rwf_t;
>>
>> #define FSMOUNT_CLOEXEC 0x00000001
>>
>> +#define FSPICK_CLOEXEC 0x00000001
>> +#define FSPICK_SYMLINK_NOFOLLOW 0x00000002
>> +#define FSPICK_NO_AUTOMOUNT 0x00000004
>> +#define FSPICK_EMPTY_PATH 0x00000008
>
> This caught my eye: why aren't we using the AT_ constants? Adding an
> AT_CLOEXEC sounds less horrible than duplicating all the lookup
> related flags for FSPICK...
For a totally new API, is there any need to support !CLOEXEC? A caller can safely remove the CLOEXEC bit without races.
Powered by blists - more mailing lists