Out of openat flag space
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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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
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
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@neopili:/tmp$ cat kk.c int main(int argc, char **argv){ return 008; } ricardo@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
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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.
participants (5)
-
David Legault -
Kernel Apprentice -
Nicholas Krause -
Ricardo Ribalda Delgado -
Sudip Mukherjee