Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Jan 2018 11:26:08 -0800
From: Linus Torvalds <>
To: Alan Cox <>, Eric Dumazet <>
Cc: Dan Williams <>, 
	Linux Kernel Mailing List <>,, 
	Andi Kleen <>, Kees Cook <>,, 
	Greg Kroah-Hartman <>, "the arch/x86 maintainers" <>, 
	Ingo Molnar <>, Al Viro <>, 
	"H. Peter Anvin" <>, Thomas Gleixner <>, 
	Andrew Morton <>
Subject: Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in
 get_user paths

On Wed, Jan 17, 2018 at 6:17 AM, Alan Cox <> wrote:
> Can we kill off the remaining users of set_fs() ?

I would love to, but it's not going to happen short-term. If ever.

Some could be removed today: the code in arch/x86/net/bpf_jit_comp.c
seems to be literally the ramblings of a diseased mind. There's no
reason for the set_fs(), there's no reason for the
flush_icache_range() (it's a no-op on x86 anyway), and the smp_wmb()
looks bogus too.

I have no idea how that braindamage happened, but I assume it got
copied from some broken source.

But there are about ~100 set_fs() calls in generic code, and some of
those really are pretty fundamental. Doing things like "kernel_read()"
without set_fs() is basically impossible.

We've had set_fs() since the beginning. The naming is obviously very
historical. We have it for a very good reason, and I don't really see
that reason going away.

So realistically, we want to _minimize_ set_fs(), and we might want to
make sure that it's done only in limited settings (it might, for
example, be a good idea and a realistic goal to make sure that drivers
and modules can't do it, and use proper helper functions like that

But getting rid of the concept entirely? Doesn't seem likely.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.