[m-rev.] for review: Clarify some code relating to redzones.

[Zoltan Somogyi]

On Sun, 1 Nov 2026 00:31:10 +1100, Julien Fischer <jfischer at opturion.com> wrote:

> On Sun, 1 Nov 2026 at 00:12, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> >
> >
> >
> > On Sun, 1 Nov 2026 00:03:34 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> >
> > > Hi Zoltan,
> > >
> > > On Sat, 31 Oct 2026 at 20:47, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> >
> > > > - The soft redzone is the rest of the redzone. It starts out with no access
> > > >   being permitted (or as close to it as mprotect/equivalents can get),
> > > >   but we undo this protection on access.
> > > >
> > > > - The purpose of the hard redzone is definitely to guarantee that we catch
> > > >   about-to-happen overflows.
> > >
> > > This suggests that for some uses of memory zones we don't need hard redzones.
> > > (The zones used for stack and trail segments are the obvious examples.)
> >
> > Exactly. I don't think this interaction was thought through when we introduced
> > segments.
> 
> It does raise the question of whether we are incurring a system call for
> every stack or trail segment.

Yes, it does. We should probably do something about that.

I also thought about this when I looked at the code that unprotected the redzone
when a zone was being freed. When we next take that zone off the freelist,
and start using it again, we would probably want to set up a redzone again.
In the presence of soft redzones, the new redzone may be of a different size,
but if we are using hard redzones only, it will always be the same size. That means
that both syscalls in the unprotect/reprotect pair are wasted. It would have been better
if zones on the freelist simply recorded what their protection status was, and
when reusing a zone from there, we left the existing protection in place if it matches
the new need.

Of course, I don't think we ever really reuse memory zones in non-parallel,
non-segment grades, so the point is moot for them.

> > And also presumably, it only matters if agc works in LLDS grades,
> > which I do not remember ever happening. Even in MLDS grades,
> > agc worked only for (subjectively) five minutes.
> 
> LLDS agc grades didn't compile the last time I looked.

I don't think they *ever* worked. I don't think they were ever *intended* to work,
in that noone ever worked on them seriously.

> > That is an argument for soft redzones not being needed, and for documenting
> > them as not being needed. We may still want to keep the trivial amount of code
> > supporting them, but if we do, we should add comments saying (a) what functionality
> > they are intended to support, and (b) that there is nothing to support just yet.

I notice you didn't comment on this part. Do you think soft redzones are needed?
I don't.

> > > > Do you guys agree?
> > >
> > > In principle, sure. I would also offer the following observation:  using names
> > > like  "redzone" and "hardzone" inside something called a "memory zone" is
> > > fairly confusing.
> >
> > What terminology would you suggest instead?
> 
> I was trying to think of something.
> 
>   soft guard pages == soft redzone
>   hard guard page == hard redzone

That works for me. However, whatever terminology we pick, we have to
use it *consistently*.

Zoltan.