[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjF2fkhuN8N-MnTwvzNig83XdQK50nir8oieF7jV6Om=A@mail.gmail.com>
Date: Mon, 7 Oct 2019 11:11:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <David.Laight@...lab.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Guenter Roeck <linux@...ck-us.net>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user()
On Mon, Oct 7, 2019 at 8:40 AM David Laight <David.Laight@...lab.com> wrote:
>
> You don't really want an extra access_ok() for every 'word' of a copy.
Yes you do.
> Some copies have to be done a word at a time.
Completely immaterial. If you can't see the access_ok() close to the
__get/put_user(), you have a bug.
Plus the access_ok() is cheap. The real cost is the STAC/CLAC.
So stop with the access_ok() "optimizations". They are broken garbage.
Really.
I've been very close to just removing __get_user/__put_user several
times, exactly because people do completely the wrong thing with them
- not speeding code up, but making it unsafe and buggy.
The new "user_access_begin/end()" model is much better, but it also
has actual STATIC checking that there are no function calls etc inside
th4e region, so it forces you to do the loop properly and tightly, and
not the incorrect "I checked the range somewhere else, now I'm doing
an unsafe copy".
And it actually speeds things up, unlike the access_ok() games.
Linus
Powered by blists - more mailing lists