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: <20160926022559.GB27872@dastard>
Date:   Mon, 26 Sep 2016 12:25:59 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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

On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> 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

It's whatever git-send-email spat out. I was under the impression it
encodes like that whenever it sees a utf-8 character in a commit...

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

Yup, normally I remember to fix that up when composing the patch -
ever since GNU went to those fucked up "grammatically correct"
non-ascii quotes it's caused problems with pasting error messages
into ascii-only contexts.

> 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 turned off utf-8 support in vim on the machine I write all my code
on - I got sick of stupid stray marks in my code, digraphs being
composed when I just want to replace a single character, git sending
patches in utf-8 encoding because I copied a SoB with a utf-8
character in the name, etc....

> 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

Ok.

> because the default git commit shortening value of 7 is practically
> too short for the kernel these days.

7 characters, 12 characters, whatever. Neither make any sense in
commit messages by themselves without the short description that
goes along with the hash.....

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com