Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error

From: Linus Torvalds
Date: Sun Sep 25 2016 - 21:21:29 EST

Thanks, applied.

I did happen to notice:

On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> ./include/linux/pagemap.h: In function Âfault_in_multipages_readableÂ:
> ./include/linux/pagemap.h:602:16: error: variable Âc set but not used [-Werror=unused-but-set-variable]

You have some nasty unicode corruption. The email is marked as being

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

but those are not the right unicode characters. I think gcc actually
uses back-tick and tick (which is ugly as hell in many fonts since
they aren't generally necessarily symmetric, but oh well). So some
cut-and-paste path of yours corrupted the utf8.

Obviously not a big deal, but you might want to look at your character
set setting in your mailer or other environment. Perhaps some odd
non-utf8 editor environment or something?

I also noticed:

> This is a regression caused by commit e23d415 ("fix
> fault_in_multipages_...() on architectures with no-op access_ok()").

I'd suggest doing

git config --global core.abbrev 12

because the default git commit shortening value of 7 is practically
too short for the kernel these days. What can I say? I was naÃve, and
based my original abbreviation decision on the BitKeeper numbers,
where we were just about to hit 64k commits. So seven hex digits
seemed plenty. And now, ten years later, I just look stupid.

Anyway - while git will always pick a shortname that is unique (ie it
will add characters until it is unique), it's unique only at that
moment in time. And practically speaking seven hex digits can easily
have collisions in the hear future (ie it already happens with many

So telling git "give me a minimum of 12 hex digits in hash
abbreviations" should be fairly safe for a while.

I guess I should ping Junio and see if we can just change the default,
but for smaller projects the default abbreviation is likely still
reasonable. So I've been just mentioning that simple "set core.abbrev
to 12" to kernel people..