On 23/02/2022 16:08, Robin Murphy wrote:

On 2022-02-23 14:22, Krzysztof Kozlowski wrote:

quoted

On 23/02/2022 15:04, Robin Murphy wrote:

quoted

On 2022-02-22 14:06, Krzysztof Kozlowski wrote:

quoted

On 22/02/2022 14:51, Rasmus Villemoes wrote:

quoted

On 22/02/2022 14.27, Krzysztof Kozlowski wrote:

quoted

Hi,

Drivers still seem to use driver_override incorrectly. Perhaps my old
patch makes sense now?
https://lore.kernel.org/all/1550484960-2392-3-git-send-email-krzk@kernel.org/ (local)

Not tested - please review and test (e.g. by writing to dirver_override
sysfs entry with KASAN enabled).

Perhaps it would make sense to update the core code to release using
kfree_const(), allowing drivers to set the initial value with
kstrdup_const(). Drivers that currently use kstrdup() or kasprintf()
will continue to work [but if they kstrdup() a string literal they could
be changed to use kstrdup_const].

The core here means several buses, so the change would not be that
small. However I don't see the reason why "driver_override" is special
and should be freed with kfree_const() while most of other places don't
use it.

The driver_override field definition is here obvious: "char *", so any
assignments of "const char *" are logically wrong (although GCC does not
warn of this literal string const discarding). Adding kfree_const() is
hiding the problem - someone did not read the definition of assigned field.

That's not the issue, though, is it? If I take the struct
platform_device definition at face value, this should be perfectly valid:

	static char foo[] = "foo";
	pdev->driver_override = &foo;

Yes, that's not the issue. It's rather about the interface. By
convention we do not modify string literals but "char *driver_override"
indicates that this is modifiable memory. I would argue that it even
means that ownership is passed. Therefore passing string literal to
"char *driver_override" is wrong from logical point of view.

Plus, as you mentioned later, can lead to undefined behavior.

But does anything actually need to modify a driver_override string? I 
wouldn't have thought so. I see at least two buses that *do* define 
theirs as const char *, but still assume to kfree() them.

I think the drivers/clk/imx/clk-scu.c (fixed here) does not actually
need it. It uses the feature to create multiple platform devices for
each clock, with unique names matching the clock (e.g. pwm0_clk,
pwm1_clk) and then bind all them via common clock driver.

It looks therefore like something for convenience of debugging or going
through sysfs devices.

Removal of driver_override from such drivers is a bit too much here,
because I would not be able to test it.

quoted

quoted

And in fact that's effectively how the direct assignment form works
anyway - string literals are static arrays of type char (or wchar_t),
*not* const char, however trying to modify them is undefined behaviour.

There's a big difference between "non-const" and "kfree()able", and
AFAICS there's no obvious clue that the latter is actually a requirement.

Then maybe kfreeable should be made a requirement? Or at least clearly
documented?

Indeed, there's clearly some room for improvement still. And I'm not 
suggesting that these changes aren't already sensible as they are, just 
that the given justification seems a little unfair :)

Yeah, maybe also my "const" in the title and commit is not accurate. I
think that literal strings are part of .rodata (and objdump confirm)
thus are considered const.

Even kfree_const() can't help if someone has put their string in the 
middle of some larger block of kmalloc()ed memory, so perhaps 
encouraging a dedicated setter function rather than just exposing a raw 
string pointer is the ideal solution in the long term.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel