Locking while executing bottom-halves and process context code

[Pratyush Patel]

On Sun, Feb 14, 2016 at 3:40 PM, Henrik Austad <henrik at 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