From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936254AbdADMWN (ORCPT ); Wed, 4 Jan 2017 07:22:13 -0500 Received: from imap.thunk.org ([74.207.234.97]:38034 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752243AbdADMWJ (ORCPT ); Wed, 4 Jan 2017 07:22:09 -0500 Date: Wed, 4 Jan 2017 07:22:05 -0500 From: "Theodore Ts'o" To: David Binderman Cc: "adilger.kernel@dilger.ca" , "linux-ext4@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: fs/ext4/indirect.c:81: possible 32 / 64 bit mixup ? Message-ID: <20170104122205.n6ex2h54kmcevs5d@thunk.org> Mail-Followup-To: Theodore Ts'o , David Binderman , "adilger.kernel@dilger.ca" , "linux-ext4@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 04, 2017 at 10:40:38AM +0000, David Binderman wrote: > Hello there, > > linux-4.10-rc2/fs/ext4/indirect.c:81]: (style) int result is assigned to long variable. If the variable is long to avoid loss of information, then you have loss of information. The on disk representation of indirect blocks is a u32. Which is to say, you can't use an indirect block mapped inode to address physical block numbers beyond 2**32. A 64-bit ext4 file system normally only uses extent-mapped inodes, which can address the full set of block numbers. It is _possible_, but rare to have a 64-bit file system with indirect blocks. The only way it can happen in practice is with a 32-bit file system that is later converted to be 64-bit using an off-line conversion process. (Which many distributions don't support beecause it's one more thing for their QA folks to test; it also requires the latest e2fsprogs 1.43.x utilities, and since it's relatively new code, I usually tell people to backup their file system first. That way, if it succeeds, it's faster than doing a backup, mkfs, restore sequence; and if it fails, you can always fall back to that. :-) Cheers, - Ted