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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7F81C433F5 for ; Wed, 24 Nov 2021 22:33:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lQW6A+JHLJ3NeFCyk/Vb1LBCxMRxLZv2AcOvEbKDXBg=; b=2nzOqNAvFqcE/v qMkz38r8sxF75p+kmDk7c5W8fr1O7WPKY9ZoxHjsCknvmoMKvSAEkHM9PrIl4UKypRYNKOxRV27mE 2uGCeHCk4wr32AmATjT9wSkvuFVtF0qC/8aAhknjzaS3k0+vlEXSd84lmQJiFbNrIrFOt/GIpr7Za G1zhu+TxPbUdYsRbGBN/uUGW4n7f2PMuguQAw7ZRnwM8TtiyAX5uKYHln7oIhx9Ni65+fs7nTZH7x duuRz3XIQYb13B7FrrA+X+248UhudkWl/PZLo4/F/1kA16KJupWxqmvsooM7Mc7/E5H4YcwkAQY5C NFM+UWVZvjljUb8bPiCg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mq0o7-005xnw-0l; Wed, 24 Nov 2021 22:32:03 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mq0o2-005xmw-GQ for linux-arm-kernel@lists.infradead.org; Wed, 24 Nov 2021 22:31:59 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 156826108B; Wed, 24 Nov 2021 22:31:55 +0000 (UTC) Date: Wed, 24 Nov 2021 22:31:52 +0000 From: Catalin Marinas To: Andrew Morton Cc: Linus Torvalds , Josef Bacik , David Sterba , Andreas Gruenbacher , Al Viro , Will Deacon , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-btrfs@vger.kernel.org Subject: Re: [PATCH 0/3] Avoid live-lock in fault-in+uaccess loops with sub-page faults Message-ID: References: <20211124192024.2408218-1-catalin.marinas@arm.com> <20211124133600.94f0b9a6c611ee663c9a8d6d@linux-foundation.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211124133600.94f0b9a6c611ee663c9a8d6d@linux-foundation.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211124_143158_610875_BC201EB7 X-CRM114-Status: GOOD ( 17.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 24, 2021 at 01:36:00PM -0800, Andrew Morton wrote: > On Wed, 24 Nov 2021 19:20:21 +0000 Catalin Marinas wrote: > > There are a few places in the filesystem layer where a uaccess is > > performed in a loop with page faults disabled, together with a > > fault_in_*() call to pre-fault the pages. On architectures like arm64 > > with MTE (memory tagging extensions) or SPARC ADI, even if the > > fault_in_*() succeeded, the uaccess can still fault indefinitely. > > > > In general this is not an issue since such code restarts the > > fault_in_*() from where the uaccess failed, therefore guaranteeing > > forward progress. The btrfs search_ioctl(), however, rewinds the > > fault_in_*() position and it can live-lock. This was reported by Al > > here: > > Btrfs livelock on some-of-arm sounds fairly serious. Luckily not much btrfs use on Arm mobile parts. > Should we > backport this? If so, a48b73eca4ce ("btrfs: fix potential deadlock in > the search ioctl") appears to be a suitable Fixes: target? This should be a suitable target together with a Cc stable to v4.4 (that's what the above commit had). Of course, the other two patches need backporting as well and they won't apply cleanly. Once we agreed on the fix, I'm happy to do the backports and send them all to stable. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel