Confusion in the usage of linux key management APIs
Hi, I need to store some crypto keys in the kernel where each key is related to a path on the disk. A restricted set of users can create files on such a path but the crypto keys are shared by all such user. I am thinking of using linux kernel key management facilities for my project. I have a usermode application that manages key and a kernel module. However the add_key interface is not clear to me. How do I create a global keyring that is accessible to everyone? Man page of add_key has this to say about add_key ---88-- key_serial_t add_key(const char *type, const char *description, const void *payload, size_t plen, key_serial_t keyring); DESCRIPTION add_key() asks the kernel to create or update a key of the given type and description, Instantiate it with the payload of length plen, and to attach it to the nominated keyring and to return its serial number. The destination keyring serial number may be that of a valid keyring to which the caller has write permission, or it may be a special keyring ID: KEY_SPEC_THREAD_KEYRING This specifies the caller's thread-specific keyring. KEY_SPEC_PROCESS_KEYRING This specifies the caller's process-specific keyring. KEY_SPEC_SESSION_KEYRING This specifies the caller's session-specific keyring. KEY_SPEC_USER_KEYRING This specifies the caller's UID-specific keyring. KEY_SPEC_USER_SESSION_KEYRING This specifies the caller's UID-session keyring. ---88-- I understand that I may need to register my own type in the kernel using register_key_type API in the kernel. However I do not understand what value should be passed to the keyring parameter. Also what is meant by possessor in assigning permissions? Also what should be passed to uid and gid parameters in the call to kernel API key_alloc() -- Regards, Ranjan ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[Need Help] time: questions about kernel function timekeeping_bigadjust()
Hi All,
Could anybody explain the following kernel code for me in detail ? I am
royally confused on it.
kernel/time/timekeeping.c
timekeeping_bigadjust()
{
/*
* Use the current error value to determine how much to look ahead.
* The larger the error the slower we adjust for it to avoid problems
* with losing too many ticks, otherwise we would overadjust and
* produce an even larger error. The smaller the adjustment the
* faster we try to adjust for it, as lost ticks can do less harm
* here. This is tuned so that an error of about 1 msec is adjusted
* within about 1 sec (or 2^20 nsec in 2^SHIFT_HZ ticks).
*/
error2 = tk-ntp_error (NTP_SCALE_SHIFT + 22 - 2 * SHIFT_HZ);
}
Thanks in advance.
--
Best Regards,
Dong Zhu
MySite: http://bluezd.info
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel build error
On Fri, Mar 22, 2013 at 10:41:56AM +0700, Mulyadi Santosa wrote: On Thu, Mar 21, 2013 at 1:16 PM, Kumar amit mehta gmate.a...@gmail.com wrote: boot issue. But before attaching these small files(136K and 32K respectively) and send it to the mailing list, I'd like to ask, if that's fine with you folks. maybe it's better if you upload those files somewhere, maybe google docs and send the link here. I've uploaded the kernel configuration and the screenshot in google drive [1]. With these particular settings, I'm able to build the kernel, but still not able to boot from it: $ egrep -i 'pktgen|binfmt_misc|cxt1|isdn' .config CONFIG_BINFMT_MISC=y # CONFIG_NET_PKTGEN is not set # CONFIG_ISDN is not set # CONFIG_CXT1E1 is not set Just to be a little more verbose, I've listed below the steps that I follow to build and boot from the newly built kernel on my ubuntu box: $ sudo apt-get install build-essential $ make oldconfig $ make -jX all ;;Where X= Number of CPU cores $ sudo make modules_install install $ sudo update-grub $ sudo shutdown -y now [1] https://docs.google.com/folder/d/0B4un01St9Hdsb18xYU1yaF9ET0U/edit?usp=sharing Please let me know if you face any problem in accessing these. -Amit ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: optimization in kernel compile
On Fri, 22 Mar 2013 13:41:25 +0800, ishare said: Is it needed or must to compile fs and driver with -O2 option when compiling kernel ? It's not strictly mandatory to use -O2 (for a while, -Os was the default). There are a few places that for correctness, you *cannot* use -O0. For instance, a few places where we use builtin_return_address() inside an inline (-O0 won't inline so builtin_return_address() ends up returning a pointer to a function when we want the function's parent). Since gdb and friends are able to deal with -O2 compiled code just fine, there's really no reason *not* to optimize the kernel. pgpXTcS9iUOyU.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: optimization in kernel compile
On Fri, Mar 22, 2013 at 09:55:53AM -0400, valdis.kletni...@vt.edu wrote: On Fri, 22 Mar 2013 13:41:25 +0800, ishare said: Is it needed or must to compile fs and driver with -O2 option when compiling kernel ? It's not strictly mandatory to use -O2 (for a while, -Os was the default). There are a few places that for correctness, you *cannot* use -O0. For instance, a few places where we use builtin_return_address() inside an inline (-O0 won't inline so builtin_return_address() ends up returning a pointer to a function when we want the function's parent). So it will cause an error ? Since gdb and friends are able to deal with -O2 compiled code just fine, there's really no reason *not* to optimize the kernel. the debug information will be stripped by -O2 ,for example ,you can not touch the value of some varibles at stack , and debugging will not run line by line, instead , the source jump in unexpectable order . ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: optimization in kernel compile
On Fri, 22 Mar 2013 22:32:40 +0800, ishare said: are a few places that for correctness, you *cannot* use -O0. For instance, a few places where we use builtin_return_address() inside an inline (-O0 won't inline so builtin_return_address() ends up returning a pointer to a function when we want the function's parent). So it will cause an error ? Yes, there are places where failing to optimize causes errors. Consider this code: static inline foo (return builtin_return_address()); int bar ( x = foo()); If you don't optimize, x ends up with a pointer into bar. If it gets inlined because you're optimizing, x ends up pointing to bar's caller. This breaks stuff like the function tracer. Since gdb and friends are able to deal with -O2 compiled code just fine, there's really no reason *not* to optimize the kernel. the debug information will be stripped by -O2 ,for example ,you can not touch No debug information is stripped by -O2. Debug information isn't emitted if you don't compile with -g. At one time, long ago (quite possibly literally before you were born for some of the younger readers on the list), gcc was unable to generate -g output if the optimizer was invoked. But that was last century (gcc 2.95 era). the value of some varibles at stack , and debugging will not run line by line, instead , the source jump in unexpectable order . I'm probably going to piss a bunch of people off by saying this, but: If your C skills aren't up to debugging code that's been compiled with -O2, maybe you shouldn't be poking around inside the kernel. pgp2l_ihNO3sv.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: BFQ: simple elevator
On Thu, Mar 21, 2013 at 8:52 PM, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Hi On Thu, Mar 21, 2013 at 4:37 PM, Raymond Jennings shent...@gmail.com wrote: At any rate I suppose the best way to get started on this is to get a grip on the api's involved in receiving requests from above and dispatching them below. Is studying the deadline scheduler a good start or would I be better off looking at documentation? Valdis already gave you great feedback, so I'll just add that what you need is lots of experiments. Oh I already agree with Valdis's feedback, and especially the concept of this not being as simple as one would hope. Before I get close to considering submitting my work upstream I'll be playing with it a lot. Mostly I want to get a grip on the brass tacks of interfacing properly with the code layers above and below my scheduler. Hence my question on the best way to learn the ropes of actually handling the requests. My goal in writing this was more to get practice writing kernel code and properly interfacing iwth other subsystems than to actually write a decent scheduler ^^. Reading your detailed proposal, sounds like what you're doing is much similar to Con Kolivas old- Staircase scheduler (a process scheduler). The difference is, you're implementing it on disk which has way bigger latency to consider. But again, IMHO there is nothing to stop you from experimenting. So I suggest, maybe you need to add something that anticipatory does, wait for few moments to anticipate I/O coming in nearby sectors. You need to define the limit of nearby. If nothing coming, just keep moving. If there is one, service them while changing the service path. Just my 2 cents idea.. Quite, quite. Wonderful feedback everyone. At this point it's time to get my feet wet so all I'm after right now is -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: BFQ: simple elevator
I think I might split incoming requests into two heaps. The first heap would be synchronous requests such as reads and syncs that someone in userspace is blocking on. The second is background I/O like writeback and readahead. The same distinction that CFQ completely makes. Anyway, I plan to give the first heap strict priority over the second. But anyway yeah, I'm into this more for learning how to interface with the APIs in question and write kernel code in general. Good performance is a secondary objective. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: optimization in kernel compile
On Fri, 22 Mar 2013 10:52:56 -0400, valdis.kletni...@vt.edu said: No debug information is stripped by -O2. Debug information isn't emitted if you don't compile with -g. At one time, long ago (quite possibly literally before you were born for some of the younger readers on the list), gcc was unable to generate -g output if the optimizer was invoked. But that was last century (gcc 2.95 era). GCC 4.8 was officially released today (since I sent the previous note). From the release notes: A new general optimization level, -Og, has been introduced. It addresses the need for fast compilation and a superior debugging experience while providing a reasonable level of runtime performance. Overall experience for development should be better than the default optimization level -O0. The current Linus tree does build with 4.8. I do *not* know if earlier releases build correctly (or how far back), nor if -Og is sufficient optimization to allow correct kernel functioning. But it's something to look at. pgpvT83zc9Q26.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: BFQ: simple elevator
On Fri, 22 Mar 2013 13:53:45 -0700, Raymond Jennings said: The first heap would be synchronous requests such as reads and syncs that someone in userspace is blocking on. The second is background I/O like writeback and readahead. The same distinction that CFQ completely makes. Again, this may or may not be a win, depending on the exact workload. If you are about to block on a userspace read, it may make sense to go ahead and tack a readahead on the request for free - at 100MB/sec transfer and 10ms seeks, reading 1M costs the same as a seek. If you read 2M ahead and save 3 seeks later, you're willing. Of course, the *real* problem here is that how much readahead to actually do needs help from the VFS and filesystem levels - if there's only 600K more data before the end of the current file extent, doing more than 600K of read-ahead is a loss. Meanwhile, over on the write side of the fence, unless a program is specifically using O_DIRECT, userspace writes will get dropped into the cache and become writeback requests later on. So the vast majority of writes will usually be writebacks rather than syncronous writes. So in many cases, it's unclear how much performance CFQ gets from making the distinction (and I'm positive that given a sufficient supply of pizza and caffeine, I could cook up a realistic scenario where CFQ's behavior makes things worse)... Did I mention this stuff is tricky? :) pgpwattaBMg37.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: BFQ: simple elevator
On Fri, Mar 22, 2013 at 2:20 PM, valdis.kletni...@vt.edu wrote: On Fri, 22 Mar 2013 13:53:45 -0700, Raymond Jennings said: The first heap would be synchronous requests such as reads and syncs that someone in userspace is blocking on. The second is background I/O like writeback and readahead. The same distinction that CFQ completely makes. Again, this may or may not be a win, depending on the exact workload. If you are about to block on a userspace read, it may make sense to go ahead and tack a readahead on the request for free - at 100MB/sec transfer and 10ms seeks, reading 1M costs the same as a seek. If you read 2M ahead and save 3 seeks later, you're willing. Of course, the *real* problem here is that how much readahead to actually do needs help from the VFS and filesystem levels - if there's only 600K more data before the end of the current file extent, doing more than 600K of read-ahead is a loss. That sounds more like an argument for pushing readahead logic up into the fs and vfs levels. If it were up to me, linear/physical readahead would be disabled entirely. Speaking of which, I hear that tux3 is in the works to take more charge of bossing the block layer around. Meanwhile, over on the write side of the fence, unless a program is specifically using O_DIRECT, userspace writes will get dropped into the cache and become writeback requests later on. So the vast majority of writes will usually be writebacks rather than syncronous writes. So in many cases, it's unclear how much performance CFQ gets from making the distinction (and I'm positive that given a sufficient supply of pizza and caffeine, I could cook up a realistic scenario where CFQ's behavior makes things worse)... Did I mention this stuff is tricky? :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Why we Use both mm_users and mm_count in struct mm_struct{ }
Hi all,
I have been going through the Address Space in the linux and came across
two variables in the struct mm_struct and I'm a bit confused about the two:
struct mm_struct
{
..
atomic_t mm_users;
atomic_t mm_count;
}
Basically, after reading through I came to understand that mm_users are
used to store the number of processes or threads using the memory so
depending upon the number of users it is going to be set.
But, I am confused with mm_count, it is said the mm_count is increment by
one for all the mm_users and when all the mm_users value is reduced to zero
then mm_count is reduced. So, my question is can the value of mm_count be
ever greater than one because all the mm_users are equivalent to mm_count .
So, if not then why are we using the mm_count as we can simply remove the
memory areas whenever the mm_users count reduce to zero.
May be the explanation is simple but I'm lost. Thanking all of you in
advance.
Regards,
Niroj Pokhrel
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
