Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5364857ybv; Mon, 17 Feb 2020 18:27:27 -0800 (PST) X-Google-Smtp-Source: APXvYqyeehJSFGbDyQEzdXhFN7z+Y7Vvyb2p8UxGlU2r7O+mDy/dtlds1casJ7ZovfTS7KUvC93U X-Received: by 2002:a9d:6446:: with SMTP id m6mr13716396otl.122.1581992847081; Mon, 17 Feb 2020 18:27:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581992847; cv=none; d=google.com; s=arc-20160816; b=tRue7YN++z9G39kSf4rMI+linUOuCZrHV1NSCynPVAD2BV8SRDTozxnebdMJaTU8WQ TVF66q4F0Gv8X6SP472RSC+H4sfVHDDJcVA6SHiAl8j2ob9oW3zcRhK7U8LpxoU5ZPwJ zraIj6G5BKrVSG6p5of8zKjiEoDKCyIMJUsjA3TnB0311RHLnONprUhw0153PfZe5Hxr oCBNs5kBSPu2kz/LuQ+EeD4TMwOhoMcORbvobGQyHrisgowxZg4h7mvMUcFqZXkFxB8a g8LeH1p7VKZsPja3G3sk94EcZmXW0L3GXBElY5yBuePsd6zev4T2uoCwCNi0+n7Aek1I ipaQ== 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:dkim-signature; bh=s+rxSpvQ1vwDbeuy8s6SOqVEIqbGp9AfMoz3S66N13U=; b=MNkOA41eLDn++wJSfPQpuMIa3m1nOn0k0+d5KmI62cmU50EgYJWB5VA4+Fqp+C6kma Uigd2WB8kXTeh5hjyfwUf45g0HutMAGwqvKqoR4kGO31bFADG4jUsR+1rXB7BC+ncon/ azMEqUf0r7P3LkKZCremne3MWWVPtXq9+tTy+AAvoDMrpQli/IAsWNc/pIpYr7SosPcd XCFj5FO+WI5kjZeLYfxI1BbwPEUeXHhYQgTJtFBlxfRLCToicWmy2mq7z/0Icq3EaC+p c3z+1uO03SZY6Q/TOrZXZ0XrGFp+OHoPelXzv7kTGu4xleeJvPaUogQALr1UNRAyUUz4 xUlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ao33AH+3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l5si1044545otf.37.2020.02.17.18.27.11; Mon, 17 Feb 2020 18:27:27 -0800 (PST) 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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ao33AH+3; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726276AbgBRC1D (ORCPT + 99 others); Mon, 17 Feb 2020 21:27:03 -0500 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:35438 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726212AbgBRC1D (ORCPT ); Mon, 17 Feb 2020 21:27:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581992822; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=s+rxSpvQ1vwDbeuy8s6SOqVEIqbGp9AfMoz3S66N13U=; b=Ao33AH+3k/3xXjH1GzjqfNC+107fPX7FWuTqwitvgwnT0Hox+sHQigxANc8jh4jFqaK0qn bLnQ6YwMwWQ24Bg6wGnt1PUsFSXp7hVWpr7Wf8MlkTJGSjMZGjuDy65gPGAIem0QGNopXJ hOC+dzoHRGFNTxNCxGMzvgKEeS0irLI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-372-_n4gutFuPVm5i0c0jyjSWg-1; Mon, 17 Feb 2020 21:27:01 -0500 X-MC-Unique: _n4gutFuPVm5i0c0jyjSWg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C9E9118A5500; Tue, 18 Feb 2020 02:26:59 +0000 (UTC) Received: from mail (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EF9B360BE1; Tue, 18 Feb 2020 02:26:56 +0000 (UTC) Date: Mon, 17 Feb 2020 21:26:55 -0500 From: Andrea Arcangeli To: Brian Geffon Cc: Peter Xu , Andrew Morton , linux-mm , LKML , Mike Rapoport , Sonny Rao , "Kirill A . Shutemov" Subject: Re: [RFC PATCH] userfaultfd: Address race after fault. Message-ID: <20200218022655.GE29216@redhat.com> References: <20200214225849.108108-1-bgeffon@google.com> <20200214231954.GA29849@redhat.com> <20200217160739.GB1309280@xz-x1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.13.1 (2019-12-14) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 17, 2020 at 07:50:19PM -0600, Brian Geffon wrote: > But in the meantime, if the plan of record will be to always allow > retrying then shouldn't the block I mailed a patch on be removed > regardless because do_user_addr_fault always starts with > FAULT_FLAG_ALLOW_RETRY and we shouldn't ever land there without it in > the future and allows userfaultfd to retry? It might hide the limitation but only if the page fault originated in userland (Android's case), but that's not something userfault users should depend on. Userfaults (unlike sigsegv trapping) are meant to be reliable and transparent to all user and kernel accesses alike. It is also is unclear how long Android will be forced to keep doing bounce buffers copies in RAM before considering passing any memory to kernel syscalls. For all other users where the kernel access may be the one triggering the fault the patch will remove a debug aid and the kernel fault would then fail by hitting on the below: /* Not returning to user mode? Handle exceptions or die: */ no_context(regs, hw_error_code, address, SIGBUS, BUS_ADRERR); There may be more side effects in other archs I didn't evaluate because there's no other place where the common code can return VM_FAULT_RETRY despite the arch code explicitly told the common code it can't do that (by not setting FAULT_FLAG_ALLOW_RETRY) so it doesn't look very safe and it doesn't seem a generic enough solution to the problem. That dump_stack() helped a lot to identify those kernel outliers that erroneously use get_user_pages instead of the gup_locked/unlocked variant that are uffd-capable. Thanks, Andrea