On Tue, Jan 19, 2016 at 9:34 PM, Michael Ellerman <m...@ellerman.id.au> wrote:
>
> The kernel describes those error codes as:
>
> #define SEGV_MAPERR (__SI_FAULT|1) /* address not mapped to object */
> #define SEGV_ACCERR (__SI_FAULT|2) /* invalid permissions for mapped
> object */
>
> Which one is correct in this case isn't entirely clear. There is a stack
> mapping, but you're not allowed to use it because of the stack ulimit, so
> arguably ACCERR is more accurate.
>
> However that's only true because of the stack guard page, which is supposed to
> be somewhat invisible to userspace. If I disable the stack guard page logic,
> userspace sees SEGV_MAPERR, so it seems that historically that's what is
> expected.
I think MAPERR is likely the right thing for a guard page access.
That said, I'd also warn people from caring too mucbh about the
details of si_code. We've not traditionally been very good at filling
it in. So any program that uses it for any actual semantic behavior is
likely just broken. Print it it in debuggers by all means, but relying
on it in any other way is just crazy. It's just not historically
reliable enough.
So I wouldn't worry about it excessively.
Linus
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
