June 2018 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Question regarding dynamic allocated tasklet
by Abhinav Misra June 19, 2018

June 19, 2018

Hi Guys, I am Abhinav, new to this mailing list. Have some query on tasklet. Going Jerry Cooperstein's LDD book chapter-20 (Interrupt handling and deferrable functions) lab exercises. Attached is the snapshot of problem-2,3. I am referring here to only tasklet. Solution to problem for tasklet provided is below. ------------------------------------------------------------ -------------------------------- static void t_fun(unsigned long t_arg) { struct my_dat *data = (struct my_dat *)t_arg; atomic_inc(&counter_bh); pr_info( "In BH: counter_th = %d, counter_bh = %d, jiffies=%ld, %ld\n", atomic_read(&counter_th), atomic_read(&counter_bh), data->jiffies, jiffies); } static DECLARE_TASKLET(t_name, t_fun, (unsigned long)&my_data); /* initialize tasklet */ static irqreturn_t my_interrupt(int irq, void *dev_id) { struct my_dat *data = (struct my_dat *)dev_id; atomic_inc(&counter_th); data->jiffies = jiffies; tasklet_schedule(&t_name); mdelay(delay); /* hoke up a delay to try to cause pileup */ return IRQ_NONE; /* we return IRQ_NONE because we are just observing */ } module_init(my_generic_init); module_exit(my_generic_exit); ------------------------------------------------------------ ------------------------------------- Above solution will miss some bottom halves. To solve this problem, a solution is provided using dynamically allocated tasklet as below ------------------------------------------------------------------------- static void t_fun(unsigned long t_arg) { struct my_dat *data = (struct my_dat *)t_arg; atomic_inc(&counter_bh); pr_info("In BH: counter_th = %d, counter_bh = %d, jiffies=%ld, %ld\n", atomic_read(&counter_th), atomic_read(&counter_bh), data->jiffies, jiffies); kfree(data); } static irqreturn_t my_interrupt(int irq, void *dev_id) { struct tasklet_struct *t; struct my_dat *data; data = (struct my_dat *)kmalloc(sizeof(struct my_dat), GFP_ATOMIC); t = &data->tsk; data->jiffies = jiffies; tasklet_init(t, t_fun, (unsigned long)data); atomic_inc(&counter_th); tasklet_schedule(t); mdelay(delay); /* hoke up a delay to try to cause pileup */ return IRQ_NONE; /* we return IRQ_NONE because we are just observing */ } module_init(my_generic_init); module_exit(my_generic_exit); ------------------------------------------------------------------------- Above solution will not miss any bottom halves. Can somebody explains me why above solution is working ? What is so special about dynamic tasklets ? BR,Abhinav

2 1

dummy interrupt handler using timer
by Pintu Kumar June 18, 2018

June 18, 2018

Hi, I wanted to develop a dummy interrupt handler for an ARM board which is connected to a remote location. This is required for some debugging purpose during the interrupt context. It does not have a keyboard or any GPIO pins. So, I wonder how to develop a custom interrupt handler, may be using timer invocation. If anybody can give some pointers or reference, it will be of great help. Thanks, Pintu

1 0

Various pages on the kernelnewbies.org website throwing 502 errors
by Robert Miesen June 17, 2018

June 17, 2018

I was trying to navigate to some pages on kernelnewbies.org and I got 502 bad gateway errors. The homepage works sporadically, but others throw the error mentioned. Examples include: - https://kernelnewbies.org/OutreachyIntro - https://kernelnewbies.org/FAQ - https://kernelnewbies.org/Documents - https://kernelnewbies.org/KernelJanitors - https://kernelnewbies.org/KernelProjects I apologize if this information is redundant: I just subscribed to the list.

1 0

Question about mmap
by bing zhu June 16, 2018

June 16, 2018

Dear Sir/Ma'am How can i map a kernel virtual address to a user process's same virtual address ?is it possible ? thank you for your time best wishes!

3 2

eth0: hw csum failure
by Mathieu Malaterre June 14, 2018

June 14, 2018

