Re: [take12 3/3] kevent: Timer notifications.

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

On Mon, Aug 21, 2006 at 02:13:49PM +0200, Arjan van de Ven (arjan@infradead.org) wrote:
> > > Call me a cynic, but I'm always a bit sceptical about needing lockdep
> > > annotations like this... Can you explain why you need it in this case,
> > > including the proof that it's safe?
> > 
> > Ok, again :)
> > Kevent uses meaning of storage of kevents without any special knowledge
> > what is is (inode, socket, file, timer - anything), so it's
> > initalization function among other things calls spin_lock_init().
> > Lockdep inserts static variable just before real spinlock
> > initialization, and since all locks are initialized in the same place,
> > all of them get the same static magic.
> > Later those locks are used in different context (for example inode
> > notificatins only in process context, but socket can be called from BH
> > context), since lockdep thinks they are the same, it screams.
> > Obviously the same inode can not be used for sockets and files, so I
> > added above lockdep initialization.
> 
> ok... but since kevent doesn't know what is in it, wouldn't the locking
> rules need to be such that it can deal with the "worst case" event? Eg
> do you really have both no knowledge of what is inside, and specific
> locking implementations for the different types of content??? That
> sounds rather error prone.....
> (if you had consistent locking rules lockdep would be perfectly fine
> with that)

It is tricky - currently there is RCU protection for storage list
traversal from each origin, i.e. the that path takes a lock when
kevent is really ready (to put it into ready list) and to check kevent's
flags (actually event that could be replced by more strict callback's 
return values).
No existing origins call kevent_storage_ready() from context where it
can be reentered (it guarantees from other side that locks will not be
reentered), so in theory that lockdep tricks are not needed right now
(they were added before I moved list traversal to RCU).

In the current code storage->lock is safe and correct from lockdep point 
of view (since different origins are never crossed), so I have not
changed reinit.

> -- 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com

-- 
	Evgeniy Polyakov