Hey Matt,
I've stumbled across this code in do_read_cache_page():
struct folio *folio;
folio = do_read_cache_folio(mapping, index, filler, file, gfp);
if (IS_ERR(folio))
return &folio->page;
return folio_file_page(folio, index);
Following 'do_read_cache_folio()' I see that it does things like
folio = filemap_alloc_folio(gfp, 0);
if (!folio)
return ERR_PTR(-ENOMEM);
Now I freely admit that my knowledge of folios is hazy at best, but
dereferencing an error pointer is something I would seriously frown upon
if I were to review the code.
Care to explain?
Or is it, indeed, simply a bug?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
Hi Matthew!
On Mon 27-06-22 07:17:35, Matthew Wilcox wrote:
> &folio->page does not dereference the pointer, it simply performs
> arithmetic on it. In this case, adding zero. It also changes the type from
> folio to page. There's no bug here.
I agree there's no functional bug there (at least yet). But arguably this
would be much more readable and definitely more future-proof as:
return (struct page *)ERR_CAST(folio);
Because even doing arithmetics on error pointer is fishy...
Honza
>
> On Mon., Jun. 27, 2022, 04:12 Hannes Reinecke, <[email protected]> wrote:
>
> > Hey Matt,
> >
> > I've stumbled across this code in do_read_cache_page():
> >
> > struct folio *folio;
> >
> > folio = do_read_cache_folio(mapping, index, filler, file, gfp);
> > if (IS_ERR(folio))
> > return &folio->page;
> > return folio_file_page(folio, index);
> >
> > Following 'do_read_cache_folio()' I see that it does things like
> >
> > folio = filemap_alloc_folio(gfp, 0);
> > if (!folio)
> > return ERR_PTR(-ENOMEM);
> >
> > Now I freely admit that my knowledge of folios is hazy at best, but
> > dereferencing an error pointer is something I would seriously frown upon
> > if I were to review the code.
> > Care to explain?
> > Or is it, indeed, simply a bug?
> >
> > Cheers,
> >
> > Hannes
> > --
> > Dr. Hannes Reinecke Kernel Storage Architect
> > [email protected] +49 911 74053 688
> > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 N?rnberg
> > HRB 36809 (AG N?rnberg), GF: Felix Imend?rffer
> >
--
Jan Kara <[email protected]>
SUSE Labs, CR