linux-kernel - Re: [PATCH] [4.8-rc7, regression] fault_in_multipages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFzN5TUBof1Hj6RKSqvoduT5JYCTr_DzBHvsar92r55fDg@mail.gmail.com>
Date:   Sun, 25 Sep 2016 18:21:05 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dave Chinner <david@...morbit.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable()
 throws set-but-unused error

Thanks, applied.

I did happen to notice:

On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner <david@...morbit.com> 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
commits).

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

              Linus