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 37B551DF75D for ; Mon, 16 Feb 2026 04:17:08 +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=1771215430; cv=none; b=QK9OFoHQO+dNdWcMy7EH1M/DIuFTxap2r2/yl5f5S3rPUa6gF17XPuO+E9yCj9l9kS1XKx7Wey61SUqTw12a2LGSzWSANrY3WFZ64sMj5Ne4kUx1To8nh20Mc/IMQYj3610W4EXzpteFw4PlBowXV4CN1vqNnPeC2VtrQ1R4Cdg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771215430; c=relaxed/simple; bh=MyTl4PFX3mRfdVM6cxgi5l2WTjlSXSbGDQbx09kyBSw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LGm/gqp4yK7tZmk+7sz7SDLQLa2g4n6tZx5UdY0qu5l1pk8S0ofbhpuhT4QnJBqffxXDMYTppi4BtzNTt9mPflm8x5aDa7T6lEveix+TxpwZ3QayZfIz7dJR1hf/QjL/FuSvpPT3Wy4I20NxNx6CSdKDDUEHvfC6zCL3XJFtr2w= 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=DwZyKygH; 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="DwZyKygH" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2aaecf9c325so18924975ad.1 for ; Sun, 15 Feb 2026 20:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771215427; x=1771820227; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=87a60IrPsZEkv8dm8fdH6Kik8z1oUurYwvGZt/o8UEs=; b=DwZyKygH8Vvj11lW+wTer3DS93+2/kaY9RiLEiXIP1KKv82RamFINzE7HCCgxwG4/b /nsMBimlIKcgUqlY96CZa1r1ZXOUtoBdERCHckrn4gTUZqTqs8TmkRMuPWEEHOruC/U4 GvMlFMzVfFOX3hH7VphvelGR+P0Ois5bxqvpzNrlvfPDrwqy2isKIp2SprF2EtH0QFwL IS0fWu03cVFFG7Yo+mPdhXeu2/byB6nF+uRxX4YzUTYUsViKeWiwtqyWAcFoAzOoUbuj J/DaQhS8lx3FZL2oF/xhpGgqnuU6KNVfal2H7vSW5Y5HoVsEf0BcxL+dHUihJ7F/Cmk2 eCwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771215427; x=1771820227; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=87a60IrPsZEkv8dm8fdH6Kik8z1oUurYwvGZt/o8UEs=; b=I6XZdmvb0GC79zo6YT8ytRFEtrBpE7fjC0hxzn4pP+8gsx0OfVco1qyDRPcdgdNj8s jseXg0Zqg0wtHHCU+/ZyEpR/mRyypEfnYVAmK60bSjXElkKcAxDd/Am5CUZ0wou2zt1O dh5f3EyhMMcqrY8XmgL6YaUYl/qtPEGG7FT4QSpSd8ysZ9m3JHNcu6MI19Stmm2RGwt9 TZ/lKIyeNZvg3oJdQdAtgt//yL4GBbsXgSzD777M1UwBmfSgqS6JMivMAv/P4P9HXNWM 6wiIHu/nqOAw/JLiBmLjaWJGVZbpru0j30oQb+avyCQWK5VrgjMbmzdH8MF77n+Cxd9j J6og== X-Forwarded-Encrypted: i=1; AJvYcCU6huA77igmcKm8EEM+++jwDZyHlP60U9JF7kpcVRGOZxHIsgkCSym47vCKG7fz70lahvyQ61ATFEZah3A=@vger.kernel.org X-Gm-Message-State: AOJu0YwhfWpX2llMyoRdjbxvzR+EubFIojykszxxzcn+ciCmvf/0h56w 6Lo1TT06GxlnWQcaZ5Ltu8xFRCBk76KPc4FRT+wArXAu+Mtu8LR5+MGy X-Gm-Gg: AZuq6aItXHpU3YBxuUsf9ZROYXL6fR1eMmJXrYG4pjuo8hJAp2Eycdr9pNnuMqbiFY3 JiPmYwZD+hzWA2Q5auH5lZ0gwZoYdIUrunXKGPv+GAa3VB4dM2ZocVdL4LdOc0enM1Z2e0+S78J +xRNydp8kwlHTh3fQdAlerilDlicY/YATc5eBaNm6Ov+h/hSuzOo+wqv6olm9tbJVo7MoaaMs2i 06gIcfRwQLuo/lMuUXPO+mRK6eaO+Te0p+Ja+EiSK2nvaenMmCGH1tZ29S7OVgv3ORouPZfoF4x oKFts7N6GNOHmWfgFw4Is2eQxDBPkr9iSmzNy74Y3awoqXAncfZlEOLhyxfOOEPoybocmgU+Gmi L9CwDBtHY/jouzWL5dK+3ZkFzdVrpjRPHJUxqHq1l3h0IYOD0Pry57DPXXeHUrrhpAqUhuT27WG lP4qpYogzukkTNahs7FTVFMjLf6gZnhn8= X-Received: by 2002:a17:902:ef44:b0:2aa:e47d:e3b with SMTP id d9443c01a7336-2ac93edf6b2mr83476105ad.0.1771215427466; Sun, 15 Feb 2026 20:17:07 -0800 (PST) Received: from inspiron ([114.79.136.20]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad1a6f9df1sm50515445ad.10.2026.02.15.20.17.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Feb 2026 20:17:07 -0800 (PST) Date: Mon, 16 Feb 2026 09:46:59 +0530 From: Prithvi To: willy@infradead.org, joseph.qi@linux.alibaba.com Cc: mark@fasheh.com, jlbec@evilplan.org, heming.zhao@suse.com, ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linux.dev, skhan@linuxfoundation.org, david.hunter.linux@gmail.com, khalid@kernel.org Subject: Re: [PATCH] ocfs2: Fix circular locking dependency in ocfs2_del_inode_from_orphan() Message-ID: <20260216041659.plgrj5tiseeqwbkl@inspiron> References: <20260106125100.327980-1-activprithvi@gmail.com> <94b4189d-dfb6-4443-a336-abbae89d36ad@linux.alibaba.com> <20260108183652.ro4xueuj6itfaph3@inspiron> <20260115031809.w7ksrj2ostwyxa54@inspiron> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jan 15, 2026 at 04:47:56AM +0000, Matthew Wilcox wrote: > On Thu, Jan 15, 2026 at 08:48:09AM +0530, Prithvi wrote: > > On Fri, Jan 09, 2026 at 12:07:00AM +0530, Prithvi wrote: > > > IIUC that would be the case when ocfs2_dio_end_io_write() operates on normal > > > files. However, according to the report of the bug, ocfs2_dio_end_io_write() > > > is holding &ocfs2_quota_ip_alloc_sem_key so I think due to random fuzzing by > > > syzkaller, the function is curently operating on a quota file. > > So the right fix is probably to disallow DIO to a quota file, wouldn't > you say? Hello all, Firstly I apologize for the delay...I was trying to understand the bug in detail and few strange things I noticed. I have now confirmed the bug is due to uninitialized locks during slab reuse. Here are the deatils: According to earlier observations, we knew that a file with a quota lock was trying to enter DIO path which is not permitted. I observed that that in spite of adding checks like IS_NOQUOTA(inode) since I observed: else if (fe->i_flags & cpu_to_le32(OCFS2_QUOTA_FL)) { inode->i_flags |= S_NOQUOTA; } in ocfs2_populate_inode(). However with this change also the issue didn't seem to get resolved. I found that it was some inode numbered 16979 which was entering DIO. However, upon investigation I noticed that inode 16979 passed through ocfs2_populate_inode() only when create_ino = 1. Upon adding a few printk statements in __ocfs2_mknod_locked() I found that the inode 16979 strangely held ocfs2_quota_ip_allc_sem lock at the mknod stage. I suspected it to be a lock cleanup issue in the slab object when inodes are returned to the slab. I found that in one mount session, an inode was mounted as a quota file, with a very small number (mostly <50) then later on in another mount session that same slab object is reused for the inode with number 16979 which immediately causes the lockdep warning to occur since it still holds the quota_ip_alloc_sem lock. IIUC, I did not find any way the semaphore is cleaned when an inode is evicted. Hence I think to add init_rwsem() to the ocfs2_clear_inode() to stop the warning, since now that inode held ip_alloc_sem lock only, thus no quota lock acquired during DIO and the issue never occurs, even if same slab object is used which retains the lock identity. In addition, a check can be added to block DIO on quota files. Thus, I think the following change should work: diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index 76c86f1c2b1c..372c198afa25 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -2420,7 +2420,13 @@ static ssize_t ocfs2_direct_IO(struct kiocb *iocb, struct iov_iter *iter) struct inode *inode = file->f_mapping->host; struct ocfs2_super *osb = OCFS2_SB(inode->i_sb); get_block_t *get_block; - + + if(IS_NOQUOTA(inode)) { + mlog(ML_ERROR, "Direct IO is not allowed for Quota inode %lu\n", + inode->i_ino); + return -ENOTSUP; + } + /* * Fallback to buffered I/O if we see an inode without * extents. diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index b5fcc2725a29..3e36da2ca5d0 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1268,7 +1268,8 @@ static void ocfs2_clear_inode(struct inode *inode) "Clear inode of %llu, alloc_sem is locked\n", (unsigned long long)oi->ip_blkno); up_write(&oi->ip_alloc_sem); - + init_rwsem(&oi->ip_alloc_sem); + mlog_bug_on_msg(oi->ip_open_count, "Clear inode of %llu has open count %d\n", (unsigned long long)oi->ip_blkno, oi->ip_open_count); What do you think? Thank you and best regards, Prithvi