lkml.org 
[lkml]   [2018]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] driver-core: Log the BUG() causing driver
    From
    Date
    On 07.03.2018 16:13, Greg Kroah-Hartman wrote:
    > On Wed, Mar 07, 2018 at 10:49:02AM +0100, Florian Schmaus wrote:
    >> I triggerd the BUG_ON(), which was added in
    >> f48f3febb2cbfd0f2ecee7690835ba745c1034a4, when booting a domU Xen
    >> domain.
    >
    > How?

    Basically just by booting the domU kernel with the wmi-bmof driver
    compiled in. After I deselected the wmi-bmof driver, the kernel booted
    just fine.

    I'd probably be able to re-create the faulty kernel and show you the
    image and/or kernel config if you want.

    >> Since there was no contextual information logged, I needed to
    >> attach kgdb to determine the culprit (the wmi-bmof driver in my case).
    >>
    >> Signed-off-by: Florian Schmaus <flo@geekplace.eu>
    >> ---
    >> drivers/base/driver.c | 6 +++++-
    >> 1 file changed, 5 insertions(+), 1 deletion(-)
    >>
    >> diff --git a/drivers/base/driver.c b/drivers/base/driver.c
    >> index ba912558a510..55f8db41df2b 100644
    >> --- a/drivers/base/driver.c
    >> +++ b/drivers/base/driver.c
    >> @@ -148,7 +148,11 @@ int driver_register(struct device_driver *drv)
    >> int ret;
    >> struct device_driver *other;
    >>
    >> - BUG_ON(!drv->bus->p);
    >> + if (!drv->bus->p) {
    >> + printk(KERN_ERR "Driver '%s' was unable to register bus_type\n",
    >> + drv->name);
    >> + BUG();
    >> + }
    >
    > We could just log the error and return with an error, that would be
    > nicer, right? Crashing the system isn't usually a good idea, even at
    > boot time :)

    It sure is, and I did consider it. I just wasn't sure which return value
    to use in that case. Probably the best solution would be to use the
    return value of bus_register(), which caused p to become NULL. Although
    that possibly requires extending the bus_type struct by an 'int' storing
    the return value (Or could the return value be mangled into the 'p'
    pointer?).

    I'd be happy to hear your thoughts on this.

    BTW: Should I retain the 'unlikely' semantic of BUG_ON() in this case?

    - Florian

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-03-07 16:36    [W:4.160 / U:0.552 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site