From: Al Viro <viro@zeniv.linux.org.uk>
To: Ivan Delalande <colona@arista.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Kees Cook <keescook@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] proc/sysctl: don't return ENOMEM on lookup when a table is unregistering
Date: Thu, 13 Dec 2018 06:58:26 +0000 [thread overview]
Message-ID: <20181213065826.GL2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20181213015742.GA28776@visor>
On Wed, Dec 12, 2018 at 05:57:43PM -0800, Ivan Delalande wrote:
> proc_sys_lookup can fail with ENOMEM instead of ENOENT when the
> corresponding sysctl table is being unregistered. In our case we see
> this upon opening /proc/sys/net/*/conf files while network interfaces
> are being removed, which confuses our configuration daemon.
>
> The problem was successfully reproduced and this fix tested on v4.9.122
> and v4.20-rc6.
>
> Fixes: ace0c791e6c3 ("proc/sysctl: Don't grab i_lock under sysctl_lock.")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ivan Delalande <colona@arista.com>
> ---
> fs/proc/proc_sysctl.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
> index 89921a0d2ebb..834be5bc3d07 100644
> --- a/fs/proc/proc_sysctl.c
> +++ b/fs/proc/proc_sysctl.c
> @@ -474,7 +474,7 @@ static struct inode *proc_sys_make_inode(struct super_block *sb,
> if (unlikely(head->unregistering)) {
> spin_unlock(&sysctl_lock);
> iput(inode);
> - inode = NULL;
> + inode = ERR_PTR(-ENOENT);
> goto out;
> }
> ei->sysctl = head;
> @@ -549,10 +549,11 @@ static struct dentry *proc_sys_lookup(struct inode *dir, struct dentry *dentry,
> goto out;
> }
>
> - err = ERR_PTR(-ENOMEM);
> inode = proc_sys_make_inode(dir->i_sb, h ? h : head, p);
> - if (!inode)
> + if (IS_ERR_OR_NULL(inode)) {
> + err = inode ? ERR_CAST(inode) : ERR_PTR(-ENOMEM);
*gags*
If you want to return specific errors, do just that and for pity sake,
do *NOT* invent such hybrids. "Pointer to object on success,
ERR_PTR(-E...) on failure, NULL means ERR_PTR(-ENOMEM)" is a bitch to
reason about and prone to breakage.
"Return NULL on error" and "return ERR_PTR() on error" do not mix.
Just make proc_sys_make_inode() return ERR_PTR(-ENOMEM) on allocation
failures and update the callers (as you have to, anyway).
IS_ERR_OR_NULL() is usually a sign of bad calling conventions and it
certainly is just that in this case.
Just do
inode = new_inode(sb);
if (!inode)
return ERR_PTR(-ENOMEM);
in there, in addition to your return of ERR_PTR(-ENOENT), and lose those
IS_ERR_OR_NULL() things. Make those IS_ERR() and turn the assignment
to err into straight ERR_CAST(). All there is to it...
next prev parent reply other threads:[~2018-12-13 6:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 1:57 [PATCH] proc/sysctl: don't return ENOMEM on lookup when a table is unregistering Ivan Delalande
2018-12-13 6:58 ` Al Viro [this message]
2018-12-13 23:20 ` [PATCH v2] " Ivan Delalande
2018-12-14 1:45 ` 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=20181213065826.GL2217@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=colona@arista.com \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@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.