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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55067C433EF for ; Wed, 20 Oct 2021 22:44:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D2086128E for ; Wed, 20 Oct 2021 22:44:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231180AbhJTWqg (ORCPT ); Wed, 20 Oct 2021 18:46:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:39478 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbhJTWqf (ORCPT ); Wed, 20 Oct 2021 18:46:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5CBE26115B; Wed, 20 Oct 2021 22:44:18 +0000 (UTC) Date: Wed, 20 Oct 2021 23:44:15 +0100 From: Catalin Marinas To: Linus Torvalds Cc: Andreas Gruenbacher , Paul Mackerras , Alexander Viro , Christoph Hellwig , "Darrick J. Wong" , Jan Kara , Matthew Wilcox , cluster-devel , linux-fsdevel , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com, kvm-ppc@vger.kernel.org, linux-btrfs Subject: Re: [PATCH v8 00/17] gfs2: Fix mmap + page fault deadlocks Message-ID: References: <20211019134204.3382645-1-agruenba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Oct 20, 2021 at 10:11:19AM -1000, Linus Torvalds wrote: > On Wed, Oct 20, 2021 at 6:37 AM Catalin Marinas wrote: > > The atomic "add zero" trick isn't that simple for MTE since the arm64 > > atomic or exclusive instructions run with kernel privileges and > > therefore with the kernel tag checking mode. > > Are there any instructions that are useful for "probe_user_write()" > kind of thing? If it's on a user address, the only single-instruction that works with MTE is STTR (as in put_user()) but that's destructive. Other "add zero" constructs require some potentially expensive system register accesses just to set the tag checking mode of the current task. A probe_user_write() on the kernel linear address involves reading the tag from memory and comparing it with the tag in the user pointer. In addition, it needs to take into account the current task's tag checking mode and the vma vm_flags. We should have most of the information in the gup code. > Although at least for MTE, I think the solution was to do a regular > read, and that checks the tag, and then we could use the gup machinery > for the writability checks. Yes, for MTE this should work. For CHERI I think an "add zero" would do the trick (it should have atomics that work on capabilities directly). However, with MTE doing both get_user() every 16 bytes and gup can get pretty expensive. The problematic code is fault_in_safe_writable() in this series. I can give this 16-byte probing in gup a try (on top of -next) but IMHO we unnecessarily overload the fault_in_*() logic with something the kernel cannot fix up. The only reason we do it is so that we get an error code and bail out of a loop but the uaccess routines could be extended to report the fault type instead. It looks like we pretty much duplicate the uaccess in the fault_in_*() functions (four accesses per cache line). -- Catalin