All of lore.kernel.org
 help / color / mirror / Atom feed
From: 'Christoph Hellwig' <hch@lst.de>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Christoph Hellwig' <hch@lst.de>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"x86@kernel.org" <x86@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 09/11] x86: remove address space overrides using set_fs()
Date: Thu, 27 Aug 2020 11:37:48 +0200	[thread overview]
Message-ID: <20200827093748.GA13887@lst.de> (raw)
In-Reply-To: <935d551809894d14965e430e05d21057@AcuMS.aculab.com>

On Mon, Aug 17, 2020 at 08:23:11AM +0000, David Laight wrote:
> From: Christoph Hellwig
> > Sent: 17 August 2020 08:32
> >
> > Stop providing the possibility to override the address space using
> > set_fs() now that there is no need for that any more.  To properly
> > handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> > x86 a new alternative is introduced, which just like the one in
> > entry_64.S has to use the hardcoded virtual address bits to escape
> > the fact that TASK_SIZE_MAX isn't actually a constant when 5-level
> > page tables are enabled.
> ....
> > @@ -93,7 +69,7 @@ static inline bool pagefault_disabled(void);
> >  #define access_ok(addr, size)					\
> >  ({									\
> >  	WARN_ON_IN_IRQ();						\
> > -	likely(!__range_not_ok(addr, size, user_addr_max()));		\
> > +	likely(!__range_not_ok(addr, size, TASK_SIZE_MAX));		\
> >  })
> 
> Can't that always compare against a constant even when 5-levl
> page tables are enabled on x86-64?
> 
> On x86-64 it can (probably) reduce to (addr | (addr + size)) < 0.

I'll leave that to the x86 maintainers as a future cleanup if wanted.

WARNING: multiple messages have this Message-ID (diff)
From: 'Christoph Hellwig' <hch@lst.de>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	'Christoph Hellwig' <hch@lst.de>
Subject: Re: [PATCH 09/11] x86: remove address space overrides using set_fs()
Date: Thu, 27 Aug 2020 11:37:48 +0200	[thread overview]
Message-ID: <20200827093748.GA13887@lst.de> (raw)
In-Reply-To: <935d551809894d14965e430e05d21057@AcuMS.aculab.com>

On Mon, Aug 17, 2020 at 08:23:11AM +0000, David Laight wrote:
> From: Christoph Hellwig
> > Sent: 17 August 2020 08:32
> >
> > Stop providing the possibility to override the address space using
> > set_fs() now that there is no need for that any more.  To properly
> > handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> > x86 a new alternative is introduced, which just like the one in
> > entry_64.S has to use the hardcoded virtual address bits to escape
> > the fact that TASK_SIZE_MAX isn't actually a constant when 5-level
> > page tables are enabled.
> ....
> > @@ -93,7 +69,7 @@ static inline bool pagefault_disabled(void);
> >  #define access_ok(addr, size)					\
> >  ({									\
> >  	WARN_ON_IN_IRQ();						\
> > -	likely(!__range_not_ok(addr, size, user_addr_max()));		\
> > +	likely(!__range_not_ok(addr, size, TASK_SIZE_MAX));		\
> >  })
> 
> Can't that always compare against a constant even when 5-levl
> page tables are enabled on x86-64?
> 
> On x86-64 it can (probably) reduce to (addr | (addr + size)) < 0.

