This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] nptl: change default stack guard size of threads

On Wed, Dec 06, 2017 at 08:41:29PM +0000, Szabolcs Nagy wrote:
> On 06/12/17 14:27, Wilco Dijkstra wrote:
> > Florian Weimer wrote:
> >> On 11/29/2017 11:28 PM, Wilco Dijkstra wrote:
> >>> It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to
> >>> run old binaries so a larger guard size is definitely beneficial. No existing code
> >>> uses probing, so increasing the guard size means far fewer functions could
> >>> jump the guard.  The dropoff is exponential, each doubling of guard page size
> >>> halves the number of functions with a stack larger than the guard size.
> >>
> >> That's not actually true in the sense that the math doesn't work out 
> >> that way.  If you have a weird function which skips by a really large 
> >> amount, you can double the guard size many, many times until the number 
> >> of unprotected functions drops further.
> >>
> >> And there is definitely a long tail here, due to GNU's affinity to 
> >> variable-length arrays and alloca.
> > 
> > The math works fine for most of the curve. The measurements I did
> > show that the number of functions with really large stack allocations is
> > extremely small. So it's a long tail only in terms of maximum stack
> > allocation, not in number of functions.
> with 4k probe interval about 1% of functions need probes
> with 64k probe interval about 0.01% (order of magnitude,
> alloca not included), so increasing the default guard can
> be useful for existing code.

Rather than what % of all functions need probes, I think it would be
more meaningful to ask what % of functions with a useful (not trivial
error) code path less than N instructions (for N=100 or so) need
probes. My hypothesis is that, for either threshold 4k or 64k, the %
is negligible.

Of course this is a bit harder to measure but maybe there's some way
to do it? It would be nice if static analysis tools could report that
(they wouldn't exclude trivial error ones but some additional
heuristic or manual review pass could).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]