From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034796AbcIZC0I (ORCPT ); Sun, 25 Sep 2016 22:26:08 -0400 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:10153 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S941237AbcIZC0D (ORCPT ); Sun, 25 Sep 2016 22:26:03 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIfABqG6Fd5LJiaEGdsb2JhbABdGgEBAQECAQEBAQgBAQEBgzsBAQEBAR6BU4J6g3mcSQEBAgEHjQqDcIZBhhgCAgEBAoFATQECAQEBAQECBgEBAQEBAQEBN0BBDIQUAQEBAwEMJgEjIwULCAMYCSUPBSUDBxoKCYhDB710AQEBAQYCASQehU+FHoE8AYJZEQGDS4IvBY40i0KMLYMxgg+NZkiMI4N8g2wBDQ8YgUosNIJxgmuCHwEBAQ Date: Mon, 26 Sep 2016 12:25:59 +1000 From: Dave Chinner To: Linus Torvalds Cc: Linux Kernel Mailing List , Al Viro Subject: Re: [PATCH] [4.8-rc7, regression] fault_in_multipages_readable() throws set-but-unused error Message-ID: <20160926022559.GB27872@dastard> References: <1474847853-9668-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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