Re: [PATCH 004 of 4] Make address_space_operations->invalidatepage return void

[Neil Brown <neilb@suse.de>]

On Monday March 13, shaggy@austin.ibm.com wrote:
> On Mon, 2006-03-13 at 10:53 +1100, NeilBrown wrote:
> > diff ./fs/jfs/jfs_metapage.c~current~ ./fs/jfs/jfs_metapage.c
> > --- ./fs/jfs/jfs_metapage.c~current~    2006-03-09 17:29:35.000000000
> > +1100
> > +++ ./fs/jfs/jfs_metapage.c     2006-03-13 10:46:55.000000000 +1100
> > @@ -578,14 +578,13 @@ static int metapage_releasepage(struct p
> >         return 0;
> >  }
> >  
> > -static int metapage_invalidatepage(struct page *page, unsigned long
> > offset)
> > +static void metapage_invalidatepage(struct page *page, unsigned long
> > offset)
> >  {
> >         BUG_ON(offset);
> >  
> > -       if (PageWriteback(page))
> > -               return 0;
> > +       BUG_ON(PageWriteback(page));
> 
> I'm a little concerned about adding a BUG_ON for something this function
> used to allow, but it looks like the BUG_ON is valid.  I'm asking myself
> why did I add the test for PageWriteback in the first place.

Yes.... as far as I can tell, ->invalidatepage is only called with
the page locked, and with Writeback clear, so PageWriteback can never
be true.  So the BUG_ON should be a no-op.

> 
> >  
> > -       return metapage_releasepage(page, 0);
> > +       metapage_releasepage(page, 0);
> >  }
> >  
> >  struct address_space_operations jfs_metapage_aops = { 
> 
> I'll try to stress test jfs with these patches to see if I can trigger
> the an oops here.

Thanks.  I'd be very interested if you do.
I got on oops with a similar bug_on in the new nfs_invalidatepage and
it turned out to be a bug in radixtree (which I had already found and
fixed, but not in that source tree).

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