From mboxrd@z Thu Jan 1 00:00:00 1970 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 D7E633B5DED for ; Tue, 30 Jun 2026 15:28:39 +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=1782833323; cv=none; b=tfR+NWFgNc3WHO7VvrDihrS2RAVWNeSXGGRBaDX/mrkBCiv7PnVX2Nvz+3IVRCPvFo7q4iSwG/AHYo+SogUdhkKTy3DOkvWoBTIjli53kfpi0oeYbV/LWO95OUCd2v2NYBnGhDJypIuzqmXcNqBFN6ex0FBL6si2rJyyO3fb3q4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782833323; c=relaxed/simple; bh=Ozwrg5vtYkvUjByMh8Q7JYkkU7wDlbu9EjlFXZuBF3E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uroZzTYZSiz/4vgjg5wZZjga6OfcZPGEY0LplM7F//VWGM6bUxRSngZR8+zmSS/8MlV4sYOs/u/JcrpNUAX1WzmWCbiNrE+lmObc36jTNbxRfSU1a251vyfPHS2+/WjFcvOJkT4421tVUE09RmFpSZAkt/OgPqGS4WxSwa5LRhA= 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=VtyfQhQu; 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="VtyfQhQu" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2c7c61b5292so42162295ad.0 for ; Tue, 30 Jun 2026 08:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782833319; x=1783438119; 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=MKTgauuOYaFio2lSDyUix5l+tJ8GaI8cbBppvZ2p7Hg=; b=VtyfQhQulJeqamxXY3z//tstQhbwvBqdRhjXCRoy56qGTeqzmYcfZCyS2HmUoUrjLh 5QOYj6Sp0C3QJQMvDketkEY7s00IwUXAyaXaWtck2qrA+QMTAT142AnvfUWRf3+Zmq0L mxhor0kIihQgW4J+ypWaO9ZihkBxRg7hHgXAe50ZvCJ8AgnhwkIuTmFqCxyS+AqL1gSr lUgNwwlGgbikWT+uQS4JAxeu1zWPiHVd2kmMgZTtUGeKyM9Orvb6GGVfBmnqRKWhKtvV rZpvK3Hm46uAE0WyIvOb9pJxY7blafFolDXmT+rbVy6slScU+YLvwJkWGewUvhcbBK5P ijnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782833319; x=1783438119; 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=MKTgauuOYaFio2lSDyUix5l+tJ8GaI8cbBppvZ2p7Hg=; b=YdU7MMlv4J7CiLsUWucteRVVFgF2RqN6Mf3nwJwwozHNXFWXaAtxpvyrJOhibQOsPs NCSpWz3RkU88th8OTJEfpjkEJv8A7VTM7J6MXdpiOYl44Clvytsb+FA4WXaIJ81or4qw piD8o9QPqd0f4/kxnlrztiycqxogNO+IaZ3l3x6ErYZ4GWQl5TNArgI/C4Nxq1ScLrqT 0Uje/VT1dgrDjWTJpsE9OYrp+GSCck1KPGHKASAprn72Ds40pa85v/rbw+aG4n46YksD KBR5LH8yn0RDfm5QLR8TIBuveXXyrzi7AAm+UxYCUoSLIPTAUbjZq3A5D6BAUgQPfvxq 5fsg== X-Forwarded-Encrypted: i=1; AHgh+Ro/+aMakCBzAojQkEhOHzHbmfdW9xFSG7DRlk5rUdTU/O6EVHtPnYZtr19wRE7gXIkeGEk4qb6mkWeF0hY=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+aewxCHPZ+/lSjv7HsRdv826zgELIuZDmd/4uqq/J08Z0HefC XGgcjd0/pEmXwS/GBpPvIn6tLso0HtfWpPMCBvlzDTDrxBqIcU9oIk0z X-Gm-Gg: AfdE7cnBglQ/4p8rcGPcHgmnciflbeguiGuY+mnsf3w9QjdX/tld2iSI+KD6NJNpxo4 83oFyuPD7/HQKsBtSPFy7pYMtduXl/Q3QhBeqYylk5j5RL9GA/l4eFmKKktbw62IxBmmk4NKxLs PQ+hSyu8pGFkuqzgfd850HK0sJsMW9OFWXKchjYQ9z6Q99sPpjb2bMBQ2U8ycYi46dlg2C/QXvZ RpFYTR1NyE/OtKkP0rc5HKBziAWHm1JKNS+D2gDzwHWKhoG0C0SycDEinDBAihpdSCrRfeSzr9p H2Q64f1g1v7jvgs2/nr6GsAlWbAgfu/Vm1u/oLBDoY5blxnAzubuDQPpCHfib+9zENT7ML6EfvW JqAexF7B+4ruBLTwJN1vgUJsKwKS9BPLbtWdDjkdUM03Q/KQIaOFI+lFEgk6PJYWnD8lJ/pj/Bh pCqYbKH5Ftp/7V9kZjPubeT7+6qKHMSCcV1BceW2eCiePELFtMZ3ua4ifhKBUiE5aCBXu38CQAs rVld5znslPxTxqm+O8TxDsGHdD18gAU4IxXsF8PLXfCVdCknvg5dnPZVUVDE5hYI+5AO5zKZbD9 fCVyLDs7nP+0U8+mzBHHL2i27Q== X-Received: by 2002:a17:903:fa4:b0:2bf:dd0:c8b1 with SMTP id d9443c01a7336-2ca2d3d28admr36079005ad.0.1782833318526; Tue, 30 Jun 2026 08:28:38 -0700 (PDT) Received: from cs-1047136853211-default.asia-southeast1-b.c.d33bddc1d573818c7-tp.internal (126.60.158.34.bc.googleusercontent.com. [34.158.60.126]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ca4bae1e2asm10501645ad.73.2026.06.30.08.28.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jun 2026 08:28:37 -0700 (PDT) From: Aditya Srivastava To: Theodore Ts'o Cc: Andreas Dilger , Jan Kara , Baokun Li , Ojaswin Mujoo , Ritesh Harjani , Zhang Yi , Tao Ma , syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Aditya Prakash Srivastava Subject: [PATCH 0/2] ext4: fix race conditions and clean up locking of inline data writes Date: Tue, 30 Jun 2026 15:28:10 +0000 Message-ID: <20260630152812.1706-1-aditya.ansh182@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 From: Aditya Prakash Srivastava This patch series addresses the remaining race conditions and locking issues involved with inline data writes, implementing the clean state-communication design suggested by Jan Kara. Previously, `ext4_write_end()`, `ext4_journalled_write_end()`, and `ext4_da_write_end()` checked the inode state and the inline data flag directly to decide whether to finish writing inline data or to fall back to block writes. This is highly susceptible to TOCTOU race conditions where concurrent memory-mapped page faults (`ext4_page_mkwrite()`) can convert the inline data to an extent between `write_begin` and `write_end`. Since block buffers were not allocated in the inline path during `write_begin`, such fallbacks resulted in kernel crashes and NULL pointer dereferences because `folio_buffers(folio)` was NULL. The series cleans up and resolves these issues in two distinct steps: 1) Patch 1 introduces state tracking via the standard `fsdata` parameter. By marking whether a write was prepared as inline (`EXT4_WRITE_DATA_INLINE`) directly in the private per-write `fsdata` during `write_begin`, the corresponding `write_end` handlers can reliably decide whether to call `ext4_write_inline_data_end()` or complete a normal extent write. This eliminates the race-prone checks on the live inode state and gets rid of crude fallback/retry hacks. 2) Patch 2 replaces a potential kernel panic (`BUG_ON(!ext4_has_inline_data(inode))`) inside `ext4_write_inline_data_end()` with a graceful retry error path. If a concurrent conversion clears the inline flag right after the `write_end` checks pass but before the xattr semaphore is acquired, we gracefully release all held resources and return 0 (VFS retry) to let the VFS safely retry the write from scratch. The series compiles clean against the latest linux-next/ext4 tree. Thanks, Aditya Aditya Prakash Srivastava (2): ext4: use fsdata to track inline data write state ext4: replace BUG_ON with graceful retry in ext4_write_inline_data_end fs/ext4/ext4.h | 1 + fs/ext4/inline.c | 14 +++++++++++++- fs/ext4/inode.c | 22 +++++++++++++--------- 3 files changed, 27 insertions(+), 10 deletions(-) -- 2.47.3