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,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 D61E7C47256 for ; Wed, 6 May 2020 17:58:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9BB6520B1F for ; Wed, 6 May 2020 17:58:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="HgJKLXT1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9BB6520B1F 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 32D7F8E0006; Wed, 6 May 2020 13:58:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DE708E0003; Wed, 6 May 2020 13:58:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F3CA8E0006; Wed, 6 May 2020 13:58:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 057F58E0003 for ; Wed, 6 May 2020 13:58:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B4A91BEE7 for ; Wed, 6 May 2020 17:58:17 +0000 (UTC) X-FDA: 76787053434.01.bird58_8294401a23e0b X-HE-Tag: bird58_8294401a23e0b X-Filterd-Recvd-Size: 4812 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 May 2020 17:58:17 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id l19so3338593lje.10 for ; Wed, 06 May 2020 10:58:17 -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=amhqtC0jx3Soa4PMXxAnnhfkbBJzW3RmXIKW7xjvTm8=; b=HgJKLXT1DdNyq51LO7Yajpy+kFP02OcEtgqoKUtFS1yGSN45VqntoJwH+X2ojFI5Yz VanVze+sYnLUdhLxZWaCjc0lht8OTs/pF6rfb8vQjJNFuC8VJ1vNt8Biip5j85VsAxzZ GcH0M+IVfjrqrmfFOzxxtIOPztNPNJHUO70hQ= 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=amhqtC0jx3Soa4PMXxAnnhfkbBJzW3RmXIKW7xjvTm8=; b=j/uWHhE9vJpcGryPIUH9s/3NQxWqaYUDYv7x7i/4IPHoPK/A5rygK0NFd8VeY1gGjm 1yoi0DDiJJh6fQUPNuFmtllME3BLkOaBcaybWhp45EldGXLk3f6cN8WnV0KNCR+l9AfH V1Y8JQzCBExhFJd3NO9OoPoPqk7A9jzRvcMwjOuffp0WvK+Hc1x9JnOTpUp82q2F+lPn mM847b5PuJW1CQoDyv01QyG0buEj7IbeGBS26oWTWHGtl2cHZ+S23+z11xeS7cOj/vNJ yrCXjn74d6FQ1SuP2XjCiZLn9BhhWwTEJ8Bf85GNKhtzJnb13zweD9HvuULt5sVPlPzk va0w== X-Gm-Message-State: AGi0PuYLSg5/ELE/k1n9gov7c0aiFgnhqwoQwqsegQw2fNwYyY45K65Z p1gIVLhDGylKBcudKMUAVeCgLJI6XJ4= X-Google-Smtp-Source: APiQypJmgeNbvOXx6+t7d0SlV5Ib1jnroxDK6lcS4Eo7hTlD7/ac1HzuGDoyFUpP9u2Q2J5tcEuoIA== X-Received: by 2002:a2e:3209:: with SMTP id y9mr5486144ljy.154.1588787895284; Wed, 06 May 2020 10:58:15 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id x29sm2034080lfn.46.2020.05.06.10.58.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2020 10:58:14 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id u4so2104587lfm.7 for ; Wed, 06 May 2020 10:58:14 -0700 (PDT) X-Received: by 2002:ac2:418b:: with SMTP id z11mr6180281lfh.30.1588787893824; Wed, 06 May 2020 10:58:13 -0700 (PDT) MIME-Version: 1.0 References: <20200506062223.30032-1-hch@lst.de> <20200506062223.30032-9-hch@lst.de> <20200506174747.GA7549@lst.de> In-Reply-To: <20200506174747.GA7549@lst.de> From: Linus Torvalds Date: Wed, 6 May 2020 10:57:57 -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 Wed, May 6, 2020 at 10:47 AM Christoph Hellwig wrote: > > > 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? > > True. If we wanted to do _nofaul, what would the basic read/write > versions be? I think "copy_to/from_kernel_nofault()" might be the most consistent model, if we are looking to be kind of consistent with the user access functions.. Unless we want to make "memcpy" be part of the name, but I think that we really want to have that 'from/to' part anyway, which forces the "copy_from/to_xyz" kind of naming. I dunno. I don't want to be too nit-picky, I just would like us to be more consistent and have the naming say what's up without having multiple different versions of the same thing. We've had this same discussion with the nvdimm case, but there the issues are somewhat different (faulting is ok on user addresses - you can sleep - but kernel address faults aren't about the _context_ any more, they are about the data not being safe to access any more) Anybody else? Linus