From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 AAB712DCF6B for ; Fri, 19 Sep 2025 13:39:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758289198; cv=none; b=F/e0QHeTYjnpqwViSftzvK2V/KGpqw46JR62hxTVOzOpRewd3H2CQ0Q5SxAsZ0FJ3YpBWogBuBl4cOrKehS00u8Cf9A9GfP6JqxR1ohHDr9qEO3whNvy2RAbEHQvq3V4S7xABD1hwb//820QbiJINmq1l2varrRC4Sh/9tTYYQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758289198; c=relaxed/simple; bh=yS4tjevziR0toZXf/8EWO3F7qazDep+9Exg0qySjl74=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=n6TNElLXFYlAOKhspAT524ZW6QdSA/zcPqw9yAJlwRVk2VAZiYQf68zrzssLN+3aydF10HAuWKFpeQWeWFVL+o09cVwGXtNRmT+VEKvwa61t6zyIt75j3GhKfm/NYOd+1Vxj7zyaNv40xF+CWFbZa80jSrWf/KzNmm1+14KZDSQ= 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=jnXbZG+z; arc=none smtp.client-ip=209.85.208.53 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="jnXbZG+z" Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-62fbd0a9031so1540456a12.0 for ; Fri, 19 Sep 2025 06:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758289195; x=1758893995; 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=yS4tjevziR0toZXf/8EWO3F7qazDep+9Exg0qySjl74=; b=jnXbZG+zX9hZ6XwqFUrBGnWw27SogfV9/JKlKEpktyKWb5O2fIVJJEH8q4uuvODhoM 724vvfts7YOcJAvxLoeFc/IKQe+Ive081Hyfw6FH7zWqjG9SUeHcESyxxpEnOUvgNiYS g/4hGXkCmSZDuRokbzpe5ZuklfVp+v2XT7rSWspN8SeXk5QrT/+qUN7UOpaJIjf6HLMy b3glQe4a1+2XTUVwoqJOUk+bs1iOIQW1aAk15/oq5o2B+7qpXGgT70twthgf/sMOq7Rc XqVI+L1igrk9IOoUilhvYVXZUFK8nN7jUl7YmCvz2FZIs3cVYMjxEFCNPF4ouhxL3fV2 xxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758289195; x=1758893995; 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=yS4tjevziR0toZXf/8EWO3F7qazDep+9Exg0qySjl74=; b=ST8PBb/KbBeIBgU2r020L97iHpm1HjfAZEEcRgW/agMId1GEwO3T50nL3bkY9KA6Up gza+8GdZudwczt8q7Tkfrlop1k4MFib/bVB7GbcBCjQYa9N/MjeO9vmPNLZVoaR0lMQk 5eS9ETYhia9TSdLaSPpYk8MIpRyBi5Nr6bERElFYDlZLLkQWWDjtVpMdWlj+2JQRVKyK EWxa5XITUMzpgImxeoQFm0NGANzJ46bSRYCXB1NNPgHf4tBuXGULXQ434E6ciatNIeZR GiqtL/tYmujwuFHXFRasALmHt+OxyZDaNW8/FO4yEgdZsrOkBJRci4szla5/w3+KEWaU ErFA== X-Forwarded-Encrypted: i=1; AJvYcCVKpWmhKsYTge51AmPNZwJRpOyuScjpoCPlVSTavI5T6iCxFJ39Peiqci33SvhwfLXUvld+gNZoImXQ@vger.kernel.org X-Gm-Message-State: AOJu0YwPCv6q2Ph2yWRsAy6VSzwB0lhj4M2n4vQsgZWV9gRRxnXwPINa YjHlB8EDp/bdNsBVcLPJkY94AHImyLjDaIpFVzCQT3WC2jq9WdQJ6Lx8SqowCXG+eV7xKSOqhhW PI1ukH+2r9ByGo9b5rqFfJOqYIdrwtYo= X-Gm-Gg: ASbGncsSRT9pZOY7+V9d7iaUDlbhWBz1iLDNnN7Ep3ATE3D2jJuUadOZGW6VBeyXBcs Dz/beO2HHtsKJE/y6oyk5M17+NJJhocW/DhTIY37DiXmjP7znMf7ANOXUKUpz5nFkVAhYChrEf7 +EnIcc+a0IXdLTiaR9IjA5Cr2Ulpp6CFDBfw73R+WazjjBeRjNSuQRGEDG/wtIyl3hVLIuIH7lq o7qEsVmUIUQgLzhXkrcHNgheTfa+Dvu+WyO2OA= X-Google-Smtp-Source: AGHT+IG8y92yXBXG6PZ8P/ch2ZSS1wNstcNcIuj6+aYZ7P6TYOVq/b6w97srocc+Y3Zhyd7rZ7srrxYnAt6SbPx+jsY= X-Received: by 2002:a05:6402:4612:b0:62f:36bb:d8ba with SMTP id 4fb4d7f45d1cf-62fc0a7af44mr2864980a12.22.1758289194894; Fri, 19 Sep 2025 06:39:54 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250916135900.2170346-1-mjguzik@gmail.com> <20250919-unmotiviert-dankt-40775a34d7a7@brauner> In-Reply-To: From: Mateusz Guzik Date: Fri, 19 Sep 2025 15:39:41 +0200 X-Gm-Features: AS18NWBesGPMB9d6nHQB7uHFd7U6Qkkb038pDKj5Q9kZX-8UZXEAoD__UTqjpFY Message-ID: Subject: Re: [PATCH v4 00/12] hide ->i_state behind accessors To: Christian Brauner 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2025 at 3:09=E2=80=AFPM Mateusz Guzik w= rote: > > On Fri, Sep 19, 2025 at 2:19=E2=80=AFPM Christian Brauner wrote: > > > > On Tue, Sep 16, 2025 at 03:58:48PM +0200, Mateusz Guzik wrote: > > > This is generated against: > > > https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/commit/?h= =3Dvfs-6.18.inode.refcount.preliminaries > > > > Given how late in the cycle it is I'm going to push this into the v6.19 > > merge window. You don't need to resend. We might get by with applying > > and rebasing given that it's fairly mechanincal overall. Objections > > Mateusz? > > First a nit: if the prelim branch is going in, you may want to adjust > the dump_inode commit to use icount_read instead of > atomic_read(&inode->i_count)); > > Getting this in *now* is indeed not worth it, so I support the idea. Now that I wrote this I gave it a little bit of thought. Note almost all of the churn was generated by coccinelle. Few spots got adjusted by hand. Regressions are possible in 3 ways: - wrong routine usage (_raw/_once vs plain) leading to lockdep splats - incorrect manual adjustment between _raw/_once and plain variants, again leading to lockdep splats - incorrect manually added usage (e.g., some of the _set stuff and the xfs changes were done that way) The first two become instant non-problems if lockdep gets elided for the merge right now. The last one may be a real concern, to which I have a counter-proposal: extended coccinelle to also cover that, leading to *no* manual intervention. Something like that should be perfectly safe to merge, hopefully avoiding some churn headache in the next cycle. Worst case the _raw/_once usage would be "wrong" and only come out after lockdep is restored. Another option is to make the patchset into a nop by only providing the helpers without _raw/_once variants, again fully generated with coccinelle. Again should make it easier to shuffle changes in the next cycle. I can prep this today if it sounds like a plan, but I'm not going to strongly argue one way or the other.