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,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 26627C433E0 for ; Wed, 3 Feb 2021 20:30:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D710A64F76 for ; Wed, 3 Feb 2021 20:30:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D710A64F76 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 1230A6B0005; Wed, 3 Feb 2021 15:30:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D54C6B006C; Wed, 3 Feb 2021 15:30:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB8C06B006E; Wed, 3 Feb 2021 15:30:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id D65626B0005 for ; Wed, 3 Feb 2021 15:30:05 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 99933180AD81A for ; Wed, 3 Feb 2021 20:30:05 +0000 (UTC) X-FDA: 77778098370.13.CA7B2F9 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf04.hostedemail.com (Postfix) with ESMTP id 1B16012E for ; Wed, 3 Feb 2021 20:30:03 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id w124so1268829oia.6 for ; Wed, 03 Feb 2021 12:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eNYLKrHHFpo2W+MgM64k66uhU/rYD0kH/7hNDtjliGE=; b=DIeJeHCeI1SX9JRP36sM+W6rFO4OdsJpfGTkBtUBqCnklQGL6KVyuYn41Odc9/rLLe ISiwA+5txu4Ckq5KLKgiP0C/6WCuG77XxYxfBn96xe5UwbX1KuUtHivcIwEaeYETczwR NVLOPhppjYD4HewAedlleI8pu+9/HV0nd48To= 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=eNYLKrHHFpo2W+MgM64k66uhU/rYD0kH/7hNDtjliGE=; b=Y+qvOuCqCHhkKNliUZhVBE+OurhKYabhOxNfPy5yzYgIMQgiIXbMOVdvMD/VLv8sBs eifZ/9zYGMmXuloOvtZC20e/RzP8/nTeSOFVHUV146H3Wqedeka3z+oKqd9d78/g3wDh TiRrX9+sJGWSBlvJ/CoNOXwc4fN2hpuDiT3oR7JwsuEGW4sCIvlpiC1dYL2Ce8nEmfTi kP4w8ZYApkJhOqsdolvmQ1c28e5fB2qL4UzR1Xb674ymGpj6CYTV93k1qafz/86H/Iab +Mm55fH4Q20ndMO/nzJdI+LpAmBvjhvoQVAsmLzz4T+fxVCvUxWyXrhxjBcEIzJPXwgD LPAA== X-Gm-Message-State: AOAM531UQDBumIHeny08L3uB7DlmdLMRG+qoXohw63CnmdQkO9KwMAnD hdRsNdNdAQcrUkx/K+a9XtSivcOOEO0N/jLGdzM4oQ== X-Google-Smtp-Source: ABdhPJyZhpy+g0VGu5Ql8GRoYkjiipujRTnm3ivUEZ35jHpMHly6+eUAlEp4YwgW+F7ju02Z87k8fcr1y7ezggeHw5s= X-Received: by 2002:aca:4ac5:: with SMTP id x188mr2940752oia.14.1612384203966; Wed, 03 Feb 2021 12:30:03 -0800 (PST) MIME-Version: 1.0 References: <20210203003134.2422308-1-surenb@google.com> <20210203015553.GX308988@casper.infradead.org> In-Reply-To: From: Daniel Vetter Date: Wed, 3 Feb 2021 21:29:52 +0100 Message-ID: Subject: Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page with a return of an error To: Suren Baghdasaryan Cc: Matthew Wilcox , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Sandeep Patil , =?UTF-8?Q?Christian_K=C3=B6nig?= , Android Kernel Team , James Jones , Linux Kernel Mailing List , Liam Mark , Brian Starkey , Christoph Hellwig , Minchan Kim , Linux MM , John Stultz , dri-devel , Chris Goldsworthy , Hridya Valsaraju , Andrew Morton , Robin Murphy , "open list:DMA BUFFER SHARING FRAMEWORK" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 6odsiqjw13tgoydkj416g375odae5xtr X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1B16012E Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=mail-oi1-f174.google.com; client-ip=209.85.167.174 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1612384203-600830 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, Feb 3, 2021 at 9:20 PM Suren Baghdasaryan wrote: > > On Wed, Feb 3, 2021 at 12:52 AM Daniel Vetter wrote: > > > > On Wed, Feb 3, 2021 at 2:57 AM Matthew Wilcox wrote: > > > > > > On Tue, Feb 02, 2021 at 04:31:33PM -0800, Suren Baghdasaryan wrote: > > > > Replace BUG_ON(vma->vm_flags & VM_PFNMAP) in vm_insert_page with > > > > WARN_ON_ONCE and returning an error. This is to ensure users of the > > > > vm_insert_page that set VM_PFNMAP are notified of the wrong flag usage > > > > and get an indication of an error without panicing the kernel. > > > > This will help identifying drivers that need to clear VM_PFNMAP before > > > > using dmabuf system heap which is moving to use vm_insert_page. > > > > > > NACK. > > > > > > The system may not _panic_, but it is clearly now _broken_. The device > > > doesn't work, and so the system is useless. You haven't really improved > > > anything here. Just bloated the kernel with yet another _ONCE variable > > > that in a normal system will never ever ever be triggered. > > > > Also, what the heck are you doing with your drivers? dma-buf mmap must > > call dma_buf_mmap(), even for forwarded/redirected mmaps from driver > > char nodes. If that doesn't work we have some issues with the calling > > contract for that function, not in vm_insert_page. > > The particular issue I observed (details were posted in > https://lore.kernel.org/patchwork/patch/1372409) is that DRM drivers > set VM_PFNMAP flag (via a call to drm_gem_mmap_obj) before calling > dma_buf_mmap. Some drivers clear that flag but some don't. I could not > find the answer to why VM_PFNMAP is required for dmabuf mappings and > maybe someone can explain that here? > If there is a reason to set this flag other than historical use of > carveout memory then we wanted to catch such cases and fix the drivers > that moved to using dmabuf heaps. However maybe there are other > reasons and if so I would be very grateful if someone could explain > them. That would help me to come up with a better solution. > > > Finally why exactly do we need to make this switch for system heap? > > I've recently looked at gup usage by random drivers, and found a lot > > of worrying things there. gup on dma-buf is really bad idea in > > general. > > The reason for the switch is to be able to account dmabufs allocated > using dmabuf heaps to the processes that map them. The next patch in > this series https://lore.kernel.org/patchwork/patch/1374851 > implementing the switch contains more details and there is an active > discussion there. Would you mind joining that discussion to keep it in > one place? How many semi-unrelated buffer accounting schemes does google come up with? We're at three with this one. And also we _cannot_ required that all dma-bufs are backed by struct page, so requiring struct page to make this work is a no-go. Second, we do not want to all get_user_pages and friends to work on dma-buf, it causes all kinds of pain. Yes on SoC where dma-buf are exclusively in system memory you can maybe get away with this, but dma-buf is supposed to work in more places than just Android SoCs. If you want to account dma-bufs, and gpu memory in general, I'd say the solid solution is cgroups. There's patches floating around. And given that Google Android can't even agree internally on what exactly you want I'd say we just need to cut over to that and make it happen. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch