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=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 AD087C433DF for ; Wed, 13 May 2020 23:28:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 99BF2205ED for ; Wed, 13 May 2020 23:28:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99BF2205ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BE5CC900138; Wed, 13 May 2020 19:28:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B95BB900022; Wed, 13 May 2020 19:28:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD282900138; Wed, 13 May 2020 19:28:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 93DD6900022 for ; Wed, 13 May 2020 19:28:26 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4D87A8248D52 for ; Wed, 13 May 2020 23:28:26 +0000 (UTC) X-FDA: 76813287012.06.field60_49a19e4d19b42 X-HE-Tag: field60_49a19e4d19b42 X-Filterd-Recvd-Size: 2429 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 13 May 2020 23:28:25 +0000 (UTC) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZ0nQ-007rFB-Ju; Wed, 13 May 2020 23:28:16 +0000 Date: Thu, 14 May 2020 00:28:16 +0100 From: Al Viro To: Daniel Borkmann Cc: Christoph Hellwig , Linus Torvalds , the arch/x86 maintainers , Alexei Starovoitov , Masami Hiramatsu , Andrew Morton , linux-parisc@vger.kernel.org, linux-um , Netdev , bpf@vger.kernel.org, Linux-MM , Linux Kernel Mailing List Subject: Re: [PATCH 11/18] maccess: remove strncpy_from_unsafe Message-ID: <20200513232816.GZ23230@ZenIV.linux.org.uk> References: <20200513160038.2482415-1-hch@lst.de> <20200513160038.2482415-12-hch@lst.de> <20200513192804.GA30751@lst.de> <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c1a7066-b269-9695-b94a-bb5f4f20ebd8@iogearbox.net> 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, May 14, 2020 at 12:36:28AM +0200, Daniel Borkmann wrote: > > So on say s390 TASK_SIZE_USUALLy is (-PAGE_SIZE), which means we'd alway > > try the user copy first, which seems odd. > > > > I'd really like to here from the bpf folks what the expected use case > > is here, and if the typical argument is kernel or user memory. > > It's used for both. Given this is enabled on pretty much all program types, my > assumption would be that usage is still more often on kernel memory than user one. Then it needs an argument telling it which one to use. Look at sparc64. Or s390. Or parisc. Et sodding cetera. The underlying model is that the kernel lives in a separate address space. Yes, on x86 it's actually sharing the page tables with userland, but that's not universal. The same address can be both a valid userland one _and_ a valid kernel one. You need to tell which one do you want.