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 kernel
