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: <CAMSo37UxxZ6dc9cY=TArOP01jTuBHuLT1BGv0d=y_hJA1_7Zvw@mail.gmail.com>
Date:   Sun, 6 Aug 2023 00:06:28 +0800
From:   Yongqin Liu <yongqin.liu@...aro.org>
To:     Hugh Dickins <hughd@...gle.com>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        David Hildenbrand <david@...hat.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        Yang Shi <shy828301@...il.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Peter Xu <peterx@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Will Deacon <will@...nel.org>, Yu Zhao <yuzhao@...gle.com>,
        Alistair Popple <apopple@...dia.com>,
        Ralph Campbell <rcampbell@...dia.com>,
        Ira Weiny <ira.weiny@...el.com>,
        Steven Price <steven.price@....com>,
        SeongJae Park <sj@...nel.org>,
        Lorenzo Stoakes <lstoakes@...il.com>,
        Huang Ying <ying.huang@...el.com>,
        Naoya Horiguchi <naoya.horiguchi@....com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Zack Rusin <zackr@...are.com>, Jason Gunthorpe <jgg@...pe.ca>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Pasha Tatashin <pasha.tatashin@...een.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        Minchan Kim <minchan@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Song Liu <song@...nel.org>,
        Thomas Hellstrom <thomas.hellstrom@...ux.intel.com>,
        Ryan Roberts <ryan.roberts@....com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v2 04/32] mm/pgtable: allow pte_offset_map[_lock]() to fail

On Sat, 29 Jul 2023 at 00:58, Hugh Dickins <hughd@...gle.com> wrote:
>
> On Fri, 28 Jul 2023, Matthew Wilcox wrote:
> > On Fri, Jul 28, 2023 at 09:53:29PM +0800, Yongqin Liu wrote:
> > > Hi, Hugh
> > >
> > > It seems this change makes pte_offset_map_lock not possible to be
> > > called in out of tree modules,
> > > otherwise it will report error like this:
> > >         ERROR: modpost: "__pte_offset_map_lock"
> > > [../omap-modules/android-mainline/pvr/pvrsrvkm.ko] undefined!
> > >
> > > Not sure if you have any idea about it, and any suggestions on how to
> > > resolve it?
> >
> > Please explain why this module needs to map page tables
>
> +1
Sorry, I am not able to give any explanation here,
I am not familiar with the pvrsrvkm source, I just use it to have one
working AOSP build.

here is the source file where pte_offset_map_lock is called,
    https://android-git.linaro.org/kernel/omap-modules.git/tree/pvr/services4/srvkm/env/linux/osfunc.c?h=android-mainline#n3508
in case you could know something with a quick look.

Otherwise, it has to wait for another one to report the problem again.

> Thank you for testing 6.5-rc, and I am sorry to have inconvenienced you.
>
> But there is not one example of an in-tree module needing that,
> which is a very strong hint that no module should be needing that.
>
> Sounds like pvrsrvkm.ko wants to muck around with page table entries,
> without the core mm knowing.  Not something core mm can encourage!
>
> If what pvrsrvkm.ko is aiming to do there would be useful for others,
> maybe its owner can share that, and work with core mm developers to
> expose a generally useful interface - but that is not likely to be
> __pte_offset_map_lock itself.
>

Thanks for the explanation!
Let's see if any other pvrsrvkm engineer or other out of tree modules could help
give some explanations on this case or similar cases.

Thanks,
Yongqin Liu


--
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android@...ts.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-android

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