From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 751D8C2D0DB for ; Thu, 23 Jan 2020 20:04:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1F7652253D for ; Thu, 23 Jan 2020 20:04:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="eQxTZQW0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1F7652253D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8AB2C6B0274; Thu, 23 Jan 2020 15:04:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 836196B0276; Thu, 23 Jan 2020 15:04:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FD806B0277; Thu, 23 Jan 2020 15:04:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 5691B6B0274 for ; Thu, 23 Jan 2020 15:04:15 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id E16B9181AEF10 for ; Thu, 23 Jan 2020 20:04:14 +0000 (UTC) X-FDA: 76409975628.10.chair21_7c474c8a15861 X-HE-Tag: chair21_7c474c8a15861 X-Filterd-Recvd-Size: 5998 Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 23 Jan 2020 20:04:13 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id cy15so4634564edb.4 for ; Thu, 23 Jan 2020 12:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8DVtOQwrFkEAE5or+ctC9NfF/UngBhO5F9zvyg/cwIE=; b=eQxTZQW0N74htNr8ZIoBTg2RQDPW3OjTEHCMc4sFe5oYhaOUGSJvrl6o1eL0CZRoF6 x82sJpEoaWzhBeyAQr4AJVLWbXFgY8LgUhy1SsB1ddXX6DI1lqW3atZTfWsWptXew+SX fwPcf1xNLR3ZLFeVh0I0M9xVVUDiWrMIvhW4U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8DVtOQwrFkEAE5or+ctC9NfF/UngBhO5F9zvyg/cwIE=; b=oss/P0tnY01MOkXVqGc0sGlNQ/TzQAFO/O5eN77W1LO79Wm3hdUWPWUo4Yo+XhvsUi eiK1KY5tR4uIwxQgcA8x9UebkkJk/bXjU8cobsu3qVlVkfyGrYYE2Ex4pRFBpf6ST1iS yTFyzRxSpxQsgNQXoa0Xqt+n7WCSleGn+mxvyWAZT0likEdbGWuAMEITNZ+BGmPpmB8a D2UCNcS0GYDu1pYjVsF8+k/c2TtzlWXQaT99eaElGXZfEyzuEoTGHf9zaC//RJ30QlAy YoFV+OnjD/Mc3Ux+wX+xB9xhbSSHgz3vshieJaFFxe+/VEdddcVKdJm9n4olkqhMxLxx YfRw== X-Gm-Message-State: APjAAAU7U3xNWZ8G2WaS7/PMHMtEnse3htVzLpEV0HzVL25K3kH5rcDY V+YWO3wS7j0da5hBEQg1zaMwtW/ayKs= X-Google-Smtp-Source: APXvYqye/GTREGA67ecXUlU2KMDhfAnOUBp0+2Lck8icpgMwNCBNSuWXafJYVbUUFTkou8Z9wGeACg== X-Received: by 2002:a17:906:c444:: with SMTP id ck4mr8370614ejb.224.1579809852059; Thu, 23 Jan 2020 12:04:12 -0800 (PST) Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com. [209.85.208.51]) by smtp.gmail.com with ESMTPSA id a24sm41283edr.84.2020.01.23.12.04.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jan 2020 12:04:11 -0800 (PST) Received: by mail-ed1-f51.google.com with SMTP id v28so4588913edw.12 for ; Thu, 23 Jan 2020 12:04:11 -0800 (PST) X-Received: by 2002:a2e:88c5:: with SMTP id a5mr3682ljk.201.1579809493632; Thu, 23 Jan 2020 11:58:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Thu, 23 Jan 2020 11:57:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not To: christophe leroy Cc: Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Alexander Viro , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Jani Nikula , Linux Kernel Mailing List , linuxppc-dev , linux-fsdevel , Linux-MM , dri-devel , "the arch/x86 maintainers" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jan 23, 2020 at 11:47 AM christophe leroy wrote: > > I'm going to leave it aside, at least for the time being, and do it as a > second step later after evaluating the real performance impact. I'll > respin tomorrow in that way. Ok, good. >From a "narrow the access window type" standpoint it does seem to be a good idea to specify what kind of user accesses will be done, so I don't hate the idea, it's more that I'm not convinced it matters enough. On x86, we have made the rule that user_access_begin/end() can contain _very_ few operations, and objtool really does enforce that. With objtool and KASAN, you really end up with very small ranges of user_access_begin/end(). And since we actually verify it statically on x86-64, I would say that the added benefit of narrowing by access type is fairly small. We're not going to have complicated code in that user access region, at least in generic code. > > Also, it shouldn't be a "is this a write". What if it's a read _and_ a > > write? Only a write? Only a read? > > Indeed that was more: does it includes a write. It's either RO or RW I would expect that most actual users would be RO or WO, so it's a bit odd to have those choices. Of course, often writing ends up requiring read permissions anyway if the architecture has problems with alignment handling or similar, but still... The real RW case does exist conceptually (we have "copy_in_user()", after all), but still feels like it shouldn't be seen as the only _interface_ choice. IOW, an architecture may decide to turn WO into RW because of architecture limitations (or, like x86 and arm, ignore the whole RO/RW/WO _entirely_ because there's just a single "allow user space accesses" flag), but on an interface layer if we add this flag, I really think it should be an explicit "read or write or both". So thus my "let's try to avoid doing it in the first place, but if we _do_ do this, then do it right" plea. Linus