linux-kernel - Re: [PATCH v3] tty: tty_io: remove hung_up_tty

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240502181444.GF2118490@ZenIV>
Date: Thu, 2 May 2024 19:14:44 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Marco Elver <elver@...gle.com>, paulmck@...nel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	syzbot <syzbot+b7c3ba8cdc2f6cf83c21@...kaller.appspotmail.com>,
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
	Nathan Chancellor <nathan@...nel.org>,
	Arnd Bergmann <arnd@...nel.org>, Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops

On Thu, May 02, 2024 at 10:29:52AM -0700, Linus Torvalds wrote:

> Yes, this is unusual. The *common* thing is to mark pointers as being
> volatile. But this really is something entirely different from that.

The common thing is to mark pointers are pointers to volatile;
calling them "volatile pointers" is common and incorrect, and the only
reason why that sloppy turn of phrase persists is that real "volatile
pointers" are rare...

Marco,
	struct foo volatile *p;
declares p as a (non-volatile) pointer to volatile struct foo.
	struct foo * volatile p;
declares p as volatile pointer to (non-volatile) struct foo.

The former is a statement about the objects whose addresses might
be stored in p; the latter is a statement about the object p itself.

Replace volatile with const and it becomes easier to experiment with:
	char const *p;
	char s[] = "barf";
	char * const q = s;
	...
	p = "yuck"; 	- fine, p itself can be modified
	*p = 'a';	- error *p can not be modified, it's an l-value of type const char
	q = s + 1;	- error, can't modify q
	*q = 'a';	- fine, *q is l-value of type char
	p = q;		- fine, right-hand side of assignment loses the top
			  qualifier, so q (const pointer to char as l-value)
			  becomes a plain pointer to char, which can be
			  converted to pointer to const char, and stored in
			  p (l-value of type pointer to const char)
	strlen(q);	- almost the same story, except that it's passing
			  an argument rather than assignment; they act the
			  same way.
	strcpy(q, "s");	- almost the same, except that here the type of
			  argument is pointer to char rather than pointer to
			  const char (strlen() promises not to modify the
			  string passed to it, strcpy() obviously doesn't)
	strcpy(p, "s");	- error; pointer to char converts to a pointer
			  to const char, but not the other way round.

The situations where you want a const (or volatile) pointer (as opposed to
pointer to const or volatile object) are rare, but this is exactly what
you are asking for - you want to say that the value of 'f_op' member
in any struct file can change at any time.  That value is an address of
some instance of struct file_operations and what you want to express is
the property of f_op member itself, not that of the objects whose addresses
might end up stored there.

So having a driver do
	const struct file_operations *ops = file->f_op;
is fine - it's basically "take the value of 'file'; it will be an address
of some struct file instance.  Fetch 'f_op' from that instance, without
any assumptions of the stability of that member.  Use whatever value
you find there as initial value of 'ops'".

That's fine, and since nobody is going to change 'ops' itself behind your
back, you don't need any qualifiers on it.  The type of 'ops' here is
"(unqualified) pointer to const struct file_operations".