Tags: rhvgoyal/linux

fuse,virtiofs: Add logic to free up a memory range

Add logic to free up a busy memory range. Freed memory range will be
returned to free pool. Add a worker which can be started to select
and free some busy memory ranges.

Process can also steal one of its busy dax ranges if free range is not
available. I will refer it to as direct reclaim.

If free range is not available and nothing can't be stolen from same
inode, caller waits on a waitq for free range to become available.

For reclaiming a range, as of now we need to hold following locks in
specified order.

	down_write(&fi->i_mmap_sem);
	down_write(&fi->i_dmap_sem);

We look for a free range in following order.

A. Try to get a free range.
B. If not, try direct reclaim.
C. If not, wait for a memory range to become free

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>

fuse,virtiofs: Add logic to free up a memory range

Add logic to free up a busy memory range. Freed memory range will be
returned to free pool. Add a worker which can be started to select
and free some busy memory ranges.

Process can also steal one of its busy dax ranges if free range is not
available. I will refer it to as direct reclaim.

If free range is not available and nothing can't be stolen from same
inode, caller waits on a waitq for free range to become available.

For reclaiming a range, as of now we need to hold following locks in
specified order.

	down_write(&fi->i_mmap_sem);
	down_write(&fi->i_dmap_sem);

We look for a free range in following order.

A. Try to get a free range.
B. If not, try direct reclaim.
C. If not, wait for a memory range to become free

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>

fuse: Get rid of -EAGAIN logic in dmap free worker thread

Now we are not doing inode trylock anymore. That means we will not get
-EAGAIN at high frequency. So get rid of this logic. Its not needed anymore.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

virtiofs: Support blocking posix locks (fcntl(F_SETLKW))

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.

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 locking 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. 

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

virtiofs: Support blocking posix locks (fcntl(F_SETLKW))

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.

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 locking 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. 

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

fuse: Take inode lock for dax inode truncation

When a file is opened with O_TRUNC, we need to make sure that any other
DAX operation is not in progress. DAX expects i_size to be stable.

In fuse_iomap_begin() we check for i_size at multiple places and we expect
i_size to not change.

Another problem is, if we setup a mapping in fuse_iomap_begin(), and
file gets truncated and dax read/write happens, KVM currently hangs.
It tries to fault in a page which does not exist on host (file got
truncated). It probably requries fixing in KVM.

So for now, take inode lock. Once KVM is fixed, we might have to
have a look at it again.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

fuse: Get rid of -EAGAIN logic in dmap free worker thread

Now we are not doing inode trylock anymore. That means we will not get
-EAGAIN at high frequency. So get rid of this logic. Its not needed anymore.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

fuse: Get rid of -EAGAIN logic in dmap free worker thread

Now we are not doing inode trylock anymore. That means we will not get
-EAGAIN at high frequency. So get rid of this logic. Its not needed anymore.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

fuse: Get rid of -EAGAIN logic in dmap free worker thread

Now we are not doing inode trylock anymore. That means we will not get
-EAGAIN at high frequency. So get rid of this logic. Its not needed anymore.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>

fuse: Get rid of ->fh field from fuse_removemapping_in

David Gilbert mentioned we are not using this field. So he has got rid of
it in virtiofsd as well.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>