Locking while executing bottom-halves and process context code
Hello, While reading a section in Linux Kernel Development, I came across the following: "If process context code and a bottom half share data, you need to disable bottom-half processing and obtain a lock before accessing the data." Why is this the case? Can one not disable/lock the process context code instead of the bottom-half and access data? Similarly, for the statement, "If interrupt context code and a bottom half share data, you need to disable interrupts and obtain a lock before accessing the data." Any help in clarifying this would be much appreciated. Thanks, Pratyush
On Sun, Feb 14, 2016 at 11:00:40AM +0530, Pratyush Patel wrote:
Hello,
While reading a section in Linux Kernel Development, I came across the following:
"If process context code and a bottom half share data, you need to disable bottom-half processing and obtain a lock before accessing the data."
Why is this the case? Can one not disable/lock the process context code instead of the bottom-half and access data?
You need to do it in both. You need to grab the lock in BH in case other threads also calls the same syscall. You need to lock in from user process context to avoid being interrupted and having a BH walk in and update the data. A Thread | do_something() do_a_syscall() // update a var in kernel, but on behalf of thread read shared var A * Interrupt * irq_entry // ack interrupt, do critical stuff // trigger softirq do the rest irq_exit softirq_entry Update shared var A softirq_exit (now back in thread A, inside kernel) write old value of A back // updated A from softirq now lost!
Similarly, for the statement,
"If interrupt context code and a bottom half share data, you need to disable interrupts and obtain a lock before accessing the data."
Any help in clarifying this would be much appreciated.
Same as for userprocess vs. BH, an ISR can interrupt a BH and update data unless you have disabled interrupt. HTH, -- Henrik Austad
On Sun, Feb 14, 2016 at 3:40 PM, Henrik Austad <henrik@austad.us> wrote:
On Sun, Feb 14, 2016 at 11:00:40AM +0530, Pratyush Patel wrote:
Hello,
While reading a section in Linux Kernel Development, I came across the following:
"If process context code and a bottom half share data, you need to disable bottom-half processing and obtain a lock before accessing the data."
Why is this the case? Can one not disable/lock the process context code instead of the bottom-half and access data?
You need to do it in both.
That makes a lot more sense.
You need to grab the lock in BH in case other threads also calls the same syscall. You need to lock in from user process context to avoid being interrupted and having a BH walk in and update the data.
A Thread | do_something() do_a_syscall() // update a var in kernel, but on behalf of thread read shared var A * Interrupt * irq_entry // ack interrupt, do critical stuff // trigger softirq do the rest irq_exit softirq_entry Update shared var A softirq_exit
(now back in thread A, inside kernel) write old value of A back // updated A from softirq now lost!
Wonderful explanation, thank you.
Similarly, for the statement,
"If interrupt context code and a bottom half share data, you need to disable interrupts and obtain a lock before accessing the data."
Any help in clarifying this would be much appreciated.
Same as for userprocess vs. BH, an ISR can interrupt a BH and update data unless you have disabled interrupt.
-Pratyush
participants (2)
-
Henrik Austad -
Pratyush Patel