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.9 required=3.0 tests=DKIMWL_WL_HIGH,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 4376BC4724C for ; Thu, 30 Apr 2020 17:17:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 225562082E for ; Thu, 30 Apr 2020 17:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588267061; bh=wMHfXxlqbC2DwaJUbiQuSilxhl1f1EP1X/5pSV6f1m0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Fv0HbbAbN8meq6CTgVqVtWhbEqVyMkrvri1rnUP32zI35+ynoH6jA8d2PG3dwdUwp s3l46sEi84VzqrtS7SBpIUEXiZVtF9L/5vzCwkVCoqEUB3CmXzSNmwzoGS9etdjY2n ZSdKAYc6DvKobPCb93S+v2tVDmTG/xikAQMYaT8c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726491AbgD3RRk (ORCPT ); Thu, 30 Apr 2020 13:17:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726440AbgD3RRj (ORCPT ); Thu, 30 Apr 2020 13:17:39 -0400 Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69BE7C035495 for ; Thu, 30 Apr 2020 10:17:39 -0700 (PDT) Received: by mail-lf1-x144.google.com with SMTP id y3so1887932lfy.1 for ; Thu, 30 Apr 2020 10:17:39 -0700 (PDT) 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=AbtaQ1Pr8o8wY3oZ0XUT+6r9NQjFUKQ2iX6lszWerYA=; b=hvyYWSqj2/fPEY1WvRlxpzG6+BEmdG53Q6FGr0rmFjqrtn6k+h40SEBcbuDXCqxUgu oQj9pLhUMMsLzXOxx5yIsXnoxM5edRADMw3Nok9hHdGYJi9aZqee4YhpZbofCd09La3i YD/BYT0Ja4/85/lTKRMWx/UXUjWBdf/VeXqqw= 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=AbtaQ1Pr8o8wY3oZ0XUT+6r9NQjFUKQ2iX6lszWerYA=; b=ONOS4LUyIhagiIzsPBsizTOkHUUbm7qiO3343BfvKqt6Ra9bM2lARSyqnUaGa7zV8q ysbJLpx6pi0GDng6TIs58Tom+4N4/an10rvqBUw4STcUonE2fONrVdnuCsPjQoMhw8wR oJLlCPd5oADcf8Q9FXSphYyRKnRJkHx4cAeVFxPKkCax1GIsRNM2a81mUBDFFucK+vF9 hrgQfOj6eCyWhSFA8/lSCdUDDW3N8tMaW5NSzuTN1kkEY9854ITCmt7SygFHHjiGO50y sOmKlULegMFPuX6y1yTOyEHimA2WYfbo6Tz+BbugRZaqhDoz1VFLy7maINBCl8CnC/BJ 3X3w== X-Gm-Message-State: AGi0Pua/uPV8eYwmP6/3PrBeMRNdbN2yH1Cj35KZM+XpIsONFYUH/E3b GYL4jYEZ9vwTJNySuv9ClIegW8gU7+w= X-Google-Smtp-Source: APiQypIUhqK4rK5dvUYCtW0df72Q7miKkv6BO6DJvTerLVjNOgm3+htkgSL7JlSZyGvT1KChO8RUVA== X-Received: by 2002:a19:b10:: with SMTP id 16mr2915441lfl.133.1588267057334; Thu, 30 Apr 2020 10:17:37 -0700 (PDT) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id v18sm243988lfd.0.2020.04.30.10.17.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2020 10:17:36 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id b2so163288ljp.4 for ; Thu, 30 Apr 2020 10:17:35 -0700 (PDT) X-Received: by 2002:a05:651c:319:: with SMTP id a25mr167004ljp.209.1588267055471; Thu, 30 Apr 2020 10:17:35 -0700 (PDT) MIME-Version: 1.0 References: <158823509800.2094061.9683997333958344535.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: From: Linus Torvalds Date: Thu, 30 Apr 2020 10:17:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe() To: Andy Lutomirski Cc: Dan Williams , Thomas Gleixner , Ingo Molnar , Tony Luck , Peter Zijlstra , Borislav Petkov , stable , "the arch/x86 maintainers" , "H. Peter Anvin" , Paul Mackerras , Benjamin Herrenschmidt , Erwin Tsaur , Michael Ellerman , Arnaldo Carvalho de Melo , linux-nvdimm , Linux Kernel Mailing List 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 Thu, Apr 30, 2020 at 9:52 AM Andy Lutomirski wrote: > > If I'm going to copy from memory that might be bad but is at least a > valid pointer, I want a function to do this. If I'm going to copy > from memory that might be entirely bogus, that's a different > operation. In other words, if I'm writing e.g. filesystem that is > touching get_user_pages()'d persistent memory, I don't want to panic > if the memory fails, but I do want at least a very loud warning if I > follow a wild pointer. > > So I think that probe_kernel_copy() is not a valid replacement for > memcpy_mcsafe(). Fair enough. That said, the part I do like about probe_kernel_read/write() is that it does indicate which part we think is possibly the one that needs more care. Sure, it _might_ be both sides, but honestly, that's likely the much less common case. Kind of like "copy_{to,from}_user()" vs "copy_in_user()". Yes, the "copy_in_user()" case exists, but it's the odd and unusual case. Looking at the existing cases of "memcpy_mcsafe()", they do seem to generally have a very clearly defined direction, not "both sides can break". I also find myself suspecting that one case people _do_ want to possibly do is to copy from nvdimm memory into user space. So then that needs yet another function. And we have that copy_to_user_mcsafe() for that, and used in the disgustingly named "copyout_mcsafe()". Ugly incomprehensible BSD'ism. But oddly we don't have the "from_user" case. So this thing seems messy, the naming is odd and inconsistent, and I'd really like the whole "access with exception handling" to have some clear rules and clear names. The whole "there are fifty different special cases" really drives me wild. It's why I think the hardware was so broken. And now the special "writes can fault" rule still confuses me. _copy_to_iter_mcsafe() was mentioned, which makes me think that it's literally about that "copy from nvram to user space" issue. But that can't just trap on the destination, that fundamentally needs special user space accesses anyway. Even on x86 you have the whole STAC/CLAC issue, on other architectures the stores may not be normal stores at all. So a "copy_safe()" model doesn't actually work for that at all. So I'm a bit (maybe a _lot_) confused about what the semantics should actually be. And I want the naming to reflect whatever those semantics are. And I don't think "copy_safe()" reflects any semantics at all. Linus