mapping user data in kernel

mapping user data in kernel

[Hermann, Guy]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

Hi everybody,

here is a pb we don't manage to solve.

The general idea consists in a user process that gives data from its userspace to the kernel.
And the kernel makes them available to other user processes.


To modelize that we have 3 entities:

-a (user process) producer that mounts a FS and gives the corresponding data to the kernel
 thanks to the 5th parameter of mount()

-a dedicated kernel module handles the FS, it receives the (user process) data and makes
them available to the user processes (produceur and other processes)

-a (user process) consumer that gets data from the kernel via the FS syscalls.


While the producer keeps being alive (doing nothing, but data given to the kernel still existing),
 a consumer reads the mounted FS :  the kernel makes the producer's data available (to another
process than the producer) by finding the corresponding page and mapping it in the kernel when
needed. Indeed, the kernel has kept the data virtual address and the struct task of the producer
(having therefore access to the mm of the producer)

But it seems that the kernel does not see the correct data after mapping the page of the producer
when being in the context of the  consumer.

1st question:
Is such a treament (mapping in the kernel a page belonging to a user process that is not the
current one) relevant ? (can we use pgd_offset for a task->mm that does not belong to the current
process?)

2nd question:
If 1st question OK, why does this not work (were it in user-mode linux or in kernel mode) ?

Please find enclosed, the code of the module (which should be inserted in the kernel), the code of
the producer and consumer and the makefiles.

All these sources have been simplified as far as possible, the strategic treatments are in
-newfs_getpage of module.c: this function tries to remap a page that does not belong to the
current process in the kernel
-newfs_check_data of module.c: this function tries to find the bytes that characterize
(magic bytes) the data into the mapped page

Furthermore, the read data (even when incorrect) are displayed to have a visual comparison:
original data are characters or '.', incorrect data are represented by '?'....

To perform the test:
-insert the module in the kernel (insmod)
-mkdir    /mnt/newfs
-run the producer
-then run the consumer

Thanks in advance for helping...

GH


[-- Attachment #2: sources.tar.gz --]
[-- Type: application/x-gzip, Size: 16714 bytes --]

Re: mapping user data in kernel

[Christoph Lameter]

On Wed, 23 Feb 2005, Hermann, Guy wrote:

> The general idea consists in a user process that gives data from its userspace to the kernel.
> And the kernel makes them available to other user processes.

There is already a shared memory implementation in Linux that allows the
sharing of data between processes.

See shm_open

> 1st question:
> Is such a treament (mapping in the kernel a page belonging to a user process that is not the
> current one) relevant ? (can we use pgd_offset for a task->mm that does not belong to the current
> process?)

Yes, the kernel is able to map the same page into the address spaces of
multiple processes. And no, the page tables are separate thus you
wont be able to use addresses of page tables pages from one process for
the next.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

RE: mapping user data in kernel

[Hermann, Guy]

thanks for the answer Christoph,

I understand what did not work in our previsous try,
but as you probably have guessed the problem is more complex than
sharing memory between user processes (shm_open).


The real need we have is to provide a new filesystem called xxxFS
inserted in the kernel as a module. The raw data containing the data of the
the xxxFS are formatted and can only be handled by xxxFS: they are nevertheless
available, once interpreted by the xxxFS, to user processes thanks
to the open/read/close POSIX functions.


The critical functional points/constraints are the following:

-1.the xxxFS, which is in the kernel, should receive its raw data
during the read_super_block (mount)

-2.the raw data are known by xxxFS thanks to their address (the xxxFS
directly accesses the raw data without driver/device)

-3.we don't want that the symbol pointing the address be used in
the code of the xxxFS -> for link reasons we don't wan't that the
module contains  a symbol that points the raw data of the xxxFS

-4.so the address of xxxFS raw data should come from a user process

-5.but since xxxFS is a filesystem, it should access the raw data
even if the FS syscalls are done in the context of a process that
didn't provide the raw data address

-6.we did not know, a priori, the other processes that will access
the xxxFS data


I would like to know if these constraints are relevant and not contradictory?

If there is a contradiction, then we will cancel the constraints
that are problematic.

Thanks for your help

GH


-----Message d'origine-----
De : Christoph Lameter [mailto:christoph@graphe.net]De la part de
Christoph Lameter
Envoye : mercredi 23 fevrier 2005 17:07
A : Hermann, Guy
Cc : linux-mm@kvack.org
Objet : Re: mapping user data in kernel


On Wed, 23 Feb 2005, Hermann, Guy wrote:

> The general idea consists in a user process that gives data from its userspace to the kernel.
> And the kernel makes them available to other user processes.

There is already a shared memory implementation in Linux that allows the
sharing of data between processes.

See shm_open

> 1st question:
> Is such a treament (mapping in the kernel a page belonging to a user process that is not the
> current one) relevant ? (can we use pgd_offset for a task->mm that does not belong to the current
> process?)

Yes, the kernel is able to map the same page into the address spaces of
multiple processes. And no, the page tables are separate thus you
wont be able to use addresses of page tables pages from one process for
the next.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>