From: Al Viro <viro@zeniv.linux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: Kees Cook <keescook@chromium.org>,
Iurii Zaikin <yzaikin@google.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org,
bpf@vger.kernel.org
Subject: Re: [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler
Date: Wed, 22 Apr 2020 03:46:26 +0100 [thread overview]
Message-ID: <20200422024626.GI23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200421191615.GE23230@ZenIV.linux.org.uk>
On Tue, Apr 21, 2020 at 08:16:15PM +0100, Al Viro wrote:
> On Tue, Apr 21, 2020 at 07:15:39PM +0200, Christoph Hellwig wrote:
> > Instead of having all the sysctl handlers deal with user pointers, which
> > is rather hairy in terms of the BPF interaction, copy the input to and
> > from userspace in common code. This also means that the strings are
> > always NUL-terminated by the common code, making the API a little bit
> > safer.
> >
> > As most handler just pass through the data to one of the common handlers
> > a lot of the changes are mechnical.
>
> > @@ -564,27 +564,38 @@ static ssize_t proc_sys_call_handler(struct file *filp, void __user *buf,
> > if (!table->proc_handler)
> > goto out;
> >
> > - error = BPF_CGROUP_RUN_PROG_SYSCTL(head, table, write, buf, &count,
> > - ppos, &new_buf);
> > + if (write) {
> > + kbuf = memdup_user_nul(ubuf, count);
> > + if (IS_ERR(kbuf)) {
> > + error = PTR_ERR(kbuf);
> > + goto out;
> > + }
> > + } else {
> > + error = -ENOMEM;
> > + kbuf = kzalloc(count, GFP_KERNEL);
>
> Better allocate count + 1 bytes here, that way a lot of insanity in the
> instances can be simply converted to snprintf(). Yes, I know it'll bring
> the Church Of Avoiding The Abomination Of Sprintf out of the woodwork,
> but...
FWIW, consider e.g. net/sunrpc/sysctl.c:
Nevermind that the read side should be simply
int err = proc_douintvec(table, write, buffer, lenp, ppos);
/* Display the RPC tasks on writing to rpc_debug */
if (!err && strcmp(table->procname, "rpc_debug") == 0)
rpc_show_tasks(&init_net);
return err;
the write side would become
len = snprintf(buffer, *lenp + 1, "0x%04x\n",
*(unsigned int *)table->data);
if (len > *lenp)
len = *lenp;
*lenp -= len;
*ppos += len;
return 0;
and I really wonder if lifting the trailing boilerplate into the caller would've
been better. Note that e.g. gems like
if (!first)
err = proc_put_char(&buffer, &left, '\t');
if (err)
break;
err = proc_put_long(&buffer, &left, lval, neg);
if (err)
break;
are due to lack of snprintf-to-user; now, lose the "to user" part and we suddenly
can be rid of that stuff...
next prev parent reply other threads:[~2020-04-22 2:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 17:15 pass kernel pointers to the sysctl ->proc_handler method v2 Christoph Hellwig
2020-04-21 17:15 ` [PATCH 1/5] bpf-cgroup: remove unused exports Christoph Hellwig
2020-04-22 23:39 ` Andrey Ignatov
2020-04-21 17:15 ` [PATCH 2/5] mm: remove watermark_boost_factor_sysctl_handler Christoph Hellwig
2020-04-21 19:31 ` David Rientjes
2020-04-21 19:31 ` David Rientjes
2020-04-21 17:15 ` [PATCH 3/5] sysctl: remove all extern declaration from sysctl.c Christoph Hellwig
2020-04-22 10:30 ` Vlastimil Babka
2020-04-22 17:24 ` Christoph Hellwig
2020-04-21 17:15 ` [PATCH 4/5] sysctl: avoid forward declarations Christoph Hellwig
2020-04-21 17:15 ` [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler Christoph Hellwig
2020-04-21 19:16 ` Al Viro
2020-04-22 2:46 ` Al Viro [this message]
2020-04-22 6:09 ` Christoph Hellwig
2020-04-21 19:23 ` Andrey Ignatov
2020-04-22 17:22 ` Christoph Hellwig
2020-04-22 23:40 ` Andrey Ignatov
2020-04-24 6:43 pass kernel pointers to the sysctl ->proc_handler method v3 Christoph Hellwig
2020-04-24 6:43 ` [PATCH 5/5] sysctl: pass kernel pointers to ->proc_handler Christoph Hellwig
2020-04-24 19:06 ` Andrey Ignatov
2020-04-27 5:34 ` Christoph Hellwig
2020-05-04 19:01 ` Kees Cook
2020-05-05 5:57 ` Christoph Hellwig
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=20200422024626.GI23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hch@lst.de \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=netdev@vger.kernel.org \
--cc=yzaikin@google.com \
/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.