On Sun, Feb 14, 2016 at 3:40 PM, Henrik Austad [off-list ref] wrote:

On Sun, Feb 14, 2016 at 11:00:40AM +0530, Pratyush Patel wrote:

quoted

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.

quoted

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