From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0466334403A for ; Tue, 12 May 2026 02:16:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778552173; cv=none; b=l3IaZS5HD+THr1pQWF0T4GD68z5xMtyr+7NsuxHt+sb6UaV3g9IDXS4dW09mqNkKxjG/thC5/6+5f1Qqg/K7VAAjdUN79mBx8wVJZrK110bRZ42BKlwA+4rymQTpPozCqmWUe7+1UIRl+LKh6qJy9d9RnHQ+5+vzFYD/mmtT/B8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778552173; c=relaxed/simple; bh=P+q9UUBZTVPw5TkujswOPQoFe7jrHdnRfV8HXiKF0K8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=E7GSnq+8wwBt4k2wOd2sbRtQ8pphvubOrRKXe/+gnBAdUcA8p1ac8X4te+2GpkIhjatbNvoeGGRkaTCHpWQYDec+1AqWDshJN9zqqpNCrjoiL4diAlVk1m9u1DETXLp0zd2ORj8S8ydgcuH1kman5DbqVY+M4grALX1dGPqGArE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=f7wccxR9; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="f7wccxR9" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-83d31ac4017so1706679b3a.3 for ; Mon, 11 May 2026 19:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778552171; x=1779156971; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=o73m3dQgHqFuu5RPyAMqDNOcllL4aap7hOBC+h+RpYc=; b=f7wccxR9ypvwBKpJ/Xg9kBj2rAtqwmN72pU431oVzbSL2w1sMkDG4UDCfd4HqSPAk0 VL9DEhC3eea8Eb70DhUKIuu/lmrDL7+nUKvAdE0egjPbev2mZsyDAY04/DauHSPZkKNt Crp3dKtvTQJnA2+oNlN4Tt3dIw80hmG+kbAetGcngRhHGQNR2XaXS/4x2zdGCuLpE8UZ tCEBUUiirB1498HHkFQ1JBdSKz9R3jYEOmsGa1H+ds6DCWf6zAQ4dQfAjgCryMAVoNCi F5VimRQOBpGev4StjuGjmy5qlq16HeR+bjV79hI18nDKk1hjdd+iKhNUw0Ezopf07qTQ nLtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778552171; x=1779156971; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=o73m3dQgHqFuu5RPyAMqDNOcllL4aap7hOBC+h+RpYc=; b=GE5O9zNaYP+3zYOSNdIMl8I7LCA/oGXS1gajHAUTwnIwMUiaqb5RYzPNUnE+C1iTpA gYW/Be/uVwJCcnSFZZ0MSwNislHC1yTp7+1pDzs3j93ipe7vql2RW6hlEIs9nHqMwj7l wzs3lJdFZSF6NWPsEurhPhqH10Afv6GV9JThiDZFQ8Cx7Ry/pmVCHKtZ5Fx5s89n9xVb ylCk457qFp27wyp+t9pNo84Mg27wCbnQs4yjoRklShlSrygs8r9YGLFYLfiJojcDeF9u KkXV7Q53PsncyiwxTV85/epq8UFPrcYEF6QdfvXtRPcatT5mQcuSP6R7NCok8F4r9qrH YQgQ== X-Forwarded-Encrypted: i=1; AFNElJ/mG7vPPF4znA+jY3CZ7+TY5+cfGdKFUpcT8dJpuSdf84YEzqpBurznKeKzyEjPx4KQpPY29PXOId4IBso=@vger.kernel.org X-Gm-Message-State: AOJu0YxwSeU0Grl/rp/DIyLxbJSdoDMJiIavCD6FtU+nsMA/oxTFdRv1 WHfqCK0eKagBnPLXkC7CHkTCQKrd0MAB9KAavBnkDITSDMGM/5a5ZIpu X-Gm-Gg: Acq92OHu9d5qUEx/9sDuxHBIsWON/tx+JlRwLr4jmFNYVwBOPKN1loghKkCSvRrG8Ns dQrWMZFreSnC9u5dBt1/Cu77SJLJLc1pBmDHlh7qcL9KO7PJyxcfLqpQyAsKdPqzcpgZb+cGTWh jPPQ6UpiFTjUu9kmGAT1RECb65jq/FMtLVBgB8fGRgIKOr+Y92ks0MojkmloFgLDzBkxNZB+16u ci172tEojp1QHvzffwe+80lbEk8p0+chMyH0ItMxfo4Uc/6eNwWOYOhqFFYVrs72jBcIpy9oKg/ uaZP6bC1SGVDtVOb0f8W68Guen5iYTKy3PxKJRxxVf+Xl7ibURDk64QiSnutvcf9JsY/VYUCeQH pGaG9VuqDU8lQJ/MouAs3NJvsc80k+tm8NwnvCUuxgR8D4QjFjixSzohFft1MBnK15jSI+0gP66 XQe7eX5J7WrXjRCgW1ab3chufaPO4owX1HsnpIQhi0AdbvtCloI3zZv47NGUa/hxi6XnnipdutA Jrr X-Received: by 2002:a05:6a00:2990:b0:82c:e692:1f91 with SMTP id d2e1a72fcca58-83a5dc5df18mr26811854b3a.39.1778552171071; Mon, 11 May 2026 19:16:11 -0700 (PDT) Received: from gmail.com ([103.172.182.26]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-839682a52cesm20701081b3a.57.2026.05.11.19.16.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 19:16:10 -0700 (PDT) From: ZhengYuan Huang To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, ZhengYuan Huang Subject: [PATCH v2] ocfs2: reject inconsistent inode size before truncate Date: Tue, 12 May 2026 10:16:00 +0800 Message-ID: <20260512021601.3936417-1-gality369@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit [BUG] openat(..., O_WRONLY|O_CREAT|O_TRUNC) can hit: kernel BUG at fs/ocfs2/file.c:454! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:ocfs2_truncate_file+0x1204/0x13c0 fs/ocfs2/file.c:454 Call Trace: ocfs2_setattr+0xa6d/0x1fd0 fs/ocfs2/file.c:1212 notify_change+0x4b5/0x1030 fs/attr.c:546 do_truncate+0x1d2/0x230 fs/open.c:68 handle_truncate fs/namei.c:3596 [inline] do_open fs/namei.c:3979 [inline] path_openat+0x260f/0x2ce0 fs/namei.c:4134 do_filp_open+0x1f6/0x430 fs/namei.c:4161 do_sys_openat2+0x117/0x1c0 fs/open.c:1437 do_sys_open fs/open.c:1452 [inline] __do_sys_openat fs/open.c:1468 [inline] __se_sys_openat fs/open.c:1463 [inline] __x64_sys_openat+0x15b/0x220 fs/open.c:1463 ... [CAUSE] ocfs2_truncate_file() treats di_bh->i_size matching inode->i_size as an internal code invariant and BUGs if it is broken. That assumption is too strong for corrupted metadata. The dinode block can still be structurally valid enough to pass ocfs2_read_inode_block() while no longer matching an already-instantiated VFS inode. On local mounts, ocfs2_inode_lock_update() skips refresh entirely, so truncate can observe the mismatch directly and crash instead of rejecting the corruption. [FIX] Turn the BUG_ON into normal OCFS2 corruption handling. If truncate sees di_bh->i_size disagree with inode->i_size, report it with ocfs2_error() and abort before touching truncate state. This keeps the fix at the first boundary that actually requires the sizes to match and avoids widening checks into hotter generic inode-lock paths Signed-off-by: ZhengYuan Huang --- v2: - Tie the new truncate comment to the local mount case where inode refresh is skipped. diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c --- a/fs/ocfs2/file.c +++ b/fs/ocfs2/file.c @@ -444,15 +444,17 @@ int ocfs2_truncate_file(struct inode *inode, int status = 0; struct ocfs2_dinode *fe = NULL; struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); - /* We trust di_bh because it comes from ocfs2_inode_lock(), which - * already validated it */ + /* + * On local mounts ocfs2_inode_lock_update() skips the inode + * refresh path, so truncation still needs to reject an inode + * state that no longer matches di_bh. + */ fe = (struct ocfs2_dinode *) di_bh->b_data; trace_ocfs2_truncate_file((unsigned long long)OCFS2_I(inode)->ip_blkno, (unsigned long long)le64_to_cpu(fe->i_size), (unsigned long long)new_i_size); - mlog_bug_on_msg(le64_to_cpu(fe->i_size) != i_size_read(inode), - "Inode %llu, inode i_size = %lld != di " - "i_size = %llu, i_flags = 0x%x\n", - (unsigned long long)OCFS2_I(inode)->ip_blkno, - i_size_read(inode), - (unsigned long long)le64_to_cpu(fe->i_size), - le32_to_cpu(fe->i_flags)); + if (unlikely(le64_to_cpu(fe->i_size) != i_size_read(inode))) { + status = ocfs2_error(inode->i_sb, + "Inode %llu has inconsistent i_size: inode = %lld, dinode = %llu, i_flags = 0x%x\n", + (unsigned long long)OCFS2_I(inode)->ip_blkno, + i_size_read(inode), + (unsigned long long)le64_to_cpu(fe->i_size), + le32_to_cpu(fe->i_flags)); + goto bail; + } if (new_i_size > le64_to_cpu(fe->i_size)) { trace_ocfs2_truncate_file_error( (unsigned long long)le64_to_cpu(fe->i_size), -- 2.43.0