[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201001131659.GE3421308@ZenIV.linux.org.uk>
Date: Thu, 1 Oct 2020 14:16:59 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Qian Cai <cai@...hat.com>
Cc: David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] pipe: Fix memory leaks in create_pipe_files()
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@...hat.com>
=======================
Powered by blists - more mailing lists