Date: Thu, 22 May 2025 08:04:19 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Brooks Davis <brooks@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, freebsd-current@freebsd.org Subject: Re: Un-sucking EINVAL Message-ID: <aC6wUwOltpoo2P_4@kib.kiev.ua> In-Reply-To: <aC5gYD2XGe2UtILd@spindle.one-eyed-alien.net> References: <aC0CgBBWrodf6pa8@ragweed.eden.le-fay.org> <202505210722.54L7MTqw025632@critter.freebsd.dk> <aC2Ap5ogfrlC-kHn@ragweed.eden.le-fay.org> <bc073de5-1c4a-41e8-b163-fcbfc4fb9c8f@FreeBSD.org> <CANCZdfoY_2UyaRsVpjENvRy8aTDUAmQka75=JfDSNa=BVKb53g@mail.gmail.com> <aC5gYD2XGe2UtILd@spindle.one-eyed-alien.net>
index | next in thread | previous in thread | raw e-mail
On Wed, May 21, 2025 at 11:23:12PM +0000, Brooks Davis wrote: > On Wed, May 21, 2025 at 11:07:09AM -0600, Warner Losh wrote: > > In short, I'd love to widen the interface, but there's a number of practical > > issues in the way. > > I think caching something in the kernel of later retrieval or adding a > new return path to the ABI is the wrong way around. Instead I think the > right solution is for each thread to register a userspace buffer. You > end up adding one or two entries to struct thread (pointer to a > structure or pointer to an buffer and length) and if the pointer is > non-NULL you copyout a string to the buffer. This avoids signficant > new storage in the kernel and means programs that won't use this data > don't see it. It also means that the debugger can access it without > needing a new PT_ argument. > > As a minor downside you would introduce some new error conditions if the > programmer messes up registration, but we'd probably just have libthr do > it in most cases (that would be more debugger friendly since you > could hang it off a known location in userspace). I mostly agree with this proposal, and can implement it. I strongly object against blowing the kernel with MBs of strings. Userspace can register per-thread extended errno location, and kernel can copyout the ext-errno when returning error. We already have a similar mechanism for fast signals blocking, so I am talking with relatively good experience about related machanism. There is no problem with userspace not registering or messing up the registration: after the first failure the mechanism stops working, until the next registration attempt. Since registration must be per-thread, some libc/libthr wrapper would be provided to fetch the value for C runtime. Go would handle it on its own, as it already does for vdso. I do not see a problem with Rust/Java/Nodejs, since they play well with C runtime. All this is quite doable, and the biggest work is to adjust kernel to record additional metadata to places where it identifies an error condition.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aC6wUwOltpoo2P_4>