Received: by 10.223.148.5 with SMTP id 5csp6265741wrq; Wed, 17 Jan 2018 11:26:51 -0800 (PST) X-Google-Smtp-Source: ACJfBoukXRUcpg7PBGsdDMUkb9uSpXTAKJHa6VlLfWyx/lcTyLgG+pYD3t/uBsVsQ6aNhCMSR8O8 X-Received: by 10.99.97.209 with SMTP id v200mr26096057pgb.126.1516217211238; Wed, 17 Jan 2018 11:26:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516217211; cv=none; d=google.com; s=arc-20160816; b=XOo8Wuvv1ZQI8M1eTzjYPcV1ZqRU8wKHDyY1FZIMWztSFXdalkt4wdo5n3R1815i8x wyAOdOL1hhLBTaXsse3649prrXpOigYshbM6qHKUU/ho95dhVxgMcHI5XYuZvFOfoKV5 UL2MU9apte4c3dsmp18JUB6dsHaGlcjX7k7+7VO/uWZrwtF95TMF7nlHfJPqNDsH9FRf jHyY7xJqfqAusv2/Ego9fodc4Dcb56oPOai5UVXhzTSF9+5eRS9R7gXcfrc6eWG6MW2/ oAKBFBE3pkbNb64/DlIdaFKd0OENdY6TnCL8ZDQxViuqWQEsmHG3DUI7uDXmrH3+gAod W8hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=SW0Ji3+dIOIhLhg5b0COme8EktQwmzuXaAT6zfMFMJM=; b=fVVYxituCUDt3R2VS6sBSf/JC6uVAai1G5o2ClYs3mufuuNmQYvbUY5v/Bsn+EsEnh c5io+ppdYXbEGObW63IuzFI3DI6XpV4C6V0oaBikLYB5qKwMLqqp9EbDo4xe5e6Dr+AF ViwkqoGI3yZ5x54eddRR15m42QP84AsnbI9yAEVLerfRVonkwl406+MiMj8POj0m9CBU 2t1qYJDugW5LtsIHHDSQ3EEKLkOQcs/W/+MEN6KY+1TVFneev/44a7ojQCXZNdPsWPpL 9A2LGGwYrXiUJ/LazIc8/047jtPPSaDMQsGFfmNN6z3x3E9s03Yza2a9hLNmWugpg5IK /xUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=s5myeO9J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1si4363678pgr.410.2018.01.17.11.26.36; Wed, 17 Jan 2018 11:26:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=s5myeO9J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752693AbeAQT0L (ORCPT + 99 others); Wed, 17 Jan 2018 14:26:11 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:33712 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750931AbeAQT0J (ORCPT ); Wed, 17 Jan 2018 14:26:09 -0500 Received: by mail-io0-f194.google.com with SMTP id n7so5631735iob.0; Wed, 17 Jan 2018 11:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SW0Ji3+dIOIhLhg5b0COme8EktQwmzuXaAT6zfMFMJM=; b=s5myeO9JpOJivqeIizG0fxl/7RG9XXgLVmCGQ+VWQrN2TbbU8qHSOKk2w1gvbllE9F fYmY20oAoTPNhhk08ttCtS/U1im4zyzLmGEQBIjCWHnlrXJQIOe+DZ2tWRmV72DlBvuj +ijn3PQ00im0/uSFAK30h7HzzkAREvtTBr+Q+nEP7U5BxSWRXsfOzmmvjFALCKxNes+M ovNwW3h0JKzLc9q6bNWD1rQe86si8XUSG8qScCvl8H7PdNpgRt0w2IDTkRuZ18ApO0Bw AKqNVtOKRuiyKqCu2GUnj3/fz0Xqf/DBaJNX3GccogBEyFZPIFVv6nWRTQscd68u60PI T7mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SW0Ji3+dIOIhLhg5b0COme8EktQwmzuXaAT6zfMFMJM=; b=fV+e3DIuxr7acwaCSBjX3CZh13EFKzeWA5b+or2rvvPABQUCOsAGUWe1jIa3xwe1Y+ QAnSy/Kx+3Ac2qc99Crt2QyIZqlTwZx1ySFkh9EVq4NXR3mVEi+ALarEVV6SAIIIDBpx Xr4knQDz82OsxPXuxl7ahCRyb4+ZSp/ew3rTc3OpjOcvXpD0/3OsYgjlg5l9A5vCTojO mhSUFFDrLxBdqDIo6OT8O3KFnMz4AhB/wU2ZwoA2SNXt26kyoGFiNOHzcl3h/964jY5n UkE7e8LMj1iSWg2Sy1VjuquN1Yx47ixAzrzW8E+xUl2eDyJY+fVPvNacCBwXoYFE3DPB gtoQ== X-Gm-Message-State: AKGB3mIDQiF1iDdmaxxCzkR6O6Uz9n5lN8QFmwafetdjssPY8qYeNKXB mrnFR2xbAq52bkgwhiA1BTPD+oP+ksiSi5UDgmg= X-Received: by 10.107.13.12 with SMTP id 12mr45033721ion.174.1516217169007; Wed, 17 Jan 2018 11:26:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.6.147 with HTTP; Wed, 17 Jan 2018 11:26:08 -0800 (PST) In-Reply-To: <1516198646.4184.13.camel@linux.intel.com> References: <151586744180.5820.13215059696964205856.stgit@dwillia2-desk3.amr.corp.intel.com> <151586748981.5820.14559543798744763404.stgit@dwillia2-desk3.amr.corp.intel.com> <1516198646.4184.13.camel@linux.intel.com> From: Linus Torvalds Date: Wed, 17 Jan 2018 11:26:08 -0800 X-Google-Sender-Auth: x6sssr0Uo-iIEHLTwS9f48lmCXo Message-ID: Subject: Re: [PATCH v3 8/9] x86: use __uaccess_begin_nospec and ASM_IFENCE in get_user paths To: Alan Cox , Eric Dumazet Cc: Dan Williams , Linux Kernel Mailing List , linux-arch@vger.kernel.org, Andi Kleen , Kees Cook , kernel-hardening@lists.openwall.com, Greg Kroah-Hartman , "the arch/x86 maintainers" , Ingo Molnar , Al Viro , "H. Peter Anvin" , Thomas Gleixner , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 "read_kernel()"). But getting rid of the concept entirely? Doesn't seem likely. Linus