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 6225BC28CBC for ; Wed, 6 May 2020 17:44:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 24F322080D for ; Wed, 6 May 2020 17:44:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="QfIhp8bn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24F322080D 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 61FB88E0005; Wed, 6 May 2020 13:44:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D0308E0003; Wed, 6 May 2020 13:44:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BF388E0005; Wed, 6 May 2020 13:44:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0138.hostedemail.com [216.40.44.138]) by kanga.kvack.org (Postfix) with ESMTP id 2FE7D8E0003 for ; Wed, 6 May 2020 13:44:37 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DD5AC249B for ; Wed, 6 May 2020 17:44:36 +0000 (UTC) X-FDA: 76787018952.28.skin25_b2398d246c17 X-HE-Tag: skin25_b2398d246c17 X-Filterd-Recvd-Size: 5623 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 May 2020 17:44:36 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id f18so3275359lja.13 for ; Wed, 06 May 2020 10:44:36 -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=uNt2KHwB8PiMSyUUcvWbb3LmQf/yl99wmVRwAMCe6Sw=; b=QfIhp8bnkHziXy45j6AZQvnQuPZVCBRmkYNh4Qk1yBWY/AbDih3c468GHPPi0NxUWC +RsQItHsCm4TW5y+JMWQZhOFGKrkw/OMHO8k0Ff3ChO35z8KVI8vHTXhfxO6dpDN2zOT R/3GLd58rAk/zgyKNOtvPikt/JEPwM8VJVw+4= 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=uNt2KHwB8PiMSyUUcvWbb3LmQf/yl99wmVRwAMCe6Sw=; b=hNUqQ1lPpeqj5Z2RTe4Ei4WSi59OzJvEv1STBU9kDwuJNYCyO3Ne2JP9wOz1vlSfkv rB5PsgxTtJNF9N21gJjI065Txh1YMjl3T5uki2FdYBzDQy2ypk9p46yDlL0rHyYzCtz5 lT516J0olPDgZzPDjOtcozaqd6dxOpSNHg5FgqCWJnLSoqZpmfmz5IWHThHcUbSV/erE cvFnDMgPuNMaEF6ag2CgYRvwo83KeK0C1Y6iN4TimI3IVS/P2oZR8dZhMj1kmk5YFK6M aUwaw766XUxyFonLqNTeR6aGO5mDAIROg1einHhQw5ZsFtZYfpdN6FHQpEhAfJziRlny rpBw== X-Gm-Message-State: AGi0Pua9LNkGvb2ObvQ7185byM1hdiy+udXpg5zpClwkRZCQqgnPLqUk fXI2j8YIMFQSw8WgjKeiBPr5FCv8Gw8= X-Google-Smtp-Source: APiQypIL4m0hlkCaVRf3XQFPfLoTkIjY2dqvuPJ1G3+dNMakeWAvBfIvisPo9euUuAgAZC/xDbjKaA== X-Received: by 2002:a2e:8087:: with SMTP id i7mr5288148ljg.99.1588787072983; Wed, 06 May 2020 10:44:32 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id b1sm2155897lfb.22.2020.05.06.10.44.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 10:44:32 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id s9so2093566lfp.1 for ; Wed, 06 May 2020 10:44:31 -0700 (PDT) X-Received: by 2002:a19:6e4e:: with SMTP id q14mr5836440lfk.192.1588787071388; Wed, 06 May 2020 10:44:31 -0700 (PDT) MIME-Version: 1.0 References: <20200506062223.30032-1-hch@lst.de> <20200506062223.30032-9-hch@lst.de> In-Reply-To: <20200506062223.30032-9-hch@lst.de> From: Linus Torvalds Date: Wed, 6 May 2020 10:44:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 08/15] maccess: rename strnlen_unsafe_user to strnlen_user_unsafe To: Christoph Hellwig Cc: "the arch/x86 maintainers" , Alexei Starovoitov , Daniel Borkmann , Masami Hiramatsu , Andrew Morton , linux-parisc@vger.kernel.org, linux-um , Netdev , bpf@vger.kernel.org, Linux-MM , Linux Kernel Mailing List 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 Tue, May 5, 2020 at 11:22 PM Christoph Hellwig wrote: > > This matches the convention of always having _unsafe as a suffix, as > well as match the naming of strncpy_from_user_unsafe. Hmm. While renaming them, can we perhaps clarify what the rules are? We now have two different kinds of "unsafe". We have the "unsafe_get_user()" kind of unsafe: the user pointer itself is unsafe because it isn't checked, and you need to use a "user_access_begin()" to verify. It's the new form of "__get_user()". And then we have the strncpy_from_user_unsafe(), which is really more like the "probe_kernel_read()" kind of funtion, in that it's about the context, and not faulting. Honestly, I don't like the "unsafe" in the second case, because there's nothing "unsafe" about the function. It's used in odd contexts. I guess to some degree those are "unsafe" contexts, but I think it might be better to clarify. So while I think using a consistent convention is good, and it's true that there is a difference in the convention between the two cases ("unsafe" at the beginning vs end), one of them is actually about the safety and security of the operation (and we have automated logic these days to verify it on x86), the other has nothing to do with "safety", really. Would it be better to standardize around a "probe_xyz()" naming? Or perhaps a "xyz_nofault()" naming? I'm not a huge fan of the "probe" naming, but it sure is descriptive, which is a really good thing. Another option would be to make it explicitly about _what_ is "unsafe", ie that it's about not having a process context that can be faulted in. But "xyz_unsafe_context()" is much too verbose. "xyz_noctx()" might work. I realize this is nit-picky, and I think the patch series as-is is already an improvement, but I do think our naming in this area is really quite bad. The fact that we have "probe_kernel_read()" but then "strncpy_from_user_unsafe()" for the _same_ conceptual difference really tells me how inconsistent the naming for these kinds of "we can't take page faults" is. No? Linus