On Tue, Nov 23, 2021 at 12:07:48AM +0000, Pavel Begunkov wrote: > Apparently, implicit 0 to NULL conversion with ERR_PTR is not > recommended and makes some tooling like Smatch to complain. Handle it > explicitly, compilers are perfectly capable to optimise it out. > > Link: https://lore.kernel.org/all/20211108134937.GA2863@kili/ > Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx> > Signed-off-by: Pavel Begunkov <asml.silence@xxxxxxxxx> I like that this this code is now really explicit that the NULL returns are intentional. I had figured that out from the git log already. Passing zero to ERR_PTR() is valid. Linus complained about this Smatch warning. But I'm not going to delete the check because probably around 70% (complete guess) of the cases in new code are bugs. In older kernels the Smatch warnings tend to be 100% false positives because we fix the real bugs. Also the kbuild-bot hits a bunch of error pointer false positives for cross compile builds but I don't have a cross compile system set up so I haven't debugged that. :/ It has something to do with pointers being treated as signed on those arches. But what I really like to see is documentation explaining when a function is going to return NULL vs an error pointer. regards, dan carpenter
