On Thu, Aug 24, 2017 at 9:58 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Wed, Aug 23, 2017 at 04:48:40PM -0700, Dan Williams wrote: >> We are running running short of vma->vm_flags. We can avoid needing a >> new VM_* flag in some cases if the original @flags submitted to mmap(2) >> is made available to the ->mmap() 'struct file_operations' >> implementation. For example, the proposed addition of MAP_DIRECT can be >> implemented without taking up a new vm_flags bit. Another motivation to >> avoid vm_flags is that they appear in /proc/$pid/smaps, and we have seen >> software that tries to dangerously (TOCTOU) read smaps to infer the >> behavior of a virtual address range. >> >> This conversion was performed by the following semantic patch. There >> were a few manual edits for oddities like proc_reg_mmap. >> >> Thanks to Julia for helping me with coccinelle iteration to cover cases >> where the mmap routine is defined in a separate file from the 'struct >> file_operations' instance that consumes it. > > How are we going to check that an instance actually supports any > of those flags? In patch 3 I validate the flags by introducing an "mmap_supported_mask" field to 'struct file_operations'. It will be zero by default for almost all implementations and zero means "support the legacy mmap flags". -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
