linux-kernel - Re: [PATCH V4] firmware: arm_scmi: Make scmi core independent of the transport type

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]

Message-ID: <20200124030212.qjlzz75dgt5kla7t@vireshk-i7>
Date:   Fri, 24 Jan 2020 08:32:12 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     arnd@...db.de, jassisinghbrar@...il.com, cristian.marussi@....com,
        peng.fan@....com, peter.hilber@...nsynergy.com,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V4] firmware: arm_scmi: Make scmi core independent of the
 transport type

On 23-01-20, 10:30, Sudeep Holla wrote:
> WARNING: CPU: 1 PID: 187 at drivers/base/dd.c:519 really_probe+0x11c/0x418
> Modules linked in:
> CPU: 1 PID: 187 Comm: kworker/1:2 Not tainted 5.5.0-rc7-00026-gf7231cd3108d-dirty #20
> Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 16 2020
> Workqueue: events deferred_probe_work_func
> pstate: 80000005 (Nzcv daif -PAN -UAO)
> pc : really_probe+0x11c/0x418
> lr : really_probe+0x10c/0x418
> Call trace:
>  really_probe+0x11c/0x418
>  driver_probe_device+0xe4/0x138
>  __device_attach_driver+0x90/0x110
>  bus_for_each_drv+0x80/0xd0
>  __device_attach+0xdc/0x160
>  device_initial_probe+0x18/0x20
>  bus_probe_device+0x98/0xa0
>  deferred_probe_work_func+0x90/0xe0
>  process_one_work+0x1ec/0x4a8
>  worker_thread+0x210/0x490
>  kthread+0x110/0x118
>  ret_from_fork+0x10/0x18
> ---[ end trace 06f96d55ce6093a8 ]---

linux-next didn't had a WARN at line 519 and so I looked at the
difference between your and my branch and reached to this patch:

commit 7c35e699c88bd60734277b26962783c60e04b494
Author: Geert Uytterhoeven <geert+renesas@...der.be>
Date:   Fri Dec 6 14:22:19 2019 +0100

    driver core: Print device when resources present in really_probe()
    
    If a device already has devres items attached before probing, a warning
    backtrace is printed.  However, this backtrace does not reveal the
    offending device, leaving the user uninformed.  Furthermore, using
    WARN_ON() causes systems with panic-on-warn to reboot.
    
    Fix this by replacing the WARN_ON() by a dev_crit() message.
    Abort probing the device, to prevent doing more damage to the device's
    resources.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@...der.be>
    Link: https://lore.kernel.org/r/20191206132219.28908-1-geert+renesas@glider.be
    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
 drivers/base/dd.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index d811e60610d3..b25bcab2a26b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -516,7 +516,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
        atomic_inc(&probe_count);
        pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
                 drv->bus->name, __func__, drv->name, dev_name(dev));
-       WARN_ON(!list_empty(&dev->devres_head));
+       if (!list_empty(&dev->devres_head)) {
+               dev_crit(dev, "Resources present before probing\n");
+               return -EBUSY;
+       }
 
 re_probe:
        dev->driver = drv;


-------------------------8<-------------------------

I think this defines the problem somewhat, though I wasn't able to
reproduce the problem on my platform :)

-- 
viresh