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

[Alexander Leidinger]

Am 2025-02-26 16:20, schrieb Alexander Leidinger:

Hi,




---snip---
if not LIBC.setfstab(fstab_file_path.encode()):
---snip---

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 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.



Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netch...@freebsd.org  : PGP 0x8F31830F9F2772BF

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?

signature.asc
Description: OpenPGP digital signature