Re: [PATCH] err_ptr.h: introduce ERR_PTR_SAFE()
David Laight <[email protected]> Sat, 16 May 2026 09:42:42 +0100
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260516094242.77d20c92@pumpkin> |
On Fri, 15 May 2026 21:26:04 +0200 Amir Goldstein <[email protected]> wrote: > On Fri, May 15, 2026 at 8:30 PM David Laight > <[email protected]> wrote: > > > > On Thu, 14 May 2026 22:01:29 +0200 > > Amir Goldstein <[email protected]> wrote: > > ... > > > > The object code bloat would be noticeable if this were used everywhere. > > But you could make it a bit simpler: > > if (__builtin_constant_p(__e)) > > BUILD_BUG_ON(__e && !IS_ERR_VALUE(__e)); > > else if WARN_ON(__e && !IS_ERR_VALUE(__e)) > > __e = -MAX_ERRNO; // Or maybe -EINVAL to stop and other boundary errors > > (void *)__e; > > Yeh that's nicer thanks. Actually this might be better still (or just more succinct): void *__e = (void *)error; BUILD_BUG_ON(!statically_true(IS_ERR_OR_NULL(__e)); if (WARN_ON(!IS_ERR_OR_NULL(__e)) __e = (void *)-EINVAL; __e; The WARN_ON() will be optimised away (valid) constants. > > The check for constants may be fairly pointless. > > One of the static checkers may already detect the obvious fubar ERR_PTR(EINVAL). > > True, but I figured it didn't add much overhead if we are placing > the runtime assertions anyway? The 'size' check in READ_ONCE() measurably slows down the kernel compilation. But there are a lot of those. I think I know the main reason - the extern for the 'error message function'. -- David > > Thanks, > Amir.