[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200519164146.GA28313@lst.de>
Date: Tue, 19 May 2020 18:41:46 +0200
From: Christoph Hellwig <hch@....de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Christoph Hellwig <hch@....de>,
the arch/x86 maintainers <x86@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Masami Hiramatsu <mhiramat@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-parisc@...r.kernel.org,
linux-um <linux-um@...ts.infradead.org>,
Netdev <netdev@...r.kernel.org>, bpf@...r.kernel.org,
Linux-MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/20] maccess: remove strncpy_from_unsafe
On Tue, May 19, 2020 at 09:25:57AM -0700, Linus Torvalds wrote:
> On Tue, May 19, 2020 at 6:45 AM Christoph Hellwig <hch@....de> wrote:
> >
> > + if (IS_ENABLED(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE) &&
> > + compat && (unsigned long)unsafe_ptr < TASK_SIZE)
> > + ret = strncpy_from_user_nofault(dst, user_ptr, size);
> > + else
> > + ret = strncpy_from_kernel_nofault(dst, unsafe_ptr, size);
>
> These conditionals are completely illegible.
I had a lot of folks complaining about things like:
#ifdef CONFIG_FOO
if (foo)
do_stuff();
else
#endif
do_something_else();
which I personally don't mind at all, so I switched to this style.
> static long bpf_strncpy_from_legacy(void *dest, const void
> *unsafe_ptr, long size, bool legacy)
> {
> #ifdef CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
> if (legacy && addr < TASK_SIZE)
> return strncpy_from_user_nofault(dst, (const void __user
> *) unsafe_ptr, size);
> #endif
>
> return strncpy_from_kernel_nofault(dst, unsafe_ptr, size);
> }
>
> and then you'd just use
>
> if (bpf_strncpy_from_unsafe(dst, unsafe_ptr, size, compat) < 0)
> memset(dst, 0, size);
>
> and avoid any complicated conditionals, goto's, and make the code much
> easier to understand thanks to having a big comment about the legacy
> case.
Sure.
> In fact, separately I'd probably want that "compat" naming to be
> scrapped entirely in that file.
Not my choice.. Maybe Daniel has a recommendation of what to change
there, but I'd love to not have to deal with that renaming as well
in this series.
Powered by blists - more mailing lists