From nobody Sat Jun 20 14:11:19 2026 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 A2D6F47798D for ; Thu, 30 Apr 2026 17:21:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569665; cv=none; b=jt6waUjipHq3iRSdiFVmMk9cPpBbP4oEzWaOSr4D8dhQ90MCkGV7ijpaZ4/x5PbqVezsF2Q/vfvTSxAARVwAJ4R6QgykO9wACeqrI53hJnViQrwaGIKqyYC4GH09h/UfLq+jdqUx4AYpuK4aoOP19NLeCzxP0BKpsrPNT/GSYls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569665; c=relaxed/simple; bh=bhrIiFkqisYrNnLDHJt2WB+bQ8eTaLnEMB4CU7n8KPU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RCLqOm3jg+fscRtLJJYMw2J4YQvyrYnvgCbZnCn4haZiUv6Q+GIAISUW4OX5h1JB6YMPGHHAQBrDojJ6NJnMMGl+lmqpaKMTCV9frEZNcEVb7tkuoHOT5xaIQpY0uvOuVOzex7UAlGWpghqNnFQcKRyNRvFhLPOts0AkHsFLzD8= 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=sl3pODq9; arc=none smtp.client-ip=209.85.214.181 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="sl3pODq9" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2b95a78a11dso1910975ad.0 for ; Thu, 30 Apr 2026 10:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777569663; x=1778174463; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0rkZuFsQKFtmCUkCnQjdOLllhL4V1PYXXSXU9jElRg0=; b=sl3pODq9mP2Ee2WVxhH3kPdRuQPydc5PKfZ6GaBSehwf0DVpOSdWLJiwgA67Dd/lgR R3J+32iSQOLAkKvYjRaNlWdXkHti3c+KLEcV04xmRHxphwXAGjOxzYFlC2e8G8Wdvtvk pAR9we3lixXLaOAdsMW25p50NqFIRTr6Qi3bzcmisdwKklLqFqDBlmurgZnaX3rFvM3P Dk9w3lZgRhN85iS56qLoPUMHWqkS8nfdzUsP2R8sTGd/gSvCo8KO0AE/123oP7ph//y5 YY5ueB+YTY5tK78ExlSpxIcgw6BmNLdyJ21EntqXeR48SWaZCz0VOT++BuqJaQCFg21D UVnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777569663; x=1778174463; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0rkZuFsQKFtmCUkCnQjdOLllhL4V1PYXXSXU9jElRg0=; b=s45GHFcqUkDs2W8LDInHlmEQEbbKAC5/UM8bjz3PHdjFikqSmCagVFjQ4PIMzmICHm dZjDHY0dqQPZ0noBvNoYsjnes4Ac8GKWIWOvCvzLeeDtWtDA/izl7tJaW95sxfahCK8v OYyX8IVv0uFNR+M/0Wiq7qbBnBsnf4FmbVBHezjdhKpzKbPtJDEDJSBpA9DYj7zW8n1T LiYugrblQZ2Jg/gSUPZ/NovYKZVnSpWOHi0Od8htPgT8HOJnV0R0JBQdj5bF9LdUmTPa RIjHl5KRlQ1URcl33ZrMtpLPiQu0GY1CqqK2MO/nCXV22KndhUO4tknLJxyQTHB83rqj g/JQ== X-Forwarded-Encrypted: i=1; AFNElJ9dGfDOQQLXTCzb2rcQlgJm52ZmAjtaxHSAQPSVgPhfmMgTu7nJlch5PYEbQCua8q8WVGhktRinDT/ndyY=@vger.kernel.org X-Gm-Message-State: AOJu0YzsK/rpj4jhvaraSjxYS6Z7Ks5CewEeGLTTAvr2TzueP4MYLyDd qEKueoSczki2+qkg5UiE0fchPpZycAP+kaNTaYrx65AIT88vWZyvK8Ag X-Gm-Gg: AeBDiet8u4DostntnqQCIdbWWC2OAr3PoUXEsUs5ID7a3V5M202p0SRO6hsin6NMOLp faxpr7y7ejU2dMV0ydxKiAnvr2sVLcxVEF+CrIifqMFDI7kmklSRcW5wSJAY1KYWILgTL/uLv07 UYegQlh+2KHiPWcwSXcKbuFvVhlVUKwNs9Ki/rz1blE+0KGVQfmACneeagCs1qOEwWt/st4jt6C R4xQxunJwoQKJLyYnHcqG7Ps7P2HdhbfeQPPaJUGWssgmVWeOPAVk0uO6rb5Y8xVZ4ZqUPiS1jw i6oLDkx3/e9yFnsAPFh667bxoRALtc04u0GOCwaywe5A9tK6B9HejXG3lBXkubGQCTIf6f3jQPT Sfpb5+yn/rm4SXweQinqyokyJqzo335Vqc9j3xLNksuD2//3n5Jg2TzLmLQeAAGqkJC607kv+Av mTKSln5U1Lv3q6DNIJiFYz7UxTRSo= X-Received: by 2002:a17:902:7c06:b0:2b9:5926:d057 with SMTP id d9443c01a7336-2b9a1d2c524mr15730205ad.0.1777569662739; Thu, 30 Apr 2026 10:21:02 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b9caa7e7besm2043795ad.12.2026.04.30.10.21.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 10:21:02 -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 1/3] ntfs: wait for sync mft writes to complete Date: Fri, 1 May 2026 02:20:53 +0900 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ntfs_sync_mft_mirror() and write_mft_record_nolock() with @sync set are both documented as synchronous, but neither actually waits for the bio they submit nor inspects bi_status. write_inode() can return success while dirty mft record bytes are still in flight, and bio errors are silently dropped: the volume is not marked with errors and the inode is not redirtied. This breaks fsync()/sync metadata durability. Switch ntfs_sync_mft_mirror() and the @sync path of write_mft_record_nolock() to submit_bio_wait() and propagate the returned error to the caller. Capture ntfs_sync_mft_mirror()'s return value at its call sites in write_mft_record_nolock() so a mirror write failure surfaces too. The @sync parameter only controls the main MFT bio. The !@sync main submission is therefore unchanged and still uses ntfs_bio_end_io() to drop the folio reference taken before submission. The mirror call has always been documented as performing synchronous I/O regardless of @sync, so making it actually block restores the originally intended contract for both @sync and !@sync callers. Note this only fixes the synchronous mirror/main paths reachable from write_mft_record_nolock(). The main MFT write submitted from ntfs_write_mft_block() (the .writepages path) still does not wait for completion or check bi_status; that requires a larger restructuring and is left to a follow-up patch. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee --- fs/ntfs/mft.c | 63 +++++++++++++++++++++++++++++++++------------------ 1 file changed, 41 insertions(+), 22 deletions(-) diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c index 7d989267a82b..4051b4823162 100644 --- a/fs/ntfs/mft.c +++ b/fs/ntfs/mft.c @@ -449,7 +449,7 @@ static void ntfs_bio_end_io(struct bio *bio) int ntfs_sync_mft_mirror(struct ntfs_volume *vol, const u64 mft_no, struct mft_record *m) { - u8 *kmirr =3D NULL; + u8 *kmirr; struct folio *folio; unsigned int folio_ofs, lcn_folio_off =3D 0; int err =3D 0; @@ -479,6 +479,7 @@ int ntfs_sync_mft_mirror(struct ntfs_volume *vol, const= u64 mft_no, kmirr =3D kmap_local_folio(folio, 0) + folio_ofs; /* Copy the mst protected mft record to the mirror. */ memcpy(kmirr, m, vol->mft_record_size); + kunmap_local(kmirr); =20 if (vol->cluster_size_bits > PAGE_SHIFT) { lcn_folio_off =3D folio->index << PAGE_SHIFT; @@ -490,20 +491,22 @@ int ntfs_sync_mft_mirror(struct ntfs_volume *vol, con= st u64 mft_no, NTFS_B_TO_SECTOR(vol, NTFS_CLU_TO_B(vol, vol->mftmirr_lcn) + lcn_folio_off + folio_ofs); =20 - if (!bio_add_folio(bio, folio, vol->mft_record_size, folio_ofs)) { + if (bio_add_folio(bio, folio, vol->mft_record_size, folio_ofs)) + err =3D submit_bio_wait(bio); + else err =3D -EIO; - bio_put(bio); - goto unlock_folio; - } + bio_put(bio); =20 - bio->bi_end_io =3D ntfs_bio_end_io; - submit_bio(bio); - /* Current state: all buffers are clean, unlocked, and uptodate. */ + /* + * The in-memory mirror is now valid because we just memcpy()'d the + * mst-protected mft record into it. Mark the folio uptodate even on + * write error so a subsequent read_mapping_folio() does not refetch + * the stale on-disk mirror and overwrite this copy. The error is + * propagated to the caller via @err. + */ folio_mark_uptodate(folio); =20 -unlock_folio: folio_unlock(folio); - kunmap_local(kmirr); folio_put(folio); if (likely(!err)) { ntfs_debug("Done."); @@ -588,20 +591,36 @@ int write_mft_record_nolock(struct ntfs_inode *ni, st= ruct mft_record *m, int syn } =20 /* Synchronize the mft mirror now if not @sync. */ - if (!sync && ni->mft_no < vol->mftmirr_size) - ntfs_sync_mft_mirror(vol, ni->mft_no, fixup_m); + if (!sync && ni->mft_no < vol->mftmirr_size) { + int sub_err =3D ntfs_sync_mft_mirror(vol, ni->mft_no, + fixup_m); + if (unlikely(sub_err) && !err) + err =3D sub_err; + } =20 - folio_get(folio); - bio->bi_private =3D folio; - bio->bi_end_io =3D ntfs_bio_end_io; - submit_bio(bio); + if (sync) { + int sub_err =3D submit_bio_wait(bio); + + bio_put(bio); + if (unlikely(sub_err) && !err) + err =3D sub_err; + } else { + folio_get(folio); + bio->bi_private =3D folio; + bio->bi_end_io =3D ntfs_bio_end_io; + submit_bio(bio); + } offset +=3D vol->cluster_size; i++; } =20 /* If @sync, now synchronize the mft mirror. */ - if (sync && ni->mft_no < vol->mftmirr_size) - ntfs_sync_mft_mirror(vol, ni->mft_no, fixup_m); + if (sync && ni->mft_no < vol->mftmirr_size) { + int sub_err =3D ntfs_sync_mft_mirror(vol, ni->mft_no, fixup_m); + + if (unlikely(sub_err) && !err) + err =3D sub_err; + } kunmap_local(kaddr); if (unlikely(err)) { /* I/O error during writing. This is really bad! */ @@ -617,10 +636,10 @@ int write_mft_record_nolock(struct ntfs_inode *ni, st= ruct mft_record *m, int syn bio_put(bio); err_out: /* - * Current state: all buffers are clean, unlocked, and uptodate. - * The caller should mark the base inode as bad so that no more i/o - * happens. ->drop_inode() will still be invoked so all extent inodes - * and other allocated memory will be freed. + * The caller should mark the base inode as bad so no more I/O + * happens. ->drop_inode() will still be invoked so all extent inodes + * and other allocated memory will be freed. ENOMEM is retried by + * redirtying the mft record below. */ if (err =3D=3D -ENOMEM) { ntfs_error(vol->sb, --=20 2.43.0 From nobody Sat Jun 20 14:11:19 2026 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 B387540FDAA for ; Thu, 30 Apr 2026 17:21:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569671; cv=none; b=mNbd10GXzWftFxtxmqlq8p8pg8b6a0BfsXrIltfU7NtFDOTS+ua9FRAqyENPYNEhfCIcpoJ83FphIJcHi79QmIC7s9LnmY1lH2vf7G6fu96cv05JmpocOJjnVkV9gAIzSW/AymTZc0On6lhHRKbzUfWscJzfc6I6wZltbQf1jUg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569671; c=relaxed/simple; bh=Y6cqM4EvlGBOS6YziDRM0sHRZX+RsE98GsTLUFKYfi0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mVGqoCj7OdpjFfmgULHp/pu6dF/pylSOx0dw83QL6KBIHvU1WxEIQPUN8FYaNNToXuXH4nFqTEHNMD2dT0kxo6O9ac82igkbDq8hZYUl5sgpkXKowJElhYyqVq1kFYkbB56w85TOz43AjPAsNy+e9UCWGvDl3kSuG4jBoTbd6gw= 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=nx90Pvv4; arc=none smtp.client-ip=209.85.210.172 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="nx90Pvv4" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-82f0647ce27so114760b3a.1 for ; Thu, 30 Apr 2026 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777569669; x=1778174469; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=jr3axVcnDiZy1sAOlbAWcyfqiZ/0xXxvJPVhUZbgyfs=; b=nx90Pvv44opU3V4qRyXp7aVoeh7IvNQQDHRXO7fQzfovzK/+ycjYt1ad9OudTduNzF +ZL5N3s8uEtNjNLbmd0Jev/WbbzAW5OoddGF98RIzkVD1LN9XhCKRN7xyb9qc1HmiZWG UgbtFQOd3IMNcE5BTZGPaay2G7dPMq2pYB8HPCGyM3TY4OuNJq8FputfcXq8eJSu/td5 W5OculZopKGJFtGL32ch9vIc1Y9RV7vx92/MdXoC1nRvrJdahQRApTuE6h4hc8nmZ0dj p//XNsqWWq5hpKwdyHxs49HDCX243koCLRZqi3B8mDFLahv06Ln8VUAd5xm7NayQSTWM Y3QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777569669; x=1778174469; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jr3axVcnDiZy1sAOlbAWcyfqiZ/0xXxvJPVhUZbgyfs=; b=iMIim11jx1Tr4xBEYLqW4m4K8CybdHw5ZSjmxJ97YRIZUUaIsge5hUIb8QUAz/OuG0 Yk/aQbC8xKk/NZNb175E00zLKMKYNOCUD3+EY1TRB7ASCCdLbqlwq9yXJ16AyUb+1Hhu gm4xBIvL3ydt8CLFuq0TCDk+D9P5S8u+yPIlsYWTb4WhxVgz0MqCutmqO9hdGuLSZczP zBi8Rs7UKugWFj0PUEFjGcn9TUx5+tpHDUzLkFdozvPQtE5Wi/L41qpQqGosbLk4Wn2z pWPjo+2MGs9Wfd8KNZRltt9rDwPw1o07jl1lLbxt9TYW4Am0sh9Z7ggp3f/sooe27v+/ yAvg== X-Forwarded-Encrypted: i=1; AFNElJ/M8LAs9TTNIJMLJT2M13k594zI2jqHLhsdqRd1js/0668J1hNL/FmOeJZEChzsq8T8klunLGJP0pdSFWI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzua9mLOttWlh+nlPbmi+FDDa6DVG/NtJpq9E1w27qoXAqUyt7l XnFTu30GVavU0BagmAXOToFKYvlplmtikrTXwJJCsta2wiMtqRPVcFJt X-Gm-Gg: AeBDieum2/iz5I6xrDAUmAR4lUk7knx0xpP87wtPypkn0DGQ05izXO6Y2Bu+af36CUT 7QSv56MXDWLWXFBkHxV4jzSwsP2wOP0RNEboNsllBkClh//GYbjbIiBWMFlqpqPDxH/qW3ejL6C dM7perhuzuRtQmqOpzQBJhrhn4lWGl+IFDkyy4VCtgvYvP3RwjUvwo0HcopNb6efI406QPiciQM s01XAC8qghGCXxwiPOwwaknPdyuu+H3lvypNJyFpdVuhKTXINVwvyomes/oKFG4w3ibmBYQWPf+ 1LizKiBV0AeYfKK5F2/ilpgYv1zd5uPTpsi7zWSH9nWtlfhGZUhOzhZFhSzwDN2+veb9/XzwYH0 w8H+vgRRi99iNOeVVJQLig/BR3wWHbKvu8uSYRrhmyE9Sd2+NFz0PNoH8xDLsMvZzeHzkN8hFkg UPOH+thJhvXvzYG2tsEhCCqE/N6Lo= X-Received: by 2002:a17:903:b06:b0:2ae:464f:fe3e with SMTP id d9443c01a7336-2b9a2861e94mr21157545ad.5.1777569668859; Thu, 30 Apr 2026 10:21:08 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b9caa7e7besm2043795ad.12.2026.04.30.10.21.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 10:21:08 -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 2/3] ntfs: redirty folio when ntfs_write_mft_block() runs out of memory Date: Fri, 1 May 2026 02:20:54 +0900 Message-ID: <0d61bd7f181f4e46207572c5d8a4b026e370a57b.1777568957.git.charsyam@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" ntfs_write_mft_block() is called by writeback_iter() with the folio locked. When the per-call allocations for @locked_nis or @ref_inos fail, the function returns -ENOMEM directly without unlocking the folio. Any later task that needs the folio's lock then stalls, and the folio's dirty state is silently lost from the writeback iterator's point of view. Use folio_redirty_for_writepage() so the folio remains dirty for a subsequent writeback pass, unlock it, and only then return -ENOMEM so the caller can propagate the error to fsync()/sync_filesystem(). Fixes: f462fdf3d6a4 ("ntfs: reduce stack usage in ntfs_write_mft_block()") Signed-off-by: DaeMyung Kang Reviewed-by: Hyunchul Lee --- fs/ntfs/mft.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c index 4051b4823162..00f172fd1b21 100644 --- a/fs/ntfs/mft.c +++ b/fs/ntfs/mft.c @@ -2740,8 +2740,11 @@ static int ntfs_write_mft_block(struct folio *folio,= struct writeback_control *w ntfs_debug("Entering for inode 0x%llx, attribute type 0x%x, folio index 0= x%lx.", ni->mft_no, ni->type, folio->index); =20 - if (!locked_nis || !ref_inos) + if (!locked_nis || !ref_inos) { + folio_redirty_for_writepage(wbc, folio); + folio_unlock(folio); return -ENOMEM; + } =20 /* We have to zero every time due to mmap-at-end-of-file. */ if (folio->index >=3D (i_size >> folio_shift(folio))) --=20 2.43.0 From nobody Sat Jun 20 14:11:19 2026 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 53F3444D688 for ; Thu, 30 Apr 2026 17:21:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569674; cv=none; b=u+tmEIJk8DsX3+yHE1A4NCBinxDFxZMo20CeAoXi3DOGyIDGXHvzwKnW5caYww/By97iF659vc1Qw4vzpxaowJZO32lzPv2t2ewCMigVaL9J7M3ylJ1sq5txE56/YSjcVUx86+XKzwcV0Durmtv0oloLngDdkMfm2guqV4QatWA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777569674; c=relaxed/simple; bh=umo4zIPzLejFoJtAFxdj3s7yRQi2X8Xhk9rRZgAVPcY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GaLKnTWaoKLrfUm9fLDjwL5G+dckUNhRsH5BR7IzluQan/x+beriDFGvq01dsdB/kMrQ0uoMTJr+MuDCxIBcaH5mv+U0jzW2xxCyNaiImad9VnQGsSlXRerDPh86QVvPzsmN37hBs2YtoYQ50KApx4OjC8nrmv6HRwM/vW3o61s= 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=p+4B8sGY; arc=none smtp.client-ip=209.85.214.173 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="p+4B8sGY" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2ab08e6c553so493165ad.3 for ; Thu, 30 Apr 2026 10:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777569671; x=1778174471; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=J6IbrhHuu9LdihQtZR7Baqf3GnWs6lIG8jJXLzb7smA=; b=p+4B8sGYdZkBwT7u1Ri4neTsu00fmKitfGh5767VBrpUEpLHwDPXXNuFHE4cixHVL4 lsoEZNAsP618HIjTYJXHfNC4V2DpJMPaFdt87I0yp7OmyqM0NqeDb1d7MtEqkK2AzoQZ +jyRgxFIIR7gYC91lPzLxvQ0tDAQHu4k5rNY5WZPOH8JEffUPkftp0+tmbl1Y8m7s9Go sz2dtgf2ZgLHnHs2ytCaUTNQYH0yQFfdSLJZu66uycbZs1lzWmgckYSqr7L7OTffJTWr cTXZ8RtTcabSMNmX2O+FaR6TZxOXu9cPq1AtdR7MBhXZFoBco5wuwd1TLK/+VD80p2rp FSKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777569671; x=1778174471; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=J6IbrhHuu9LdihQtZR7Baqf3GnWs6lIG8jJXLzb7smA=; b=rbJ4i1Cl4U/x/kH11wz1IHMWAigI/5AhPiIA8td1vqvrVjF4HPhT5DK/bIKrvzlpBu u6ttW2GAQObd2rPxPuVjXROG7Ht5Wv1mzBUtEFzpsP8RMpt0FUzUT8NYKoBdbnKwjPg+ VmYs3eU+vmoTIa8d6n1GZLoM/rRjBy3E3B6K+QC/P+Ffye5Z3RFkRtadxxe4oqLKkEnW gNyJvi1HQAlJgc97Q4MtTzAU+jiTnN9LshKqZsyUfBGDMTbYe39U7B5ETRYdASrk+xOh t05cNFocbSfM/AD4XvCVehL35+jrdR2Agx49m/C1c37AysGJGFuEeNx/H+00XPcXG/rI 2fOw== X-Forwarded-Encrypted: i=1; AFNElJ9wCUmszyUBfuNiGm+3ge1Ip0ZumWMuVBEHOqA/Vi69Li/ARtw1SRCUEn38T43dDtEfFiW78hfdM21Jn9I=@vger.kernel.org X-Gm-Message-State: AOJu0YybNGlV476wiPUTpfsmVbZY2GQbABMM4TB9EQDir5HZNTjZEOql 0mKbozaNDSF+hZmwvlY8j/jIWI6djphBwWVcKu76kt1Cad7oRk5rWZ4BsXuJyA== X-Gm-Gg: AeBDiev/HruRUPIddMIhpKr577jv59dgChBuOCXViK7WTENjuyJ3T/3Mv1vSRBFVE86 9XVSqnjJnt/Dfq+e8qPWe+ebRNgj8IHZttwWzd/KxCnarKhJDlrZhXYpps05NUVJDug1bFeExRo WZQNDj9nTEbgx0634PO9109ldiK/R7AWqnVUBG92sVReMV6om+LKr2D5h+wc0GMam0W6j0ihLbk 5gAEAiDOoLU3KGVZj4ygQA7P46JeeNLt2ccvTlTocqcP752z1N0tHxGksIbdZd4b0bihe2c6gcU to5WdVD6/U24q7WWBf5rWc2i3NhVNMS2dV1kOH9FLPDQV2WnJ9ToNzlPMc/ZpDAmP/3A3cBh190 SqVXOWWXZk42ch2oBhMsXpKtZBE7IpIYjRGsGdLIxZb54I+aZ/Snwl+ALR7J2xYszC54wjItrCB 7Fm7RVJeeD4lyyV87OJu5ovIdHZe0= X-Received: by 2002:a17:902:f650:b0:2ae:3f3f:67c4 with SMTP id d9443c01a7336-2b9a1cf7d35mr21854375ad.0.1777569671378; Thu, 30 Apr 2026 10:21:11 -0700 (PDT) Received: from ser8.. ([221.156.231.192]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b9caa7e7besm2043795ad.12.2026.04.30.10.21.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Apr 2026 10:21:11 -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 3/3] ntfs: capture mft mirror sync errors in ntfs_write_mft_block() Date: Fri, 1 May 2026 02:20:55 +0900 Message-ID: X-Mailer: git-send-email 2.43.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" After ntfs_sync_mft_mirror() became able to return real I/O errors, ntfs_write_mft_block() still discards its return value at the call site inside the per-record loop. A failed $MFTMirr write therefore leaves the volume looking clean from the writeback path even though the on-disk mirror is now stale. Capture the return value and feed it into the function's existing @err variable using the same "first error wins" pattern already used on other failure paths. The error is propagated to the caller and, via the existing tail of the function, sets NVolErrors so umount and chkdsk see the volume as inconsistent. Fixes: 115380f9a2f9 ("ntfs: update mft operations") Signed-off-by: DaeMyung Kang --- fs/ntfs/mft.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/ntfs/mft.c b/fs/ntfs/mft.c index 00f172fd1b21..866816f710b5 100644 --- a/fs/ntfs/mft.c +++ b/fs/ntfs/mft.c @@ -2862,9 +2862,13 @@ static int ntfs_write_mft_block(struct folio *folio,= struct writeback_control *w } prev_mft_ofs =3D mft_ofs; =20 - if (mft_no < vol->mftmirr_size) - ntfs_sync_mft_mirror(vol, mft_no, + if (mft_no < vol->mftmirr_size) { + int sub_err =3D ntfs_sync_mft_mirror(vol, mft_no, (struct mft_record *)(kaddr + mft_ofs)); + + if (unlikely(sub_err) && !err) + err =3D sub_err; + } } else if (ref_inos[nr_ref_inos]) nr_ref_inos++; } --=20 2.43.0