On Mon, May 11, 2026 at 05:59:23PM -0400, Michael S. Tsirkin wrote: > On Mon, May 11, 2026 at 12:52:10PM -0400, Gregory Price wrote: > > On Mon, May 11, 2026 at 11:55:40AM -0400, Michael S. Tsirkin wrote: > > > On Mon, May 11, 2026 at 11:37:37AM -0400, Gregory Price wrote: > > > > On Mon, May 11, 2026 at 05:01:55AM -0400, Michael S. Tsirkin wrote: > > > > > > > > > +/* > > > > > + * Sentinel for user_addr: indicates a non-user allocation. > > > > > + * Cannot use 0 because address 0 is a valid userspace mapping. > > > > > + */ > > > > > +#define USER_ADDR_NONE ((unsigned long)-1) > > > > > > > > Ehm, hm. Does -1 hold as a non-user address across all architectures? > > > > > > > > What about in linear addressing / no VM mode? > > > > > > this is used on a fault. I don't think there are any faults then? > > > But maybe FAULT_ADDR_NONE would be clearer. > > > > > > > Meh, naming here is less relevant than the sentinel correctness. > > > > My only concern is really whether -1 could end up being a valid address > > in some horrid future timeline and this all going belly up. > > > > Is why I asked about whether this is correct on all architectures. > > I think the answer is yes: on all architectures Linux supports, the last > page of the address space is never a valid user mapping. The kernel > enforces this -- mmap will not create a mapping whose end wraps past -1. > > if (addr > TASK_SIZE - len) > return -ENOMEM; > > > So the maximum vm_end = addr + len <= TASK_SIZE. > On every architecture TASK_SIZE <= (unsigned long)-1, so vm_end can > never wrap around to 0 and address -1 can never be within any > VMA. >
That is worth documenting at least in the changelog if not the comment with the define there's a clue if anything ever changes. ~Gregory
