Hey guys,<div><br></div><div>while attempting to port a relatively small kernel module that was</div><div>written for Linux kernel 3.1.4 to git master, I was encountering</div><div>a few issues.</div><div>First to note, I am really new to kernel development.</div>
<div>So while knowing C, I don't know much about the kernel APIs yet :)</div><div><br></div><div>Things that have changed mostly has been visibility changes,</div><div>like symbols got unexported and such, but the thing that worries me</div>
<div>are the stack traces regarding the use of smp_processor_id() when</div><div>using a PREEMPTible kernel.</div><div><br></div><div>So it seems the kernel module I am porting assumed to always run</div><div>on the same CPU core once entered kernelspace, but on a preemptive</div>
<div>system you cannot guarantee that. So my question is, how</div><div>can I force certain calls not to be preempted by the scheduler and/or</div><div>not changing the core it was running on?</div><div><br></div><div>AFAIK, the userspace has already defined a cpu affinity mask,</div>
<div>and that's why that kernel module assumes that.</div><div><br></div><div>1.) If that stack trace is non-fatal, can I make it less spammy in the log</div><div>files, meaning, that the use of smp_processor_id() is only used</div>
<div>for logging / informational purposes?</div><div><br></div><div>2.) there is one part in the kernel where it actually uses the smp_processor_id()</div><div>value for further tests, so here it really shouldn't reschedule during the call -</div>
<div>how do I ensure not being preempted there then?</div><div><br></div><div>Many thanks, and best regards,</div><div>Christian Parpart.</div>