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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 551A8C4332F for ; Wed, 23 Nov 2022 13:10:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236378AbiKWNKy (ORCPT ); Wed, 23 Nov 2022 08:10:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237244AbiKWNKZ (ORCPT ); Wed, 23 Nov 2022 08:10:25 -0500 Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EF4A6DFE9 for ; Wed, 23 Nov 2022 04:53:21 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id jr19so11115754qtb.7 for ; Wed, 23 Nov 2022 04:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=MWtQ+HQ7UjlTxeOZBwuIDBaW841V6JDDje6JFtn0Gm8=; b=kbHo21c+VjBArF8kANL4SpDL1ev6zm/1Ww3D2+PzFYwurEg6+qp0EuSseviqrfx0/f GBqzJ0OGcTLoYmbeuC8JAB6o+8R5apVCWygPdTWQ2c7MKRJjPHrgxLCuqTAoFxaipqLQ lwA5s+wmzlg+lUYLRa5WyG0bwo4VK6KpsD/ghuPmnzgzflFHqvidZvmCxARhE95E6gCM HiLT2lam0W46lxxjmcnKoGA64c1s8wzvk/9iVZg2JJlQNg0SPHCoC0/4GQrQnzmoV/Ye LUltVgutM1DaNNaG+TkFxWH4RzuBPtyDYVNo6Hg9hB4qhcbCuod1kx7H6CzyfxfwTqUg p8KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MWtQ+HQ7UjlTxeOZBwuIDBaW841V6JDDje6JFtn0Gm8=; b=r/F96kYbSu9VVmWkMQrjhF/P30Mvnphzg2N0D6GIexWXEBgQNrUjZOAVod9zKW4/CB I9mnvJbxyqLCSNtFZwG2PoDi7lsfDuQPxedCKbDgmFCCWnk+fHFQ3rh/viIUQ27cv9dF j5ouPCJAlzrS4jXzES6Sq0OIM0jDVFS+qi1impjb8P3dWMp+oqvgfM4tTl+Iwq3NV2gX hbVjro4+LgcVyRQGF/3xCuFds+qsHh3IYe9gE+5am7N9oBcBS3fh8JM+4xcOtBnJ4W6i ujCk2auxmEecRJNuleIgtrVGWjSEjmkyuPvEhHfrYJ6PoiCieSifebRWKqzHHVt5P5yZ gP0g== X-Gm-Message-State: ANoB5pnAnnt2WQ2q7a81kWnqJ4GZcGHqGu3rYfxmeDty3725X+1aZIs2 2rnQf2VXh7J/EOMTIol495nWlg== X-Google-Smtp-Source: AA0mqf5sY0FR2qWwiQ5/kTR4M+a6Z0BMf66P6/CLTclatyf0ZZNmbzpD51oJTq4KjYinih+bEDBsbQ== X-Received: by 2002:ac8:754b:0:b0:3a5:fbb6:b0fa with SMTP id b11-20020ac8754b000000b003a5fbb6b0famr26154000qtr.665.1669208000539; Wed, 23 Nov 2022 04:53:20 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-47-55-122-23.dhcp-dynamic.fibreop.ns.bellaliant.net. [47.55.122.23]) by smtp.gmail.com with ESMTPSA id d5-20020ac85445000000b0039492d503cdsm9751175qtq.51.2022.11.23.04.53.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Nov 2022 04:53:19 -0800 (PST) Received: from jgg by wakko with local (Exim 4.95) (envelope-from ) id 1oxpFe-00AJLy-Np; Wed, 23 Nov 2022 08:53:18 -0400 Date: Wed, 23 Nov 2022 08:53:18 -0400 From: Jason Gunthorpe To: Christian =?utf-8?B?S8O2bmln?= Cc: Daniel Vetter , Christian =?utf-8?B?S8O2bmln?= , DRI Development , Intel Graphics Development , Thomas Zimmermann , Suren Baghdasaryan , Matthew Wilcox , John Stultz , Daniel Vetter , Sumit Semwal , linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Require VM_PFNMAP vma for mmap Message-ID: References: <3d8607b4-973d-945d-c184-260157ade7c3@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Wed, Nov 23, 2022 at 01:49:41PM +0100, Christian König wrote: > Am 23.11.22 um 13:46 schrieb Jason Gunthorpe: > > On Wed, Nov 23, 2022 at 11:06:55AM +0100, Daniel Vetter wrote: > > > > > > Maybe a GFP flag to set the page reference count to zero or something > > > > like this? > > > Hm yeah that might work. I'm not sure what it will all break though? > > > And we'd need to make sure that underflowing the page refcount dies in > > > a backtrace. > > Mucking with the refcount like this to protect against crazy out of > > tree drives seems horrible.. > > Well not only out of tree drivers. The intree KVM got that horrible > wrong as well, those where the latest guys complaining about it. kvm was taking refs on special PTEs? That seems really unlikely? > > The WARN_ON(pag_count(p) != 1) seems like a reasonable thing to do > > though, though you must combine this with the special PTE flag.. > > That's not sufficient. The pages are released much later than things > actually go wrong. In most cases this WARN_ON here won't hit. How so? As long as the page is mapped into the PTE there is no issue with corruption. If dmabuf checks the refcount after it does the unmap mapping range it should catch any bogus pin that might be confused about address coherency. Jason