lkml.org 
[lkml]   [2017]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] cramfs: direct memory access support
On Sat, 12 Aug 2017, Christoph Hellwig wrote:

> Direct physical memory access in a file system is never safe.
> Please make sure this goes through struct dax_operations.

Well, after having a closer look, I don't think dax might be relevant
here for a couple reasons:

- cramfs is read-only. No concurrent writes to worry about. Please
elaborate if you have other safety concerns in mind.

- This series targets small no-MMU systems. There is no paging involved
given the lack of a MMU. The whole of the filesystem is always
directly accessible in the address space from ROM alongside with the
actual kernel code being executed. I don't see how dax would ever be
pertinent here.

- Even with MMU systems, the maximum size of a cramfs image can't exceed
272MB. In practice it is likely to be much much less. Given this
targets small memory systems, there is always plenty of vmalloc space
left to map it all and even a 272MB memremap() wouldn't be a problem.
If it is a problem then maybe your system has large resources to
manage already and you're pretty unlikely to be using cramfs in the
first place, otherwise accessing it through a block device would be
just fine, at which point you'd better consider squashfs instead of
this.

All this to say that I think that dax is _way_ overkill and
inappropriate for the intended cramfs use case this series is
addressing.


Nicolas

\
 
 \ /
  Last update: 2017-08-14 04:30    [W:0.058 / U:0.992 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site