Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp36352ybp; Tue, 8 Oct 2019 13:36:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqwNWnlkq+7yTe78m6RxMAzwgiBnAqBIZ5OHHpNjPT4RO/GV0evhJZ/JXgEYN9wBSi4HI7JX X-Received: by 2002:a17:906:d154:: with SMTP id br20mr30417599ejb.79.1570567005000; Tue, 08 Oct 2019 13:36:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570567004; cv=none; d=google.com; s=arc-20160816; b=IzX64Rl4XwuC12DLiLVwiYmZzFe6P4/u8BrANyP2C73qAevktz/7BeCAighxJFGJr4 WdoSEE3AjnwaycG3ee4O0Rjt8bhZ4LZCCoM3KD2Ol+eAM54vu/vm+qzxoDhX1w9+hdQI mCTlby8kt5HJS7FWoliNsocPHIUbaV/+SGXHvGBtOaCS7z+Z43nHmkvO7x4rhGXrukB7 8QsQt5wl2FOu14xwlufdDTufb4Pnq1mhjv2qf9FcND3udHPKZvksyxZKPTMOR318MT3O nG8hm6KObPyp7UH1T4PrtFY5W5dddPBfy89NR8Fz2CqdhF+AQe3C6DcBNyjdFc+ecba8 SRhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=P2xOX+iERMEZOUdN0V2RizqkBFrcbBJu2TJZFBxPzNc=; b=edhLJbJ9hdcAjYyzroPRNVvFdmmMmf8uqwqClccKOw91RqUDR0d6FeAMQhPtuRUP2b /8KNyly7B7he1RTccJB7M2OfSK0onIGq68TDUYPaZs77lX+5rKjjRbd3arJNj3tFNghE ilcQ+67nLygxNA7bxFblxgMedLv/hPuAjiyS/9t8jo569OEwsF4OYTQv95DN+X8Gt3KR lgl84/C06yHJrHpJMHHW7v8AxCBqWaOlDk2j2GsLYU4o5GDgYiR844PNS3DBUuC0PaV/ RO17AvdK3LY54G3R6oLircGegzCQkXuBE3JV3U40KhaemjVGwVkK1AWrBvFcwcl++f8/ U1dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id gz11si9714226ejb.341.2019.10.08.13.36.12; Tue, 08 Oct 2019 13:36:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730923AbfJHUey (ORCPT + 99 others); Tue, 8 Oct 2019 16:34:54 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:34624 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727835AbfJHUey (ORCPT ); Tue, 8 Oct 2019 16:34:54 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.2 #3 (Red Hat Linux)) id 1iHwC4-0002Mx-0p; Tue, 08 Oct 2019 20:34:52 +0000 Date: Tue, 8 Oct 2019 21:34:51 +0100 From: Al Viro To: Linus Torvalds Cc: Guenter Roeck , Linux Kernel Mailing List , linux-fsdevel Subject: Re: [PATCH] Convert filldir[64]() from __put_user() to unsafe_put_user() Message-ID: <20191008203451.GX26530@ZenIV.linux.org.uk> References: <5f06c138-d59a-d811-c886-9e73ce51924c@roeck-us.net> <20191007012437.GK26530@ZenIV.linux.org.uk> <20191007025046.GL26530@ZenIV.linux.org.uk> <20191008195858.GV26530@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191008195858.GV26530@ZenIV.linux.org.uk> User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 08, 2019 at 08:58:58PM +0100, Al Viro wrote: > The difference is, they have separate "for read" and "for write" primitives > and they want the range in their user_access_end() analogue. Separating > the read and write isn't a problem for callers (we want them close to > the actual memory accesses). Passing the range to user_access_end() just > might be tolerable, unless it makes you throw up... NOTE: I'm *NOT* suggesting to bring back the VERIFY_READ/VERIFY_WRITE argument to access_ok(). We'd gotten rid of it, and for a very good reason (and decades overdue). The main difference between access_ok() and user_access_begin() is that the latter is right next to actual memory access, with user_access_end() on the other side, also very close. And most of those guys would be concentrated in a few functions, where we bloody well know which direction we are copying. Even if we try and map ppc allow_..._to_user() on user_access_begin(), access_ok() remains as it is (and I hope we'll get rid of the majority of its caller in process).