[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScKa+1WMLywzNTraCxkHAshix6v4Fxf3kh5ZENirsicMA@mail.gmail.com>
Date: Mon, 11 Jan 2021 20:16:35 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>,
Arnd Bergmann <arnd@...nel.org>
Subject: Re: [PATCH 0/6] fs: deduplicate compat logic
On Mon, Jan 11, 2021 at 7:58 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Mon, Jan 11, 2021 at 07:30:11PM -0500, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@...gle.com>
> >
> > Use in_compat_syscall() to differentiate compat handling exactly
> > where needed, including in nested function calls. Then remove
> > duplicated code in callers.
>
> IMO it's a bad idea. Use of in_compat_syscall() is hard to avoid
> in some cases, but let's not use it without a good reason. It
> makes the code harder to reason about.
In the specific cases of select, poll and epoll, this removes quite a
bit of duplicate code that may diverge over time. Indeed, for select
already has. Reduction of duplication may also make subsequent changes
more feasible. We discussed avoiding in epoll an unnecessary
ktime_get_ts64 in select_estimate_accuracy, which requires plumbing a
variable through these intermediate helpers.
I also personally find the code simpler to understand without the
various near duplicates. The change exposes their differences
more clearly. select is the best example of this.
The last two patches I added based on earlier comments. Perhaps
the helper in 5 adds more churn than it's worth.
Powered by blists - more mailing lists