[RFC] mm: Allow 64-bit mmap syscalls to access higher addresses.

[RFC] mm: Allow 64-bit mmap syscalls to access higher addresses.

[Derek Lesho]

For those curious about my usecase, I'm working on running some windows 64-bit driver code in context of any given process.  I accomplish this by mapping some of the fake kernel
bits in the target process, and running the code in a dedicated thread.
---
 mm/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 40248d84ad5f..3a6940ef6128 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2240,7 +2240,7 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len,
 	if (IS_ERR_VALUE(addr))
 		return addr;
 
-	if (addr > TASK_SIZE - len)
+	if (addr > TASK_SIZE_MAX - len)
 		return -ENOMEM;
 	if (offset_in_page(addr))
 		return -EINVAL;
@@ -2767,7 +2767,7 @@ int __do_munmap(struct mm_struct *mm, unsigned long start, size_t len,
 	unsigned long end;
 	struct vm_area_struct *vma, *prev, *last;
 
-	if ((offset_in_page(start)) || start > TASK_SIZE || len > TASK_SIZE-start)
+	if ((offset_in_page(start)) || start > TASK_SIZE_MAX || len > TASK_SIZE_MAX-start)
 		return -EINVAL;
 
 	len = PAGE_ALIGN(len);
-- 
2.28.0

Re: [RFC] mm: Allow 64-bit mmap syscalls to access higher addresses.

[Derek Lesho]

For some reason, git send-email cut off the first paragprah in my first email, so I'm resending it now:

Hello everyone, I am sending this mostly as a discussion starter/curiosity.  I would like to be able to use the 48-bit address range while in long mode on an IA32 process.  However,
these two checks prevent mmap and munmap from dealing with addresses in that range.  My question, is there any will to support something like this in the kernel, and if so, how
would it be accomplished, generally.  Maybe the TASK_SIZE macro could check for whether we are currently in the context of a x86-64 syscall?

For those curious about my usecase, I'm working on running some windows 64-bit driver code in context of any given process.  I accomplish this by mapping some of the fake kernel
bits in the target process, and running the code in a dedicated thread.
---