Re: power_supply_show_property Kernel Oops

[Alistair]

On Thu, 30 Mar 2023, at 8:47 AM, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Mar 29, 2023 at 04:43:19PM +0200, Linus Walleij wrote:
> > On Wed, Mar 29, 2023 at 1:16 PM Alistair <alistair@xxxxxxxxxxxxx> wrote:
> > 
> > > [    2.466136]  string from vsnprintf+0x158/0x424
> > > [    2.470603]  vsnprintf from vscnprintf+0x10/0x24
> > > [    2.475241]  vscnprintf from sysfs_emit+0x50/0xac
> > > [    2.479975]  sysfs_emit from power_supply_show_property+0x1d0/0x26c
> > > [    2.486269]  power_supply_show_property from add_prop_uevent+0x30/0x8c
> > > [    2.492815]  add_prop_uevent from power_supply_uevent+0xb4/0xe4
> > > [    2.498753]  power_supply_uevent from dev_uevent+0xc4/0x21c
> > > [    2.504352]  dev_uevent from kobject_uevent_env+0x1cc/0x510
> > > [    2.509953]  kobject_uevent_env from power_supply_changed_work+0x7c/0xb4
> > > [    2.516675]  power_supply_changed_work from process_one_work+0x1e8/0x3e8
> > > [    2.523396]  process_one_work from worker_thread+0x2c/0x504
> > > [    2.528986]  worker_thread from kthread+0xcc/0xec
> > > [    2.533716]  kthread from ret_from_fork+0x14/0x24
> > > [    2.538443] Exception stack(0xf0dadfb0 to 0xf0dadff8)
> > 
> > This looks like running a worker before something this worker is
> > accessing has been set up.
> > 
> > > As it's on a consumer device I don't have a way to connect a debugger. So I'm
> > > a little stuck on what the problem is. The only related change I see between
> > > 6.2 and 6.3-rc4 is commit a441f3b90a340e5c94df36c33fb7000193ee0aa7
> > > "power: supply: use sysfs_emit() instead of sprintf() for sysfs show()", but
> > > that doesn't look like it would cause this oops.
> > 
> > Did you try reverting it?
> 
> Does not look like a race condition with a worker to me. The patch
> adds a couple of properties to the power-supply in an incorrect way.

Thanks for that.

It appears that these two drivers cause the problem:

https://github.com/alistair23/linux/blob/rM2-mainline/drivers/power/supply/max77818-charger.c
https://github.com/alistair23/linux/blob/rM2-mainline/drivers/regulator/max77818-regulator.c 

as removing those two fixes the oops.

> I did not look deeply, but it's at least missing an update to
> power_supply_attrs. I guess you were 'lucky' that it did not crash
> with v6.2.

Do you mind pointing to an example that does this correctly? I don't see
anything obviously wrong compared to the in-tree max* drivers.

Anything to help point me in the right direction would be greatly
appreciated :)

> 
> None of the extra properties are acceptable upstream btw.:
> 
> POWER_SUPPLY_PROP_CURRENT_MAX2:
>     The driver seems to use CURRENT_MAX2 for input current;
>     POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT should be used for that
> 
> POWER_SUPPLY_PROP_CHARGER_MODE:
>     OTG should be handled via a regulator
> 
> POWER_SUPPLY_PROP_STATUS_EX:
>     Use extcon for connectors

Thanks! I figured as much. These are just taken from the vendor tree, I need to
clean everything up for upstreaming. I just wanted to have a working base point
to start.

> 
> Greetings,
> 
> -- Sebastian
> 
> 
> *Attachments:*
>  • signature.asc