Re: [PATCH 1/5] mm: Constify a lot of struct page arguments

["Kirill A. Shutemov" <kirill@shutemov.name>]

On Thu, Apr 09, 2020 at 07:15:50AM -0700, Matthew Wilcox wrote:
> On Thu, Apr 09, 2020 at 05:09:14PM +0300, Kirill A. Shutemov wrote:
> > On Wed, Apr 08, 2020 at 08:01:44AM -0700, Matthew Wilcox wrote:
> > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > > index 4aba6c0c2ba8..a8c3fa076f43 100644
> > > --- a/include/linux/mm_types.h
> > > +++ b/include/linux/mm_types.h
> > > @@ -221,15 +221,8 @@ struct page {
> > >  #endif
> > >  } _struct_page_alignment;
> > >  
> > > -static inline atomic_t *compound_mapcount_ptr(struct page *page)
> > > -{
> > > -	return &page[1].compound_mapcount;
> > > -}
> > > -
> > > -static inline atomic_t *compound_pincount_ptr(struct page *page)
> > > -{
> > > -	return &page[2].hpage_pinned_refcount;
> > > -}
> > > +#define compound_mapcount_ptr(page)	(&(page)[1].compound_mapcount)
> > > +#define compound_pincount_ptr(page)	(&(page)[2].hpage_pinned_refcount)
> > 
> > Looks like this conversion is not covered by the reason given in the
> > commit message. Hm?
> 
> They were supposed to be covered by "That means some inline functions
> have to become macros so they can return a struct page which is the same
> const-ness as their argument."
> 
> They're not quite covered since they need to return an atomic_t that
> is the same constness as their argument.

Ah, right.

> > > +#define compound_head(page) ({						\
> > > +	__typeof__(page) _page = page;					\
> > > +	unsigned long head = READ_ONCE(_page->compound_head);		\
> > > +	if (unlikely(head & 1))						\
> > > +		_page = (void *)(head - 1);				\
> > > +	_page;								\
> > > +})
> > 
> > Ugh..
> > 
> > Other option would be to make compound_head() take 'const struct page *'
> > and return 'void *'. It arguably would provide better type safety, no?
> 
> We have a few places that do things like
> 
> mm/filemap.c:           if (unlikely(compound_head(page)->mapping != mapping)) {

Good point.

Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

-- 
 Kirill A. Shutemov