From: Dave Chinner <david@fromorbit.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error
Date: Mon, 26 Sep 2016 12:25:59 +1000 [thread overview]
Message-ID: <20160926022559.GB27872@dastard> (raw)
In-Reply-To: <CA+55aFzN5TUBof1Hj6RKSqvoduT5JYCTr_DzBHvsar92r55fDg@mail.gmail.com>
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@fromorbit.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@fromorbit.com
next prev parent reply other threads:[~2016-09-26 2:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-25 23:57 Dave Chinner
2016-09-26 1:21 ` Linus Torvalds
2016-09-26 2:25 ` Dave Chinner [this message]
2016-09-26 3:06 ` Linus Torvalds
2016-09-26 11:24 ` Stephen Rothwell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160926022559.GB27872@dastard \
--to=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®