Re: [RFC] free_pages stuff

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Dec 21, 2015 at 05:23:11PM -0800, Linus Torvalds wrote:

> And if the code really explicitly wants a page (or set of aligned
> pages) for some vm reason, I suspect having the cast there isn't a bad
> thing. It's clearly not just a random pointer allocation if the bit
> pattern of the pointer matters.
> 
> And yes, most of the people who used to want "unsigned long" have long
> since been converted to take "struct page *" instead, since things
> like the VM wants highmem pages etc.  There's a reason why the
> historical interface returns "unsigned long": it _used_ to be the
> right thing for a lot of code. The fact that there now are more casts
> than not are about changing use patterns, but I don't think that means
> that we should change the calling convention that has a historical
> reason for it.

Umm...  Depends on how early you look.  In 0.01:
fs/exec.c:179:                  if (!(page[i]=get_free_page()))
fs/inode.c:208: if (!(inode->i_size=get_free_page())) {
kernel/fork.c:70:       p = (struct task_struct *) get_free_page();
mm/memory.c:143:                if (!(to_page_table = (unsigned long *) get_free_page()))
mm/memory.c:185:                if (!(tmp=get_free_page()))
mm/memory.c:203:        if (!(new_page=get_free_page()))
mm/memory.c:241:        if (tmp=get_free_page())

the last 3 are "we want struct page *" variety, the rest is "want a pointer"
stuff (exec.c one is copy_strings() and the only use of pages[...] is a cast
to char *, inode.c one is get_pipe_inode() - I guess you didn't want to bother
with adding pipe-specific fields to struct inode at that point and since
->i_size is unused for pipes anyway reused it to keep a pointer to pipe
buffer).  Even then it wasn't the majority.

By 2.0 (still before highmem) the fraction was already _way_ below 50%...