Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp898986ybk; Wed, 13 May 2020 16:30:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBq0sgJu3nftkh16Yh+A+gO5fmyeskUfR6x24l5XxENpMSUmGhjoCLOnN9oEPIbATEK4wP X-Received: by 2002:aa7:dc48:: with SMTP id g8mr1745454edu.33.1589412602599; Wed, 13 May 2020 16:30:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589412602; cv=none; d=google.com; s=arc-20160816; b=r3SQN4M/daIzZdHgbrfpHu5K8efJ+3lpd5ywLTl5ckloGbLEFVv6YBVO/SKc2uNI0X udA55cRLgWlcuBHEUq/+L7PjXZjvHtwH8y893q+JwYpuclKc6EKPAKoOvDCeAneE2bfx zVf2HOxd10S8JCIlSAV1IgQvu7xJnbXqLLLm/NYgFr8xDYJKR38MTgnSLrzDxgtqrBz3 2Qk7TI+aumJaLe/T+nfee8z8cqqYb8KKiq7yGksHTmDyTXvssdmbowBrygxJ4G1RhP9F NStlfM3Hy9J/0n8Cg/mq4rgGlNtaPRTTTCu/UxqF59MdYZndgn2lHK45HSsNCRLzuHkt cySA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2LXL6+WmLTDMSzxW3fVSX/99Z+TWjBQ1Y5vzgf46yLU=; b=KJMsFRt9rNWNmjq3E7C5koHKtK+NIh7s3mRa/mPl4PRwG81Rja91eu90qkb4ee3S+s RglD7UXoLHjpl4+NVOFFfXgB5W5tzO72sJFv/ZSjmwrDGzNngDPXaxo1ik/gfipcODBF dWd9mlWo9sL7pEROHuqANYbZXgkDO3aUzKTL9DNinrPFCmuHiEd8mNolOMGu3JmuFpcA iYyQVrp1nxaOM8nHrTqS6prR11kCbufLPe/fGKVDoAY3z9144U/Dko5W4bNvXyjXtqew cshffTmYIK6f4a4ylVGqLjiMw1elV19vu8Gxr+/ygihBWwvmZGfGm08fwEAMhBtautjB HYvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n8si646160edq.213.2020.05.13.16.29.40; Wed, 13 May 2020 16:30:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732666AbgEMX2Z (ORCPT + 99 others); Wed, 13 May 2020 19:28:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36218 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1732573AbgEMX2Y (ORCPT ); Wed, 13 May 2020 19:28:24 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64A6CC061A0C; Wed, 13 May 2020 16:28:24 -0700 (PDT) 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> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.