From: Al Viro <viro@zeniv.linux.org.uk>
To: Qian Cai <cai@redhat.com>
Cc: David Howells <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] pipe: Fix memory leaks in create_pipe_files()
Date: Thu, 1 Oct 2020 14:16:59 +0100 [thread overview]
Message-ID: <20201001131659.GE3421308@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20201001125055.5042-1-cai@redhat.com>
On Thu, Oct 01, 2020 at 08:50:55AM -0400, Qian Cai wrote:
> Calling pipe2() with O_NOTIFICATION_PIPE could results in memory leaks
> in an error path or CONFIG_WATCH_QUEUE=n. Plug them.
[snip the copy of bug report]
No objections on the patch itself, but commit message is just about
unreadable. How about something along the lines of the following?
=======================
Calling pipe2() with O_NOTIFICATION_PIPE could results in memory
leaks unless watch_queue_init() is successful.
In case of watch_queue_init() failure in pipe2() we are left
with inode and pipe_inode_info instances that need to be freed. That
failure exit has been introduced in commit c73be61cede5 ("pipe: Add
general notification queue support") and its handling should've been
identical to nearby treatment of alloc_file_pseudo() failures - it
is dealing with the same situation. As it is, the mainline kernel
leaks in that case.
Another problem is that CONFIG_WATCH_QUEUE and !CONFIG_WATCH_QUEUE
cases are treated differently (and the former leaks just pipe_inode_info,
the latter - both pipe_inode_info and inode).
Fixed by providing a dummy wath_queue_init() in !CONFIG_WATCH_QUEUE
case and by having failures of wath_queue_init() handled the same way
we handle alloc_file_pseudo() ones.
Fixes: c73be61cede5 ("pipe: Add general notification queue support")
Signed-off-by: Qian Cai <cai@redhat.com>
=======================
next prev parent reply other threads:[~2020-10-01 13:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 12:50 [PATCH v3] pipe: Fix memory leaks in create_pipe_files() Qian Cai
2020-10-01 13:16 ` Al Viro [this message]
2020-10-01 13:37 ` Qian Cai
2020-10-01 13:43 ` Al Viro
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=20201001131659.GE3421308@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=cai@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.