On Mon, May 05, 2025 at 10:27:30AM -0700, Nicolin Chen wrote: > > So when calling mtree_alloc_range: > > > > int mtree_alloc_range(struct maple_tree *mt, unsigned long *startp, > > void *entry, unsigned long size, unsigned long min, > > unsigned long max, gfp_t gfp) > > > > size should be the number of PFNs this mmap is going to use, which is > > not sizeof() anything > > > > min should be 0 and max should be uh.. U32_MAX >> PAGE_SHIFT > > IIRC.. There is a different limit for pgof fon 32 bit mmap() > > Should the startp (input) be the pfn_start (i.e. pgoff)? pfn_start/pgoff is the output of the allocation, it is not an input. > In this case, it would return startp as the ID, which will > be further returned to the user space. So, basically user > space know the pfn range, v.s being given an mmap cookie? Userspace is given the pgoff to pass to mmap as a cookie, it doesn't know anything about it beyond that passing that pgoff will get the mmap it should get. Userspace must also know how big the mmap is. The pgoffs should all be allocated from non-overlapping ranges as though they were bytes in a file so that the mmaps are all disjoint. This makes debugging easier and the API saner. There is no "id" here.. Jason
