preemptive kernels and the use of smp_processor_id()

[Christian Parpart]

Hey guys,

while attempting to port a relatively small kernel module that was
written for Linux kernel 3.1.4 to git master, I was encountering
a few issues.
First to note, I am really new to kernel development.
So while knowing C, I don't know much about the kernel APIs yet :)

Things that have changed mostly has been visibility changes,
like symbols got unexported and such, but the thing that worries me
are the stack traces regarding the use of smp_processor_id() when
using a PREEMPTible kernel.

So it seems the kernel module I am porting assumed to always run
on the same CPU core once entered kernelspace, but on a preemptive
system you cannot guarantee that. So my question is, how
can I force certain calls not to be preempted by the scheduler and/or
not changing the core it was running on?

AFAIK, the userspace has already defined a cpu affinity mask,
and that's why that kernel module assumes that.

1.) If that stack trace is non-fatal, can I make it less spammy in the log
files, meaning, that the use of smp_processor_id() is only used
for logging / informational purposes?

2.) there is one part in the kernel where it actually uses the
smp_processor_id()
value for further tests, so here it really shouldn't reschedule during the
call -
how do I ensure not being preempted there then?

Many thanks, and best regards,
Christian Parpart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130709/20d4c214/attachment-0001.html