From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (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 C5FD4246781 for ; Tue, 23 Jun 2026 09:05:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782205553; cv=none; b=IkQHq6laDrINWQmuYtNjIQAB5aohlpn0NhMvJueKOIQl9SWsISqPBpLnn0pBarFQXe6FPbsMEwouP7S1RXNjBkRc6BllDaR8FuecPayM/HRgVJc3LUTDg//GNLWnUVJPIB+faKPyAOGwW2Lej8fsikj1H1QFe5B1qDpd4YRzk3w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782205553; c=relaxed/simple; bh=C2ePjiXBRNuHtWlgtGjxZfYjg23YUH/DnuCn0zkAr9A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=tvXIcOELQxYhIOiTxp3eUlEwVE1ZkCSGvHcUnJd5NyMk6eOoAUS8sp9YHSMnvLeoKU17gXWCspACqXkvP1xPvvGmsO2oK9ATDAb/w6GqFwXhI4Ta6uA6t0oQRH2e5i/pa9sKh17NA3g4eWmoUSwcOvbqSLuVVxT+HB63gS1xO4I= 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=I7ujNkIt; arc=none smtp.client-ip=209.85.214.176 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="I7ujNkIt" Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2c6fcfcdb2bso41515155ad.1 for ; Tue, 23 Jun 2026 02:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782205551; x=1782810351; 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=/TONqHesEiZLcKhLuAN7Ro2X9K7Wb3/mcZREbo/K/cc=; b=I7ujNkItsMknEehlcR4g+P2WdXmmGuzeMSH0BPPartsm5fX7Ddb3rQpnih7buZ32N9 9W7SH1MRlivtk7QDpdcSET3gm9OKJdnAsO6oT/lgHJ0tyYtzgzXqwMstO1X98ZGQYFeN Yjutsh9bQDa2aSMjubY4ipG4KINDxarSRK1OUn8Hmgnhmo6W5nIN3De6AWTzC7zAYOfM PpwoupjVirx0YzTxKDLKvcK9Sf6GjzL0mRA12pI6zgtmfJ/IJXeR6a1nRhbuyYTnTNQq DtzFggyRlQ3ihERUlSR3dLwYMoNa82OkyyeE2hqUgjm2gH6QqP3RdxPj9ReiiRTFq1Bt WzEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782205551; x=1782810351; 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=/TONqHesEiZLcKhLuAN7Ro2X9K7Wb3/mcZREbo/K/cc=; b=SnjpSReCemxRnV/yHnDFZrmbo66HsCFqw+iHQ61pQhpV2qWptdgaBfI42BZ6KvBBDF k1YEzn9IgidRO12pixEVt/h67Xs4eBTOEKkGywe+JrWCGwJxgKIeebzfQUIQ+zQZ23kD XlaP+p1fDc9ugA26TJm0UCh1KByLZrCquJX4p/9Nal1UM4qs7Ma3RpFDiKyslm+kuwiq xjzC1/+UK5f+Di64aiBMnwrL51s6R3YsD45Gbf8CaAS7vnqsNNVzP5kmrUjjsKyX+Cpf K+gjDrV2i/buNRSXASJzsqhQO0OOqeBwqq4UiOWC2HW+bMk8hlz3gu3xDEFsHKCqbeR3 Hluw== X-Forwarded-Encrypted: i=1; AHgh+RpRznViGwX9zb2dCWAX5CKI/tnrFZOO4scQHQ3DqbYk0F5e1pV7wGSEU/vEmLic7iAdCAsvlr7LYqU5A8U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0rLtLix/Td82BrYaTbMr2VuML7yoWHMTQEpUN+faFDP9pWdYA dWPTmOooor7YeXZ7UEOhVc3G265+Thx2zFJetvqMQ/VLiSDcwGoJh6FL X-Gm-Gg: AfdE7cnDr/BBLHhUUFZJllGjWmtT6rjeIQ/x0yii5E3XEBuWhWNtiYw66I4Z5w3SkK2 FiRNTJMGbvoImg5nULi8+/iOwejIRL4cQg5qWu5Hgz+zbIaduSAowuqxRNJo1kUZo0FTml0BrnA gjqO25Dj/nbeXcCOnIX/OMeQZI5795hIqnYgcm82/HLMseUHyQFpVuNQAwdCQyA8FHqm0D7eQnG RAW7QOEq13Db9BxeT4hamrxV+CdlNySETM+uKeuGTylCrnSDnsh4kNAa1O5WiX7EXEKzMx8k+4E E6d1i36++/oIpZlODxT7QrCUjUrjU6sxmc7E8iJs8HFEytdYRojuHHDQiQxTUn4sBpDTwFwn/Ra GheZKBNlBClqi0e9SjoKUJFlUnGoDSnCcfsct/L0k8BN1U0ZlHFxqF+URfrTpCfy3MB4YYmb9Fo IPbtckTLRYodWW7Iyf3jiXLqS5Ph2ev0w/NOJUDTkG7fsrivx6+jcBhR4vBtQkSr0zJZyyAQtwr LiA8syGBGWWwidfDvj4/tonfBxs/iAMFSOCzxw6iG+FoYXGILrihXGCDWQ2vO6P76lT2x5GX9V0 GW75LFli+hcu8aDratqNsU9XFw== X-Received: by 2002:a17:903:1983:b0:2c1:e426:70f4 with SMTP id d9443c01a7336-2c7c768468fmr21932375ad.23.1782205550732; Tue, 23 Jun 2026 02:05:50 -0700 (PDT) Received: from cs-1047136853211-default.asia-southeast1-a.c.d33bddc1d573818c7-tp.internal (69.129.240.35.bc.googleusercontent.com. [35.240.129.69]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7436af57asm111648685ad.13.2026.06.23.02.05.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 02:05:50 -0700 (PDT) From: Aditya Srivastava To: tytso@mit.edu Cc: jack@suse.cz, adilger.kernel@dilger.ca, libaokun@linux.alibaba.com, ritesh.list@gmail.com, yi.zhang@huawei.com, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Aditya Prakash Srivastava , Colin Ian King Subject: [PATCH] ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find() Date: Tue, 23 Jun 2026 09:05:19 +0000 Message-ID: <20260623090519.2239-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 Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, perform a non-blocking lookup of the EA inode using VFS's find_inode_nowait() API. If the EA inode is currently being evicted (marked with I_FREEING or I_WILL_FREE), simply skip it (treat as a cache miss) rather than waiting for eviction to complete. If the returned inode is found to be I_NEW, wait for its initialization to clear using wait_on_new_inode(). This deadlock was made much easier to hit after commit 0a46ef234756 ("ext4: do not create EA inode under buffer lock") which removed synchronization on the buffer lock. Reported-by: Colin Ian King Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219283 Fixes: 0a46ef234756 ("ext4: do not create EA inode under buffer lock") Signed-off-by: Aditya Prakash Srivastava --- fs/ext4/xattr.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 982a1f831e22..8c0082362a9b 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1523,6 +1523,20 @@ static struct inode *ext4_xattr_inode_create(handle_t *handle, return ea_inode; } +static int ext4_xattr_inode_match(struct inode *inode, u64 ino, void *data) +{ + if (inode->i_ino != ino) + return 0; + spin_lock(&inode->i_lock); + if (inode_state_read(inode) & (I_FREEING | I_WILL_FREE)) { + spin_unlock(&inode->i_lock); + return 0; + } + __iget(inode); + spin_unlock(&inode->i_lock); + return 1; +} + static struct inode * ext4_xattr_inode_cache_find(struct inode *inode, const void *value, size_t value_len, u32 hash) @@ -1549,10 +1563,12 @@ ext4_xattr_inode_cache_find(struct inode *inode, const void *value, } while (ce) { - ea_inode = ext4_iget(inode->i_sb, ce->e_value, - EXT4_IGET_EA_INODE); - if (IS_ERR(ea_inode)) + ea_inode = find_inode_nowait(inode->i_sb, ce->e_value, + ext4_xattr_inode_match, NULL); + if (!ea_inode) goto next_entry; + if (inode_state_read(ea_inode) & I_NEW) + wait_on_new_inode(ea_inode); ext4_xattr_inode_set_class(ea_inode); if (i_size_read(ea_inode) == value_len && !ext4_xattr_inode_read(ea_inode, ea_data, value_len) && -- 2.47.3