Re: Out of openat flag space
On Wed, Apr 8, 2015 at 6:06 AM, Kernel Apprentice kernelapprent...@gmail.com wrote: On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice [snip] I guess this should be 01? 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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
Am 08.04.2015 um 10:17 schrieb Sudip Mukherjee: On Wed, Apr 8, 2015 at 1:30 PM, Kernel Apprentice kernelapprent...@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: 0x400 (= 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: maybe dumb question about RCU
From: Rock Lee [mailto:rocklee_...@outlook.com]
Sent: Tuesday, April 07, 2015 7:09 PM
To: Jeff Haran
Cc: kernelnewbies
Subject: Re: maybe dumb question about RCU
256 If you are going to be fetching multiple fields from the
257 RCU-protected structure, using the local variable is of
258 course preferred. Repeated rcu_dereference() calls look
259 ugly and incur unnecessary overhead on Alpha CPUs.
From lines 256 to 259 I conclude that reader()'s code is considered
ugly and wasteful,
but a will always equal b.
But looking at how rcu_dereference() and rcu_assign_pointer() are
implemented, I'm having a
hard time seeing how reader() would always see a and b equal.
This is the implementation of rcu_dereference(). It is a little old, but
useful as well.
#define rcu_dereference(p) ({ \
typeof(p) _p1 = ACCESS_ONCE(p); \
smp_read_barrier_depends(); \
(_p1); \
})
It uses memory barrier to guarantee the order of code execution.
rcu_read_lock() actually disables preemption, so writer has no chance to
modify critical section in the rcu_read_lock()/rcu_read_unlock() pair.
Thanks for getting back to me, Rock.
Disabling preemption would prevent a writer on the same core as the reader
from changing the pointer in the read critical section.
But what happens if the writer is running on another core of a multi-core
system?
Seems like a writer on another core could still get in there and change the
value of the pointer between the two rcu_dereference() calls in the reader.
Jeff Haran
Ys, rcu_read_lock() and rcu_read_unlock() calls never spin or block,
nor do they prevent the writer from changing the value of the critical
section concurrently.
I am still confused about this part, sorry. I think this article will
help, although my poor English hasn't make me fully understand it.
http://lwn.net/Articles/262464/
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice [snip] I guess this should be 01? 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 04000 /* 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
On Wed, Apr 8, 2015 at 4:00 AM, Kernel Apprentice kernelapprent...@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 0x400 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 02000 #define __O_TMPFILE04000 +#define O_BENEATH 08000 /* no / or .. in openat path */ #define F_GETLK64 8 #define F_SETLK64 9 I guess this should be 01? 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 04000 /* 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
On Tue, Apr 7, 2015 at 7:04 PM, Nicholas Krause xerofo...@gmail.com wrote: On April 7, 2015 1:05:42 PM EDT, David Legault legault.da...@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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
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 0x400 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 02000 #define __O_TMPFILE04000 +#define O_BENEATH 08000 /* no / or .. in openat path */ #define F_GETLK64 8 #define F_SETLK64 9 I guess this should be 01? http://www.spinics.net/lists/fstests/msg01064.html Thanks David ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Out of openat flag space
On Wed, Apr 8, 2015 at 1:30 PM, Kernel Apprentice kernelapprent...@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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[mil...@krutt.org: Re: Delaying an interrupt handler]
- Forwarded message from Milton Krutt mil...@krutt.org - Date: Tue, 7 Apr 2015 18:46:46 +0200 From: Milton Krutt mil...@krutt.org To: Malte Vesper malte.ves...@postgrad.manchester.ac.uk Subject: Re: Delaying an interrupt handler Not that late! I take your advice, and I inform all the folks who suggested me to jump on a new kernel that now I am on a 3.19! So their hints are still welcome. Bye Despite beeing fairly late, take a look at threaded interrupt handlers, they might help you. You will handle the interrupt fast but you can delay doing the actual work. In the threaded part of the interrupt handler you can sleep and thus use semaphores. hope it is still useful - End forwarded message - ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RT process priority Interrupts ?
In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted? Is RT process considered superior to interrupts? Best Regards, Sandeep Kumar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: RT process priority Interrupts ?
On Thu, 09 Apr 2015 10:59:20 +0900, manty kuma said: In Linux, when a real time process is executing and an interrupt comes, will the RT process be preempted? Is RT process considered superior to interrupts? Think it through - that would imply that RT processes effectively run with interrupts disabled (or ignored, which amounts to the same thing). What would be the result of that? How would the system behave? Consider in particular that RT processes want a hard maximum on latency (and usually as low latency as you can get). Remember to consider the case of more than one RT process on a system For bonus points, work it out for both hard and soft IRQs. pgphC1hGaUq9n.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
pci devices
Hi, One of my pci device is not showing up in /proc/pci/bus/devices. I'm using 2.6.36 kernel. which part of code i can look to troubleshoot, i'm looking at drivers/pci/probe.c. Any pointers / tips will be helpful ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Spoon feeding
Spoon-feeding = Actually explaining to you now what spoon-feeding means. On Thu, Apr 9, 2015 at 8:45 AM, Nicholas Krause xerofo...@gmail.com wrote: Greetings All, After thinking for a few days I have come to the conclusion that the communities definition of spoon feeding and my are different. If someone would like to give me the community definition so there is no more misunderstandings and time wasting that would be great. Nick -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Spoon feeding
On April 8, 2015 11:18:13 PM EDT, Chinmay V S cvs...@gmail.com wrote: Spoon-feeding = Actually explaining to you now what spoon-feeding means. I know what it means however whenever I ask a question, I always get the response do more research. I am wondering if this is due to a lack of effort on my part or a misunderstanding that I am putting in time but my questions are too open ended. Ni5 On Thu, Apr 9, 2015 at 8:45 AM, Nicholas Krause xerofo...@gmail.com wrote: Greetings All, After thinking for a few days I have come to the conclusion that the communities definition of spoon feeding and my are different. If someone would like to give me the community definition so there is no more misunderstandings and time wasting that would be great. Nick -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ 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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Spoon feeding
Greetings All, After thinking for a few days I have come to the conclusion that the communities definition of spoon feeding and my are different. If someone would like to give me the community definition so there is no more misunderstandings and time wasting that would be great. Nick -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
