From patchwork Sat Mar 19 21:12:04 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolai Stange X-Patchwork-Id: 599805 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 3qSFDf0mY9z9s5l for ; Sun, 20 Mar 2016 08:13:06 +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=pMy0KOjD; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755269AbcCSVMw (ORCPT ); Sat, 19 Mar 2016 17:12:52 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:33369 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755075AbcCSVMV (ORCPT ); Sat, 19 Mar 2016 17:12:21 -0400 Received: by mail-wm0-f65.google.com with SMTP id x188so13438452wmg.0; Sat, 19 Mar 2016 14:12:20 -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=XRMInr9c9yeyCZ+mvJKUiEbkZm0r0b2PpdBNDFd3mzM=; b=pMy0KOjDiETlFd+abpnGWwcrIaG7BN2mckfcze4v7L1HfUrVC6pk0P5KxngL/lEd/X IoToHnceXI8uDIqzuCt9PA3VYQlSf/yTGNDxoyAQKBkoprSw+rYzksshWAowS5YH3uJo mFYDMyb4fwaZmq2EZmFcqQmsezOPlgQlmyUy7CiKJsmC6v3snlQKRLPmxpxYz5wznwor 4I3aIV6GRU2To/4XsPOMxmoYRSOfyRrVoPpiEsHif7tP9xfydGQ4NCUbTeLlsxeymxda fVe2zNhXJ1ok7qSsDXLBW3WXE4krzgK4aVQcPITkCS78JJrgBle9At156APT2ydFhSo0 onYQ== 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=XRMInr9c9yeyCZ+mvJKUiEbkZm0r0b2PpdBNDFd3mzM=; b=FUyLwXdpvYxpY4WHnwx2sQXzGsbzn5vUp2lwAQxGjBSK8hzUWrcW9uVoQzYbwqWVKA uvw/HIWh/H/+5aemkwHI2wQTo3POKeEoL5cKiyw3eMg99rDaWPjt+yN7D585UhijdNV6 gYxWb8MvydckpfnbOL4hL3ks094u45np9P+Qvcuqid2nX3fcjIIk5UcxerOEQoEovFBp 5hz6416tCKhWMRkkMmV/z987hG+ib9hZNbeprpMUmCIKS4KjVGpNH5p53fp/ecxZ8DEn E8VobZvkmQ0lAROFyf4b6q2pKFo8Uvv6ldhZkp9HPdoguFDuNtXYAboaHlv/wfp8KXkI shnA== X-Gm-Message-State: AD7BkJJaw9alAbRaGGZojWa28ysfF/uN8kRaw6vPyOpxQMJfEkB35A2aSf6F3mGRpzXw4Q== X-Received: by 10.28.15.211 with SMTP id 202mr5385470wmp.31.1458421939995; Sat, 19 Mar 2016 14:12:19 -0700 (PDT) Received: from localhost (f054124197.adsl.alicedsl.de. [78.54.124.197]) by smtp.gmail.com with ESMTPSA id bg1sm18058999wjc.27.2016.03.19.14.12.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Mar 2016 14:12:19 -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 1/2] fs/ext4: mb_find_order_for_block(): silence UBSAN Date: Sat, 19 Mar 2016 22:12:04 +0100 Message-Id: <1458421925-5481-2-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 mb_find_order_for_block(), there's a loop like the following: while (order <= e4b->bd_blkbits + 1) { ... bb += 1 << (e4b->bd_blkbits - order); } Note that the updated bb is used in the loop's next iteration only. However, at the last iteration, that is at order == e4b->bd_blkbits + 1, the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11 shift exponent -1 is negative [...] 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 [] ? ext4_mb_generate_from_pa+0x590/0x590 [] ? ext4_read_block_bitmap_nowait+0x598/0xe80 [] mb_find_order_for_block+0x1ce/0x240 [...] 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 bb is never used again. Silence UBSAN by introducing another variable, bb_incr, holding the next increment to apply to bb and adjust that one by right shifting it by one position per loop iteration. Signed-off-by: Nicolai Stange --- fs/ext4/mballoc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 50e05df..4bc89fe 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -1266,6 +1266,7 @@ static void ext4_mb_unload_buddy(struct ext4_buddy *e4b) static int mb_find_order_for_block(struct ext4_buddy *e4b, int block) { int order = 1; + int bb_incr = 1 << (e4b->bd_blkbits - 1); void *bb; BUG_ON(e4b->bd_bitmap == e4b->bd_buddy); @@ -1278,7 +1279,8 @@ static int mb_find_order_for_block(struct ext4_buddy *e4b, int block) /* this block is part of buddy of order 'order' */ return order; } - bb += 1 << (e4b->bd_blkbits - order); + bb += bb_incr; + bb_incr >>= 1; order++; } return 0;