On Tue, 2017-06-20 at 15:17 -0400, Benjamin Coddington wrote: > On 20 Jun 2017, at 13:06, Jeff Layton wrote: > > > > Now that I think about it a bit more, I don't think we really need a > > flag here. > > > > Just have the ->lock operation set the fl_pid to a negative value. That > > will never be a valid pid anyway. Then flock_translate_pid could just > > return any negative value directly instead of trying to translate it. > > > > In practice we would always just set it to -1. Maybe even add something > > like this that the lock-> operation could set it to? > > > > #define FILE_LOCK_OWNER_UNDEFINED -1 > > So for filesystems that set a remote pid, they should negate the pid to mean > that the pid should not be translated? Then when we return that pid, we > flip it back again, or display a negative number, or turn it into -1? > > The flag, having a readable name, would make things a bit clearer as to what > the filesystems expect to happen to that pid value. > I now think that we really only ought to be filling out the pid when it refers to a process on the local host. It seems sketchy to me to return a pid here that is really the pid on another host, but happens to have the same pid as something else on this host. It's misleading at best, and if anyone tries to act on that info it could be dangerous. So I'm thinking that we should just set it to -1 when the lock is held by another host entirely. But, since pid values must be positive, we can code the basic infrastructure to return any negative value as-is instead of trying to translate it. -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
