Re: Big compat issue with a recent current (zfs + syscall)

Am 2025-08-22 01:29, schrieb Xin LI:

> On Thu, Aug 21, 2025 at 2:56 PM Kyle Evans <kevans@freebsd.org> wrote:
> [...]
> 
>> I don't think I'd expect it to help with zfs dataset stuff.
> 
> There are also some recent ZFS changes, but I don't know (didn't have 
> read through all changes) if there are something related.
> 
>>>> I had wondered the same, but the use of 'segfault' gave me pause; 
>>>> these would be SIGSYS rather than SIGSEGV, but that could just be a 
>>>> minor terminology dispute.
>>> 
>>> Aug 20 10:35:32 Andromeda kernel: [566445] pid 52166 (auth), jid 50, 
>>> uid 143: exited on signal 6 (no core dump - sugid process denied by 
>>> ke
>>> rn.sugid_coredump)
>>> Aug 20 10:35:37 Andromeda kernel: [566450] pid 52172 (auth), jid 50, 
>>> uid 143: exited on signal 6 (no core dump - sugid process denied by 
>>> ke
>>> rn.sugid_coredump)
>>> Aug 20 10:35:44 Andromeda kernel: [566457] pid 52179 (auth), jid 50, 
>>> uid 143: exited on signal 6 (no core dump - sugid process denied by 
>>> ke
>>> rn.sugid_coredump)
>>> Aug 20 10:35:51 Andromeda kernel: [566463] pid 52185 (auth), jid 50, 
>>> uid 143: exited on signal 6 (no core dump - sugid process denied by 
>>> ke
>>> rn.sugid_coredump)
>>> Aug 20 10:35:56 Andromeda kernel: [566469] pid 52193 (auth), jid 50, 
>>> uid 143: exited on signal 6 (no core dump - sugid process denied by 
>>> ke
>>> rn.sugid_coredump)
>>> 
>> 
>> SIGABRT would seem to imply something like an assertion being tripped, 
>> which is a bit unusual.  Might need to flip
>> kern.sugid_coredump for a minute and see if you can gather some more 
>> context from a coredump.
> 
> Well, yes (it's somewhat unusual) and no (I think it's expected 
> behavior here):  It's not unusual for a program to explicitly abort() 
> when a setgroups() call failed, though: if I was the programmer who 
> wanted to drop privileges and failed, showing some error message and 
> abort() as soon as possible would be a reasonable choice (IMHO) because 
> I wouldn't have a lot of other remedies, so to me it sounded reasonable 
> here, especially when Alexander saw some missing system calls earlier.

COMPAT_FREEBSD14 makes a huge difference. Seems you find the issue. We 
should change the UPDATING part and tell to use COMPAT_FREEBSD14 until 
all the 3rd party stuff is updated/recompiled.

Bye,
Alexander.

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