Out of openat flag space

Out of openat flag space

[David Legault]

Hello,

Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there
is no space left to add more flags since the flags variable is a 32 bit
int. How does one resolve this issue and extend this? A new syscall with a
64bit wide flags support?

http://www.spinics.net/lists/fstests/msg01064.html

Thanks

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150407/272ef1b0/attachment.html 

Out of openat flag space

[Nicholas Krause]

On April 7, 2015 1:05:42 PM EDT, David Legault <legault.david@gmail.com> wrote:
>Hello,
>
>Now that we have O_TMPFILE and O_BENEATH added to the openat flags,
>there
>is no space left to add more flags since the flags variable is a 32 bit
>int. How does one resolve this issue and extend this? A new syscall
>with a
>64bit wide flags support?
>
>http://www.spinics.net/lists/fstests/msg01064.html
>
>Thanks
>
>David
>
That would be the easiest way to my knowledge.  However with anything system call related,  test it out in every way you can think of as not to break user space applications using this call already .  I am curious through as to your reasoning for changing this system call as generally this is only done only  with either a very good  reason or when it  is a must.
Hope this helps, 
Nick 
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Kernelnewbies mailing list
>Kernelnewbies at kernelnewbies.org
>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Out of openat flag space

[David Legault]

On Tue, Apr 7, 2015 at 7:04 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
>
>
> On April 7, 2015 1:05:42 PM EDT, David Legault <legault.david@gmail.com> wrote:
>>Hello,
>>
>>Now that we have O_TMPFILE and O_BENEATH added to the openat flags,
>>there
>>is no space left to add more flags since the flags variable is a 32 bit
>>int. How does one resolve this issue and extend this? A new syscall
>>with a
>>64bit wide flags support?
>>
>>http://www.spinics.net/lists/fstests/msg01064.html
>>
>>Thanks
>>
>>David
>>
> That would be the easiest way to my knowledge.  However with anything system call related,  test it out in every way you can think of as not to break user space applications using this call already .  I am curious through as to your reasoning for changing this system call as generally this is only done only  with either a very good  reason or when it  is a must.

The reason is that I want to add a new flag and there is no room left
to add it in the current setup since all flag values are used. And
this issue will crop up for the kernel sooner or later for the next
person that wants to add a flag to it. I couldn't find any discussion
online of the "what do we do when we reach that point".

That's what I was thinking but wasn't 100% sure which is why I am
asking. It wouldn't be too difficult since I have full control over
the kernel and libc in this env but I'd prefer doing it the same way
that it would be done so that I could submit my extension to the
kernel as a patch if required.

> Hope this helps,
> Nick
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Kernelnewbies mailing list
>>Kernelnewbies at kernelnewbies.org
>>http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Out of openat flag space

[Kernel Apprentice]

Hello,

> Hello,
> 
> Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there
> is no space left to add more flags since the flags variable is a 32 bit
> int. How does one resolve this issue and extend this? A new syscall with a
> 64bit wide flags support?

Maybe I'm missing something, but a signed 32 bit integer variable holds
a maximum value of

  2,147,483,647

The highest value for the O_BENEATH flag that i could spot in the patch
you linked is

  0x4000000

which equals

  67,108,864

so there should be plenty of room for more flags?

If the limit would be reached though I guess one could adjust the flag
arguments to unsigned int types. I haven't reasearched the implications
of this though. But OR'ing them for checks shouldn't yield any side effects.

By the way there's - as far as I can tell - an invalid flag value
defined in octal notation:

diff --git a/arch/parisc/include/uapi/asm/fcntl.h
b/arch/parisc/include/uapi/asm/fcntl.h
index 34a46cbc76ed..3adadf72f929 100644
--- a/arch/parisc/include/uapi/asm/fcntl.h
+++ b/arch/parisc/include/uapi/asm/fcntl.h
@@ -21,6 +21,7 @@

 #define O_PATH		020000000
 #define __O_TMPFILE	040000000
+#define O_BENEATH	080000000	/* no / or .. in openat path */

 #define F_GETLK64	8
 #define F_SETLK64	9

I guess this should be 0100000000?

> 
> http://www.spinics.net/lists/fstests/msg01064.html
> 
> Thanks
> 
> David
> 
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> 

Out of openat flag space

[Sudip Mukherjee]

On Wed, Apr 8, 2015 at 1:30 PM, Kernel Apprentice
<kernelapprentice@gmail.com> wrote:
> Hello,
>
>> Hello,
>>
>> Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there
>> is no space left to add more flags since the flags variable is a 32 bit
>> int. How does one resolve this issue and extend this? A new syscall with a
>> 64bit wide flags support?
>
> Maybe I'm missing something, but a signed 32 bit integer variable holds
> a maximum value of
>
>   2,147,483,647

as far as i know each bit of the number will represent a flag. so a 8
bit value can have a maximum of 8 flags and not 256 flags . same goes
for a 32 bit  integer.

regards
sudip

Out of openat flag space

[Kernel Apprentice]

