[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0442526f-b6d9-8868-ac1c-dd11a2d3b2ab@arm.com>
Date: Wed, 23 Feb 2022 14:04:23 +0000
From: Robin Murphy <robin.murphy@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Abel Vesa <abel.vesa@....com>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
NXP Linux Team <linux-imx@....com>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Andy Gross <agross@...nel.org>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-remoteproc@...r.kernel.org,
linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [RFT PATCH 0/3] Fix kfree() of const memory on setting
driver_override
On 2022-02-22 14:06, Krzysztof Kozlowski wrote:
> On 22/02/2022 14:51, Rasmus Villemoes wrote:
>> On 22/02/2022 14.27, Krzysztof Kozlowski wrote:
>>> 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/
>>>
>>> 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;
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.
Cheers,
Robin.
Powered by blists - more mailing lists