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.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 BE288C47253 for ; Fri, 1 May 2020 18:29:00 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7EEE8208DB for ; Fri, 1 May 2020 18:29:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="DBxmwg4X" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EEE8208DB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 5AEE811460B65; Fri, 1 May 2020 11:27:41 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::241; helo=mail-lj1-x241.google.com; envelope-from=torvalds@linuxfoundation.org; receiver= Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C9A1311460B61 for ; Fri, 1 May 2020 11:27:38 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id g4so3438577ljl.2 for ; Fri, 01 May 2020 11:28:57 -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=Rg73oT2i7CN6P9GKzkav2692ScwMvCV8w1kfBm2rvpc=; b=DBxmwg4XXi8IArR4p+XyseptF37LsJFDYGKqn4Fej360l2/VSOaUYBVFHiPhk/xhQ8 s6lROshASV7jHjtWyNPvqjhgrgkaFVzegagn8zAtbWr/xDt6AORujuznySe6OYHZ6Vgb o4yy070krugoANDoZtUamLdr0Ij+rfCPnRdZE= 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=Rg73oT2i7CN6P9GKzkav2692ScwMvCV8w1kfBm2rvpc=; b=C7ECpJJEV7pav0GM3VSYQ0tZA31hnQIzcj9YgYeCHPcNMo+SEuL8KiCfacCoJhiRCD +BivhDCD7vVij0jSGIUebSM9kIx4z6jjPAfd/1TvpfeKlnpJSxhPKzTnNDwjq8iKvGId Uu7/lzlzicZlDUrMu31ITgfGqJkVJSocTRv2jl0i7TYOH36wd15B7oMSoM7K2Eg434p3 Kku0NSovgYV/DPvGyijeKQim4QYtavslD+3+zMh5K5VTpj4EQc4g9LTwynvB6qDQZohT OpycOMCWXb7YzMRimNJiSU5DocUP0/VkmxL7t1J9dTCLtZbKrvrhg3oEeVAJd4JNRBWL j2mw== X-Gm-Message-State: AGi0PublabOrIFyIqObAcyBFlevnRVyGv+TrhJpKuAIQEW5AP0TRYswF czO2OuqJP+06sj+ImwFbLqcE6EtZkN8= X-Google-Smtp-Source: APiQypKP87fPtYLNZQ5ibSsMfIR+7chz41tm6FF0cTynDTlu4TGsUqRlcS2BHkdivu04W9Yi1EHBHQ== X-Received: by 2002:a2e:a313:: with SMTP id l19mr3164748lje.133.1588357733618; Fri, 01 May 2020 11:28:53 -0700 (PDT) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com. [209.85.208.174]) by smtp.gmail.com with ESMTPSA id a15sm2381514ljb.37.2020.05.01.11.28.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 May 2020 11:28:52 -0700 (PDT) Received: by mail-lj1-f174.google.com with SMTP id a21so3376670ljj.11 for ; Fri, 01 May 2020 11:28:51 -0700 (PDT) X-Received: by 2002:a2e:7308:: with SMTP id o8mr3129793ljc.16.1588357731518; Fri, 01 May 2020 11:28:51 -0700 (PDT) MIME-Version: 1.0 References: <158823509800.2094061.9683997333958344535.stgit@dwillia2-desk3.amr.corp.intel.com>

<20200430192258.GA24749@agluck-desk2.amr.corp.intel.com>

In-Reply-To: From: Linus Torvalds Date: Fri, 1 May 2020 11:28:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe() To: Dan Williams Message-ID-Hash: JNHF2IENDR4PCWDTC2JCXUUN7A7LDNVO X-Message-ID-Hash: JNHF2IENDR4PCWDTC2JCXUUN7A7LDNVO X-MailFrom: torvalds@linuxfoundation.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: "Luck, Tony" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , 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 X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Apr 30, 2020 at 6:21 PM Dan Williams wrote: > > However now I see that copy_user_generic() works for the wrong reason. > It works because the exception on the source address due to poison > looks no different than a write fault on the user address to the > caller, it's still just a short copy. So it makes copy_to_user() work > for the wrong reason relative to the name. Right. And it won't work that way on other architectures. On x86, we have a generic function that can take faults on either side, and we use it for both cases (and for the "in_user" case too), but that's an artifact of the architecture oddity. In fact, it's probably wrong even on x86 - because it can hide bugs - but writing those things is painful enough that everybody prefers having just one function. That's particularly true since that "one function" is actually a whole family of functions - just for different optimizations. Plus on x86 you can't reasonably even have different code sequences for that case, because CLAC/STAC don't have a "enable users read accesses" vs "write accesses" case. It's an all-or-nothing "enable user faults". We _used_ to have a difference on x86, back when we did the whole "fs segment points to user space". But on other architectures, there really is a difference between "copy_to_user()" and "copy_from_user()", and the functions won't do fault handling for the kernel side accesses. > How about, following your suggestion, introduce copy_mc_to_user() (can > just use copy_user_generic() internally) and copy_mc_to_kernel() for > the other the helpers that the copy_to_iter() implementation needs? Yes. That at least solves my naming worries, and is conceptually something that works on other architectures. Those other architectures may not have nvdimm support yet, but I think everybody is at least looking at it. And I really do think it will make the users more readable too, when you see on a source level that "oh, this code is expecting that it could take a poison fault/machine check on the source/destination". > Following Jann's ex_handler_uaccess() example I could arrange for > copy_mc_to_kernel() to use a new _ASM_EXTABLE_MC() to validate that > the only type of exception meant to be handled is MC and warn > otherwise? That may be a good idea, but won't work for any shared case. IOW, it would be lovely to have a "copy_mc_to_user()" check that if it's a write fault, it's because it's a user address (and if it's a read fault it's because it's a poisoned page or mc or whatever, but a valid kernel address). But it's exactly the kind of thing that we currently don't do even for the bog-standard "copy_to_user()", because we share all the code because we're lazy. And as DavidL pointed out - if you ever have "iomem" as a source or destination, you need yet another case. Not because they can take another kind of fault (although on some platforms you have the machine checks for that too), but because they have *very* different performance profiles (and the ERMS "rep movsb" sucks baby donkeys through a straw). Linus _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org