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.
> > > So the trade off is:
> > > a) churn the current interface for everyone
> > > b) add a user_ variant and know people will just get it wrong
> >
> > I was also explicitly asked not to proliferate too many new APIs.
> >
>
> Yeah simply spelling it out, not asking for a change. Probably no
> better way to go about it.
>
> ~Gregory