I am trying to understand the following stacktrace in dmesg: [ 34.023281] eth0: hw csum failure [ 34.023438] CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0+ #2 [ 34.023618] Call Trace: [ 34.023707] [dffedbd0] [c069ddac] __skb_checksum_complete+0xf0/0x108 (unreliable) [ 34.023948] [dffedbf0] [c0777a70] tcp_v4_rcv+0x604/0xe00 [ 34.024118] [dffedc70] [c0731624] ip_local_deliver_finish+0xa8/0x3c4 [ 34.024315] [dffedcb0] [c0732430] ip_local_deliver+0xf0/0x154 [ 34.024493] [dffedcf0] [c07328dc] ip_rcv+0x448/0x774 [ 34.024653] [dffedd50] [c06aeae0] __netif_receive_skb_core+0x5e8/0x1184 [ 34.024857] [dffedde0] [c06bba20] napi_gro_receive+0x160/0x22c [ 34.025044] [dffede10] [e14b2590] gem_poll+0x7fc/0x1ac0 [sungem] [ 34.025228] [dffedee0] [c06bacf0] net_rx_action+0x34c/0x618 [ 34.025402] [dffedf60] [c07fd27c] __do_softirq+0x16c/0x5f0 [ 34.025575] [dffedfd0] [c0064c7c] irq_exit+0x110/0x1a8 [ 34.025738] [dffedff0] [c0016170] call_do_irq+0x24/0x3c [ 34.025903] [c0cf7e80] [c0009a84] do_IRQ+0x98/0x1a0 [ 34.026055] [c0cf7eb0] [c001b474] ret_from_except+0x0/0x14 [ 34.026225] --- interrupt: 501 at arch_cpu_idle+0x30/0x78 LR = arch_cpu_idle+0x30/0x78 [ 34.026510] [c0cf7f70] [c0cf6000] 0xc0cf6000 (unreliable) [ 34.026682] [c0cf7f80] [c00a3868] do_idle+0xc4/0x158 [ 34.026835] [c0cf7fb0] [c00a3ab0] cpu_startup_entry+0x20/0x28 [ 34.027013] [c0cf7fc0] [c0998820] start_kernel+0x47c/0x490 [ 34.027181] [c0cf7ff0] [00003444] 0x3444 If I decompile the kernel here is what I can find: $ powerpc-linux-gnu-objdump -dS vmlinux > kernel.s $ cat kernel.s ... c077746c <tcp_v4_rcv>: { ... tcp_v4_send_reset(NULL, skb); c0777a58: 7f e4 fb 78 mr r4,r31 c0777a5c: 38 60 00 00 li r3,0 c0777a60: 4b ff b3 01 bl c0772d60 <tcp_v4_send_reset> c0777a64: 4b ff fc 14 b c0777678 <tcp_v4_rcv+0x20c> csum = __skb_checksum_complete(skb); c0777a68: 7f e3 fb 78 mr r3,r31 c0777a6c: 4b f2 62 51 bl c069dcbc <__skb_checksum_complete> skb->csum_valid = !csum; c0777a70: 81 5f 00 60 lwz r10,96(r31) if (skb_checksum_init(skb, IPPROTO_TCP, inet_compute_pseudo)) ... So the call to skb_checksum_init (0xc077746c+0x604) from tcp_v4_rcv is producing the checksum error. What I fail to understand is how is that going to help me track down the actual issue ? Thanks -- Mathieu

1 0

[PATCH v4] staging: pi433: fix race condition in pi433_ioctl
by Hugo Lefeuvre June 14, 2018

June 14, 2018

