On Sun, Mar 06, 2022 at 04:19:26AM +0000, Matthew Wilcox wrote:
On Sun, Mar 06, 2022 at 06:11:21AM +0200, Jarkko Sakkinen wrote:
On Sun, Mar 06, 2022 at 03:52:12AM +0000, Matthew Wilcox wrote:
On Sun, Mar 06, 2022 at 05:21:11AM +0200, Jarkko Sakkinen wrote:
On Sun, Mar 06, 2022 at 02:57:55AM +0000, Matthew Wilcox wrote:
On Sun, Mar 06, 2022 at 04:15:33AM +0200, Jarkko Sakkinen wrote:
Sometimes you might want to use MAP_POPULATE to ask a device driver to initialize the device memory in some specific manner. SGX driver can use this to request more memory by issuing ENCLS[EAUG] x86 opcode for each page in the address range.
Add f_ops->populate() with the same parameters as f_ops->mmap() and make it conditionally called inside call_mmap(). Update call sites accodingly.
Your device driver has a ->mmap operation. Why does it need another one? More explanation required here.
f_ops->mmap() would require an additional parameter, which results heavy refactoring.
struct file_operations has 1125 references in the kernel tree, so I decided to check this way around first.
Are you saying that your device driver behaves differently if MAP_POPULATE is set versus if it isn't? That seems hideously broken.
MAP_POPULATE does not do anything (according to __mm_populate in mm/gup.c) with VMA's that have some sort of device/IO memory, i.e. vm_flags intersecting with VM_PFNMAP | VM_IO.
I can extend the guard obviously to:
if (!ret && do_populate && file->f_op->populate && !!(vma->vm_flags & (VM_IO | VM_PFNMAP))) file->f_op->populate(file, vma);
Are you deliberately avoiding the question? I'm not asking about implementation. I'm asking about the semantics of MAP_POPULATE with your driver.
No. I just noticed a bug in the guard from your comment that I wanted point out.
With the next version I post the corresponding change to the driver, in order to see this in context.
BR, Jarkko