Re: kmemcheck caught read from freed memory (cfq_free_io_context)

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Apr 02, 2008 at 03:16:25PM +0200, Fabio Checconi wrote:
> > From: Jens Axboe <jens.axboe@oracle.com>
> > Date: Wed, Apr 02, 2008 02:58:58PM +0200
> >
> > On Wed, Apr 02 2008, Jens Axboe wrote:
> > > On Wed, Apr 02 2008, Fabio Checconi wrote:
> > > > > From: Jens Axboe <jens.axboe@oracle.com>
> > > > > Date: Wed, Apr 02, 2008 02:36:39PM +0200
> > > > >
> > > > > > Looks good and tests fine as well. I've applied it, on top of the
> > > > > > hlist_for_each_entry_safe_rcu() fix.
> > > > > > 
> > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=436151ad32b4a59e0d36165a7d6312545f126661
> > > > > > 
> > > > 
> > > > ok, thanks.  anyway I don't think the hlist_for_each_entry_safe_rcu()
> > > > is needed at this point, since the pos->next pointer is still valid
> > > > (at least) until the next rcu_read_unlock().  am I wrong?
> > > 
> > > it isn't, but it's still clearer. so either that or a nice comment, I
> > > just stuck with what I had already committed.
> > 
> 
> ok I agree on that.  the only remaining concern I have is that when
> I first looked at it it seemed to me that hlist_for_each_entry_safe_rcu()
> was missing by purpose from the list interface, since hlist_del_rcu()
> can be called anyway during the traversal from a concurrent context,
> so the semantics of *_safe_* have to be carried out by other means
> (i.e., call_rcu()).

Exactly.  ;-)

							Thanx, Paul