/dev/mem implementation

/dev/mem implementation

[Felix Rubinstein]

The recent kernels use CONFIG_STRICT_DEVMEM and CONFIG_X86_PAT
concerning the /dev/mem (/dev/kmem) so interchangeably one cannot
figure out what exactly does it mean to access the /dev/mem if both
CONFIG_STRICT_DEVMEM and CONFIG_X86_PAT are disabled.

It would be more logically to remove pat_enabled variable in
arch/x86/mm/pat.c and to make everything under CONFIG_X86_PAT define.
The same goes for phys_mem_access_prot_allowed function (from
arch/x86/mm/pat.c) even though CONFIG_X86_PAT is disabled.
To make the story worse there are four implementations of
range_is_allowed depending on how CONFIG_STRICT_DEVMEM and
CONFIG_X86_PAT are defined.


I see the motivation to limit the access to DRAM from root account
CONFIG_STRICT_DEVMEM by mmap'ing /dev/[k]mem but it's easily overruled
by simple char driver and implementing mmap of it's own totally
bypassing all limitations.

What do you think about it guy?
Appreciate it.

Thanks,
Felix R.

Re: /dev/mem implementation

[Arjan van de Ven]

On Sun, 17 Jan 2010 18:47:10 +0200
Felix Rubinstein <felixru@gmail.com> wrote:

> I see the motivation to limit the access to DRAM from root account
> CONFIG_STRICT_DEVMEM by mmap'ing /dev/[k]mem but it's easily overruled
> by simple char driver and implementing mmap of it's own totally
> bypassing all limitations.
> 
> What do you think about it guy?
> Appreciate it.

the reason PAT bans parts of /dev/mem is simple: it is illegal to have
mapping aliases (different cachability) for the same physical page.
Normal kernel APIs take care of this for the normal case, but /dev/mem
would be a back door into that.
This is a hardware imposed requirement, and violating the rule can have
really nasty consequences... hence the PAT code just not allowing it.

If you feel that you have a valid use case where you really want do
muck with such memory, it might be a good idea to explain that
usecase....

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: /dev/mem implementation

[Andi Kleen]

Arjan van de Ven <arjan@infradead.org> writes:
>
> If you feel that you have a valid use case where you really want do
> muck with such memory, it might be a good idea to explain that
> usecase....

To add to it this only applies to uncacheable pages which don't use
MTRRs. Unless in some special situations (e.g. a lot of GPU 3d data
active) that situation tends to be rare and not apply to most memory.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: /dev/mem implementation

[Felix Rubinstein]

The usecase is broadcom 10GbE switch driver which maps DMA memory to userspace.
I can find one more libe1000 which uses char driver to map DMA memory
to userspace too.
So, how can I implement userspace drivers in recent kernels which want
to map DMA memory to userspace if STRICT_DEVMEM or PAT (either of
them) are enabled.

The motivation to implement network drivers is not new and there are
here and there mini projects to bypass Linux networks stack to gain
better latency as stack has lots of locks around, buffer copying
(userspace to kernel and vice versa), etc... which only add latency.

Thanks,
Felix R.

On Sun, Jan 17, 2010 at 7:40 PM, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sun, 17 Jan 2010 18:47:10 +0200
> Felix Rubinstein <felixru@gmail.com> wrote:
>
>> I see the motivation to limit the access to DRAM from root account
>> CONFIG_STRICT_DEVMEM by mmap'ing /dev/[k]mem but it's easily overruled
>> by simple char driver and implementing mmap of it's own totally
>> bypassing all limitations.
>>
>> What do you think about it guy?
>> Appreciate it.
>
> the reason PAT bans parts of /dev/mem is simple: it is illegal to have
> mapping aliases (different cachability) for the same physical page.
> Normal kernel APIs take care of this for the normal case, but /dev/mem
> would be a back door into that.
> This is a hardware imposed requirement, and violating the rule can have
> really nasty consequences... hence the PAT code just not allowing it.
>
> If you feel that you have a valid use case where you really want do
> muck with such memory, it might be a good idea to explain that
> usecase....
>
> --
> Arjan van de Ven        Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
>

Re: /dev/mem implementation

[Arjan van de Ven]

On Mon, 18 Jan 2010 14:18:22 +0200
Felix Rubinstein <felixru@gmail.com> wrote:

> The usecase is broadcom 10GbE switch driver which maps DMA memory to
> userspace. I can find one more libe1000 which uses char driver to map
> DMA memory to userspace too.
> So, how can I implement userspace drivers in recent kernels which want
> to map DMA memory to userspace if STRICT_DEVMEM or PAT (either of
> them) are enabled.

for these cases the driver should provide it's own mmap method that
exposes only those pages that the hardware has access to. You need
something like this anyway to deal with the dma mapping api....



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org