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 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
