From: David Laight <David.Laight@ACULAB.COM>
To: 'Arnd Bergmann' <arnd@kernel.org>
Cc: Michal Simek <monstr@monstr.eu>,
Christoph Hellwig <hch@infradead.org>,
Arnd Bergmann <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] microblaze: remove CONFIG_SET_FS
Date: Thu, 10 Feb 2022 14:21:07 +0000 [thread overview]
Message-ID: <cc2a0d0eb77b4ace872263db7bf0c115@AcuMS.aculab.com> (raw)
In-Reply-To: <CAK8P3a3tZEc30AaiNENbHKf8+x5VOw7Q=4dVDMNwz0F6+v9YrQ@mail.gmail.com>
From: Arnd Bergmann
> Sent: 10 February 2022 13:30
...
> #define __access_ok(addr, size) \
> ((get_fs().seg == KERNEL_DS.seg) || \
> (((unsigned long)addr < get_fs().seg) && \
> (unsigned long)size < (get_fs().seg - (unsigned long)addr)))
That one is strange.
Seems to be optimised for kernel accesses!
> ia64 and sparc skip the size check entirely but rely on an unmapped page
> at the beginning of the kernel address range, which avoids this problem
> but may also be dangerous.
An unmapped page requires that the kernel do sequential accesses
(or, at least, not big offset) - which is normally fine.
Especially for 64bit where there is plenty of address space.
I guess it could be problematic for 32bit if you can/want to
use 'big pages' for the kernel addresses.
Losing a single (typically) 4k page isn't a problem.
Certainly not mapping the page at TASK_SIZE is a good safety check.
Actually, setting TASK_SIZE to 0xc0000000 - PAGE_SIZE and never
mapping the last user page has the same effect.
Except I bet the ldso has to go there :-(
Not to mention the instruction sets where loading the constant
would then be two instructions.
...
> > Although typical 64bit architectures can use the faster:
> > ((addr | size) >> 62)
>
> I think this is the best version, and it's already widely used:
I just did a quick check, both clang and gcc optimise out
constant values for 'size'.
> static inline int __range_ok(unsigned long addr, unsigned long size)
> {
> return size <= TASK_SIZE && addr <= (TASK_SIZE - size);
> }
>
> since 'size' is usually constant, so this turns into a single comparison
> against a compile-time constant.
Hmmm... maybe there should be a comment that it is the same as
the more obvious:
(addr <= TASK_SIZE && addr <= TASK_SIZE - size)
but is better for constant size.
(Provided TASK_SIZE is a constant.)
I'm sure Linus was 'unhappy' about checking against 2^63 for
32bit processes on a 64bit kernel.
Hmmm compat code that has 32bit addr/size needn't even call
access_ok() - it can never access kernel memory at all.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-02-10 14:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-09 14:48 Arnd Bergmann
2022-02-10 9:36 ` David Laight
2022-02-10 13:29 ` Arnd Bergmann
2022-02-10 14:21 ` David Laight [this message]
2022-02-10 14:53 ` Arnd Bergmann
2022-02-10 22:23 ` Stafford Horne
-- strict thread matches above, loose matches on Subject: below --
2022-01-17 13:24 [PATCH 03/10] exit: Move oops specific logic from do_exit into make_task_dead Arnd Bergmann
2022-01-17 13:27 ` [PATCH] microblaze: remove CONFIG_SET_FS Arnd Bergmann
2022-02-09 13:50 ` Michal Simek
2022-02-09 13:52 ` Christoph Hellwig
2022-02-09 14:03 ` Michal Simek
2022-02-09 14:40 ` Arnd Bergmann
2022-02-09 14:44 ` Michal Simek
2022-02-09 14:54 ` Arnd Bergmann
2022-02-09 23:31 ` Stafford Horne
2022-02-11 0:17 ` Stafford Horne
2022-02-11 16:59 ` Arnd Bergmann
2022-02-11 17:46 ` Linus Torvalds
2022-02-11 20:57 ` Arnd Bergmann
2022-02-11 21:10 ` Eric W. Biederman
2022-02-11 22:21 ` Stafford Horne
2022-02-14 7:41 ` Christoph Hellwig
2022-02-14 7:50 ` Christoph Hellwig
2022-02-14 16:20 ` Arnd Bergmann
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=cc2a0d0eb77b4ace872263db7bf0c115@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=monstr@monstr.eu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome