From: 周多明 <duoming@zju.edu.cn>
To: "Dan Carpenter" <dan.carpenter@oracle.com>
Cc: linux-hams@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, jreuter@yaina.de, kuba@kernel.org,
davem@davemloft.net, ralf@linux-mips.org, thomas@osterried.de
Subject: Re: Re: [PATCH] ax25: Fix memory leaks caused by ax25_cb_del()
Date: Fri, 11 Mar 2022 00:01:20 +0800 (GMT+08:00) [thread overview]
Message-ID: <2c28edff.f82b5.17f74902e09.Coremail.duoming@zju.edu.cn> (raw)
In-Reply-To: <20220310130508.GG3315@kadam>
Hello,
Thank you very much for pointing the wrong places in my patch.
> This is a very frustrating patch because you make a lot of unnecessary
> white space changes and you didn't run checkpatch on your patch.
>
> The whole approach feels like the wrong thing...
I will fix it.
> I have read your commit message, but I don't understand why we can't
> just use normal refcounting. It sounds like there is a layering
> violation somewhere?
The root cause of refcount leak is shown below:
(Thread 1) | (Thread 2)
ax25_bind() |
... |
ax25_addr_ax25dev() |
ax25_dev_hold() //(1) |
... |
dev_hold_track() //(2) |
... | ax25_destroy_socket()
| ax25_cb_del()
| ...
| spin_lock_bh(&ax25_list_lock);
| hlist_del_init(&ax25->ax25_node); //(3)
| spin_unlock_bh(&ax25_list_lock);
(thread 3)
ax25_kill_by_device() |
spin_lock_bh(&ax25_list_lock); |
ax25_for_each(s, &ax25_list) { |
if (s->ax25_dev == ax25_dev) //(4) |
... |
(the following code could not execute) |
Firstly, we use ax25_bind() to increase the refcount of ax25_dev in
position (1) and increase the refcount of net_device in position (2).
Then, we use ax25_cb_del() invoked by ax25_destroy_socket()
to delete ax25_cb in hlist in position (3) before calling ax25_kill_by_device().
Finally, the decrements of refcounts in ax25_kill_by_device() will not be executed,
because no s->ax25_dev equals to ax25_dev in position (4).
My patch adds two flags in ax25_dev in order to prevent reference count leaks.
If the above condition happens, the two "test_bit" checks in ax25_kill_by_device()
could pass and the refcounts could be decreased properly.
> Even if we go with this approach ->kill_flag and ->bind_flag should be
> booleans. It makes no sense to have a unsigned long where only BIT(2)
> can be set.
I will change kill_flag and bind_flag to booleans.
Best wishes,
Duoming Zhou
prev parent reply other threads:[~2022-03-10 16:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 15:06 Duoming Zhou
2022-03-10 13:05 ` Dan Carpenter
2022-03-10 16:01 ` 周多明 [this message]
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=2c28edff.f82b5.17f74902e09.Coremail.duoming@zju.edu.cn \
--to=duoming@zju.edu.cn \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=jreuter@yaina.de \
--cc=kuba@kernel.org \
--cc=linux-hams@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=thomas@osterried.de \
/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
all inboxes | Powered by JetHome®