From nobody Thu Oct 2 07:43:53 2025 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 1C65431E8AA for ; Fri, 19 Sep 2025 15:49:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758296959; cv=none; b=WCTbQ86HlIHDC0FfaRI1WAKdAcPInGUpoJ5o52lcgkIqxWDEucc5GQEyliU4D8orCuj9HjVRfZeGekjq+/9xWA2pljLZgYuY7XQEyIi4TqEOJljxMCD95ZMtQnpy+Rw3ttQ/wxp+H5lpEvGWYjZmTlu+FxkDaY7ybLBINB3rOho= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758296959; c=relaxed/simple; bh=4iwo/4hETyrGGvwl7DvWSV1pIW8nOTgSDeRa6KhBnMA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FqTXMV/1sEeRWbwirV4tGIU3uTTQHMzKX1sDN2zX+ZC/PB0K2aGbkDDlOFnb49nci1GhaNCRwM+TN89hFKq0kKBAA2mQKVO2yeW+mrhE+0/qfd4WF0K2nvQYEKNyg3cWYH1l5Ww3fpCDc5J3i6SzjB6y48QK6V+DJoehhaG7O7A= 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=DfEdrCTF; arc=none smtp.client-ip=209.85.128.42 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="DfEdrCTF" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-45dcff2f313so14721495e9.0 for ; Fri, 19 Sep 2025 08:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758296955; x=1758901755; 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=K6Nz4rZ6SPAY+5NRu1bbLzqkYF61IrDASgyLTr6XAmg=; b=DfEdrCTFo6rdzFYhld/JgF+qNufolUKLhbGDNtTgYPHDlacnV21osF/hPH9BqVco5A u/5u4Hbmx0xc4EcCChq8CAsPF8ecogqsmc6iaUBgL4tAtBjeqwoEGgmxGdou+gxqgL05 nIAHEFYmokCTym8WnaPjHyGpKKlpxHw+2xKrezfoYo+yO7H9iXRToVdJIrnEwm3D1XR3 LAJnYPnere9sfucV1mHf5UOYtTa7rJTLka3HATCQNY+2O7xu6QnPMRlcRFExIMulsXu+ uejrcrNBwLoL3TBm5OaeM1hCaOlnvddNEb7j0U9ugsmxZNQhkFpZaevx2pNJwPBg64nW pz1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758296955; x=1758901755; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K6Nz4rZ6SPAY+5NRu1bbLzqkYF61IrDASgyLTr6XAmg=; b=vS+keargawN28BzCCu1rJVfCb8IbyOHIKyDJcBk4PzJq4v5YUA313zD4/M1ps3ipt2 uiS88zNl/lCQmecmbPpCXYD/osqW3DZj2hd6HMhTfyjDbrejEC7mNwienP9ue4r5blyn Ful/Qv54W0mODXZMaS3UUibPM88xOnnYBH5Z1MdeXLSK6dzDwx3AEy7qhpKlhECDXlmo eMO4SaHVjSE+DVcJKm36tltJFCCAN5K4OFLv1AilvuGk2BBCBoaUwiOnp4/emkL7oK9X qsTeG6Kc8mZcqFLL9x1T9U4HSHDc+83QB2Px6Et+AFJfLrwQBrmAg3HOGFzFDTUtRR5Q wjcw== X-Forwarded-Encrypted: i=1; AJvYcCX4aJT2NQ8FdNac2jxkUBUerSvZsOFoF7s9B3haJDPC5XVFt00tkpOZ2yP1Q1/BReFYV2TcxJo0/zoz2WA=@vger.kernel.org X-Gm-Message-State: AOJu0YwTzcLjvEkEDvKExrGNgo9ESthT1sSK4Pa0z6V/ydNAkD7PK7/9 ffiP4sMRlrHioHdc1OyCFQludyKM32aFSMRzMOi0HsAEOhd3p1uflWBU X-Gm-Gg: ASbGncvh5nMksPC4+7+6otsoyt4dzj3vTgVMknXUSw3i7G+hUvdWPdQohpMtY5hqfAG trDmMpxUD5dIoMak4a+kshc8YsSX/pfRaG7h/LnPtjS3O+NEncPMySAAi8wEhsDm5dfySySG3M7 2dgU96jAFRsHL9SEfzVmdXaJd+Wc4TvDNXvNGLtDltkhGbPmP2rJA8uZAA1zMp9KnOk6VcHrPv8 B4isX+dOw+F2xYnRZ6e3cE21xT7rQoisluW4E0XCVufM1pw5WbPCUkKOE+8GXqyGQIpyNWG6i/D 7Umf6H348GiXnc98W13jPZUkL6KE/LQITJT/o/dcQppqGaQRcidWWK8Eb/E3cEh92N2zkHWcnyI /CFENT8tZhU4529q3BPEJxHn7CWwpITxOQ8HXV/EKwVdtUNi/ISSTZeatRbR2Xkn7bgfPXjIC X-Google-Smtp-Source: AGHT+IFi3Qiw2JmDbZ5JtfHacDK+pNgJNUdMyHN8bx8JLqrebQREXbPs43I+kD+9QA6IwdllVAvzbw== X-Received: by 2002:a05:600c:1d12:b0:45d:cff6:733f with SMTP id 5b1f17b1804b1-467ebacab73mr28722625e9.11.1758296954944; Fri, 19 Sep 2025 08:49:14 -0700 (PDT) Received: from f.. (cst-prg-88-146.cust.vodafone.cz. [46.135.88.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3ee073f53c4sm8446746f8f.3.2025.09.19.08.49.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Sep 2025 08:49:14 -0700 (PDT) From: Mateusz Guzik To: brauner@kernel.org Cc: viro@zeniv.linux.org.uk, jack@suse.cz, 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, Mateusz Guzik Subject: [PATCH v5 1/4] fs: provide accessors for ->i_state Date: Fri, 19 Sep 2025 17:49:01 +0200 Message-ID: <20250919154905.2592318-2-mjguzik@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250919154905.2592318-1-mjguzik@gmail.com> References: <20250919154905.2592318-1-mjguzik@gmail.com> 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" Open-coded accesses prevent asserting they are done correctly. One obvious aspect is locking, but significantly more can checked. For example it can be detected when the code is clearing flags which are already missing, or is setting flags when it is illegal (e.g., I_FREEING when ->i_count > 0). Given the late stage of the release cycle this patchset only aims to hide access, it does not provide any of the checks. Consumers can be trivially converted. Suppose flags I_A and I_B are to be handled, then: state =3D inode->i_state =3D> state =3D inode_state_read(inode) inode->i_state |=3D (I_A | I_B) =3D> inode_state_add(inode, I_A | I_B) inode->i_state &=3D ~(I_A | I_B) =3D> inode_state_del(inode, I_A | I_B) inode->i_state =3D I_A | I_B =3D> inode_state_set(inode, I_A | I_B) Note open-coded access compiles just fine until the last patch in the series. Signed-off-by: Mateusz Guzik --- include/linux/fs.h | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index c4fd010cf5bf..a4e93fcd4b44 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -756,7 +756,7 @@ enum inode_state_bits { /* reserved wait address bit 3 */ }; =20 -enum inode_state_flags_t { +enum inode_state_flags_enum { I_NEW =3D (1U << __I_NEW), I_SYNC =3D (1U << __I_SYNC), I_LRU_ISOLATING =3D (1U << __I_LRU_ISOLATING), @@ -840,7 +840,7 @@ struct inode { #endif =20 /* Misc */ - enum inode_state_flags_t i_state; + enum inode_state_flags_enum i_state; /* 32-bit hole */ struct rw_semaphore i_rwsem; =20 @@ -899,6 +899,35 @@ struct inode { void *i_private; /* fs or device private pointer */ } __randomize_layout; =20 +/* + * i_state handling + * + * We hide all of it behind helpers so that we can validate consumers. + */ +static inline enum inode_state_flags_enum inode_state_read(struct inode *i= node) +{ + return READ_ONCE(inode->i_state); +} + +static inline void inode_state_add(struct inode *inode, + enum inode_state_flags_enum addflags) +{ + WRITE_ONCE(inode->i_state, inode->i_state | addflags); +} + +static inline void inode_state_del(struct inode *inode, + enum inode_state_flags_enum delflags) +{ + WRITE_ONCE(inode->i_state, inode->i_state & ~delflags); + +} + +static inline void inode_state_set(struct inode *inode, + enum inode_state_flags_enum setflags) +{ + WRITE_ONCE(inode->i_state, setflags); +} + static inline void inode_set_cached_link(struct inode *inode, char *link, = int linklen) { VFS_WARN_ON_INODE(strlen(link) !=3D linklen, inode); --=20 2.43.0