From patchwork Sat Mar 19 21:12:05 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 599804 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qSFDC2wVbz9s5l for ; Sun, 20 Mar 2016 08:12:43 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=MKBskcZ8; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755225AbcCSVMY (ORCPT ); Sat, 19 Mar 2016 17:12:24 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33381 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755200AbcCSVMX (ORCPT ); Sat, 19 Mar 2016 17:12:23 -0400 Received: by mail-wm0-f66.google.com with SMTP id x188so13438512wmg.0; Sat, 19 Mar 2016 14:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=U7HsWmfu/cRGGPs0Bl0/8I1AHtU5UKh6gb6bXoU0paY=; b=MKBskcZ8I2d3elSzkYIh6PIY62rN8sOzsaMdq6l9p1hC7bBElsL9rz8M+tOAeLfq4F /BRsQLDSg+DcbFszA0K4z7KN9JxtTZGTy7lIQptdejfg8aMy6ZWeXQYE4q9855K+iHYS QvBykCjrgP1w3nOP1FsBaN4zXEjuDjHAiIFmZ0GveIELLzBJdwrcJZq6Z2q6lVw8Vi9D oy+wkE30hhZh2/S5tCaChuLFKjtOEgkOXgaqfQFf4cuWX9FrEvf4YGVX2Tkz+/BOUeRY 6Z06X3wBhxGThACnSP6bUkK3Wn8KSToLDdCsVSAZ8eDkdFCW0cwNiTuUAXqCBNbaqK24 f2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=U7HsWmfu/cRGGPs0Bl0/8I1AHtU5UKh6gb6bXoU0paY=; b=ERSBJCTz4hCHqko331nvUyGSjkW7uYLSpJaze9joDPpvgsMICWJT31LL9ezj/T5tLe ECf9UsRJQBgr5HERsllFHK588QPBFH6JyHfCGQFYuAm8ap/NlJTLgdHEuULeEKhLKIxP of/3QdVuMHAY3/dYTeoU1sK7+ihtcQ+A61o5IkUjjQx+GXybuyXUlXRXnxLTX18UFb1F ucHqeVz8Mx4YQ2HqReEBOvhcFwJayoO2U6Zxt1W8yJdfc0DtGqiCc+BtL6NE2afA1V46 PJJVkLSwxm+6P4Q4uY4wdGdH8XxZB63+ZkRLO73pI5CQ397Qkk+HvraF51THQoP1WVS+ nYww== X-Gm-Message-State: AD7BkJK+IaE7x+Ttky6k4n75m9siFj9IC1lESkUozMfPv1FqXXhTS7mfv+38/u6D4uMBQQ== X-Received: by 10.28.23.70 with SMTP id 67mr5518449wmx.70.1458421941647; Sat, 19 Mar 2016 14:12:21 -0700 (PDT) Received: from localhost (f054124197.adsl.alicedsl.de. [78.54.124.197]) by smtp.gmail.com with ESMTPSA id h67sm5146821wmf.15.2016.03.19.14.12.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Mar 2016 14:12:21 -0700 (PDT) From: Nicolai Stange To: "Theodore Ts'o" , Andreas Dilger Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Nicolai Stange Subject: [PATCH v2 2/2] fs/ext4: ext4_mb_init(): silence UBSAN Date: Sat, 19 Mar 2016 22:12:05 +0100 Message-Id: <1458421925-5481-3-git-send-email-nicstange@gmail.com> X-Mailer: git-send-email 2.7.3 In-Reply-To: <1458421925-5481-1-git-send-email-nicstange@gmail.com> References: <1458421925-5481-1-git-send-email-nicstange@gmail.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Currently, in ext4_mb_init(), there's a loop like the following: do { ... offset += 1 << (sb->s_blocksize_bits - i); i++; } while (i <= sb->s_blocksize_bits + 1); Note that the updated offset is used in the loop's next iteration only. However, at the last iteration, that is at i == sb->s_blocksize_bits + 1, the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15 shift exponent 4294967295 is too large for 32-bit type 'int' [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? kmem_cache_alloc+0x101/0x390 [] ? ext4_mb_init+0x13b/0xfd0 [] ? create_cache+0x57/0x1f0 [] ? create_cache+0x11a/0x1f0 [] ? mutex_lock+0x38/0x60 [] ? mutex_unlock+0x1b/0x50 [] ? put_online_mems+0x5b/0xc0 [] ? kmem_cache_create+0x117/0x2c0 [] ext4_mb_init+0xc49/0xfd0 [...] Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1. Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of offset is never used again. Silence UBSAN by introducing another variable, offset_incr, holding the next increment to apply to offset and adjust that one by right shifting it by one position per loop iteration. Signed-off-by: Nicolai Stange --- fs/ext4/mballoc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 4bc89fe..8dc0d9b 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -2585,7 +2585,7 @@ int ext4_mb_init(struct super_block *sb) { struct ext4_sb_info *sbi = EXT4_SB(sb); unsigned i, j; - unsigned offset; + unsigned offset, offset_incr; unsigned max; int ret; @@ -2614,11 +2614,13 @@ int ext4_mb_init(struct super_block *sb) i = 1; offset = 0; + offset_incr = 1 << (sb->s_blocksize_bits - 1); max = sb->s_blocksize << 2; do { sbi->s_mb_offsets[i] = offset; sbi->s_mb_maxs[i] = max; - offset += 1 << (sb->s_blocksize_bits - i); + offset += offset_incr; + offset_incr = offset_incr >> 1; max = max >> 1; i++; } while (i <= sb->s_blocksize_bits + 1);