Date: Sat, 15 Mar 2025 08:33:00 -0500 From: Kyle Evans <kevans@FreeBSD.org> To: freebsd-current@freebsd.org Cc: Michael Gmelin <grembo@freebsd.org> Subject: Re: -fstack-clash-protection triggers something in setfstab() Message-ID: <a44b6132-3f48-419f-ab94-49cf2ebd2240@FreeBSD.org> In-Reply-To: <2400b4d10d4804eef784768d050f6953@Leidinger.net> References: <5ebbe12dc6cb4e3fc00f0a07c03856e4@Leidinger.net> <2400b4d10d4804eef784768d050f6953@Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[+grembo@ for iocage] On 3/15/25 06:26, Alexander Leidinger wrote: > 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? > setfstab() implementation seems more or less fine, but it's hard to tell what's going on with iocage there. setfstab(3) doesn't actually have a return value in any version of FreeBSD, so I guess it's picking up some sort of garbage as the return value. Looking at the context, you can only tell if the open failed with the subsequent getfsent()/setfsent(); that branch should probably just be removed entirely, and the initial getfsent() might be worth error-checking for potential error or premature EOF. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a44b6132-3f48-419f-ab94-49cf2ebd2240>