On Tue, May 31, 2011 at 03:12:07PM +0200, Lukas Czerner wrote:
> On Tue, 31 May 2011, Greg KH wrote:
> 
> > On Tue, May 31, 2011 at 12:33:18PM +0200, Lukas Czerner wrote:
> > > On Tue, 31 May 2011, Lukas Czerner wrote:
> > > 
> > > > We need to take reference to the s_li_request after we take a mutex,
> > > > because it might be freed since then, hence result in accessing old
> > > > already freed memory. Also we should protect the whole
> > > > ext4_remove_li_request() because ext4_li_info might be in the process of
> > > > being freed in ext4_lazyinit_thread().
> > > > 
> > > > Signed-off-by: Lukas Czerner <[email protected]>
> > > > Reviewed-by: Eric Sandeen <[email protected]>
> > > > ---
> > > >  fs/ext4/super.c |   10 ++++++----
> > > >  1 files changed, 6 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > > > index fd51a4a..ed5e80e 100644
> > > > --- a/fs/ext4/super.c
> > > > +++ b/fs/ext4/super.c
> > > > @@ -2735,14 +2735,16 @@ static void ext4_remove_li_request(struct 
> > > > ext4_li_request *elr)
> > > >  
> > > >  static void ext4_unregister_li_request(struct super_block *sb)
> > > >  {
> > > > -       struct ext4_li_request *elr = EXT4_SB(sb)->s_li_request;
> > > > -
> > > > -       if (!ext4_li_info)
> > > > +       mutex_lock(&ext4_li_mtx);
> > > > +       if (!ext4_li_info) {
> > > > +               mutex_unlock(&ext4_li_mtx);
> > > >                 return;
> > > > +       }
> > > >  
> > > >         mutex_lock(&ext4_li_info->li_list_mtx);
> > > > -       ext4_remove_li_request(elr);
> > > > +       ext4_remove_li_request(EXT4_SB(sb)->s_li_request);
> > > >         mutex_unlock(&ext4_li_info->li_list_mtx);
> > > > +       mutex_unlock(&ext4_li_mtx);
> > > >  }
> > > >  
> > > >  static struct task_struct *ext4_lazyinit_task;
> > > > 
> > > 
> > > 
> > > This is upstream commit 1bb933fb1fa8e4cb337a0d5dfd2ff4c0dc2073e8
> > 
> > Ok, and what stable kernel trees do you want to see it applied to?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Oh, sorry. I would like it to be applied to stable 2.6.37, 2.6.38,
> 2.6.39.

Ok, but there is no stable .37 kernel tree anymore :)

I'll queue this up in a day or so.

thanks,

greg k-h

_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

Reply via email to