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@xxxxxxxxx>
>
> 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.
