From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 035F420B20A; Fri, 8 Nov 2024 15:32:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731079930; cv=none; b=LK9dILs39dGjfh7fqjTVJY0Ppmn/jEIEsD6ltlhqV5YtQZvUH6zDWtHx+Dk4Mnq99RXnmuOgFbjATXVh+opnpLn0hx5F+5zI5tl7L4tDwvQYEiARvS5RpFNTXmQGUZi4vD/4Cmy7+PKhGMkt3IP+N3TcB5mC0F3D0LnqGC+mB10= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731079930; c=relaxed/simple; bh=+o6SMNW5ltrwkaUFGnTAvx5ruimZe+vSc0bhjjOji04=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=nEUS0edC7nbHwyXbRExwb6ExJ7901KnGqXPkQlHPfQedKY6ppXdAey0InQpGt0JtcbiFg6Cs/G5P3+P7ElqlthHcy5oWETHpWntb6JDFdrV6kaH9nYZs/o5y9TUj+/j8KlWXvqRMd4zOy3LDtq1HviOkt9RfQ2qgGY5npjxGxKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UEeqontT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UEeqontT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56DFEC4CECD; Fri, 8 Nov 2024 15:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731079929; bh=+o6SMNW5ltrwkaUFGnTAvx5ruimZe+vSc0bhjjOji04=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=UEeqontTqm1DIKZo67sydAeXTG8uE8k+xExg3SQ8HcuIVj8Pkxet37LDE61TX4Y55 ml7mh8upGx70b2e0DnlZnKcknOif47RdpsZjF0BWQ7Dmc6Qnx0LF+CBHff8NsJnk/q vuqQW4yIAnkmzL1xEHxpq7cKDMXS8EOZQxTG9UrujnNtsTvWKXlwk1TEHogaa7F/+t iFCky72XMaQoGgj9f0kMcrNTOERWEK4TPdvwlQBINJCseNE0mIk1uBFZZKyTzPPK/T UY/NJy1oxASqjaoQ6mEpwGvyhCSA2VsfpBp9YbeZ0zFHoQamhPw00Wpp0NCVaoDv/H 47R67IEWXzuDQ== Date: Fri, 08 Nov 2024 07:32:04 -0800 From: Kees Cook To: Stas Sergeev , linux-kernel@vger.kernel.org CC: Eric Biederman , Andy Lutomirski , Aleksa Sarai , Alexander Viro , Christian Brauner , Jan Kara , Thomas Gleixner , Jeff Layton , John Johansen , Chengming Zhou , Casey Schaufler , Adrian Ratiu , Felix Moessbauer , Jens Axboe , Oleg Nesterov , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, "Peter Zijlstra (Intel)" Subject: Re: [PATCH v2 1/2] procfs: avoid some usages of seq_file private data User-Agent: K-9 Mail for Android In-Reply-To: <20241108101339.1560116-2-stsp2@yandex.ru> References: <20241108101339.1560116-1-stsp2@yandex.ru> <20241108101339.1560116-2-stsp2@yandex.ru> Message-ID: <618F0D80-F2E1-49C1-AA25-B2C0CC46F519@kernel.org> 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-Transfer-Encoding: quoted-printable On November 8, 2024 2:13:38 AM PST, Stas Sergeev wrote= : >seq_file private data carries the inode pointer here=2E >Replace >`struct inode *inode =3D m->private;` >with: >`struct inode *inode =3D file_inode(m->file);` >to avoid the reliance on private data=2E Conceptually this seems good, though I'd expect to see the removal of _set= ting_ m->private too in this patch=2E >This is needed so that `proc_single_show()` can be used by >custom fops that utilize seq_file private data for other things=2E >This is used in the next patch=2E Now that next patch is pretty wild=2E I think using proc is totally wrong = for managing uid/gid=2E If that's going to happen at all, I think it should= be tied to pidfd which will already do the correct process lifetime manage= ment, etc=2E -Kees --=20 Kees Cook