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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 10C9FC64E7A for ; Fri, 27 Nov 2020 15:37:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EAF0820B80 for ; Fri, 27 Nov 2020 15:37:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="j0CTYxjI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EAF0820B80 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6B9086B0070; Fri, 27 Nov 2020 10:37:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 668A66B0071; Fri, 27 Nov 2020 10:37:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52FE76B0072; Fri, 27 Nov 2020 10:37:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id 3BA896B0070 for ; Fri, 27 Nov 2020 10:37:03 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E9D028249980 for ; Fri, 27 Nov 2020 15:37:02 +0000 (UTC) X-FDA: 77530601484.30.hat07_5b1718827389 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id A7C01180B3C8B for ; Fri, 27 Nov 2020 15:37:02 +0000 (UTC) X-HE-Tag: hat07_5b1718827389 X-Filterd-Recvd-Size: 5183 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Fri, 27 Nov 2020 15:37:02 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id t4so5970308wrr.12 for ; Fri, 27 Nov 2020 07:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=K1Lvq4AT8euTQFOTDi7SD1yQLWPU3xtKj6SslzOCQcc=; b=j0CTYxjISTzyYB3fnH07BP1SfkXZdDJFFx3Fq1Vh21kSx5OS6XHKFajDvVcGcx8pA8 cPCJqXp/h1c+KknHtBJuMbi8uavr493P4Sb/k+TrVqytxJYTAlRNAo2DznOvjz/xp51u jzdWE2vocNjByPF32K8tQ5Xdol/Cx8Q13Vf3w= 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 :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=K1Lvq4AT8euTQFOTDi7SD1yQLWPU3xtKj6SslzOCQcc=; b=tUSGHa+OelktRas2Ol3xhCnoEIlOHchvNtXrtYHIgY23AUadU5Pl+G41stLmBrlYjA 4ADZjwwJZjl8bannxqnK0z7msjvuohMAaq3owYBi9npRAeFt10ER0iIdGeUtGqet9LDU AT5eMdnzNUzSqfNeqE4vVezY7byaPsm75RB8MPk9TS9lzP7U+ANpqub2qFlOGhwE63gn bwnENzsaOSwbiilE8SOsUdsoG8FpwAknceEeW7lIUDXyj0gLjWAFApJSz/UgvliCGwG6 vIgSz3S9wsC6zr6MtdhhxjLge3edTO/c3OK+5tNPQcBSZuP2Mll7V7xE0T6HiVYt3Mgw bT2w== X-Gm-Message-State: AOAM532UlrOgjCwXuj3A6x1eRtSqnNfu28kPttdFnjOE/oElXyKCR3qz 0JBvsGeIe5xDlKSHUmbvFZdo6w== X-Google-Smtp-Source: ABdhPJw+HtnvrbrT1AqdueQE1hAvJ6eYSG3hDtZ8dwkM1q0A/rHWJIoxRYFcjysrLjp6WJc+IFTRWQ== X-Received: by 2002:adf:dd52:: with SMTP id u18mr10975193wrm.44.1606491420509; Fri, 27 Nov 2020 07:37:00 -0800 (PST) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id t184sm2744650wmt.13.2020.11.27.07.36.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Nov 2020 07:36:59 -0800 (PST) Date: Fri, 27 Nov 2020 16:36:57 +0100 From: Daniel Vetter To: Jason Gunthorpe Cc: Daniel Vetter , DRI Development , LKML , kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org Subject: Re: [PATCH v6 00/17] follow_pfn and other iomap races Message-ID: <20201127153657.GJ401619@phenom.ffwll.local> Mail-Followup-To: Jason Gunthorpe , DRI Development , LKML , kvm@vger.kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-media@vger.kernel.org References: <20201119144146.1045202-1-daniel.vetter@ffwll.ch> <20201127131225.GX5487@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127131225.GX5487@ziepe.ca> X-Operating-System: Linux phenom 5.7.0-1-amd64 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 Fri, Nov 27, 2020 at 09:12:25AM -0400, Jason Gunthorpe wrote: > On Thu, Nov 19, 2020 at 03:41:29PM +0100, Daniel Vetter wrote: > > I feel like this is ready for some wider soaking. Since the remaining bits > > are all kinda connnected probably simplest if it all goes through -mm. > > Did you figure out a sumbission plan for this stuff? I was kinda hoping Andrew would pick it all up. > > Daniel Vetter (17): > > drm/exynos: Stop using frame_vector helpers > > drm/exynos: Use FOLL_LONGTERM for g2d cmdlists > > misc/habana: Stop using frame_vector helpers > > misc/habana: Use FOLL_LONGTERM for userptr > > mm/frame-vector: Use FOLL_LONGTERM > > media: videobuf2: Move frame_vector into media subsystem > > At the very least it would be good to get those in right away. > > > mm: Add unsafe_follow_pfn > > media/videbuf1|2: Mark follow_pfn usage as unsafe > > vfio/type1: Mark follow_pfn as unsafe > > I'm surprised nobody from VFIO has remarked on this, I think thety > won't like it Same here tbh :-) > > mm: Close race in generic_access_phys > > PCI: Obey iomem restrictions for procfs mmap > > /dev/mem: Only set filp->f_mapping > > resource: Move devmem revoke code to resource framework > > sysfs: Support zapping of binary attr mmaps > > PCI: Revoke mappings like devmem > > This sequence seems fairly stand alone, and in good shape as well Yeah your split makes sense. I'll reorder them for the next round (which I'm prepping right now). > > My advice is to put the done things on a branch and get Stephen to put > them in linux-next. You can send a PR to Lins. There is very little mm > stuff in here, and cross subsystem stuff works better in git land, > IMHO. Yeah could do. Andrew, any preferences? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch