On Wed, Oct 06, 2021 at 02:55:16PM +0200, Miklos Szeredi wrote: > On Thu, 30 Sept 2021 at 16:39, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > > Add a new notification type FUSE_NOTIFY_LOCK. This notification can be > > sent by file server to signifiy that a previous locking request has > > completed and actual caller should be woken up. > > > > As of now we don't support blocking variant of posix locks and daemon > > returns -EOPNOTSUPP. Reason being that it can lead to deadlocks. > > Virtqueue size is limited and it is possible we fill virtqueue with > > all the requests of fcntl(F_SETLKW) and wait for reply. And later a > > subsequent unlock request can't make progress because virtqueue is full. > > And that means F_SETLKW can't make progress and we are deadlocked. > > > > This problem is not limited to posix locks only. I think blocking remote > > flock and open file description locks should face the same issue. Right > > now fuse does not support open file description locks, so its not > > a problem. But fuse/virtiofs does support remote flock and they can use > > same mechanism too. > > > > Use notification queue to solve this problem. After submitting lock > > request device will send a reply asking requester to wait. Once lock is > > available, requester will get a notification saying lock is available. > > That way we don't keep the request virtueue busy while we are waiting for > > lock and further unlock requests can make progress. > > > > When we get a reply in response to lock request, we need a way to know > > if we need to wait for notification or not. I have overloaded the > > fuse_out_header->error field. If value is ->error is 1, that's a signal > > to caller to wait for lock notification. Overloading ->error in this way > > is not the best way to do it. But I am running out of ideas. > > Since all values besides -511..0 are reserved this seems okay. > However this needs to be a named value and added to uapi/linux/fuse.h. Ok, I will define this value and put in uapi/linux/fuse.h. Thanks Vivek
