Hi everyone! I'm doing a bit of testing on the Linux kthread functions, and
have the following module:
#include
#include
#include
#include
#include
#include
MODULE_LICENSE("GPL");
int function(void *data)
{
printk(KERN_DEBUG "CPU: %u\n", smp_processor_id());
do_exit(0); /* Not su
Understood. Thanks a lot!
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Still, going back to this issue: even though I made make a mistake and
incorrectly called kthread_stop on a (possibly) non-existent
task_struct, it's not clear to me why I didn't get to see the thread
function printks. If the thread function finished before reaching
kthread_stop, I should be able t
Hi everyone, I'm testing out a small kernel module and wondered what
the default file_operations methods are. I know about no_llseek for
llseek, but what about the rest? Is there anything like no_llseek for
e.g. read, write and so on?
The reason I'm asking this is that my module should only allow
Hi all,
I'm trying to build a kernel module by statically linking object files
with a library. My source tree looks like this:
source/
├── bar/
| ├── bar1.c
| └── bar2.c
└── foo.c
The relevant parts of my Makefile look like this:
mydriver-y := foo.o bar.a
obj-m += mydriver.o
bar-objs := bar
2018-04-05 2:26 GMT-03:00 :
> On Wed, 04 Apr 2018 18:29:21 -0300, Martin Galvan said:
>
>> PS: Yes, I'm aware I could just add $(bar-objs) to mydriver-y and
>> avoid building bar.a, but I really need to have those files as a
>> separate library.
>
> What'
2018-04-05 12:02 GMT-03:00 Greg KH :
> On Thu, Apr 05, 2018 at 11:49:36AM -0300, Martin Galvan wrote:
>> I want my module to be DKMS-enabled, but since the 'bar' binaries
>> don't use anything Linux-specific I don't want to distribute the
>> sources for
Hi,
I have a kernel module which needs to perform CPU core-specific
operations. I know that there's a kernel mode version of
sched_setaffinity, however it's not exported to modules and can only
be accessed through e.g. kallsyms_lookup_name, which is ugly. The
alternative is to spawn a new kthread
Hi all,
I'm looking for a way to determine the PID of the process on which
kthread_create is invoked to spawn a new kthread. The newly created
kthreads all show current->parent->pid == 2, which I understand
corresponds to kthreadd. current->tgid doesn't seem to be set to the
main process' PID eith
El mié., 11 sept. 2019 a las 16:17, Bharath Vedartham
() escribió:
> So one thing that pops to my head is using cgroups. Create a cgroup,
> modify the cpu file in cpusets cgroup and add the required task to it.
> But I am not sure whether you can do all of this from a kernel module...
Thanks, but
El jue., 12 sept. 2019 a las 6:26, Bharath Vedartham
() escribió:
> Just to be clear, What do you mean by current process. Is it the process
> which is executing the kernel module? That would be a kernel thread I
> believe or do you want to be able to set the cpu affinity for any
> process given it
El vie., 13 sept. 2019 a las 1:50, Greg KH () escribió:
> I really hate to ask, but _why_ do you feel that this is the correct
> solution to your problem? What is the problem you are attempting to
> solve by doing this?
I'm reading and comparing per-core MSR values.
_
El vie., 13 sept. 2019 a las 9:55, Greg KH () escribió:
> And doing what with that information? We have a msr driver for
> userspace access to those values, does that not work correctly for you?
My use case requires this to be done in kernel space.
In any case, thanks for the help, this seems to
Hi all,
I'm writing a kernel module, and am trying to implement some
exception-handling mechanism so that the system won't oops/panic if my
module does e.g. a NULL dereference. The (horribly hackish) way I'm
doing this right now is registering a die_notifier which will set the
'panic_on_oops' vari
El jue., 17 oct. 2019 a las 19:13, Valdis Klētnieks
() escribió:
>
> For starters, the *correct* in-kernel way to deal with this is:
> if (!ptr) {
> printk("You blew it!\n");
> goto you_blew_it;
> }
goto statements are harmful. In any case, what I me
El vie., 18 oct. 2019 a las 13:05, Bernd Petrovitsch
() escribió:
> You actually want speed in the kernel and not necessarily extra effort
> for "try" and "catch" which is - sooner or later - never really used.
> And the "safety net" reduces the motivation to actually fix pointer bugs
I don't
El vie., 18 oct. 2019 a las 14:02, Ruben Safir () escribió:
> I don't think you really understand what is going on here. On the
> kernel level you would never wrap up a process in another process in
> order to catch a mistake, and then do error correction. That method of
> programming is not appr
Hi Valdis, thanks for the thorough response.
El vie., 18 oct. 2019 a las 18:53, Valdis Klētnieks
() escribió:
> Well..here's the thing. Unless you have "panic_on_oops" set, hitting a null
> pointer will usually *NOT* panic the whole system. In fact, that # in the
> panic message is a counter
18 matches
Mail list logo
