* [Patch net v3] tun: fix a memory leak for tfile->tx_array
@ 2018-01-15 19:37 Cong Wang
2018-01-16 5:46 ` Jason Wang
0 siblings, 1 reply; 9+ messages in thread
From: Cong Wang @ 2018-01-15 19:37 UTC (permalink / raw)
To: netdev; +Cc: dvyukov, Cong Wang, Jason Wang
tfile->tun could be detached before we close the tun fd,
via tun_detach_all(), so it should not be used to check for
tfile->tx_array.
As Jason suggested, we probably have to clean it up
unconditionally both in __tun_deatch() and tun_detach_all(),
but this requires to check if it is initialized or not.
Currently skb_array_cleanup() doesn't have such a check,
so I check it in the caller and introduce a helper function,
it is a bit ugly but we can always improve it in net-next.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
Cc: Jason Wang <jasowang@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
drivers/net/tun.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 4f4a842a1c9c..a8ec589d1359 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -611,6 +611,14 @@ static void tun_queue_purge(struct tun_file *tfile)
skb_queue_purge(&tfile->sk.sk_error_queue);
}
+static void tun_cleanup_tx_array(struct tun_file *tfile)
+{
+ if (tfile->tx_array.ring.queue) {
+ skb_array_cleanup(&tfile->tx_array);
+ memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
+ }
+}
+
static void __tun_detach(struct tun_file *tfile, bool clean)
{
struct tun_file *ntfile;
@@ -657,8 +665,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
tun->dev->reg_state == NETREG_REGISTERED)
unregister_netdevice(tun->dev);
}
- if (tun)
- skb_array_cleanup(&tfile->tx_array);
+ tun_cleanup_tx_array(tfile);
sock_put(&tfile->sk);
}
}
@@ -700,11 +707,13 @@ static void tun_detach_all(struct net_device *dev)
/* Drop read queue */
tun_queue_purge(tfile);
sock_put(&tfile->sk);
+ tun_cleanup_tx_array(tfile);
}
list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) {
tun_enable_queue(tfile);
tun_queue_purge(tfile);
sock_put(&tfile->sk);
+ tun_cleanup_tx_array(tfile);
}
BUG_ON(tun->numdisabled != 0);
@@ -2851,6 +2860,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
+ memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
+
return 0;
}
--
2.13.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-15 19:37 [Patch net v3] tun: fix a memory leak for tfile->tx_array Cong Wang
@ 2018-01-16 5:46 ` Jason Wang
2018-01-16 5:49 ` Cong Wang
0 siblings, 1 reply; 9+ messages in thread
From: Jason Wang @ 2018-01-16 5:46 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: dvyukov
On 2018年01月16日 03:37, Cong Wang wrote:
> tfile->tun could be detached before we close the tun fd,
> via tun_detach_all(), so it should not be used to check for
> tfile->tx_array.
>
> As Jason suggested, we probably have to clean it up
> unconditionally both in __tun_deatch() and tun_detach_all(),
> but this requires to check if it is initialized or not.
> Currently skb_array_cleanup() doesn't have such a check,
> so I check it in the caller and introduce a helper function,
> it is a bit ugly but we can always improve it in net-next.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
> Cc: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> drivers/net/tun.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 4f4a842a1c9c..a8ec589d1359 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -611,6 +611,14 @@ static void tun_queue_purge(struct tun_file *tfile)
> skb_queue_purge(&tfile->sk.sk_error_queue);
> }
>
> +static void tun_cleanup_tx_array(struct tun_file *tfile)
> +{
> + if (tfile->tx_array.ring.queue) {
> + skb_array_cleanup(&tfile->tx_array);
> + memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
> + }
> +}
> +
> static void __tun_detach(struct tun_file *tfile, bool clean)
> {
> struct tun_file *ntfile;
> @@ -657,8 +665,7 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
> tun->dev->reg_state == NETREG_REGISTERED)
> unregister_netdevice(tun->dev);
> }
> - if (tun)
> - skb_array_cleanup(&tfile->tx_array);
> + tun_cleanup_tx_array(tfile);
> sock_put(&tfile->sk);
> }
> }
> @@ -700,11 +707,13 @@ static void tun_detach_all(struct net_device *dev)
> /* Drop read queue */
> tun_queue_purge(tfile);
> sock_put(&tfile->sk);
> + tun_cleanup_tx_array(tfile);
> }
> list_for_each_entry_safe(tfile, tmp, &tun->disabled, next) {
> tun_enable_queue(tfile);
> tun_queue_purge(tfile);
> sock_put(&tfile->sk);
> + tun_cleanup_tx_array(tfile);
> }
> BUG_ON(tun->numdisabled != 0);
>
> @@ -2851,6 +2860,8 @@ static int tun_chr_open(struct inode *inode, struct file * file)
>
> sock_set_flag(&tfile->sk, SOCK_ZEROCOPY);
>
> + memset(&tfile->tx_array, 0, sizeof(tfile->tx_array));
> +
> return 0;
> }
>
I think then you don't even need the memset trick since we are sure it
has been implemented?
Thanks
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 5:46 ` Jason Wang
@ 2018-01-16 5:49 ` Cong Wang
2018-01-16 6:00 ` Jason Wang
0 siblings, 1 reply; 9+ messages in thread
From: Cong Wang @ 2018-01-16 5:49 UTC (permalink / raw)
To: Jason Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On Mon, Jan 15, 2018 at 9:46 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> I think then you don't even need the memset trick since we are sure it has
> been implemented?
It doesn't look like sk_alloc() zero's the memory of tfile.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 5:49 ` Cong Wang
@ 2018-01-16 6:00 ` Jason Wang
2018-01-16 6:07 ` Cong Wang
0 siblings, 1 reply; 9+ messages in thread
From: Jason Wang @ 2018-01-16 6:00 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On 2018年01月16日 13:49, Cong Wang wrote:
> On Mon, Jan 15, 2018 at 9:46 PM, Jason Wang <jasowang@redhat.com> wrote:
>>
>> I think then you don't even need the memset trick since we are sure it has
>> been implemented?
> It doesn't look like sk_alloc() zero's the memory of tfile.
Typo, for "implemented" I mean "initialized".
I mean we can leave __tun_detach() as is, and just add the cleanup to
tun_detach_all(). This is because in both cases, we're sure skb array
has been initialized before.
Thanks
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 6:00 ` Jason Wang
@ 2018-01-16 6:07 ` Cong Wang
2018-01-16 6:12 ` Jason Wang
0 siblings, 1 reply; 9+ messages in thread
From: Cong Wang @ 2018-01-16 6:07 UTC (permalink / raw)
To: Jason Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On Mon, Jan 15, 2018 at 10:00 PM, Jason Wang <jasowang@redhat.com> wrote:
> I mean we can leave __tun_detach() as is, and just add the cleanup to
> tun_detach_all(). This is because in both cases, we're sure skb array has
> been initialized before.
>
Oh, I thought the same before sending v3, but I believe it is easier to
understand 'if (tfile->tx_array.ring.queue)' than 'if (tun)', because tx_array
only depends on itself rather tfile->tun in this way.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 6:07 ` Cong Wang
@ 2018-01-16 6:12 ` Jason Wang
2018-01-16 6:33 ` Cong Wang
0 siblings, 1 reply; 9+ messages in thread
From: Jason Wang @ 2018-01-16 6:12 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On 2018年01月16日 14:07, Cong Wang wrote:
> On Mon, Jan 15, 2018 at 10:00 PM, Jason Wang <jasowang@redhat.com> wrote:
>> I mean we can leave __tun_detach() as is, and just add the cleanup to
>> tun_detach_all(). This is because in both cases, we're sure skb array has
>> been initialized before.
>>
> Oh, I thought the same before sending v3, but I believe it is easier to
> understand 'if (tfile->tx_array.ring.queue)' than 'if (tun)', because tx_array
> only depends on itself rather tfile->tun in this way.
Maybe just add a comment to explain in __tun_detach(), it avoids
memset() anyway.
Thanks
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 6:12 ` Jason Wang
@ 2018-01-16 6:33 ` Cong Wang
2018-01-16 6:37 ` Jason Wang
0 siblings, 1 reply; 9+ messages in thread
From: Cong Wang @ 2018-01-16 6:33 UTC (permalink / raw)
To: Jason Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On Mon, Jan 15, 2018 at 10:12 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2018年01月16日 14:07, Cong Wang wrote:
>>
>> On Mon, Jan 15, 2018 at 10:00 PM, Jason Wang <jasowang@redhat.com> wrote:
>>>
>>> I mean we can leave __tun_detach() as is, and just add the cleanup to
>>> tun_detach_all(). This is because in both cases, we're sure skb array has
>>> been initialized before.
>>>
>> Oh, I thought the same before sending v3, but I believe it is easier to
>> understand 'if (tfile->tx_array.ring.queue)' than 'if (tun)', because
>> tx_array
>> only depends on itself rather tfile->tun in this way.
>
>
> Maybe just add a comment to explain in __tun_detach(), it avoids memset()
> anyway.
>
But __tun_detach(true) is not a hot path, a memset() doesn't harm anything.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 6:33 ` Cong Wang
@ 2018-01-16 6:37 ` Jason Wang
2018-01-16 6:49 ` Cong Wang
0 siblings, 1 reply; 9+ messages in thread
From: Jason Wang @ 2018-01-16 6:37 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On 2018年01月16日 14:33, Cong Wang wrote:
> On Mon, Jan 15, 2018 at 10:12 PM, Jason Wang <jasowang@redhat.com> wrote:
>>
>> On 2018年01月16日 14:07, Cong Wang wrote:
>>> On Mon, Jan 15, 2018 at 10:00 PM, Jason Wang <jasowang@redhat.com> wrote:
>>>> I mean we can leave __tun_detach() as is, and just add the cleanup to
>>>> tun_detach_all(). This is because in both cases, we're sure skb array has
>>>> been initialized before.
>>>>
>>> Oh, I thought the same before sending v3, but I believe it is easier to
>>> understand 'if (tfile->tx_array.ring.queue)' than 'if (tun)', because
>>> tx_array
>>> only depends on itself rather tfile->tun in this way.
>>
>> Maybe just add a comment to explain in __tun_detach(), it avoids memset()
>> anyway.
>>
> But __tun_detach(true) is not a hot path, a memset() doesn't harm anything.
Yes, but it looks more more like a workaround or trick to me.
Thanks
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Patch net v3] tun: fix a memory leak for tfile->tx_array
2018-01-16 6:37 ` Jason Wang
@ 2018-01-16 6:49 ` Cong Wang
0 siblings, 0 replies; 9+ messages in thread
From: Cong Wang @ 2018-01-16 6:49 UTC (permalink / raw)
To: Jason Wang; +Cc: Linux Kernel Network Developers, Dmitry Vyukov
On Mon, Jan 15, 2018 at 10:37 PM, Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2018年01月16日 14:33, Cong Wang wrote:
>> But __tun_detach(true) is not a hot path, a memset() doesn't harm
>> anything.
>
>
> Yes, but it looks more more like a workaround or trick to me.
>
I'd blame skb_array API for this. ;) Ideally, skb_array_cleanup()
should take care of everything I put in tun_cleanup_tx_array().
As I mentioned in changelog, we can always improve it in
-net-next, so I don't want to bother it for -net.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-01-16 6:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-15 19:37 [Patch net v3] tun: fix a memory leak for tfile->tx_array Cong Wang
2018-01-16 5:46 ` Jason Wang
2018-01-16 5:49 ` Cong Wang
2018-01-16 6:00 ` Jason Wang
2018-01-16 6:07 ` Cong Wang
2018-01-16 6:12 ` Jason Wang
2018-01-16 6:33 ` Cong Wang
2018-01-16 6:37 ` Jason Wang
2018-01-16 6:49 ` Cong Wang
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.