| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: Should we add a compiler warning for large stack frames? |
| Date: | 2024-04-11 20:35:58 |
| Message-ID: | 238847.1712867758@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> d8f5acbdb9b made me wonder if we should add a compiler option to warn when
> stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so
> that's not hard.
> Huge stack frames are somewhat dangerous, as they can defeat our stack-depth
> checking logic. There are also some cases where large stack frames defeat
> stack-protector logic by compilers/libc/os.
Indeed. I recall reading, not long ago, some Linux kernel docs to the
effect that automatic stack growth is triggered by a reference into
the page just below what is currently mapped as your stack, and
therefore allocating a stack frame greater than one page has the
potential to cause SIGSEGV rather than the desired stack extension.
(If you feel like digging in the archives, I think this was brought
up in the last round of lets-add-some-more-check_stack_depth-calls.)
> Warnings in src/bin aren't as interesting as warnings in backend code, as the
> latter is much more likely to be "exposed" to deep stacks and could be
> vulnerable due to stack overflows.
Probably, but it's still the case that such code is relying on the
original stack allocation being large enough already.
> I don't really have an opinion about the concrete warning limit to use.
Given the above, I'm tempted to say we should make it 8K. But I know
we have a bunch of places that allocate page images as stack space,
so maybe that'd be too painful.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-04-11 20:46:10 | Re: Issue with the PRNG used by Postgres |
| Previous Message | Robert Haas | 2024-04-11 20:26:52 | Re: Table AM Interface Enhancements |