linux-kernel - Re: [PATCH] kunit: Fix a NULL vs IS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fc3a2fbf-2a4f-4730-8151-6176e29f9df0@moroto.mountain>
Date: Fri, 12 Jan 2024 08:39:00 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: David Gow <davidgow@...gle.com>
Cc: Brendan Higgins <brendan.higgins@...ux.dev>,
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] kunit: Fix a NULL vs IS_ERR() bug

On Fri, Jan 12, 2024 at 07:39:14AM +0800, David Gow wrote:
> On Thu, 11 Jan 2024 at 02:55, Dan Carpenter <dan.carpenter@...aro.org> wrote:
> >
> > The kunit_device_register() function doesn't return NULL, it returns
> > error pointers.  Change the KUNIT_ASSERT_NOT_NULL() to check for
> > ERR_OR_NULL().
> >
> > Fixes: d03c720e03bd ("kunit: Add APIs for managing devices")
> > Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
> > ---
> 
> Nice catch, thanks!
> 
> Reviewed-by: David Gow <davidgow@...gle.com>
> 
> > It's a pity that there isn't a KUNIT_ASSERT_NOT_ERR_PTR() macro...
> 
> I think we'll add one, but I'm not yet totally convinced that it would
> be better than using ASSERT_NOT_ERR_OR_NULL() in cases like this,
> where we're:
> 1. In a test; and,
> 2. using the pointer afterwards, expecting it to be valid
> (dereferencing it and/or passing it to functions which will)
> 
> This is largely because it'd be nicer, if the pointer is NULL (due to
> a bug), to get a more explicit assertion failure, rather than a crash.
> It does make the test code less indicative of how the APIs are meant
> to be used elsewhere, though, and annoys the static analysis, though.
> 
> Thoughts?

It doesn't annoy any static checkers because nothing looks for it.

Expecting that this test code might be buggier than normal code probably
isn't unreasonable so I guess that makes sense.

regards,
dan carpenter