All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org, openrisc@lists.librecores.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, linux-arch@linux-xtensa.org,
	linux-kernel@linux-xtensa.org
Subject: architectures that still need to remove set_fs()
Date: Tue, 18 Jan 2022 08:48:36 +0100	[thread overview]
Message-ID: <20220118074836.GA20994@lst.de> (raw)

Hi all,

you are in this list because your architecture still implements and
uses address space overrides using set_fs(), which are deprecated and
have been removed from all mainstream architecture ports.  To help
cleanup the core kernel it would be great to make progress on removing
set_fs entirely.

The following steps are required:

 (1) implement the __get_kernel_nofault and __put_kernel_nofault
     helper to access kernel memory without page faults, replacing
     the get/put_user under set_fs(KERNEL_DS) abuse.  Mips has a good
     example for a trivial implementation for architectures that use
     a common address space in commit 04324f44cb69
 (2) remove any architecture specific use of such constructs.  This
     only affects ia64 and sh.
 (3) stop selecting the SET_FS and remove all the set_fs-related
     infrastructure.  The above mips commit is a good guide once again.

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org, openrisc@lists.librecores.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, linux-arch@linux-xtensa.org,
	linux-kernel@linux-xtensa.org
Subject: architectures that still need to remove set_fs()
Date: Tue, 18 Jan 2022 07:48:36 +0000	[thread overview]
Message-ID: <20220118074836.GA20994@lst.de> (raw)

Hi all,

you are in this list because your architecture still implements and
uses address space overrides using set_fs(), which are deprecated and
have been removed from all mainstream architecture ports.  To help
cleanup the core kernel it would be great to make progress on removing
set_fs entirely.

The following steps are required:

 (1) implement the __get_kernel_nofault and __put_kernel_nofault
     helper to access kernel memory without page faults, replacing
     the get/put_user under set_fs(KERNEL_DS) abuse.  Mips has a good
     example for a trivial implementation for architectures that use
     a common address space in commit 04324f44cb69
 (2) remove any architecture specific use of such constructs.  This
     only affects ia64 and sh.
 (3) stop selecting the SET_FS and remove all the set_fs-related
     infrastructure.  The above mips commit is a good guide once again.

Thanks!

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@kernel.org>, Guo Ren <guoren@kernel.org>,
	Brian Cain <bcain@codeaurora.org>,
	Michal Simek <monstr@monstr.eu>, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Dinh Nguyen <dinguyen@kernel.org>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	"David S. Miller" <davem@davemloft.net>,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org,
	linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org,
	linux-ia64@vger.kernel.org, openrisc@lists.librecores.org,
	linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-xtensa@linux-xtensa.org, linux-arch@linux-xtensa.org,
	linux-kernel@linux-xtensa.org
Subject: architectures that still need to remove set_fs()
Date: Tue, 18 Jan 2022 08:48:36 +0100	[thread overview]
Message-ID: <20220118074836.GA20994@lst.de> (raw)

Hi all,

you are in this list because your architecture still implements and
uses address space overrides using set_fs(), which are deprecated and
have been removed from all mainstream architecture ports.  To help
cleanup the core kernel it would be great to make progress on removing
set_fs entirely.

The following steps are required:

 (1) implement the __get_kernel_nofault and __put_kernel_nofault
     helper to access kernel memory without page faults, replacing
     the get/put_user under set_fs(KERNEL_DS) abuse.  Mips has a good
     example for a trivial implementation for architectures that use
     a common address space in commit 04324f44cb69
 (2) remove any architecture specific use of such constructs.  This
     only affects ia64 and sh.
 (3) stop selecting the SET_FS and remove all the set_fs-related
     infrastructure.  The above mips commit is a good guide once again.

Thanks!

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] architectures that still need to remove set_fs()
Date: Tue, 18 Jan 2022 08:48:36 +0100	[thread overview]
Message-ID: <20220118074836.GA20994@lst.de> (raw)

Hi all,

you are in this list because your architecture still implements and
uses address space overrides using set_fs(), which are deprecated and
have been removed from all mainstream architecture ports.  To help
cleanup the core kernel it would be great to make progress on removing
set_fs entirely.

The following steps are required:

 (1) implement the __get_kernel_nofault and __put_kernel_nofault
     helper to access kernel memory without page faults, replacing
     the get/put_user under set_fs(KERNEL_DS) abuse.  Mips has a good
     example for a trivial implementation for architectures that use
     a common address space in commit 04324f44cb69
 (2) remove any architecture specific use of such constructs.  This
     only affects ia64 and sh.
 (3) stop selecting the SET_FS and remove all the set_fs-related
     infrastructure.  The above mips commit is a good guide once again.

Thanks!

             reply	other threads:[~2022-01-18  7:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18  7:48 Christoph Hellwig [this message]
2022-01-18  7:48 ` [OpenRISC] architectures that still need to remove set_fs() Christoph Hellwig
2022-01-18  7:48 ` Christoph Hellwig
2022-01-18  7:48 ` Christoph Hellwig
2022-01-18 11:48 ` Stafford Horne
2022-01-18 11:48   ` [OpenRISC] " Stafford Horne
2022-01-18 11:48   ` Stafford Horne
2022-01-18 11:48   ` Stafford Horne
2022-01-18 11:48   ` Stafford Horne

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=20220118074836.GA20994@lst.de \
    --to=hch@lst.de \
    --cc=bcain@codeaurora.org \
    --cc=chris@zankel.net \
    --cc=dalias@libc.org \
    --cc=davem@davemloft.net \
    --cc=deanbo422@gmail.com \
    --cc=dinguyen@kernel.org \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jcmvbkbc@gmail.com \
    --cc=jonas@southpole.se \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@linux-xtensa.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-hexagon@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@linux-xtensa.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=mattst88@gmail.com \
    --cc=monstr@monstr.eu \
    --cc=nickhu@andestech.com \
    --cc=openrisc@lists.librecores.org \
    --cc=rth@twiddle.net \
    --cc=shorne@gmail.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=vgupta@kernel.org \
    --cc=ysato@users.sourceforge.jp \
    /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.