On Tue, 2023-06-20 at 15:57 +0500, stsp wrote: > Hello, > > 20.06.2023 15:51, Jeff Layton пишет: > > On Tue, 2023-06-20 at 14:55 +0500, Stas Sergeev wrote: > > > Currently F_OFD_GETLK sets the pid of the lock owner to -1. > > > Remove such behavior to allow getting the proper owner's pid. > > > This may be helpful when you want to send some message (like SIGKILL) > > > to the offending locker. > > > > > > Signed-off-by: Stas Sergeev <stsp2@xxxxxxxxx> > > > > > > CC: Jeff Layton <jlayton@xxxxxxxxxx> > > > CC: Chuck Lever <chuck.lever@xxxxxxxxxx> > > > CC: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx> > > > CC: Christian Brauner <brauner@xxxxxxxxxx> > > > CC: linux-fsdevel@xxxxxxxxxxxxxxx > > > CC: linux-kernel@xxxxxxxxxxxxxxx > > > > > > --- > > > fs/locks.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/fs/locks.c b/fs/locks.c > > > index 210766007e63..ee265e166542 100644 > > > --- a/fs/locks.c > > > +++ b/fs/locks.c > > > @@ -2158,8 +2158,6 @@ static pid_t locks_translate_pid(struct file_lock *fl, struct pid_namespace *ns) > > > pid_t vnr; > > > struct pid *pid; > > > > > > - if (IS_OFDLCK(fl)) > > > - return -1; > > > if (IS_REMOTELCK(fl)) > > > return fl->fl_pid; > > > /* > > NACK on this one. > > > > OFD locks are not owned by processes. They are owned by the file > > description (hence the name). Because of this, returning a pid here is > > wrong. > > But fd is owned by a process. No, it isn't. fd's can be handed off between processes via unix descriptors. Multithreaded processes are also a bit of a gray area here: Suppose I open a file and set an OFD lock on it in one task, and then let that task exit while the file is still open. What should l_pid say in that case? > PID has a meaning, you can send SIGKILL > to the returned PID, and the lock is clear. > Was there any reason to hide the PID at > a first place? > Yes, because OFD locks are not tied to a pid in the same way that traditional POSIX locks are. > > > This precedent comes from BSD, where flock() and POSIX locks can > > conflict. BSD returns -1 for the pid if you call F_GETLK on a file > > locked with flock(). Since OFD locks have similar ownership semantics to > > flock() locks, we use the same convention here. > OK if you insist I can drop this one and > search the PID by some other means. > Just a bit unsure what makes it so important > to overwrite the potentially useful info > with -1. > > So in case you insist on that, then should > I send a v2 or can you just drop the patch > yourself? -- Jeff Layton <jlayton@xxxxxxxxxx>