In the PI433_IOC_WR_TX_CFG case in pi433_ioctl, instance->tx_cfg is modified via copy_from_user(&instance->tx_cfg, argp, sizeof(struct pi433_tx_cfg))) without any kind of synchronization. In the case where two threads would execute this same command concurrently the tx_cfg field might enter in an inconsistent state. Additionally: if ioctl(PI433_IOC_WR_TX_CFG) and write() execute concurrently the tx config might be modified while it is being copied to the fifo, resulting in potential data corruption. Fix: Get instance->tx_cfg_lock before modifying tx config in the PI433_IOC_WR_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data and simpler code. Signed-off-by: Hugo Lefeuvre <hle(a)owl.eu.com> --- Changes in v4: - Fix incorrect buffer name in memcpy. --- drivers/staging/pi433/pi433_if.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index b061f77dda41..94e0bfcec991 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -880,6 +880,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) int retval = 0; struct pi433_instance *instance; struct pi433_device *device; + struct pi433_tx_cfg tx_cfg; void __user *argp = (void __user *)arg; /* Check type and command number */ @@ -902,9 +903,11 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) return -EFAULT; break; case PI433_IOC_WR_TX_CFG: - if (copy_from_user(&instance->tx_cfg, argp, - sizeof(struct pi433_tx_cfg))) + if (copy_from_user(&tx_cfg, argp, sizeof(struct pi433_tx_cfg))) return -EFAULT; + mutex_lock(&device->tx_fifo_lock); + memcpy(&instance->tx_cfg, &tx_cfg, sizeof(struct pi433_tx_cfg)); + mutex_unlock(&device->tx_fifo_lock); break; case PI433_IOC_RD_RX_CFG: if (copy_to_user(argp, &device->rx_cfg, -- 2.17.1

2 1

Re: [PATCH v3] staging: pi433: fix race condition in pi433_ioctl
by Hugo Lefeuvre June 14, 2018

June 14, 2018

> Thank you for the patch! Yet something to improve: > > [auto build test ERROR on staging/staging-testing] > [also build test ERROR on v4.17 next-20180613] > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] Already fixed in v4. Sorry for the noise. -- Hugo Lefeuvre (hle) | www.owl.eu.com 4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

1 0

[PATCH v3] staging: pi433: fix race condition in pi433_ioctl
by Hugo Lefeuvre June 14, 2018

June 14, 2018

In the PI433_IOC_WR_TX_CFG case in pi433_ioctl, instance->tx_cfg is modified via copy_from_user(&instance->tx_cfg, argp, sizeof(struct pi433_tx_cfg))) without any kind of synchronization. In the case where two threads would execute this same command concurrently the tx_cfg field might enter in an inconsistent state. Additionally: if ioctl(PI433_IOC_WR_TX_CFG) and write() execute concurrently the tx config might be modified while it is being copied to the fifo, resulting in potential data corruption. Fix: Get instance->tx_cfg_lock before modifying tx config in the PI433_IOC_WR_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data and simpler code. Signed-off-by: Hugo Lefeuvre <hle(a)owl.eu.com> --- Changes in v3: - Use tx_cfg for the name of temporary buffer (shorter, allows copy_from_user call to fit in a single line). - Move mutex_{un,}lock calls around memcpy instead of before copy_from_user call (was useless since we use a temporary buffer). - Remove useless comment before mutex_lock. --- drivers/staging/pi433/pi433_if.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index b061f77dda41..53a69cb37056 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -880,6 +880,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) int retval = 0; struct pi433_instance *instance; struct pi433_device *device; + struct pi433_tx_cfg tx_cfg; void __user *argp = (void __user *)arg; /* Check type and command number */ @@ -902,9 +903,11 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) return -EFAULT; break; case PI433_IOC_WR_TX_CFG: - if (copy_from_user(&instance->tx_cfg, argp, - sizeof(struct pi433_tx_cfg))) + if (copy_from_user(&tx_cfg, argp, sizeof(struct pi433_tx_cfg))) return -EFAULT; + mutex_lock(&device->tx_fifo_lock); + memcpy(&instance->tx_cfg, &tx_cfg_buffer, sizeof(struct pi433_tx_cfg)); + mutex_unlock(&device->tx_fifo_lock); break; case PI433_IOC_RD_RX_CFG: if (copy_to_user(argp, &device->rx_cfg, -- 2.17.1

2 2

[PATCH v2] staging: pi433: fix race condition in pi433_ioctl
by Hugo Lefeuvre June 14, 2018

June 14, 2018

In the PI433_IOC_WR_TX_CFG case in pi433_ioctl, instance->tx_cfg is modified via copy_from_user(&instance->tx_cfg, argp, sizeof(struct pi433_tx_cfg))) without any kind of synchronization. In the case where two threads would execute this same command concurrently the tx_cfg field might enter in an inconsistent state. Additionally: if ioctl(PI433_IOC_WR_TX_CFG) and write() execute concurrently the tx config might be modified while it is being copied to the fifo, resulting in potential data corruption. Fix: Get instance->tx_cfg_lock before modifying tx config in the PI433_IOC_WR_TX_CFG case in pi433_ioctl. Also, do not copy data directly from user space to instance->tx_cfg. Instead use a temporary buffer allowing future checks for correctness of copied data. Signed-off-by: Hugo Lefeuvre <hle(a)owl.eu.com> --- Changes in v2: - Use device->tx_fifo_lock instead of introducing a new lock in instance. - Do not copy data directly from user space to instance->tx_cfg, instead use a temporary buffer allowing future checks for correctness of copied data. --- drivers/staging/pi433/pi433_if.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index b061f77dda41..3ec1ed01d04b 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -880,6 +880,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) int retval = 0; struct pi433_instance *instance; struct pi433_device *device; + struct pi433_tx_cfg tx_cfg_buffer; void __user *argp = (void __user *)arg; /* Check type and command number */ @@ -902,9 +903,15 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) return -EFAULT; break; case PI433_IOC_WR_TX_CFG: - if (copy_from_user(&instance->tx_cfg, argp, - sizeof(struct pi433_tx_cfg))) + /* do not modify tx config while it is being copied to fifo */ + mutex_lock(&device->tx_fifo_lock); + if (copy_from_user(&tx_cfg_buffer, argp, + sizeof(struct pi433_tx_cfg))) { + mutex_unlock(&device->tx_fifo_lock); return -EFAULT; + } + memcpy(&instance->tx_cfg, &tx_cfg_buffer, sizeof(struct pi433_tx_cfg)); + mutex_unlock(&device->tx_fifo_lock); break; case PI433_IOC_RD_RX_CFG: if (copy_to_user(argp, &device->rx_cfg, -- 2.17.1

2 3

Question on kernel mode stack corruption
by Rajasekaran Chandrasekaran June 13, 2018

June 13, 2018

Hi, Sorry for the long email. I am seeing segmentation fault happening in random userspace processes periodically. I am running Linux kernel 4.1 version with atom x86 CPU. While inspecting core-dump of the user process from gdb, general-purpose registers seems to be corrupted where as EIP, ESP and EBP are all good and my stack frame is also proper. Process gets segmentation fault while dereferencing EAX thinking EAX contains a valid address, but since EAX value got corrupted, it gets killed due to invalid address access. Based on the book understanding linux kernel, all general-purpose registers gets stored in the kernel mode stack of the process, where as special registers(EIP, ESP etc) gets stored in thread_struct. Could it be possible during context switch, kernel mode stack gets corrupted resulting in bad EAX value when the control reaches user-space process? Would it be possible for some other conditions to lead to invalid EAX contents? Thanks, Raj

1 0