[Letux-kernel] [Gta04-owner] New LetuxOS Kernels

Tony Lindgren tony at atomide.com
Wed Jun 20 07:40:13 CEST 2018


* H. Nikolaus Schaller <hns at goldelico.com> [180620 04:58]:
> Problem seems to be:
> 
> 1. before driver is probed pinmux does a group = devm_kzalloc
> 2. this is added to radix tree
> 3. driver probe fails for some reason
> 4. devres_release_all(driver) ==> does a kfree(group)

This should not happen as the devm alloc is done for the pin controller
instance, not for a consumer driver instance. So we either free it
in pinctrl-single.c somehow, or do you have maybe deferred probing
happending for some additional pinctrl instance we don't have in the
mainline kernel?

To try to figure out where we free something, do you see
pcs_dt_free_map() get called for example?

> 5. someone reuses the memory area defined by kzalloc
> 6. other driver is probed and wants to check if selector exists
> 7. scans through radix tree (in pinctrl_generic_group_name_to_selector)
> 8. finds NULLified memory area [or maybe other stale data!]
> 9. strcmp(NULL)
> 
> This happens despite our checking for duplicates.
> 
> So we should not fix #9 but #4 to properly remove groups from radix tree
> and make sure that it is skipped during scanning for selectors (this is
> what a NULL test #9 finally would do - the test alone isn't enough).

To do this properly we should allow the pin controller driver to specify
the selector based on a register offset or similar and get rid of the
numbered indexing.

> Andy already pointed to a location where the cleanup should take place:
> 
> > I think there is a simple way to clean up pinctrl stuff on failed probe. See
> > https://elixir.bootlin.com/linux/v4.18-rc1/source/drivers/base/dd.c#L416
> > 
> > We only bind pins, and do not perform any actions when failure happens later on.
> 
> Or have we missed this patch?

Hmm that seems like a separate yet another issue though.

Regards,

Tony


More information about the Letux-kernel mailing list