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=-6.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 6DA42C433ED for ; Wed, 19 May 2021 12:15:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F39B461040 for ; Wed, 19 May 2021 12:15:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F39B461040 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 78B446B0073; Wed, 19 May 2021 08:15:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73A1B6B0074; Wed, 19 May 2021 08:15:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58C076B0075; Wed, 19 May 2021 08:15:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 268C26B0073 for ; Wed, 19 May 2021 08:15:47 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B9C8C824999B for ; Wed, 19 May 2021 12:15:46 +0000 (UTC) X-FDA: 78157876692.26.5D11C0E Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 863F9600028C for ; Wed, 19 May 2021 12:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621426546; 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=tpsW6GoLBuPX3m2t6ZDWDsXVHyOzAne0XpIqOVeHL30=; b=iWJyJ2JzQRelZ805GCtdPoB9VQ1XEdIFM564RmmA7mx2ZGzJqSwzReDjGZYbV/b2mEll1M EWEOflN3vFnYnv+LNtdPgqnUgeQAmdbryad4yfCU6fCUY9bC7BpELXBFv9n0mkZJyVjMMT fKznwmsLn0Y2agTqb3v5v8170IhBbME= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-330-W5OsAKIiMoG_35VuzVFjpg-1; Wed, 19 May 2021 08:15:44 -0400 X-MC-Unique: W5OsAKIiMoG_35VuzVFjpg-1 Received: by mail-qv1-f70.google.com with SMTP id c5-20020a0ca9c50000b02901aede9b5061so10159700qvb.14 for ; Wed, 19 May 2021 05:15:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tpsW6GoLBuPX3m2t6ZDWDsXVHyOzAne0XpIqOVeHL30=; b=MRimCHBrf8zMejPuXvC7u3KIVZGJ2LJTMG3eu/s2mYsJ6UHD4IWLkc0xsNgp3/7y/t 5lvm3ck7FlEc6FQKFhNuCnnUbe1QAA8PsWyWF0j5Y5atUmO07h5WJPHxNAF5qNzJqOL2 zVD5GCDvAwB5WJIXdT62Tu0KLvHi9MOVKDssWbRPhHENUnrRiXsOLYPjphexcTNLivji GqXcfMEcqgypuygeMA0Lhert8wmS4Zj5wnmOL09sTVtKKGCd+FYemoSxvmHXrctyJAgZ AzAvLrezFfYKZJQaFf9oFBrmsNXYW0OUQnxeHitYN5vRGBeOXgbJpdDR1ITxPddszgNq CT4A== X-Gm-Message-State: AOAM532BBXThDRGRBBbDJX7KEOWR6pyCWNsveFnSjj/r/ZuUzPbfwVk1 B9yVytI+SiQ94SbAwngCJcM14Y/mEKJcjSztFdpm/yAe+rra30qP58Fn7b2/JwTN2L0Y3tiEbvS nzkru/Cj/pdI= X-Received: by 2002:a05:6214:20c4:: with SMTP id 4mr13195000qve.38.1621426543764; Wed, 19 May 2021 05:15:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJeMvnD48yKledjvAvmUkVuVahWxfS9KHq8l5vFptQfcG6pDYRH4satuz1xLVBYj0ZmxaSVA== X-Received: by 2002:a05:6214:20c4:: with SMTP id 4mr13194979qve.38.1621426543531; Wed, 19 May 2021 05:15:43 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id y9sm14576208qkm.19.2021.05.19.05.15.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 05:15:42 -0700 (PDT) Date: Wed, 19 May 2021 08:15:41 -0400 From: Peter Xu To: Alistair Popple Cc: Jason Gunthorpe , linux-mm@kvack.org, nouveau@lists.freedesktop.org, bskeggs@redhat.com, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, jhubbard@nvidia.com, rcampbell@nvidia.com, jglisse@redhat.com, hch@infradead.org, daniel@ffwll.ch, willy@infradead.org, bsingharora@gmail.com, Christoph Hellwig Subject: Re: [PATCH v8 5/8] mm: Device exclusive memory access Message-ID: References: <20210407084238.20443-1-apopple@nvidia.com> <20210518230327.GG1002214@nvidia.com> <2235357.HsqDk0zIjc@nvdebian> MIME-Version: 1.0 In-Reply-To: <2235357.HsqDk0zIjc@nvdebian> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 863F9600028C Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iWJyJ2Jz; spf=none (imf09.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam04 X-Stat-Signature: 3om4siqrkj6re7awoxuxsdrwwxn8entz X-HE-Tag: 1621426545-206629 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: On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote: > Failing fork() because we couldn't take a lock doesn't seem like the right > approach though, especially as there is already existing code that retries. I > get this adds complexity though, so would be happy to take a look at cleaning > copy_pte_range() up in future. Yes, I proposed that as this one won't affect any existing applications (unlike the existing ones) but only new userspace driver apps that will use this new atomic feature. IMHO it'll be a pity to add extra complexity and maintainance burden into fork() if only for keeping the "logical correctness of fork()" however the code never triggers. If we start with trylock we'll know whether people will use it, since people will complain with a reason when needed; however I still doubt whether a sane userspace device driver should fork() within busy interaction with the device underneath.. In all cases, please still consider to keep them in copy_nonpresent_pte() (and if to rework, separating patches would be great). Thanks, -- Peter Xu