-fstack-clash-protection triggers something in setfstab() (was: Re: Strange file access issue in a recent -current (but not with the previous BE))

Am 2025-02-26 16:20, schrieb Alexander Leidinger:
> Hi,
> 
> the working system is from 2025-01-25-141603, the non working system is 
> from 2025-02-21-115311.
> 
> I'm not sure what the issue is exactly. I have traced down the change 
> of behavior to
> ---snip---
> if not LIBC.setfstab(fstab_file_path.encode()):
> ---snip---
> 
> In the working case LIBC.setfstab returns true (so with the not it 
> doesn't take this branch), and in the non-working case it returns false 
> (so with the not it takes this branch).
> 
> Is someone aware of a change in this area? Searching for it 
> (https://cgit.freebsd.org/src/log/?qt=grep&q=setfstab) only brings the 
> initial commit.

Interestingly my own commit triggers this issue.

I bisected and commit 1c2ae9233b0ed4f6b92c59c0e4026f6ddc073e4a is 
causing this. This is the first ref which triggers the issue that iocage 
can not mount filesystems anymore. And the failing call in iocage seems 
to be the python LIBC.setfstab() call. And this only triggers, when the 
basesystem is compiled with the stack clash protection. I do not see any 
obvious issue in our setfstab code. Anyone with an idea?

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF