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 X-Spam-Level: X-Spam-Status: No, score=-13.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3349C34022 for ; Tue, 18 Feb 2020 01:50:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71BB6206D5 for ; Tue, 18 Feb 2020 01:50:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="s9+lDh/5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71BB6206D5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ECB936B0003; Mon, 17 Feb 2020 20:50:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7C306B0006; Mon, 17 Feb 2020 20:50:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6A126B0007; Mon, 17 Feb 2020 20:50:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id BAA856B0003 for ; Mon, 17 Feb 2020 20:50:53 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 770A9180AD81A for ; Tue, 18 Feb 2020 01:50:53 +0000 (UTC) X-FDA: 76501569186.28.rock73_5f03eca10de23 X-HE-Tag: rock73_5f03eca10de23 X-Filterd-Recvd-Size: 5756 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Feb 2020 01:50:52 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id g19so22868948eds.11 for ; Mon, 17 Feb 2020 17:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zPJTmL7M/KQjilpjiQvSnCs28pkECQ3GbYH85X9jLmk=; b=s9+lDh/5BUI0pym1FldGomHkvz5qiNZwA0r+zHjhzGda5b6rbhrwtE4krO8GkFdagq /WCOcB6Q65T98y4ejsfeXNuYEz+0Jx2qQBEcFEcwzZJenBdwzDoInleNQd/PgTGIb9Sa ETrxr2ZZbvjfUfjitId2ryCuUY0sRGIkiLsnFBYpm8SfH7aBn0aeBxEBv6jYpxlff9MI SzkJBof+bYUhjhZBV6dVmBiR5aKCxb4q6oa34g0J9daoSU775oqGpoliOuZoCB73Xaa0 jtz3FfzTFyNFAhlN+bjGfteTf01Tgutbx3mETKFzMMHcxWBsGz3UIE3REFomgYn6obji emgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zPJTmL7M/KQjilpjiQvSnCs28pkECQ3GbYH85X9jLmk=; b=oFJmwbofhwxzIyuNSkSMyFBtKhs6XPjzPvpEkYgtoW+OU/P9iRW/P6JmY3F5UuHbFw 78Czh/lW1qS1mJeKzFjCbOs5geZHB9BVi7J3d0AfbMkFm2dWDX+37igXFXUjdpEnslxR x71Xbs/qk+khfGJ04saB8d305DqBZAz86vKz04wVerdvvHSoj6nYD/eQon2ZMTf0mjAI dFI1hsppodu8m0JeVJjiiPPEL3tOASwEyVs3kxm4JAZJNxXJl62S3ATmaV2RCivO5tmg HWdWLhLtfPLET8hFBBeh7pFcBy/HRkUF60vai7HRqpPCltZATi2Aek6o3LQuzOs0o+pM C83Q== X-Gm-Message-State: APjAAAVM+oOfEjakSs78rFdHuTPdn8gQHh08PAUcTzI8UYjyqokXnW+b ZEeVeQy46LQQfqDTyb9R2sXBtfXNymCNnXIjekdMow== X-Google-Smtp-Source: APXvYqyNN3yx/S+WRiCLT6r4gund166Nyn8aPiJYFec6JgvbZ2l4aiehPXWsqqpY8Vt6aY5rzPF5SOgw3vZPFVp7IBo= X-Received: by 2002:a17:906:4e01:: with SMTP id z1mr17520009eju.46.1581990651117; Mon, 17 Feb 2020 17:50:51 -0800 (PST) MIME-Version: 1.0 References: <20200214225849.108108-1-bgeffon@google.com> <20200214231954.GA29849@redhat.com> <20200217160739.GB1309280@xz-x1> In-Reply-To: <20200217160739.GB1309280@xz-x1> From: Brian Geffon Date: Mon, 17 Feb 2020 19:50:19 -0600 Message-ID: Subject: Re: [RFC PATCH] userfaultfd: Address race after fault. To: Peter Xu Cc: Andrea Arcangeli , Andrew Morton , linux-mm , LKML , Mike Rapoport , Sonny Rao , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Peter, I'll try helping out by giving the entire patchset a try. 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? Thanks, Brian On Mon, Feb 17, 2020 at 10:07 AM Peter Xu wrote: > > On Sat, Feb 15, 2020 at 09:29:46AM -0500, Brian Geffon wrote: > > Hi Andrea, > > Thanks for the quick reply. That's great to hear that Peter has been > > working on those improvements. I didn't try the entire patchset but I > > did confirm that patch 13, not surprisingly, also resolves that issue > > on at least on x86: > > https://lkml.org/lkml/2019/9/26/179 > > > > Given that seems pretty low risk and it definitely resolves a pretty > > big issue for the non-cooperative userfaultfd case, any chance it > > could be landed ahead of the rest of the series? > > Thanks Andrea & Brian! Yes it would be great if the series (or some > of the patches) could be moved forward. Please just let me know if > there's still anything I can do from my side. > > Thanks, > > > > > Thanks, > > Brian > > > > On Fri, Feb 14, 2020 at 6:20 PM Andrea Arcangeli wrote: > > > > > > Hello, > > > > > > this and other enhancements have already implemented by Peter (CC'ed) > > > and in the right way, by altering the retry logic in the page fault > > > code. This is a requirement for other kind of usages too, notably the > > > UFFD_WRITEPROTECT ioctl after which multiple consecutive faults can > > > happen and must be handled. > > > > > > IIRC Kirill asked at last LSF-MM uffd-wp talk if there's any > > > particular reason the fault couldn't be retried currently. I had no > > > sure answer other than there's apparently no strong reason why > > > VM_FAULT_RETRY is only allowed 1 time currently, so there should be no > > > issue in lifting that artificial restriction. > > > > > > I'm running with this patchset applied in my systems since Nov with no > > > regression at all. I got sidetracked by various other issues, so > > > unfortunately I didn' post a proper reviewed-by on the last submit yet > > > (pending), but I did at least test it and it was rock solid so far. > > > > > > https://lore.kernel.org/lkml/20190926093904.5090-1-peterx@redhat.com/ > > > > > > Can you test and verify it too if it solves your use case? > > > > > > Also note the complete uffd-WP support submit also from Peter: > > > > > > https://lore.kernel.org/lkml/20190620022008.19172-1-peterx@redhat.com/ > > > > > > https://github.com/xzpeter/linux/tree/uffd-wp-merged > > > > > > Thanks, > > > Andrea > > > > > > > -- > Peter Xu >