From: Simon Horman <horms@kernel.org>
To: Zhipeng Lu <alexious@zju.edu.cn>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Maor Gottlieb <maorg@mellanox.com>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/mlx5e: fix a double-free in arfs_create_groups
Date: Wed, 3 Jan 2024 17:22:54 +0000 [thread overview]
Message-ID: <20240103172254.GB31813@kernel.org> (raw)
In-Reply-To: <20231224081348.3535146-1-alexious@zju.edu.cn>
On Sun, Dec 24, 2023 at 04:13:48PM +0800, Zhipeng Lu wrote:
> When `in` allocated by kvzalloc fails, arfs_create_groups will free
> ft->g and return an error. However, arfs_create_table, the only caller of
> arfs_create_groups, will hold this error and call to
> mlx5e_destroy_flow_table, in which the ft->g will be freed again.
>
> Fixes: 1cabe6b0965e ("net/mlx5e: Create aRFS flow tables")
> Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn>
Thanks,
I agree this addresses the issue that you describe.
And as a minimal fix it looks good.
Reviewed-by: Simon Horman <horms@kernel.org>
However, I would like to suggest that some clean-up work could
take place as a follow-up.
I think that the error handling in this area of the code
is rather fragile. This is because initialisation is not necessarily
unwound on error within the function that initialisation occurs.
I think it would be better if arfs_create_groups():
1. Released allocates resources it allocates, including ft->g and
elements of ft->g, on error.
2. This was achieved by using a goto unwind ladder.
3. The caller treated ft->g as uninitialised if
arfs_create_groups fails.
Likewise, I think that:
* arfs_create_groups, should initialise ft->num_groups
And further, logic similar to the above should guide
how arfs_create_table() initialises ft->t and cleans it
up on error.
I did not look at the code beyond the scope described above.
But the above are general principles that may well apply in
other nearby code too.
...
next prev parent reply other threads:[~2024-01-03 17:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-24 8:13 [PATCH] net/mlx5e: fix a double-free in arfs_create_groups Zhipeng Lu
2024-01-03 17:22 ` Simon Horman [this message]
2024-01-08 9:12 ` alexious
2024-01-08 11:05 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240103172254.GB31813@kernel.org \
--to=horms@kernel.org \
--cc=alexious@zju.edu.cn \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=maorg@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).