Date: Fri, 23 May 2025 09:44:27 +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: <aDAZS4dlY2KdBure@kib.kiev.ua> In-Reply-To: <aC9J0rWt_gFZ1njp@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> <aC6wUwOltpoo2P_4@kib.kiev.ua> <aC9J0rWt_gFZ1njp@spindle.one-eyed-alien.net>
index | next in thread | previous in thread | raw e-mail
On Thu, May 22, 2025 at 03:59:14PM +0000, Brooks Davis wrote: > On Thu, May 22, 2025 at 08:04:19AM +0300, Konstantin Belousov wrote: > > 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. > > I really want them to be strings in the kernel. Anything else is too > annoying to maintain and will interact poorly with running old versions > of userspace and introduce namespace complications for downstreams. > > If you want the option to save the space, make the interface that copies > the string out a macro and provide an option to compile them away. > (Using a macro would also allow you to transparently embed e.g., file, > function, or line information if desired.) D50483 Extended errors from kernelhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aDAZS4dlY2KdBure>