Re: [1/3] OSF: code beautification.

["Pavel A. Nekrasov" <pnekras@gmail.com>]

On 6/1/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Wed, 1 Jun 2005 02:03:28 +0200
> "Pavel A. Nekrasov" <pnekras@gmail.com> wrote:
> 
> > it seems that I forgot to reply to the mailling list...
> >
> > On 6/1/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > On Wed, 1 Jun 2005 02:57:31 +0400
> > > Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > >
> > > > On Wed, 1 Jun 2005 00:37:05 +0200
> > > > "Pavel A. Nekrasov" <pnekras@gmail.com> wrote:
> > >
> > > ...
> > >
> > > > > BTW, fix a deadlock. match() can be called from both bh and process context.
> > > >
> > > > Neither it suffers rcu lock in nf_hook_slow()?
> > >
> > > Ugh, it is read lock, but OSF match() method can be safely
> > > interrupted and reentered. BH are disabled when broadcasting over netlink,
> > > reading finger table is guarded by read_lock, while modification
> > > can be done only in process context which uses write_lock_bh().
> >
> > not talking about netlink
> >
> > say a program does send() running on you machine, so some packets can
> > hit match() from process context. While holding read lock, match() is
> > interrupted to handle a bh. now say, a packet coming from bh context
> > hits match() and tries to gets read lock but it's already held by the
> > packet coming from process context. deadlock.
> 
> It is read lock, which can be held by several users.
> 
> Modification part, which lives in osf_proc_write(), uses write_lock_bh().

You are right, sorry for the noise.

kind regards,
Pavel