Thread (3 messages) 3 messages, 2 authors, 2016-02-14

Locking while executing bottom-halves and process context code

From: Henrik Austad <hidden>
Date: 2016-02-14 10:10:14

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160214/2d6d2c1d/attachment.bin 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help