From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752702AbbLVDKT (ORCPT <rfc822;w@1wt.eu>);
	Mon, 21 Dec 2015 22:10:19 -0500
Received: from zeniv.linux.org.uk ([195.92.253.2]:33991 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752333AbbLVDKQ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 21 Dec 2015 22:10:16 -0500
Date: Tue, 22 Dec 2015 03:10:14 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] free_pages stuff
Message-ID: <20151222031013.GZ20997@ZenIV.linux.org.uk>
References: <20151221234615.GW20997@ZenIV.linux.org.uk>
 <CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com>
 <20151222010403.GX20997@ZenIV.linux.org.uk>
 <CA+55aFy9NrV_RnziN9z3p5O6rv1A0mirhLD0hL7Wrb77+YyBeg@mail.gmail.com>
 <CA+55aFwyxJ+TOpaJZnC5MPJ-25xbLAEu8iJP8zTYhmA3LXFF8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFwyxJ+TOpaJZnC5MPJ-25xbLAEu8iJP8zTYhmA3LXFF8Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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%...