linux-kernel - Re: [RFC PATCH] file: Wrap locking mechanism for f_pos

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] [day] [month] [year] [list]

Message-ID: <20241204163449.GR3387508@ZenIV>
Date: Wed, 4 Dec 2024 16:34:49 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Jan Kara <jack@...e.cz>
Cc: I Hsin Cheng <richard120310@...il.com>, brauner@...nel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] file: Wrap locking mechanism for f_pos_lock

On Wed, Dec 04, 2024 at 11:26:44AM +0100, Jan Kara wrote:
> On Wed 04-12-24 17:23:25, I Hsin Cheng wrote:
> > As the implementation of "f->f_pos_lock" may change in the future,
> > wrapping the actual implementation of locking and unlocking of it can
> > provide better decoupling semantics.
> > 
> > "__f_unlock_pos()" already exist and does that, adding "__f_lock_pos()"
> > can provide full decoupling.
> > 
> > Signed-off-by: I Hsin Cheng <richard120310@...il.com>
> 
> I guess this would make sense for consistence. But Al, what was the
> motivation of introducing __f_unlock_pos() in the first place? It has one
> caller and was silently introduced in 63b6df14134d ("give
> readdir(2)/getdents(2)/etc. uniform exclusion with lseek()") about 8 years
> ago.

Encapsulation, actually.  Look:

* grabbing the lock without setting FDPUT_POS_UNLOCK should never happen;
fdget_pos() does handle that, no need for grabbing the lock as an operation
on existing struct fd instance

* dropping the lock is done in destructor; no need for separate "it may be
locked here" scope

* we want fdput_pos() to be inlined (and preferably eliminated in the case
of failed fdget_pos())

__f_lock_pos() would *break* encapsulation - any user of that thing would
have to deal with FDPUT_POS_UNLOCK bit and the rest of struct fd guts.