Disabling a BH : spin_lock_bh or local_bh_disable.

Disabling a BH : spin_lock_bh or local_bh_disable.

[priyaranjan]

Hi All,

I was referring to  "Unreliable Guide To Locking by Paul Rusty Russell".

Here is a quote below :-

"If a bottom half shares data with user context, you have two problems.
Firstly, the current user context can be interrupted by a bottom half, and
secondly, the critical region could be entered from another CPU. This is
where spin_lock_bh() (include/linux/spinlock.h) is used. It disables bottom
halves on that CPU, then grabs the lock. spin_unlock_bh() does the reverse"

Note : -

"user context" here means : The kernel executing on behalf of a particular
process or kernel thread (given by the current() macro.) Not to be confused
with userspace. Can be interrupted by software or hardware interrupts.


I have below questions related to the same.

1. If the BH is a tasklet/workque and in the user context we disable it,
what happens when a interrupt(tied to the same tasklet/workque) occurs ? I
hope the spin_lock_bh() do not disable the interrupt.

2. I hope that the spin_lock_bh needs to be acquired by the user context.
Can anybody confirm this? How the critical section is achieved from the BH
in the same context?

3.Overall It would be great if anybody can help me understand what happens
when a BH is disabled with Interrupts still enabled for the BH.

Regards,
Priyaranjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140613/90edb07a/attachment.html 

Disabling a BH : spin_lock_bh or local_bh_disable.

[Pranay Srivastava]

On Fri, Jun 13, 2014 at 12:27 PM, priyaranjan
<priyaranjan45678@gmail.com> wrote:
> Hi All,
>
> I was referring to  "Unreliable Guide To Locking by Paul Rusty Russell".
>
> Here is a quote below :-
>
> "If a bottom half shares data with user context, you have two problems.
> Firstly, the current user context can be interrupted by a bottom half, and
> secondly, the critical region could be entered from another CPU. This is
> where spin_lock_bh() (include/linux/spinlock.h) is used. It disables bottom
> halves on that CPU, then grabs the lock. spin_unlock_bh() does the reverse"
>
> Note : -
>
> "user context" here means : The kernel executing on behalf of a particular
> process or kernel thread (given by the current() macro.) Not to be confused
> with userspace. Can be interrupted by software or hardware interrupts.
>
>
> I have below questions related to the same.
>
> 1. If the BH is a tasklet/workque and in the user context we disable it,
> what happens when a interrupt(tied to the same tasklet/workque) occurs ? I
> hope the spin_lock_bh() do not disable the interrupt.

It doesn't afaik.

>
> 2. I hope that the spin_lock_bh needs to be acquired by the user context.
> Can anybody confirm this? How the critical section is achieved from the BH
> in the same context?

spin_lock_bh will disable softirqs on current core. Just like irq
versions of spin_lock. It's required since if the user space got just
the spin_lock

then in case the softirq is triggered on the same core due to
interrupt then it's locked up. You can protect the same with
spin_lock_irq

but that's too conservative since you know you don't need interrupts disabled.

When you do spin_lock_bh from task_struct context then your tasklet's
won't be scheduled on current core since softirqs are disabled,
thereby giving you the safe passage in case the the tasklet was
scheduled on other core.

>
> 3.Overall It would be great if anybody can help me understand what happens
> when a BH is disabled with Interrupts still enabled for the BH.
>

yes they are enabled.

> Regards,
> Priyaranjan
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
        ---P.K.S