On Sun, Feb 14, 2016 at 3:40 PM, Henrik Austad <henrik@xxxxxxxxx> 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
