Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1680161pxb; Fri, 27 Aug 2021 14:58:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0D4Nx846HeZeAl1KyrjfhYEEls5V0/QLWSQALTY/v3Yib/CeaP6CuPB58OtOj3nh25M4p X-Received: by 2002:a02:85c2:: with SMTP id d60mr8564204jai.85.1630101504165; Fri, 27 Aug 2021 14:58:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630101504; cv=none; d=google.com; s=arc-20160816; b=vIousRZD86aTAw0hHQU5c4KT5vp8M3GTelDLg3OwDVhVJW3iRWS7NQDC3urw6OUDwo G5ckZ3Uy3Ib2Y4mTN/JQJnmLl8cnlows8qwfVFjWFWfNBCa5uTJ9g0d1ctwPmDbpTrsl c7vsG+QWXEqCAbk/ZLKTEIUqX3mJxTz1FX8v+Lq/68/uqmFRRpqHcnho3YWm4QTso1jN bTm8vEr/rrYOJtsYXBYzNEkk4LG6oYuhmiXEteNOVb1lfH+y2MbeqfIoVXPXNxkEyRor jMVj8kl77hJOU9tuZcxm4RxHnqFfh8RCoNmUIZOR7oDvKHWdfvQsXCUcfifJBQrcmjx8 BMew== 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=iHaS4dwileiPzOWmOARAZ1BmWbRbfNdDgqrNuhHGkDc=; b=FzmmCy9dj1NOmvidYq5RHaFsV89pGuevMSXYhhEgpuOE3fbAwzRBwGTGXLEnlxVGFt 8qjTKjMSIGKeywmYEzBoZ7FdHnaKVGx7rgvxIt0eFtQcTMHPZ2OQ9ILxAxIfiV2uPtZi bcz0sQf4mWEgnW1+GWRUsHdeztBGHYgOz2Gk52te7U8C+++KggOnZ2t52GaD9BFxta2F PfI8sgIdKcAb8A+/Fu+0pBFCBm/QN7wDo99Be1v+K7BKzv4AHt+0o5cy0N9m3YMn7L9a iJ+kcg4wJDPR+Cb78Uj5lV+4ZdOGn5y/3NwQVFh805esTEGCefJ3wf3nI5ukqT6Quo/V mhzQ== 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 az16si7536258jab.108.2021.08.27.14.58.12; Fri, 27 Aug 2021 14:58:24 -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 S232029AbhH0V6J (ORCPT + 99 others); Fri, 27 Aug 2021 17:58:09 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:45154 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231906AbhH0V6J (ORCPT ); Fri, 27 Aug 2021 17:58:09 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mJjqY-00Gbep-Jz; Fri, 27 Aug 2021 21:57:10 +0000 Date: Fri, 27 Aug 2021 21:57:10 +0000 From: Al Viro To: Linus Torvalds Cc: Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com Subject: Re: [PATCH v7 05/19] iov_iter: Introduce fault_in_iov_iter_writeable Message-ID: References: <20210827164926.1726765-1-agruenba@redhat.com> <20210827164926.1726765-6-agruenba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 27, 2021 at 09:48:55PM +0000, Al Viro wrote: > [btrfs]search_ioctl() > Broken with memory poisoning, for either variant of semantics. Same for > arm64 sub-page permission differences, I think. > So we have 3 callers where we want all-or-nothing semantics - two in > arch/x86/kernel/fpu/signal.c and one in btrfs. HWPOISON will be a problem > for all 3, AFAICS... > > IOW, it looks like we have two different things mixed here - one that wants > to try and fault stuff in, with callers caring only about having _something_ > faulted in (most of the users) and one that wants to make sure we *can* do > stores or loads on each byte in the affected area. > > Just accessing a byte in each page really won't suffice for the second kind. > Neither will g-u-p use, unless we teach it about HWPOISON and other fun > beasts... Looks like we want that thing to be a separate primitive; for > btrfs I'd probably replace fault_in_pages_writeable() with clear_user() > as a quick fix for now... > > Comments? Wait a sec... Wasn't HWPOISON a per-page thing? arm64 definitely does have smaller-than-page areas with different permissions, so btrfs search_ioctl() has a problem there, but arch/x86/kernel/fpu/signal.c doesn't have to deal with that... Sigh... I really need more coffee...