From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (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 DB1F942B75C for ; Thu, 30 Apr 2026 17:21:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569662; cv=none; b=KwkdKK1trHdj8eCoFzPl6LgexKPKSAHx/AamVRKrv/PGOE5ZBHU6bfS5NLF7eSl9LqZVi67gHTAfHM0VyukItuzidxg6+yug4Vt1hp+uqvsG2th+JJAVnluswMOXFXuOKC1P11WlbfdIHF8fdNFGRu6UsIqgLU8kSReJ6K/ZYys= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569662; c=relaxed/simple; bh=aIh0QUpJkXYDL0vJikLQt9/WdAnbtCXSWQwWjZ1WYM4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=aHQpsg1M3TcBhKtgxVVaHqDdIQqDK33pGzPWYpj5IfjJCWHFj4rBhRnjDKFT9SpV6wQab9BIA4F2Oxb6IrMwTek9eRpa5ejsA5023HqiW0YkFRFy2mNFlLlKGvfUXC4qrcyGZiV7oIiyo8KxqHCcljViL1AZ8w0TmTEtvLCp+ME= 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=iIdTntFD; arc=none smtp.client-ip=209.85.216.44 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="iIdTntFD" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-364d13df3ccso96533a91.3 for ; Thu, 30 Apr 2026 10:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777569660; x=1778174460; 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=IMG+GSPU97B8lZo79fMBQKJT7K6QYtkwtmIjYs0oLkA=; b=iIdTntFD2G4Y0Xh2aRS8m78uVv089fPwQUfIuKVhrFFcc8VM7NR+73zkXJhHvkzMt5 kHlLaK7H1YFjWuo+cNnmAxzI2Rw0Uk1qfHH6xTZFRb/Znrl4a1qipynSN0F5zeOLvIG6 /1ZpbP1UZ9D3JSEh0OqxmJTirnSOOmVrABZOCS5teRSWicrNYTEuQ5NrY6BsaQ+8C9e2 aQtHxgEh+cHaFw6kl71nm12Kac9D0f8U5PGcewEIevK5iu7x/MrMDd0WdXLz6zeY+Htr wR+n7MqGR0p2auxqt7+DqB7zFTE8Wv9hf+2iQ9Muh3ZtAjsOJL1ow1ldGaJ6E2jVLZ/0 EUYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777569660; x=1778174460; 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=IMG+GSPU97B8lZo79fMBQKJT7K6QYtkwtmIjYs0oLkA=; b=g0bJnDdj3HdiPQuO0j1lBgCvTXMswuHYXMtqL0Q9Zmn7elHCBAj9P7vqH7J9+FdNEH IuiaHtRiSq02QmfV1YBk6NFaX/dQNsUaFqoRjXh3m676qkszzJ4LXaKri5jWzE8MatzG wj8/gVLJOr6ynZvneIGwglOveXAKtaxZo7IYB/wchdg7xrFb9RfphH1oAgPwhZPi+2Mn HDlHBjDldYhRYPLewms5/gd3l/5oIv4TSXx9qsTCSPJj4Y3ojBrqTce7SQLmldGJx+cr yN5UVPNEh0GjdhVoH8wfATrOrBGI2qBYdTKzomqL9+0G+xb4zIoxmK1WeDvgoaqKE0In 6kjA== X-Forwarded-Encrypted: i=1; AFNElJ/5UUKxvhKrTDSGQ5eHV0I1gbF6EwqTPnrid/pZR/P72DSMQ+ubAmFS2/MYJa/N/imJogbaTUpK4hWitaE=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0qaalzx6Jk8bEhiaj8HA7GwI1pSK1hAJsIu2FO5ChjtahHoDe IaBDN0x0Xp4s4y8OjZ2nXlBZnn9I4UbI9zPT6PbkKp4zv9IN9+7+vB+/uCEJfQ== X-Gm-Gg: AeBDietsUuOqbuBJ24553iQzatvCa7qaEfsqJ46HghJI72jl167Iu+J3zjfWHfeevhn J3HFF/MBqP2bMI1GjFNHc0ZpHfIPJuKAhNvFUDg9qNBjLdIALXHwMOtIib5dBf3Q3jTUtBjfkbx 8R2qlcNqjElTC5jDZwMCpIUSr8LYZS3lo5ZL9Py9LmyepbV+HZcmuzbt3RhMwQnnCbF40KVrade wpAKtP4DmY7lazmJOcvsVCmBaSDeqA4drPpuXbBJlRsIxWhP5/z34TTuirmTwEwzhpURauvwxOX C7fSee7VFjhYKZcZAiPiSwA/B+ijdnG4vxgeXOnXhnbAi5CiNZ5zyQW3BO7MoU/XmPA2XrJ6Ic/ cn7bWToItgJRjVGDjNKOFu7/DYIyxCxDWqjMHTi92JL99jj9PVvcks5QRJSe1HQCa221LvwC6MD gCm5a4w4mbXTNEj4nJy0QHmYSFf50= X-Received: by 2002:a17:903:3c6c:b0:2b2:527d:fd with SMTP id d9443c01a7336-2b9a2885feemr21009675ad.8.1777569659787; Thu, 30 Apr 2026 10:20:59 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b9caa7e7besm2043795ad.12.2026.04.30.10.20.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 10:20:59 -0700 (PDT) From: DaeMyung Kang To: Namjae Jeon , Hyunchul Lee Cc: Arnd Bergmann , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, DaeMyung Kang Subject: [PATCH 0/3] ntfs: error/durability fixes for mft writepage paths Date: Fri, 1 May 2026 02:20:52 +0900 Message-ID: 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 This series fixes three independent issues in the ntfs mft writepage paths in linux-next. Patch 1 restores the documented synchronous semantics of the @sync path of write_mft_record_nolock() and of ntfs_sync_mft_mirror(). Both functions claim to wait for I/O completion, but in the converted bio code they only call submit_bio() and return; bi_status is never inspected. As a result write_inode() can report success while dirty bytes are still in flight and bio errors are silently dropped. Introduced by commit 115380f9a2f9 ("ntfs: update mft operations"). Patch 2 fixes ntfs_write_mft_block(). When the per-call allocations for @locked_nis or @ref_inos fail, the function returns -ENOMEM with the folio still locked, which stalls any later task that needs the folio's lock and drops the dirty state from the writeback iterator's point of view. Use folio_redirty_for_writepage() and folio_unlock() before returning. Introduced when those buffers were moved off the stack by commit f462fdf3d6a4 ("ntfs: reduce stack usage in ntfs_write_mft_block()"). Patch 3 captures the return value of ntfs_sync_mft_mirror() inside ntfs_write_mft_block() so a $MFTMirr write failure during writepages is propagated and surfaces via NVolErrors. Patch 3 is what makes ntfs_sync_mft_mirror()'s newly-meaningful return value (from patch 1) visible on this code path. Also introduced by commit 115380f9a2f9 ("ntfs: update mft operations"). Note: this series does not yet wait for the main $MFT bios submitted inside ntfs_write_mft_block() to complete, nor does it propagate their bi_status, nor does it redirty folios when records are skipped by ntfs_may_write_mft_record(). Those issues require a per-folio writeback completion context and are the subject of a follow-up patch I am preparing separately. The patches apply on top of linkinjeon/ntfs-next. Build-tested on x86_64 with CONFIG_NTFS_FS=m and pass scripts/checkpatch.pl with no warnings. Runtime testing was done in QEMU with a small initramfs, ntfs.ko and dm-flakey. The test kernel used CONFIG_NTFS_FS=m, CONFIG_FAILSLAB=y, CONFIG_FAULT_INJECTION=y, and CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y. KVM was not available in the test environment, so these runs used TCG acceleration. On the unpatched baseline (the commit immediately before this series, 9e9354075d5a), the QEMU tests reproduced the fixed failures: - With dm-flakey erroring writes during a metadata fsync, utime_fsync returned success: QEMU-NTFS-ORIG: TEST patch1-original: BUG reproduced fsync returned success under write I/O failure - With failslab injected from the ntfs_mft_writepages() stack, sync stayed blocked after the injected allocation failure and the guest later emitted hung-task diagnostics: QEMU-NTFS-ORIG: TEST patch2-original: BUG reproduced sync still blocked after injected allocation failure With this series applied, the same QEMU test setup completed: - The metadata fsync path returned EIO under dm-flakey write errors: QEMU-NTFS-BATCH1: TEST patch1: PASS fsync failed as expected rc=1 - failslab injection from ntfs_mft_writepages() was observed and sync completed without hanging: QEMU-NTFS-BATCH1: TEST patch2: observed injected ntfs_mft_writepages allocation failure QEMU-NTFS-BATCH1: TEST patch2: PASS no hang after injected allocation failure rc=0 - The writepages path observed and propagated an $MFTMirr write failure: QEMU-NTFS-BATCH1: TEST patch3: observed MFT mirror sync failure QEMU-NTFS-BATCH1: TEST patch3: PASS syncfs failed as expected rc=1 - Final result: QEMU-NTFS-BATCH1: PASS all qemu ntfs batch1 checks completed The whole-device dm-flakey run is not a clean negative control for patch 3 alone because syncfs can also see main $MFT writeback errors in the unpatched tree. It nevertheless covers the patched $MFTMirr error path and verifies that the error is propagated. DaeMyung Kang (3): ntfs: wait for sync mft writes to complete ntfs: redirty folio when ntfs_write_mft_block() runs out of memory ntfs: capture mft mirror sync errors in ntfs_write_mft_block() fs/ntfs/mft.c | 76 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 25 deletions(-) -- 2.43.0