1
votes

I have been pulling my hairs for real strange issue. The kernel module is unable to send signal to user application (or user app is unable to receive) without printk, have to do dummy printk after or before sending the signal.

Actually, it works great even with empty printk. But, i am trying to understand whats happening.

Any thoughts?

Here is whats happening:

A - kernel) Char device type module gets interrupt.

It extracts the data and send signal to user.

/* have to do printk here */

Return IRQ handle.

B- user)

Receives the signal.

issues a system call and read the data from char device's buffer . (copy_to_user)

kernel:

void irq_handler(){
    int i;
    for(i =0; i < 32; i++) 
        GPIOdata[i] = read_gpio_status(i);

    struct task_struct *p = find_task_by_pid(processinfo.pid);
    if (NULL == p) 
        return;
    send_sig(SIGUSR1, p, 0);
    /* have to add printk here */
    return IRQ_HANDLED
}

user:

void signal_handler(int sig) {
    char data[32];
    ioctl(fd, READ_Data_from_Char_device, &data);
}
1
Does your user app ever run again if you don't printk? Also, how are you signaling the user app?indiv
User application is running all the time. Without printk the signal_handler is being called but the data (copy from kernel) get corrupted somehow.ila
@user2492889 Just a guess - it looks like there is some stack or memory corruption that gets hidden by the printk call. But without code its impossible to tell.bbonev
@bbonev You got a valid point and I think that could be the case. Any idea how to dig in?ila
@user2492889 Code looks pretty straightforward... I am not sure if find_task_by_pid and send_sig are safe to be called from interrupt context. A way to overcome this is to call it from softirq context via tasklet, or even user context via work queue. Another way of doing the same job is to register a netlink socket and send the data as broadcast so all interested user processes. They will get both the notification and the data itself.bbonev

1 Answers

0
votes

If you are using signal not sigaction for setting handler, then remember, that signal removes handler after getting a signal. And you should mask the signal, so it will not interrupt your process when running inside signal handler. I'ma also not sure about system call ioctl inside handler (look at man7 signal under section Async-signal-safe functions).

Calls to printk might slow down execution of other operations (because they are blocked on I/O or buffering) around these calls, so they can make synchronization slower (thus any mistakes in synchronization may not occur).