Can you explain why did you claimed, in the conversation with Mark, that the swap object does not work for you ?

If all you want is the shared memory between server and client, then IMO OBJT_SWAP or even OBJT_DEFAULT just provide it without additional overhead of single-purpose code. Does the kernel side access the memory, or is it purely transport between the server and the client ?

Can you explain why did you claimed, in the conversation with Mark, that the swap object does not work for you ?

If all you want is the shared memory between server and client, then IMO OBJT_SWAP or even OBJT_DEFAULT just provide it without additional overhead of single-purpose code. Does the kernel side access the memory, or is it purely transport between the server and the client ?

Hi,

The memory cannot be of SWAP type, because it needs to be quickly accessible. I.E. it is not allowed to swap this memory to disk.

Is that supported when using OBJT_SWAP.

Using a kernel allocated buffer might make it easier to debug memory leaks, that you can check all memory is returned when cuse.ko is unloaded.

--HPS

In D11392#257466, @hselasky wrote:

The memory cannot be of SWAP type, because it needs to be quickly accessible. I.E. it is not allowed to swap this memory to disk.

This cannot be an argument. If functionally the swap-backed memory is fine, I do not believe into the arguments 'as fast as possible'. Kernel does not slow-down you for malicious intent, but in low-memory situation, using the swappable memory allows the system to proceed instead of deadlocking. Otherwise you would not notice a difference in 'speed'.

Is that supported when using OBJT_SWAP.

Using a kernel allocated buffer might make it easier to debug memory leaks, that you can check all memory is returned when cuse.ko is unloaded.

If the shared communication memory is still mapped when cuse.ko is unloaded, what should happen ? I do not think that it is really possible to track such situations and prevent cuse.ko unload without huge and really unneeded efforts. Leaving the deallocation of the objects to normal VM lifecycle rules avoids unnecessary troubles, IMO.

If the shared communication memory is still mapped when cuse.ko is unloaded, what should happen ? I do not think that it is really possible to track such situations and prevent cuse.ko unload without huge and really unneeded efforts. Leaving the deallocation of the objects to normal VM lifecycle rules avoids unnecessary troubles, IMO.

The problem is the following. The callback functions we install will disappear from the .code segment and cannot be called after cuse.ko is unloaded. In other words cuse.ko must wait for all allocated memory or VM objects to be freed before unloading. Can this be done with SWAP ?

In D11392#257483, @hselasky wrote:

If the shared communication memory is still mapped when cuse.ko is unloaded, what should happen ? I do not think that it is really possible to track such situations and prevent cuse.ko unload without huge and really unneeded efforts. Leaving the deallocation of the objects to normal VM lifecycle rules avoids unnecessary troubles, IMO.

The problem is the following. The callback functions we install will disappear from the .code segment and cannot be called after cuse.ko is unloaded. In other words cuse.ko must wait for all allocated memory or VM objects to be freed before unloading. Can this be done with SWAP ?

What callbacks ? If you unref the allocated vm objects on cuse.ko unload, VM will correctly free both objects and objects page queues when the last process unmaps it. For OBJT_SWAP you do not need to do anything else except releasing _your_ references.

What callbacks ? If you unref the allocated vm objects on cuse.ko unload, VM will correctly free both objects and objects page queues when the last process unmaps it. For OBJT_SWAP you do not need to do anything else except releasing _your_ references.

The following callbacks:

static struct cdev_pager_ops cuse_pager_ops = {
	​        .cdev_pg_fault = cuse_pager_fault,
	​        .cdev_pg_ctor = cuse_pager_ctor,
	​        .cdev_pg_dtor = cuse_pager_dtor
	​};
	​

In D11392#257486, @hselasky wrote:

What callbacks ? If you unref the allocated vm objects on cuse.ko unload, VM will correctly free both objects and objects page queues when the last process unmaps it. For OBJT_SWAP you do not need to do anything else except releasing _your_ references.

The following callbacks:

static struct cdev_pager_ops cuse_pager_ops = {
	​        .cdev_pg_fault = cuse_pager_fault,
	​        .cdev_pg_ctor = cuse_pager_ctor,
	​        .cdev_pg_dtor = cuse_pager_dtor
	​};
	​

These callbacks only defined for the device pagers, VM automatically handles page allocations and free, as well as the page faults, for swap objects.

@kib

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

Personally I like malloc() better than the idea of a swap object. The though about having a swapout for CUSE driven device drivers I don't like.

In D11392#257488, @hselasky wrote:

@kib

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

Does the vm_ooffset_t *offset argument in the d_mmap_single() signature does what you need (I am not sure what and why you need) ?

Personally I like malloc() better than the idea of a swap object. The though about having a swapout for CUSE driven device drivers I don't like.

In D11392#257497, @kib wrote:

In D11392#257488, @hselasky wrote:

@kib

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

Does the vm_ooffset_t *offset argument in the d_mmap_single() signature does what you need (I am not sure what and why you need) ?

I need to be able to allocate a X pages VM object, and then only mmap() parts of it to userspace by d_mmap_single() calls.

--HPS

In D11392#257510, @hselasky wrote:

In D11392#257497, @kib wrote:

In D11392#257488, @hselasky wrote:

@kib

There is one more requirement. If I create a swap object I need to be able to offset inside the swap object. Is that supported?

Does the vm_ooffset_t *offset argument in the d_mmap_single() signature does what you need (I am not sure what and why you need) ?

I need to be able to allocate a X pages VM object, and then only mmap() parts of it to userspace by d_mmap_single() calls.

offset specifies the byte offset into the start of the mapping that will be created. Max allowed size of the mapping is in fact limited by the object size left after the offset, pages that are behind object limit cause SIGBUS.

But every your answer really raises next 'why' question. Why cannot you create a separate object per each pair of server/client mapping requests ?

@kib : How can two different processes share a piece of memory if not using the same VM object?

In D11392#257519, @hselasky wrote:

@kib : How can two different processes share a piece of memory if not using the same VM object?

I asked if it possible to use the same object per single pair of server/client request. It would be much simpler if you explained the userspace API you want to implement. It need not be a man page, but provide all essential details so that the suggestions would be usable.

Hi,

Yes, server and client can use same object, and that is what happens with the current patch when the "mem" handle is the same.

--HPS