On Thu, Mar 12, 2026 at 11:32:37AM -0400, James Bottomley wrote: > On Thu, 2026-03-12 at 09:57 -0300, Jason Gunthorpe wrote: > > On Wed, Mar 11, 2026 at 02:40:36AM +0800, Kuan-Wei Chiu wrote: > > > > > IMHO, the necessity of IS_ERR_OR_NULL() often highlights a > > > confusing or flawed API design. It usually implies that the caller > > > is unsure whether a failure results in an error pointer or a NULL > > > pointer. > > > > +1 > > > > IS_ERR_OR_NULL() should always be looked on with suspicion. Very > > little should be returning some tri-state 'ERR' 'NULL' 'SUCCESS' > > pointer. What does the middle condition even mean? IS_ERR_OR_NULL() > > implies ERR and NULL are semanticly the same, so fix the things to > > always use ERR. > > Not in any way supporting the original patch. However, the pattern > ERR, NULL, PTR is used extensively in the dentry code of filesystems. > See the try_lookup..() set of functions in fs/namei.c > > The meaning is > > PTR - I found it > NULL - It definitely doesn't exist > ERR - something went wrong during the lookup. > > So I don't think you can blanket say this pattern is wrong.
Lots of places also would return ENOENT, I'd argue that is easier to use.. But yes, I did use the word "suspicion" not blanket wrong :) Jason