I'll leave that to the x86 maintainers as a future cleanup if wanted.

  reply	other threads:[~2020-08-27  9:37 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17  7:32 remove the last set_fs() in common code, and remove it for x86 and powerpc Christoph Hellwig
2020-08-17  7:32 ` Christoph Hellwig
2020-08-17  7:32 ` [PATCH 01/11] mem: remove duplicate ops for /dev/zero and /dev/null Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:33   ` Kees Cook
2020-08-18 19:33     ` Kees Cook
2020-08-17  7:32 ` [PATCH 02/11] fs: don't allow kernel reads and writes without iter ops Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:34   ` Kees Cook
2020-08-18 19:34     ` Kees Cook
2020-08-17  7:32 ` [PATCH 03/11] fs: don't allow splice read/write without explicit ops Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:39   ` Kees Cook
2020-08-18 19:39     ` Kees Cook
2020-08-18 19:54     ` Christoph Hellwig
2020-08-18 19:54       ` Christoph Hellwig
2020-08-18 19:58       ` Kees Cook
2020-08-18 19:58         ` Kees Cook
2020-08-18 20:07         ` Christoph Hellwig
2020-08-18 20:07           ` Christoph Hellwig
2020-08-17  7:32 ` [PATCH 04/11] uaccess: add infrastructure for kernel builds with set_fs() Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:40   ` Kees Cook
2020-08-18 19:40     ` Kees Cook
2020-08-17  7:32 ` [PATCH 05/11] test_bitmap: skip user bitmap tests for !CONFIG_SET_FS Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-17  7:50   ` Christophe Leroy
2020-08-17  7:52     ` Christoph Hellwig
2020-08-17  7:52       ` Christoph Hellwig
2020-08-18 19:43   ` Kees Cook
2020-08-18 19:43     ` Kees Cook
2020-08-17  7:32 ` [PATCH 06/11] lkdtm: disable set_fs-based " Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:32   ` Kees Cook
2020-08-18 19:32     ` Kees Cook
2020-08-17  7:32 ` [PATCH 07/11] x86: move PAGE_OFFSET, TASK_SIZE & friends to page_{32,64}_types.h Christoph Hellwig
2020-08-17  7:32   ` [PATCH 07/11] x86: move PAGE_OFFSET, TASK_SIZE & friends to page_{32, 64}_types.h Christoph Hellwig
2020-08-18 19:27   ` [PATCH 07/11] x86: move PAGE_OFFSET, TASK_SIZE & friends to page_{32,64}_types.h Kees Cook
2020-08-18 19:27     ` Kees Cook
2020-08-17  7:32 ` [PATCH 08/11] x86: make TASK_SIZE_MAX usable from assembly code Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-18 19:44   ` Kees Cook
2020-08-18 19:44     ` Kees Cook
2020-08-18 19:55     ` Christoph Hellwig
2020-08-18 19:55       ` Christoph Hellwig
2020-08-18 19:59       ` Kees Cook
2020-08-18 19:59         ` Kees Cook
2020-08-18 20:00         ` Christoph Hellwig
2020-08-18 20:00           ` Christoph Hellwig
2020-08-18 20:08           ` Kees Cook
2020-08-18 20:08             ` Kees Cook
2020-08-17  7:32 ` [PATCH 09/11] x86: remove address space overrides using set_fs() Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-17  8:23   ` David Laight
2020-08-17  8:23     ` David Laight
2020-08-27  9:37     ` 'Christoph Hellwig' [this message]
2020-08-27  9:37       ` 'Christoph Hellwig'
2020-08-18 19:46   ` Kees Cook
2020-08-18 19:46     ` Kees Cook
2020-08-17  7:32 ` [PATCH 10/11] powerpc: use non-set_fs based maccess routines Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-17 15:47   ` Christophe Leroy
2020-08-17  7:32 ` [PATCH 11/11] powerpc: remove address space overrides using set_fs() Christoph Hellwig
2020-08-17  7:32   ` Christoph Hellwig
2020-08-17  7:39 ` remove the last set_fs() in common code, and remove it for x86 and powerpc Christoph Hellwig
2020-08-17  7:39   ` Christoph Hellwig
2020-08-18 17:46 ` Christophe Leroy
2020-08-18 18:05   ` Christoph Hellwig
2020-08-18 18:05     ` Christoph Hellwig
2020-08-18 18:23     ` Christophe Leroy
2020-08-18 18:23       ` Christophe Leroy
2020-08-19  7:16       ` Christophe Leroy
2020-08-19  7:22         ` iter and normal ops on /dev/zero & co, was " Christoph Hellwig
2020-08-19  7:22           ` 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=20200827093748.GA13887@lst.de \
    --to=hch@lst.de \
    --cc=David.Laight@ACULAB.COM \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /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.