Christoph Hellwig <[email protected]> writes: > Both exec and exit want to ensure that the uaccess routines actually do > access user pointers. Use the newly added force_uaccess_begin helper > instead of an open coded set_fs for that to prepare for kernel builds > where set_fs() does not exist.
Acked-by: "Eric W. Biederman" <[email protected]> Have you played with a tree with all of your patches and placing force_uaccess_begin in init/main.c:start_kernel? Somewhere deep in the arch code we seem to have it all backwards and kernel threads are all set_fs(KERNEL_DS). So just putting a force_uaccess_begin somewhere very early should be enough to switch things around. > Signed-off-by: Christoph Hellwig <[email protected]> > --- > fs/exec.c | 7 ++++++- > kernel/exit.c | 2 +- > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/fs/exec.c b/fs/exec.c > index e6e8a9a7032784..769af470b69124 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1380,7 +1380,12 @@ int begin_new_exec(struct linux_binprm * bprm) > if (retval) > goto out_unlock; > > - set_fs(USER_DS); > + /* > + * Ensure that the uaccess routines can actually operate on userspace > + * pointers: > + */ > + force_uaccess_begin(); > + > me->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD | > PF_NOFREEZE | PF_NO_SETAFFINITY); > flush_thread(); > diff --git a/kernel/exit.c b/kernel/exit.c > index 727150f2810338..17d486a20f0dc6 100644 > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -731,7 +731,7 @@ void __noreturn do_exit(long code) > * mm_release()->clear_child_tid() from writing to a user-controlled > * kernel address. > */ > - set_fs(USER_DS); > + force_uaccess_begin(); > > if (unlikely(in_atomic())) { > pr_info("note: %s[%d] exited with preempt_count %d\n",
