Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack:
anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get()
By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL).
In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously.
Cc: stable@vger.kernel.org Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Christian Eggers ceggers@arri.de --- drivers/regulator/dummy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/dummy.c b/drivers/regulator/dummy.c index 5b9b9e4e762d..9f59889129ab 100644 --- a/drivers/regulator/dummy.c +++ b/drivers/regulator/dummy.c @@ -60,7 +60,7 @@ static struct platform_driver dummy_regulator_driver = { .probe = dummy_regulator_probe, .driver = { .name = "reg-dummy", - .probe_type = PROBE_PREFER_ASYNCHRONOUS, + .probe_type = PROBE_FORCE_SYNCHRONOUS, }, };
Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it.
Cc: stable@vger.kernel.org Signed-off-by: Christian Eggers ceggers@arri.de --- drivers/regulator/core.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 4ddf0efead68..bb9fe44aea11 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2069,6 +2069,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)
if (have_full_constraints()) { r = dummy_regulator_rdev; + BUG_ON(!r); get_device(&r->dev); } else { dev_err(dev, "Failed to resolve %s-supply for %s\n", @@ -2086,6 +2087,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) goto out; } r = dummy_regulator_rdev; + BUG_ON(!r); get_device(&r->dev); }
@@ -2213,6 +2215,7 @@ struct regulator *_regulator_get_common(struct regulator_dev *rdev, struct devic */ dev_warn(dev, "supply %s not found, using dummy regulator\n", id); rdev = dummy_regulator_rdev; + BUG_ON(!rdev); get_device(&rdev->dev); break;
On Mon, Mar 10, 2025 at 05:33:02PM +0100, Christian Eggers wrote:
Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it.
if (have_full_constraints()) { r = dummy_regulator_rdev;
BUG_ON(!r); get_device(&r->dev);@@ -2086,6 +2087,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev) goto out; } r = dummy_regulator_rdev;
BUG_ON(!r);
This doesn't actually help anything - I'd expect this to trigger probe deferral.
Am Montag, 10. März 2025, 18:23:02 CET schrieb Mark Brown:
On Mon, Mar 10, 2025 at 05:33:02PM +0100, Christian Eggers wrote:
Due to asynchronous driver probing there is a chance that the dummy regulator hasn't already been probed when first accessing it.
if (have_full_constraints()) {r = dummy_regulator_rdev;
BUG_ON(!r); get_device(&r->dev);} else {
dev_err(dev, "Failed to resolve %s-supply for
%s\n",
@@ -2086,6 +2087,7 @@ static int regulator_resolve_supply(struct regulator_dev *rdev)> goto out; } r = dummy_regulator_rdev;
BUG_ON(!r);This doesn't actually help anything
My idea was to help identifying the problem (if it is reintroduced again later).
I'd expect this to trigger probe deferral.
I can check for this tomorrow. But is it worth to use deferred probing for a shared "NOP" driver which doesn't access any hardware? Or would this only introduce overhead for nothing?
regards, Christian
On Mon, Mar 10, 2025 at 07:22:24PM +0100, Christian Eggers wrote:
Am Montag, 10. März 2025, 18:23:02 CET schrieb Mark Brown:
BUG_ON(!r);
This doesn't actually help anything
My idea was to help identifying the problem (if it is reintroduced again later).
I'd expect this to trigger probe deferral.
I can check for this tomorrow. But is it worth to use deferred probing for a shared "NOP" driver which doesn't access any hardware? Or would this only introduce overhead for nothing?
My concern is that if something goes wrong in production then we've just escallated the problem, given that there's a clear error handling mechanism we could use we should take advantage of that rather than doing something destructive.
linux-stable-mirror@lists.linaro.org
-
Christian Eggers -
Christian Eggers -
Mark Brown