Re: [Intel-wired-lan] [PATCH net-next v3] ice: Adjust over allocation of memory in ice_sched_add_root_node() and ice_sched_add_node()

[Aleksandr Mishin]

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: -anirudh.venkataramanan@xxxxxxxxx (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/b836eb8ca8abf2f64478da48d250405bb1d90ad5.camel@xxxxxxxxxxxxxxxx/T/
>
> > Kind regards,
> >
> > Paul

--
Kind regards
Aleksandr