linux-kernel - Re: [PATCH 2/4] staging: most: Replace calls to BUG_ON() with WARN

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Mar 2018 12:47:28 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Quytelda Kahja <quytelda@...alin.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>, devel@...verdev.osuosl.org,
        christian.gromm@...rochip.com, chris@...ineersdelight.de,
        linux-kernel@...r.kernel.org, Michael.Fabry@...rochip.com
Subject: Re: [PATCH 2/4] staging: most: Replace calls to BUG_ON() with
 WARN_ONCE() and return.

On Tue, Mar 06, 2018 at 01:23:18AM -0800, Quytelda Kahja wrote:
> > Are you sure this will work?
> Well, my goal was just to replace the code that could crash the kernel
> and let somebody with a better understanding of this particular driver
> write the recovery code, if necessary.  It seemed from context that
> the BUG_ON() calls were being used like assert() though, so I assumed
> there wasn't really much recovery to be made from that problem.  If
> you feel this doesn't improve the behavior of the driver, just drop
> the patch.
> 

mbo is always non-NULL just from a quick glance.  I didn't look hard
enough to verify that mbo->context was OK.

It's generally best to just check the callers and delete these.

Say you have a BUG_ON() then that prevents memory corruption (not an
issue here) but it makes debugging hard.  But if you just have a NULL
dereference it probably kills the driver but you get an Oops which you
can debug.  So a NULL dereference is normally better than a BUG_ON().

regards,
dan carpenter