On 09.07.2024 13:25, Przemek Kitszel wrote:
On 7/9/24 11:50, Paul Menzel wrote:
Dear Przemek,
Thank you for your quick reply.
Am 09.07.24 um 11:11 schrieb Przemek Kitszel:
On 7/9/24 10:54, Paul Menzel wrote:
[Cc: [email protected] (Address rejected)]
Am 09.07.24 um 10:49 schrieb Paul Menzel:
Am 08.07.24 um 20:27 schrieb Aleksandr Mishin:
In ice_sched_add_root_node() and ice_sched_add_node() there are
calls to
devm_kcalloc() in order to allocate memory for array of pointers to
'ice_sched_node' structure. But incorrect types are used as sizeof()
arguments in these calls (structures instead of pointers) which
leads to
over allocation of memory.
If you have the explicit size at hand, it’d be great if you added
those to the commit message.
One pointer instance size is 8 bytes.
One structure instance size is (approximately) 104 bytes. I'm not quite
sure for that number, because structure is complex and includes another
structure, which includes another etc. So I could make a mistake in
calculation.
Memory allocation is performed for multiple instances, so this ~96 bytes
should be multiplied by a number of instances to get final memory
overhead size.
Adjust over allocation of memory by correcting types in
devm_kcalloc()
sizeof() arguments.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Maybe mention, that Coverity found that too, and the warning was
disabled, and use that commit in Fixes: tag? That’d be commit
b36c598c999c (ice: Updates to Tx scheduler code), different from
the one you used.
this version does not have any SHA mentioned :)
Sorry, I don’t understand your answer. What SHA do you mean?
there is no commit cited by Aleksandr in v3, IIRC there was one in v1
I agree that mention would be valuable, and we still want v4 with my
Suggested-by dropped anyway :)
I'm working on v4, but I must wait 24 hours from v3 according to netdev
rules: https://docs.kernel.org/process/maintainer-netdev.html.
In v4 I'll drop "Suggested-by" :)
But I'm a little confused whether to include "Fixes" tag into v4,
because this is not an issue for the users as Simon and Przemek wrote?
I would be grateful if you could tell me what else to change to avoid
later v5 release :)
`Documentation/process/submitting-patches.rst` says:
A Fixes: tag indicates that the patch fixes an issue in a previous
commit. It is used to make it easy to determine where a bug
originated, which can help review a bug fix. This tag also assists
the stable kernel team in determining which stable kernel versions
should receive your fix. This is the preferred method for indicating
a bug fixed by the patch.
so, this is not a "fix" per definition of a fix: "your patch changes
observable misbehavior"
If the over-allocation would be counted in megabytes, then it will
be a different case.
The quoted text just talks about “an issue”. What definition do you
refer to?
I mean that there is no issue (for the users), thus no fix.
Example of recently merged "not fix", with more links to other "non-
fixes":
https://lore.kernel.org/all/[email protected]/T/
Kind regards,
Paul
--
Kind regards
Aleksandr
