linux-kernel - Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <96fb8d14-fd9d-c21d-fa9d-81748421c6d3@gmail.com>
Date:   Thu, 4 Feb 2021 08:53:15 +0100
From:   Christian König <ckoenig.leichtzumerken@...il.com>
To:     Suren Baghdasaryan <surenb@...gle.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Sandeep Patil <sspatil@...gle.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux MM <linux-mm@...ck.org>,
        Robin Murphy <robin.murphy@....com>,
        James Jones <jajones@...dia.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthew Wilcox <willy@...radead.org>,
        Brian Starkey <Brian.Starkey@....com>,
        "moderated list:DMA BUFFER SHARING FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>, Minchan Kim <minchan@...nel.org>,
        John Stultz <john.stultz@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Chris Goldsworthy <cgoldswo@...eaurora.org>,
        Hridya Valsaraju <hridya@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Christian König <christian.koenig@....com>,
        "open list:DMA BUFFER SHARING FRAMEWORK" 
        <linux-media@...r.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH 1/2] mm: replace BUG_ON in vm_insert_page
 with a return of an error

Am 03.02.21 um 21:20 schrieb Suren Baghdasaryan:
> [SNIP]
> 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.

Well one major reason for this is to prevent accounting of DMA-buf pages.

So you are going in circles here and trying to circumvent an intentional 
behavior.

Daniel is right that this is the completely wrong approach and we need 
to take a step back and think about it on a higher level.

Going to replay to his mail as well.

Regards,
Christian.