[pso] read_lock_bh

Matei Gruber matei.gruber at gmail.com
Thu Jun 4 11:31:04 EEST 2009


Salut Răzvan,

mulțumesc ptr. răspuns.

în legatura cu _lock în bh, există cumva posibilitatea ca un
bh/softirq sa fie preemptat de unul cu prioritate mai mare? dacă
există această posibilitate atunci ar trebui touși să apelăm lock_bh
și în context bottom half. de exemplu, tablele nat si mangle din
kernel apelează acest hook, unde fac lock_bh.

http://lxr.linux.no/linux+v2.6.29/net/ipv4/netfilter/ip_tables.c#L350

Are sens treaba asta cu softirq preemption?

Matei



On Thu, Jun 4, 2009 at 11:00 AM, Razvan Deaconescu
<razvan.deaconescu at cs.pub.ro> wrote:
> On Thu, 2009-06-04 at 10:39 +0300, Matei Gruber wrote:
>> Pentru sincronizarea intre context proces si un hook netfilter, ce
>> primitive trebuie folosite, si de ce? Am observat in diverse module
>> din source tree, in hookurile netfilter se apeleaza _lock_bh. Este
>> corect sa sincronizez cu _lock in context process si _lock_bh in hook,
>> sau threbuie lock_bh in ambele?
>
> In context proces trebuie apelat neaparat _lock_bh, daca apelezi _lock
> (fara _bh) atunci nu se dezactiveaza bottom half-urile, drept pentru
> care poti ajunge la deadlock (se apeleaza _lock in context proces, se
> planifica un bottom half, bottom half-ul face un _lock si face
> busy-waiting in context amanabil ... not good).
>
> In hook-uri e suficient sa apelezi _lock, fara _bh. Nu ai de ce sa
> dezactivezi bottom half-urile cand lucrezi intr-un alt bottom half.
>
> Razvan
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> pso mailing list
> pso at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>


More information about the pso mailing list