From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 C017B2EA73B for ; Tue, 14 Oct 2025 22:24:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760480688; cv=none; b=QOzX8+SYVMAZWmN0ZqMP9l6Yvv1Ev8XgHAMl7mTmxyP6uN9MyuufEkV51ZZMY7WFNDGeqSFO5PpNcKrciU7qS7P152s0LWoHaAdBlfLg7HaZDlIpWFrziLtwLm+uQpYwN2czi6Vg6KXw09/4xL5w3g4c85HYviHpQ0di6J7hxlQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760480688; c=relaxed/simple; bh=pKj7nF9FZa4CVDaaC2vI4eiSd7iIaOqkYyjB/cLYWWQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LzowQMAR7KNgT4SHhiL3Mv9XKPGUxH8kFuG6lPo06olmEJSEcuxak29eeUqu+jf563qk4lxGzLYKxaHjbQikKPaTOb8e2bj4ktC8otHkRuZBdVe8gr9M2T1bardxVVAtYkYmz3Ql3YqctJf7wiFkoP3IRkpjrZ2YbALHED8On8s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=AfMX25/0; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="AfMX25/0" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-b63148d25c3so253057a12.1 for ; Tue, 14 Oct 2025 15:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1760480686; x=1761085486; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=VU+E0coYgVNDVEMZPHxDysYf7EYOnkoJs7l4tPFgGSs=; b=AfMX25/0TQzmfcK/hscJ/q3U1LCZyIWKBrZlsvKyPAR8npiNzUhA7zKLKIpddTmQSv cppG1JWC8OFzVe3Io5LtQmNqohuwswlqTo7m/Zea0F39qHlI+yiFHn3tY3RCEHJoi73x jeFSNIJsxuGX5bo+T5a+5Ek00nt3obBxS9MPQZlzvNJkDrMtKwtqnIaWuSyRImJn+48+ 2KBopwAIZnehbvBHu8dDgovTpqKFMDAn5cRl8y+5yboBfI7cOPLF5oJYtxM4iIGdf1Zx afn47a2S3QStZ+wPAeWvTNTKWMZQVIaT9zy2jH185heb7Fsiiz0dNu/yrA/UKPwnAInh sfkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760480686; x=1761085486; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VU+E0coYgVNDVEMZPHxDysYf7EYOnkoJs7l4tPFgGSs=; b=nI22cpCu8hAo7kULNe9aVNWcqD4khPPGrIZUIIeEWV+6d0by7xNDbCsb3fjw1+uFOe rxkUzYX2a7p9Rd0VQHpBv97gdjM/KeuYLH+9F/ZvY8HcTR6qJnBZkCFKVkcBNSHAtrOj f9Xi076H3oQ1/ohJPy445oVZVlpm2RM3rHVBRhm6NyAsHkr9Ok08wSXWPtNJUzujqUwe L0U9BVHCNrTG6euPWzJWK2UXcYdR+XRHK7gXN+diQwBa78i9gWQpVU/J/qB4E1EdtYXX k4aXZznnIIwSW8P2mvIcrc+66cC+VifHMcD1xyF/9sX94jYafkuqBzXOkxgpJOQxC0UX A0ig== X-Forwarded-Encrypted: i=1; AJvYcCUu0ePz0W2AcO5gbp5wFUZYiCE/oY5fRTx4H01eHanmoFVSpunZUcwtXSTGzTuv6pKgZQnFaKTWp4JhkEQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxfWO3F/rXMQp7JImq2RDt8r7owMolVHWTgKXT2WHg04iBp9RSD b5pKehd9AOnMg60rL8ftj+6T94zrmoTnOw1l4hhrS2TIsbwC6Y4Bky5bFT0Wfsdelhw= X-Gm-Gg: ASbGnctAz3GEis2FBfYVACvss4FLVpcPNxAWcMgUM7uhn+hIHqcxQeDE2mgdSG1uJo+ a9C2YqUIvcyLs0gLD4ATVsKgnxB3bRD8/iRPcatyHbP1FOLxq6S0GBNZIoCzFZ4Wp8MY9iUb+1x YxkYd7H6JYipX0KKFf9X6LkUNZAALuFpbRuqUmQLwPPVCGVdpowP5L2pyXwbjGZiYWJ3Ka8ubel 4UX+rir5uKC8cp7nYT6X+P+gDd83GNMHMgtUZR0iKwRoB2fPoRDquB+iGERwdCLcmRmQq7x+GgH 6/FvvOlQdHITM1gjjWYaTjfbAXt16Ap8AEHN4OGgL+D0ANkA/cPAOyGvlS7LlOVvL6FdDGvUgcN /5ry0imL4XGI55t1fXFEpU5uTkPFV7itGE4idtoZvAr37NHk0cScylLjKdFWgfPNFQlhQt+Z480 V71mKviIuQgjFkjxUxUBzi/yZxyv0= X-Google-Smtp-Source: AGHT+IEuiPLT+J2EGWyWH8Vlz1fhWHzXLhUTSRvMJ8Bb23RFgsXxsIuVuGY50FOYvF4QcobNAuFtTQ== X-Received: by 2002:a17:903:2acb:b0:265:e815:fcdf with SMTP id d9443c01a7336-28ec9c9741bmr395484345ad.17.1760480685978; Tue, 14 Oct 2025 15:24:45 -0700 (PDT) Received: from dread.disaster.area (pa49-180-91-142.pa.nsw.optusnet.com.au. [49.180.91.142]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b69c24043desm955564a12.3.2025.10.14.15.24.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Oct 2025 15:24:45 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.98.2) (envelope-from ) id 1v8nRi-0000000Etua-2BV8; Wed, 15 Oct 2025 09:24:42 +1100 Date: Wed, 15 Oct 2025 09:24:42 +1100 From: Dave Chinner To: Mateusz Guzik Cc: Jan Kara , brauner@kernel.org, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, kernel-team@fb.com, amir73il@gmail.com, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-unionfs@vger.kernel.org Subject: Re: [PATCH v7 03/14] fs: provide accessors for ->i_state Message-ID: References: <20251009075929.1203950-1-mjguzik@gmail.com> <20251009075929.1203950-4-mjguzik@gmail.com> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Oct 10, 2025 at 05:51:06PM +0200, Mateusz Guzik wrote: > On Fri, Oct 10, 2025 at 4:44 PM Jan Kara wrote: > > > > On Thu 09-10-25 09:59:17, Mateusz Guzik wrote: > > > +static inline void inode_state_set_raw(struct inode *inode, > > > + enum inode_state_flags_enum flags) > > > +{ > > > + WRITE_ONCE(inode->i_state, inode->i_state | flags); > > > +} > > > > I think this shouldn't really exist as it is dangerous to use and if we > > deal with XFS, nobody will actually need this function. > > > > That's not strictly true, unless you mean code outside of fs/inode.c > > First, something is still needed to clear out the state in > inode_init_always_gfp(). > > Afterwards there are few spots which further modify it without the > spinlock held (for example see insert_inode_locked4()). > > My take on the situation is that the current I_NEW et al handling is > crap and the inode hash api is also crap. The inode hash implementation is crap, too. The historically poor scalability characteristics of the VFS inode cache is the primary reason we've never considered ever trying to port XFS to use it, even if we ignore all the inode lifecycle issues that would have to be solved first... > For starters freshly allocated inodes should not be starting with 0, > but with I_NEW. Not all inodes are cached filesystem inodes. e.g. anonymous inodes are initialised to inode->i_state = I_DIRTY. pipe inodes also start at I_DIRTY. socket inodes don't touch i_state at init, so they essentially init i_state = 0.... IOWs, the initial inode state depends on what the inode is being used for, and I_NEW is only relevant to inodes that are cached and can be found before the filesystem has fully initialised the VFS inode. -Dave. -- Dave Chinner david@fromorbit.com