From: Stephen Hemminger <stephen@networkplumber.org>
To: David Ahern <dsahern@kernel.org>
Cc: Andrea Claudi <aclaudi@redhat.com>,
netdev@vger.kernel.org, markzhang@nvidia.com, leonro@nvidia.com
Subject: Re: [PATCH iproute2 v2 1/2] lib/fs: fix memory leak in get_task_name()
Date: Mon, 7 Mar 2022 10:14:54 -0800 [thread overview]
Message-ID: <20220307101454.24c02c76@hermes.local> (raw)
In-Reply-To: <527dab8b-6eba-da17-8cef-2614042c9688@kernel.org>
On Mon, 7 Mar 2022 10:58:37 -0700
David Ahern <dsahern@kernel.org> wrote:
> On 3/2/22 5:28 AM, Andrea Claudi wrote:
> > diff --git a/include/utils.h b/include/utils.h
> > index b6c468e9..81294488 100644
> > --- a/include/utils.h
> > +++ b/include/utils.h
> > @@ -307,7 +307,7 @@ char *find_cgroup2_mount(bool do_mount);
> > __u64 get_cgroup2_id(const char *path);
> > char *get_cgroup2_path(__u64 id, bool full);
> > int get_command_name(const char *pid, char *comm, size_t len);
> > -char *get_task_name(pid_t pid);
> > +int get_task_name(pid_t pid, char *name);
> >
>
> changing to an API with an assumed length is not better than the current
> situation. Why not just fixup the callers as needed to free the allocation?
I wonder if iproute2 should start using GCC attribute cleanup function
(like systemd) or would this be too much of using a new thing?
Not sure if using the attribute (wrapped in macro) just hides the problem
next prev parent reply other threads:[~2022-03-07 18:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-02 12:28 [PATCH iproute2 v2 0/2] fix memory leak in get_task_name() Andrea Claudi
2022-03-02 12:28 ` [PATCH iproute2 v2 1/2] lib/fs: " Andrea Claudi
2022-03-03 18:56 ` Leon Romanovsky
2022-03-07 18:07 ` Andrea Claudi
2022-03-07 18:12 ` David Ahern
2022-03-09 13:39 ` Leon Romanovsky
2022-03-07 17:58 ` David Ahern
2022-03-07 18:14 ` Stephen Hemminger [this message]
2022-03-07 18:21 ` Andrea Claudi
2022-03-07 19:57 ` Stephen Hemminger
2022-03-07 22:38 ` David Ahern
2022-03-02 12:28 ` [PATCH iproute2 v2 2/2] rdma: make RES_PID and RES_KERN_NAME alternative to each other Andrea Claudi
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=20220307101454.24c02c76@hermes.local \
--to=stephen@networkplumber.org \
--cc=aclaudi@redhat.com \
--cc=dsahern@kernel.org \
--cc=leonro@nvidia.com \
--cc=markzhang@nvidia.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.