Re: [PATCH] tipc: checking returns and Re: Possible Circular Lockingin TIPC

[Jon Maloy]

Regards
///jon

Jarek Poplawski wrote:

> I know lockdep is sometimes
> too careful but nevertheless some change is needed
> to fix a real bug or give additional information
> to lockdep. 
>  
I don't know lockdep well enough yet, but I will try to find out if that
is possible.

>  
>
> > > Btw. there is a problem with tipc_ref_discard():
> > > it should be called with tipc_port_lock, but
> > > how to discard a ref if this lock can't be
> > > acquired? Is it OK to call it without the lock
> > > like in subscr_named_msg_event()?
> > >
> > >
> > >      
> > I suspect you are mixing up things here. 
> > We are handling two different reference entries and two
> > different locks in this function.
> > One reference entry points to a subscription instance, and its
> > reference (index) is obtainable from subscriber->ref. So, we
> > could easily lock the entry if needed. However, in this
> > particular case it is unnecessary, since there is no chance that
> > anybody else could have obtained the new reference, and
> > hence no risk for race conditions.
> > The other reference entry was intended to point to a new port,
> > but, since we didn't obtain any reference in the first place,
> > there is no port to delete and no reference to discard.
> >    
>
> I admit I don't know this program and I hope I
> didn't mislead anybody with my message. I only
> tried to point at some doubts and maybe this
> function could be better commented about when
> the lock is needed.
>  
Agreed.

> Thanks for explanations & best regards,
>
> Jarek P.
>
>  

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/