Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4598664pxb; Tue, 31 Aug 2021 08:50:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtHCW5HEC8fxZji1M79N2hPADVLOuhly7Yx7vi3vO6ai5HW5JCmsOSy1bj0C0Pk4IN8f2D X-Received: by 2002:a17:907:1108:: with SMTP id qu8mr32337763ejb.58.1630425015292; Tue, 31 Aug 2021 08:50:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630425015; cv=none; d=google.com; s=arc-20160816; b=AVVxIMrgDdEZqHi2AyUbv/srv1W67XcYSUlXKgK+xvXqSP/jN4kd7wTSjFqeOS4zMf fS9H7PlW7UGXiLEx4hWHVu+KJXK1yQNAnl+IXIf2YShx7bflk7+mq8PPnBAmtbTIlYxC HmwXSa/F50OIeY7FO24yPTGSlGxfMIJwTcSheJcTkcllk4rbzYzmuH0OoL7olA61JBNl mPwIWckYr+MWrZa1iz+a01vBr17T73iWgNyxg+r5Vg9FZ5sKw3UNGEXr4ex0Z2jix726 aQ1xzxpbC6GtkYWr2TZVFPW3TxxzRO0XQdBya6KkElELFo9vQPyuUeHBAbQ7mAWK8vqK S3ew== 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=o/titx8JJTHNk9eB1TD9c7Ol1h4E7gg9EwyF3Sw+HMg=; b=vcHlraTJKEPFK1k94Yv+acJGQO0r97qP2nLvS94+kcqLzXSP2IMynICgc32S7YqCf5 fAVXqje7HwaAUd79FCbxhlMzhtKh19G0thF7CBG5FCsHCQN1QRMM/2NLf8iyxZmUyYNq mrYErTBrklsfi/58QyI13seUDTJdosnGS04nZyg2nQcyxv8ytAEHsFPAv2lNf3dlPjP9 lqL2VBBTV3hpcnBrPUIregNG2dc666HZvT0FJpjoSN1zDAhjh6j1xKVKwcdYLoPQksY7 Yt5kSaqiwJG4hWKDbJ5qJkrzDh/deySPT3TZzz/MRsoAn23BiX4hgc9peibhmxI8iXI+ kAYg== 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 g1si9585133edy.542.2021.08.31.08.49.51; Tue, 31 Aug 2021 08:50:15 -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 S239446AbhHaPeX (ORCPT + 99 others); Tue, 31 Aug 2021 11:34:23 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:33112 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234068AbhHaPeW (ORCPT ); Tue, 31 Aug 2021 11:34:22 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mL5h3-0000RV-T4; Tue, 31 Aug 2021 15:28:58 +0000 Date: Tue, 31 Aug 2021 15:28:57 +0000 From: Al Viro To: Catalin Marinas Cc: Linus Torvalds , Andreas Gruenbacher , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , "ocfs2-devel@oss.oracle.com" , Josef Bacik , Will Deacon Subject: Re: [RFC][arm64] possible infinite loop in btrfs search_ioctl() 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 Tue, Aug 31, 2021 at 02:54:50PM +0100, Catalin Marinas wrote: > An arm64-specific workaround would be for pagefault_disable() to disable > tag checking. It's a pretty big hammer, weakening the out of bounds > access detection of MTE. My preference would be a fix in the btrfs code. > > A btrfs option would be for copy_to_sk() to return an indication of > where the fault occurred and get fault_in_pages_writeable() to check > that location, even if the copying would restart from an earlier offset > (this requires open-coding copy_to_user_nofault()). An attempt below, > untested and does not cover read_extent_buffer_to_user_nofault(): Umm... There's another copy_to_user_nofault() call in the same function (same story, AFAICS). Can't say I'm fond of their ABI, but then I guess it could've been worse - iterating over btree, running a user-supplied chunk of INTERCAL over it, with all details of internal representation cast in stone by that exposure...