From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 8BC112FB084 for ; Fri, 10 Oct 2025 15:41:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760110865; cv=none; b=sOeViU1P1HZpbLjZJbq0H5c/kJzydmkTiV3Qk+LzEmUsW5Y6tM4Y3n8LjT0FOxLviNQM0ZcYwE3+x1t99qCWiFsTneDg2jbIGdtQPCoe6mlOjLHbqroZe9pKZDDGLINSOUvp7OwdG3nMYSkWv4JGQV4HNw0Wl1PT8rAkM5cm05o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760110865; c=relaxed/simple; bh=xOJuDOIlas451FiXAAHgBhsNRzt6HStLrb4Y3mKzjBE=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GuNqWmy/5F3YV2l1ggNAKbX453UteZFv9ra3uBcoMuDGxc0pCi89ZHtp9uDNZ0xwOAl6pz9YAOIIdSxtootjy4sbF+vzYdc8RqWyd0Y+nQThE/FgGQJdZQgAeQetz//+kY+r+MPRJTFXb+kT3RvqMOYBJCtuxkRCkvJ6twjWXQ8= 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=HAjzMCP6; arc=none smtp.client-ip=209.85.218.50 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="HAjzMCP6" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-b50206773adso599436066b.0 for ; Fri, 10 Oct 2025 08:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760110861; x=1760715661; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pNrx81VuCOUnlOhs53ChqFbGZmsPkwHURyqTboyD4SA=; b=HAjzMCP6WRFHv/sreS1KWvOy6uXorsCkmnygvRunN2bqmGbBktPhZ9U6HGiqyMP0cZ vcYM6+1DmRsf5UmsVPkExeA4WxM6kbNyB2VNxeu4ENsh3hpq9Wt6RuMc1X8lZ7HSIaWs EqIktZDYJcyX5J8DP6WL/i/WTfjV7NdvFv/trIlSgKJyMxW0Aisbc1WLCgoTmSmzq2tU 4rcf7rzcR3yi7nRiW4ojKWvGw1hg2qy38twmbdGmAAtI2oCDGcmLTkDX+d1WAmlwHDBy KkHR6uV/go7sPmZTc+/dBMRFzIs+gbgdJBlT9wfbYDR3m+TfJFt+zxi0ii5lQeVsCD/E 0i0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760110861; x=1760715661; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pNrx81VuCOUnlOhs53ChqFbGZmsPkwHURyqTboyD4SA=; b=gqEjBJDGRcyiEpAOYtyqhvE69GYKJbIBGWayR6w3RnaTWFC5gyXgDsyhkqfT1KAqph U2fLyiaXW6Uz5U/hX+w1zmnjXKkqj0OkUEq5tStOavwyIiwPOqrt+D2Ue1ammHCpJK44 tVJG7sL3epDMBWerOpBg9SD8SqH6Oys486KdWj/pSHjyp9LhUoWeEXDc+W5xGn5WrX/J HNK+I+DbWK3ZUBK7as2R4I3mx/TKNE87dXaDxE/50E3wGWJT9IE+M6+STamm+pKvVKng nfOfoHbgiqsObhOqgPOjcTQ6GuLAtBo5uCjsUIAMlgkaXMkuHLBOYmQyrZTCDGexdcg1 uVig== X-Forwarded-Encrypted: i=1; AJvYcCUuGZK2iHl+VhxpX1uIe5mU4hXOtB9VZk203dtC8RMaXbG76V+Jct0fHJMhXGDG/9+RIC9utFqC3WEU@vger.kernel.org X-Gm-Message-State: AOJu0Yzz1cLv2hkTw4PtDNZ7isXZ+nxH5jmbubR3sf4blWJDy6BG0OpH WS1KhkOqJko3r63ZoMUcPMHtbMtjznt8jYCkV8TpeId2O7Ozt5Vf2IE67ojnHQCDjRwmCZXgEwV nhgh+dGIwZ2AiuaDKh/T8h1jhSztc63I= X-Gm-Gg: ASbGncsn8UT7TLMWsBydH5UPE9aFPcJSn3e4FYnXO82XYxGHSDEMr9NdNA5DtYR40Lg Xj1oLkPiGh4oJt71EOI7vQ348jkmMEuCwpsbBkz28MzavExXO4+XeDl1AvhijFiyARwGBoiqH5z 72ZXvgIJnYuu59f+chz3oc+JXDSyYPugJ0L+KhyVEYIbueHUez75Vq89MgdGjNlb+YVFmfgiCcJ 5estd72XbpDlWK9zf4NT65KLM0IQGLGgK74STVja3f/dJm5qiHVDkUtXDZ2jUNuBz5a X-Google-Smtp-Source: AGHT+IFsVwlKz3dpQMSn0djeXDN0dipdKA/kgBAE2NxkawkzYdINOsshggkYLd2MlBJ2D7HcedRqmChtEct9QlvTNTA= X-Received: by 2002:a17:907:3e2a:b0:b2a:47c9:8ff5 with SMTP id a640c23a62f3a-b50bd050daemr1405146466b.10.1760110860769; Fri, 10 Oct 2025 08:41:00 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251009075929.1203950-1-mjguzik@gmail.com> <20251009075929.1203950-14-mjguzik@gmail.com> In-Reply-To: From: Mateusz Guzik Date: Fri, 10 Oct 2025 17:40:49 +0200 X-Gm-Features: AS18NWBB3Bmc7XAi8sS7M18NKhoZbvSirs7my7gPJLr4eYk4Rf7Ljkokn3EGE5o Message-ID: Subject: Re: [PATCH v7 13/14] xfs: use the new ->i_state accessors To: Jan Kara Cc: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 10, 2025 at 4:41=E2=80=AFPM Jan Kara wrote: > > On Thu 09-10-25 09:59:27, Mateusz Guzik wrote: > > Change generated with coccinelle and fixed up by hand as appropriate. > > > > Signed-off-by: Mateusz Guzik > > ... > > > @@ -2111,7 +2111,7 @@ xfs_rename_alloc_whiteout( > > */ > > xfs_setup_iops(tmpfile); > > xfs_finish_inode_setup(tmpfile); > > - VFS_I(tmpfile)->i_state |=3D I_LINKABLE; > > + inode_state_set_raw(VFS_I(tmpfile), I_LINKABLE); > > > > *wip =3D tmpfile; > > return 0; > > @@ -2330,7 +2330,7 @@ xfs_rename( > > * flag from the inode so it doesn't accidentally get mis= used in > > * future. > > */ > > - VFS_I(du_wip.ip)->i_state &=3D ~I_LINKABLE; > > + inode_state_clear_raw(VFS_I(du_wip.ip), I_LINKABLE); > > } > > > > out_commit: > > These two accesses look fishy (not your fault but when we are doing this > i_state exercise better make sure all the places are correct before > papering over bugs with _raw function variant). How come they cannot race > with other i_state modifications and thus corrupt i_state? > I asked about this here: https://lore.kernel.org/linux-xfs/CAGudoHEi05JGkTQ9PbM20D98S9fv0hTqpWRd5fWj= EwkExSiVSw@mail.gmail.com/ > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c > > index caff0125faea..ad94fbf55014 100644 > > --- a/fs/xfs/xfs_iops.c > > +++ b/fs/xfs/xfs_iops.c > > @@ -1420,7 +1420,7 @@ xfs_setup_inode( > > bool is_meta =3D xfs_is_internal_inode(ip); > > > > inode->i_ino =3D ip->i_ino; > > - inode->i_state |=3D I_NEW; > > + inode_state_set_raw(inode, I_NEW); > > > > inode_sb_list_add(inode); > > /* make the inode look hashed for the writeback code */ > > Frankly, the XFS i_state handling is kind of messy and I suspect we shoul= d > be getting i_state =3D=3D 0 here. But we need to confirm with XFS guys. I= 'm > poking into this because this is actually the only case where we need > inode_state_set_raw() or inode_state_clear_raw() outside of core VFS and > I'd like to get rid of these functions because IMHO they are actively > dangerous to use. > I'm going to address this in the other e-mail.