Am 08.04.2015 um 10:17 schrieb Sudip Mukherjee:
> On Wed, Apr 8, 2015 at 1:30 PM, Kernel Apprentice
> <kernelapprentice@gmail.com> wrote:
>> Hello,
>>
>>> Hello,
>>>
>>> Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there
>>> is no space left to add more flags since the flags variable is a 32 bit
>>> int. How does one resolve this issue and extend this? A new syscall with a
>>> 64bit wide flags support?
>>
>> Maybe I'm missing something, but a signed 32 bit integer variable holds
>> a maximum value of
>>
>>   2,147,483,647
> 
> as far as i know each bit of the number will represent a flag. so a 8
> bit value can have a maximum of 8 flags and not 256 flags . same goes
> for a 32 bit  integer.

Yes of course. But that's not what I meant. If you take the following
hex value that has been used as a flag:

  0x4000000 (= 4 * 16 ^ 6 = 67108864)

which equals

  00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
  -- -- -

  (= 1 * 2 ^ 26 = 67108864)

in binary, then you can see that there's room for 5 more flags. This is
what I was actually getting at.

But maybe I'm off here.

> 
> regards
> sudip
> 

Out of openat flag space

[Ricardo Ribalda Delgado]

I think there is a bug in

+#define O_BENEATH 080000000

In c, when a number starts with 0, it is an octal number not an hexa
(0x number). Octal numbers cannot have an 8!

ricardo at neopili:/tmp$ cat  kk.c
int main(int argc, char **argv){
return 008;
}
ricardo at neopili:/tmp$ gcc kk.c
kk.c: In function ?main?:
kk.c:2:9: error: invalid digit "8" in octal constant
  return 008;
         ^
-- 
Ricardo Ribalda

Out of openat flag space

[David Legault]

On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice
<kernelapprentice@gmail.com> wrote:
> Hello,
>
>> Hello,
>>
>> Now that we have O_TMPFILE and O_BENEATH added to the openat flags, there
>> is no space left to add more flags since the flags variable is a 32 bit
>> int. How does one resolve this issue and extend this? A new syscall with a
>> 64bit wide flags support?
>
> Maybe I'm missing something, but a signed 32 bit integer variable holds
> a maximum value of
>
>   2,147,483,647
>
> The highest value for the O_BENEATH flag that i could spot in the patch
> you linked is
>
>   0x4000000
>
> which equals
>
>   67,108,864
>
> so there should be plenty of room for more flags?
>
> If the limit would be reached though I guess one could adjust the flag
> arguments to unsigned int types. I haven't reasearched the implications
> of this though. But OR'ing them for checks shouldn't yield any side effects.
>
> By the way there's - as far as I can tell - an invalid flag value
> defined in octal notation:
>
> diff --git a/arch/parisc/include/uapi/asm/fcntl.h
> b/arch/parisc/include/uapi/asm/fcntl.h
> index 34a46cbc76ed..3adadf72f929 100644
> --- a/arch/parisc/include/uapi/asm/fcntl.h
> +++ b/arch/parisc/include/uapi/asm/fcntl.h
> @@ -21,6 +21,7 @@
>
>  #define O_PATH         020000000
>  #define __O_TMPFILE    040000000
> +#define O_BENEATH      080000000       /* no / or .. in openat path */
>
>  #define F_GETLK64      8
>  #define F_SETLK64      9
>
> I guess this should be 0100000000?

That value overflows an int of size 4 bytes.

The important one to look at is the asm-generic one which covers most
platforms where the last available value was used.

diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index e063effe0cc1..4542bc6a2950 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -92,6 +92,10 @@
 #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
 #define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)

+#ifndef O_BENEATH
+#define O_BENEATH 040000000 /* no / or .. in openat path */
+#endif
+
 #ifndef O_NDELAY
 #define O_NDELAY O_NONBLOCK
 #endif

>
>>
>> http://www.spinics.net/lists/fstests/msg01064.html
>>
>> Thanks
>>
>> David
>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>

Out of openat flag space

[Kernel Apprentice]

> On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice
[snip]
>> I guess this should be 0100000000?
> 
> That value overflows an int of size 4 bytes.

How so? That value equals 16,777,216 and fits perfectly well into a
variable of type int. Is this something architecture-specific I'm
missing here?

Same goes for the value quoted below.

> 
> The important one to look at is the asm-generic one which covers most
> platforms where the last available value was used.
> 
> diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> index e063effe0cc1..4542bc6a2950 100644
> --- a/include/uapi/asm-generic/fcntl.h
> +++ b/include/uapi/asm-generic/fcntl.h
> @@ -92,6 +92,10 @@
>  #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
>  #define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)
> 
> +#ifndef O_BENEATH
> +#define O_BENEATH 040000000 /* no / or .. in openat path */
> +#endif
> +
>  #ifndef O_NDELAY
>  #define O_NDELAY O_NONBLOCK
>  #endif
> 
>>
>>>
>>> http://www.spinics.net/lists/fstests/msg01064.html
>>>
>>> Thanks
>>>
>>> David
>>>
>>>
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>

Out of openat flag space

[David Legault]

On Wed, Apr 8, 2015 at 6:06 AM, Kernel Apprentice
<kernelapprentice@gmail.com> wrote:
>> On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice
> [snip]
>>> I guess this should be 0100000000?
>>
>> That value overflows an int of size 4 bytes.
>
> How so? That value equals 16,777,216 and fits perfectly well into a
> variable of type int. Is this something architecture-specific I'm
> missing here?
>
> Same goes for the value quoted below.
>

Yes you are right, I was mislead in thinking there was no room left
(and probably thinking too much in hex compared to octal which I don't
use often), but there is enough for a few more flags before we hit the
limit.