public inbox for openrisc@lists.librecores.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 04/14] x86: use more conventional access_ok() definition
Date: Mon, 14 Feb 2022 21:00:11 +0100	[thread overview]
Message-ID: <20220214200011.GA3786@lst.de> (raw)
In-Reply-To: <CAK8P3a1F3JaYaJPy9bSCG1+YV6EN05PE0DbwpD_GT1qRwFSJ-w@mail.gmail.com>

On Mon, Feb 14, 2022 at 08:45:52PM +0100, Arnd Bergmann wrote:
> As Al pointed out, they turned out to be necessary on sparc64, but the only
> definitions are on sparc64 and x86, so it's possible that they serve a similar
> purpose here, in which case changing the limit from TASK_SIZE to
> TASK_SIZE_MAX is probably wrong as well.
> 
> So either I need to revert the original definition as I did on sparc64, or
> they can be removed completely. Hopefully Al or the x86 maintainers
> can clarify.

Looking at the x86 users I think:

 - valid_user_frame should go away and the caller should use get_user
   instead of __get_user
 - the one in copy_code can just go away, as there is another check
   in copy_from_user_nmi
 - copy_stack_frame should just use access_ok
 - as does copy_from_user_nmi

but yes, having someone who actually knows this code look over it
would be very helpful.

  reply	other threads:[~2022-02-14 20:00 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-14 16:34 [OpenRISC] [PATCH 00/14] clean up asm/uaccess.h, kill set_fs for good Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 01/14] uaccess: fix integer overflow on access_ok() Arnd Bergmann
2022-02-14 16:58   ` Christoph Hellwig
2022-02-14 16:34 ` [OpenRISC] [PATCH 02/14] sparc64: add __{get, put}_kernel_nocheck() Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 03/14] nds32: fix access_ok() checks in get/put_user Arnd Bergmann
2022-02-14 17:01   ` Christoph Hellwig
2022-02-14 17:10     ` David Laight
2022-02-15  9:18     ` Arnd Bergmann
2022-02-15 10:25       ` Greg KH
2022-02-14 16:34 ` [OpenRISC] [PATCH 04/14] x86: use more conventional access_ok() definition Arnd Bergmann
2022-02-14 17:02   ` Christoph Hellwig
2022-02-14 19:45     ` Arnd Bergmann
2022-02-14 20:00       ` Christoph Hellwig [this message]
2022-02-14 20:01       ` Linus Torvalds
2022-02-14 20:17         ` Al Viro
2022-02-15  2:47           ` Al Viro
2022-02-14 20:24         ` Linus Torvalds
2022-02-14 22:13           ` David Laight
2022-02-14 16:34 ` [OpenRISC] [PATCH 05/14] uaccess: add generic __{get, put}_kernel_nofault Arnd Bergmann
2022-02-14 17:02   ` Christoph Hellwig
2022-02-15  0:31   ` Al Viro
2022-02-15 13:16     ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 06/14] mips: use simpler access_ok() Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 07/14] uaccess: generalize access_ok() Arnd Bergmann
2022-02-14 17:04   ` Christoph Hellwig
2022-02-14 17:15   ` Al Viro
2022-02-14 19:25     ` Arnd Bergmann
2022-02-15 10:58   ` Mark Rutland
2022-02-14 16:34 ` [OpenRISC] [PATCH 08/14] arm64: simplify access_ok() Arnd Bergmann
2022-02-14 21:06   ` Robin Murphy
2022-02-15  8:17   ` Ard Biesheuvel
2022-02-15  9:12     ` Arnd Bergmann
2022-02-15  9:21       ` Ard Biesheuvel
2022-02-15  9:39         ` Arnd Bergmann
2022-02-15 10:39           ` Mark Rutland
2022-02-15 10:37         ` Mark Rutland
2022-02-16 19:43       ` Christophe Leroy
2022-02-15  9:30     ` David Laight
2022-02-15 11:24       ` Mark Rutland
2022-02-15 11:07   ` Mark Rutland
2022-02-14 16:34 ` [OpenRISC] [PATCH 09/14] m68k: drop custom __access_ok() Arnd Bergmann
2022-02-15  0:37   ` Al Viro
2022-02-15  6:29     ` Christoph Hellwig
2022-02-15  7:13       ` Al Viro
2022-02-15 10:02         ` Arnd Bergmann
2022-02-15 13:28           ` David Laight
2022-02-14 16:34 ` [OpenRISC] [PATCH 10/14] uaccess: remove most CONFIG_SET_FS users Arnd Bergmann
2022-02-14 17:06   ` Christoph Hellwig
2022-02-14 19:40     ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 11/14] sparc64: remove CONFIG_SET_FS support Arnd Bergmann
2022-02-14 17:06   ` Christoph Hellwig
2022-02-16 13:06     ` Arnd Bergmann
2022-02-15  0:48   ` Al Viro
2022-02-16 13:07     ` Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 12/14] sh: " Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 13/14] ia64: " Arnd Bergmann
2022-02-14 16:34 ` [OpenRISC] [PATCH 14/14] uaccess: drop set_fs leftovers Arnd Bergmann
2022-02-15  3:03   ` Al Viro
2022-02-15  7:46     ` Helge Deller
2022-02-15  8:10       ` Arnd Bergmann
2022-02-14 17:35 ` [OpenRISC] [PATCH 00/14] clean up asm/uaccess.h, kill set_fs for good Linus Torvalds

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=20220214200011.GA3786@lst.de \
    --to=hch@lst.de \
    --cc=openrisc@lists.librecores.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox