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.8 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 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 CB405C433ED for ; Sat, 8 May 2021 16:47:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 281576141E for ; Sat, 8 May 2021 16:47:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 281576141E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6FFE46B006E; Sat, 8 May 2021 12:47:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6AFE96B0071; Sat, 8 May 2021 12:47:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5825D6B0072; Sat, 8 May 2021 12:47:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 399C56B006E for ; Sat, 8 May 2021 12:47:02 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DA98D8249980 for ; Sat, 8 May 2021 16:47:01 +0000 (UTC) X-FDA: 78118643442.12.CCCD2F0 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf15.hostedemail.com (Postfix) with ESMTP id D71E7A000390 for ; Sat, 8 May 2021 16:46:54 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id i9so10606335lfe.13 for ; Sat, 08 May 2021 09:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RpBgi0AKlff8147OOEepLQzMBGFd2Jt9bavNArPpQME=; b=bypPdqFJPA5UGrC7VjMqIpDRd67/c4G9oxLzYlL8bqj5WHAW1G0t+zlQDg0DLILqA8 K4pattodnxkJL9u3sPT5fbfMSAiz0Z1Bc3f1KBYDfpdNL36j/INuMqu9tRPTnyIKMJaK wTzy/qU2N01zcOpGy1Hz/2WG6ax9Mzy9on2bQ= 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=RpBgi0AKlff8147OOEepLQzMBGFd2Jt9bavNArPpQME=; b=TEJdJ31Vo99NrcMKBkFdVNoCNkVMvuD4Ff+d5a1N2PMnRxLVKNE0b/X2mHnSgSL5GG vTEjNmDVlldum5R4pKL7V8bSj0BQ+26FHIstjesqV9c5R/KXIxKP9GarJGVjvBJzHcMS MJK0x6hwmJ+/FRueeSTd7CkI1WZLcbJcL7yqAvH6BpFFOHFtA82anPaRYoGWZsAa5H8F Mc5BjNaVe8sTl2HU5z7LitOvWT5SUaM2QMjrUHOWkMfc3BxLwgYHxJd7Wrsn8wTkWtWz gRQkBXMWWFyEE1XSsR4zoT9EET40ioCK//J3SwuktLVWY/cPFc+cOLDaCjIaGv2CgPiA YzyQ== X-Gm-Message-State: AOAM532oVUFTmY2sH4bb39gvDQgRVnpCsTHdht2Djo6LSxhvNBhcIVI/ vFhluC6vJs+RmspMBDi77iuESw8/hN7usQM3LkU= X-Google-Smtp-Source: ABdhPJxWJ1af4bXbr2qdp6lcMOA+UosxJNcEmPLg50W+mOBD/bNBJ57h1hRZ2y7APU1KaCv7gEFdJQ== X-Received: by 2002:ac2:5231:: with SMTP id i17mr10394553lfl.121.1620492419065; Sat, 08 May 2021 09:46:59 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id o12sm2287828ljp.104.2021.05.08.09.46.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 May 2021 09:46:57 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id x19so17192407lfa.2 for ; Sat, 08 May 2021 09:46:57 -0700 (PDT) X-Received: by 2002:a19:7504:: with SMTP id y4mr10031878lfe.41.1620492417345; Sat, 08 May 2021 09:46:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sat, 8 May 2021 09:46:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PULL] topic/iomem-mmap-vs-gup To: Daniel Vetter , Tomasz Figa , Marek Szyprowski , Mauro Carvalho Chehab Cc: DRI Development , LKML , Linux-MM , Linux ARM , Linux Media Mailing List , linux-samsung-soc@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=bypPdqFJ; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Stat-Signature: 5i6w94ng9ewmuoyue7bh6yhfcsi7jrsy X-Rspamd-Queue-Id: D71E7A000390 Received-SPF: none (linuxfoundation.org>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=mail-lf1-f43.google.com; client-ip=209.85.167.43 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620492414-503959 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: [ Daniel, please fix your broken email setup. You have this insane "Reply-to" list that just duplicates all the participants. Very broken, very annoying ] On Fri, May 7, 2021 at 8:53 AM Daniel Vetter wrote: > > So personally I think the entire thing should just be thrown out, it's all > levels of scary and we have zero-copy buffer sharing done properly with > dma-buf since years in v4l. So I've been looking at this more, and the more I look at it, the less I like this series. I think the proper fix is to just fix things. For example, I'm looking at the v4l users of follow_pfn(), and I find get_vaddr_frames(), which is just broken. Fine, we know users are broken, but look at what appears to be the main user of get_vaddr_frames(): vb2_dc_get_userptr(). What does that function do? Immediately after doing get_vaddr_frames(), it tries to turn those pfn's into page pointers, and then do sg_alloc_table_from_pages() on the end result. Yes, yes, it also has that "ok, that failed, let's try to see if it's some physically contiguous mapping" and do DMA directly to those physical pages, but the point there is that that only happens when they weren't normal pages to begin with. So thew *fix* for at least that path is to (a) just use the regular pin_user_pages() for normal pages (b) perhaps keep the follow_pfn() case, but then limit it to that "no page backing" and that physical pages case. And honestly, the "struct frame_vector" thing already *has* support for this, and the problem is simply that the v4l code has decided to have the callers ask for pfn's rather than have the callers just ask for a frame-vector that is either "pfn's with no paeg backing" _or_ "page list with proper page reference counting". So this series of yours that just disables follow_pfn() actually seems very wrong. I think follow_pfn() is ok for the actual "this is not a 'struct page' backed area", and disabling that case is wrong even going forward. End result, I think the proper model is: - keep follow_pfn(), but limit it to the "not vm_normal_page()" case, and return error for some real page mapping - make the get_vaddr_frames() first try "pin_user_pages()" (and create a page array) and fall back to "follow_pfn()" if that fails (or the other way around). Set the IOW, get_vaddr_frames() would just do vec->got_ref = is_pages; vec->is_pfns = !is_pages; and everything would just work out - the v4l code seems to already have all the support for "it's a ofn array" vs "it's properly refcounted pages". So the only case we should disallow is the mixed case, that the v4l code already seems to not be able to handle anyway (and honestly, it looks like "got_ref/is_pfns" should be just one flag - they always have to have the opposite values). So I think this "unsafe_follow_pfn()" halfway step is actively wrong. It doesn't move us forward. Quite the reverse. It just makes the proper fix harder. End result: not pulling it, unless somebody can explain to me in small words why I'm wrong and have the mental capacity of a damaged rodent. Linus