From: Al Viro <viro@zeniv.linux.org.uk>
To: Navid Emamdoost <navid.emamdoost@gmail.com>
Cc: emamd001@umn.edu, smccaman@umn.edu, kjlu@umn.edu,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net: qrtr: fix memory leak in qrtr_tun_read_iter
Date: Thu, 26 Sep 2019 00:21:12 +0100 [thread overview]
Message-ID: <20190925232112.GR26530@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20190925230416.20126-1-navid.emamdoost@gmail.com>
On Wed, Sep 25, 2019 at 06:04:13PM -0500, Navid Emamdoost wrote:
> In qrtr_tun_read_iter we need an error handling path to appropriately
> release skb in cases of error.
Release _what_ skb?
> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
> ---
> net/qrtr/tun.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/net/qrtr/tun.c b/net/qrtr/tun.c
> index e35869e81766..0f6e6d1d2901 100644
> --- a/net/qrtr/tun.c
> +++ b/net/qrtr/tun.c
> @@ -54,19 +54,24 @@ static ssize_t qrtr_tun_read_iter(struct kiocb *iocb, struct iov_iter *to)
> int count;
>
> while (!(skb = skb_dequeue(&tun->queue))) {
The body of the loop is entered only if the loop condition has
evaluated true. In this case, it means that the value of
!(skb = skb_dequeue(&tun->queue))
had been true, i.e. the value of
skb = skb_dequeue(&tun->queue)
has been NULL, i.e. that skb_dequeue() has returned NULL, which had
been copied into skb.
In other words, in the body of that loop we have skb equal to NULL.
> - if (filp->f_flags & O_NONBLOCK)
> - return -EAGAIN;
> + if (filp->f_flags & O_NONBLOCK) {
> + count = -EAGAIN;
> + goto out;
> + }
>
> /* Wait until we get data or the endpoint goes away */
> if (wait_event_interruptible(tun->readq,
> - !skb_queue_empty(&tun->queue)))
> - return -ERESTARTSYS;
> + !skb_queue_empty(&tun->queue))) {
> + count = -ERESTARTSYS;
> + goto out;
> + }
> }
The meaning of that loop is fairly clear, isn't it? Keep looking int
tun->queue until an skb shows up there. If it's not immediately there,
fail with -EAGAIN for non-blocking files and wait on tun->readq until
some skb arrives.
next prev parent reply other threads:[~2019-09-25 23:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 23:04 [PATCH] net: qrtr: fix memory leak in qrtr_tun_read_iter Navid Emamdoost
2019-09-25 23:21 ` Al Viro [this message]
2019-09-27 3:16 ` Navid Emamdoost
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=20190925232112.GR26530@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=davem@davemloft.net \
--cc=emamd001@umn.edu \
--cc=kjlu@umn.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=navid.emamdoost@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=smccaman@umn.edu \
/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.