From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753761AbbK0BcK (ORCPT ); Thu, 26 Nov 2015 20:32:10 -0500 Received: from mga01.intel.com ([192.55.52.88]:9541 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753593AbbK0BcI (ORCPT ); Thu, 26 Nov 2015 20:32:08 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,349,1444719600"; d="scan'208";a="829844853" Date: Fri, 27 Nov 2015 09:31:54 +0800 From: Fengguang Wu To: Joe Perches Cc: Julia Lawall , Al Viro , "Theodore Ts'o" , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix an endianness bug in ext4_encrypted_follow_link() Message-ID: <20151127013154.GA23817@wfg-t540p.sh.intel.com> References: <20151126152728.GT22011@ZenIV.linux.org.uk> <1448566837.18647.16.camel@perches.com> <20151126210223.GV22011@ZenIV.linux.org.uk> <1448578076.18647.37.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448578076.18647.37.camel@perches.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 26, 2015 at 02:47:56PM -0800, Joe Perches wrote: > On Thu, 2015-11-26 at 22:28 +0100, Julia Lawall wrote: > > On Thu, 26 Nov 2015, Al Viro wrote: > > > On Thu, Nov 26, 2015 at 11:40:37AM -0800, Joe Perches wrote: > > > (cc'ing Julia Lawall) > > > > On Thu, 2015-11-26 at 15:27 +0000, Al Viro wrote: > > > > applying le32_to_cpu() to 16bit value is a bad idea... > > > Julia, perhaps you or your crew could produce a coccinelle test > > > for this class of error? > > What's wrong with something like make C=2 CF=-D__CHECK_ENDIAN__ fs/ext4/ ? > > Worked just fine, TYVM - > > sparse does locate them... > > Nothing at all. > > > As long as the code of interest is getting compiled in the current > > configuration, relying on the compiler for this seems like a better choice. > > Sparse isn't the compiler, but that would be fine by me > as long as something can catch them. > > The original commit (f348c252320b9) was from April. > Isn't the kbuild robot using sparse and __CHECK_ENDIAN__? Yes 0day did catch the sparse warning, however it seems the email somehow failed to get delivered. Here is the local record: Date: Mon, 13 Apr 2015 16:41:54 +0800 From: kbuild test robot To: Theodore Ts'o Cc: kbuild-all@01.org, Uday Savagaonkar Subject: [ext4:dev 32/33] fs/ext4/namei.c:3262:25: sparse: incorrect type in assignment (different base types) Message-ID: <201504131652.Ox8dW5C0%fengguang.wu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) tree: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev head: 3a19824f63e0a0df99c0a133097eb87c0152545e commit: f1195c72c95115858123813e9a84badad37424c0 [32/33] ext4 crypto: Add symlink encryption reproduce: # apt-get install sparse git checkout f1195c72c95115858123813e9a84badad37424c0 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> fs/ext4/namei.c:3262:25: sparse: incorrect type in assignment (different base types) fs/ext4/namei.c:3262:25: expected restricted __le16 [usertype] len fs/ext4/namei.c:3262:25: got restricted __le32 [usertype] -- >> fs/ext4/symlink.c:74:29: sparse: cast to restricted __le32 >> fs/ext4/symlink.c:74:29: sparse: cast from restricted __le16 Thanks, Fengguang