Re: [PATCH] m68knommu: remove set_fs()
Christoph Hellwig <[email protected]> Tue, 6 Jul 2021 06:13:53 +0200
| Newsgroups | gmane.linux.ports.m68k,gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jul 05, 2021 at 01:39:03PM -0700, Linus Torvalds wrote: > On Mon, Jul 5, 2021 at 1:46 AM Geert Uytterhoeven <[email protected]> wrote: > > > > Probably this should be > > > > select SET_FS if CPU_HAS_ADDRESS_SPACES > > Actually, I don't think m68k has a single real "set_fs()" at all, and > it should just be converted as-is to not use CONFIG_SET_FS. > > Yes, there is a "set_fs()" function, but none of the remaining uses > actually are the traditional kernel style of "use kernel addresses as > user addresses". So as far as the *kernel* is concerned, m68k already > looks like a no-SET_FS architecture, and "set-fs()" is purely a > syntactic thing. It still needs "real" kernel-style set_fs for the mm/maccess.c routines, but adding __{get,put}_kernel_nofault should not be too hard. > So I think the right thing to do looks something like this: > > - make the rule be that SFC/DFC is always normally USER_DATA > > - the special m68k sequences that need to play with special segments > will always do > > preempt_disable(); > set_segment(..whatever segment they need..); > .. do the special operation .. > set_segment(USER_DATA); > preempt_enable(); > > - set_fs() goes away entirely, because the user access functions > always work on USER_DATA and SFC/DFC is always right for them. Yes, that's what I mean with needing a more work.