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
| ||
|
Message-ID: <6841c408e85d3_249110075@dwillia2-xfh.jf.intel.com.notmuch> Date: Thu, 5 Jun 2025 09:21:28 -0700 From: Dan Williams <dan.j.williams@...el.com> To: David Hildenbrand <david@...hat.com>, Christoph Hellwig <hch@....de>, "Dan Williams" <dan.j.williams@...el.com> CC: Alistair Popple <apopple@...dia.com>, <linux-mm@...ck.org>, <gerald.schaefer@...ux.ibm.com>, <jgg@...pe.ca>, <willy@...radead.org>, <linux-kernel@...r.kernel.org>, <nvdimm@...ts.linux.dev>, <linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>, <linux-xfs@...r.kernel.org>, <jhubbard@...dia.com>, <zhang.lyra@...il.com>, <debug@...osinc.com>, <bjorn@...nel.org>, <balbirs@...dia.com>, <lorenzo.stoakes@...cle.com>, <linux-arm-kernel@...ts.infradead.org>, <loongarch@...ts.linux.dev>, <linuxppc-dev@...ts.ozlabs.org>, <linux-riscv@...ts.infradead.org>, <linux-cxl@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>, <John@...ves.net> Subject: Re: [PATCH 03/12] mm/pagewalk: Skip dax pages in pagewalk David Hildenbrand wrote: > On 05.06.25 09:46, Christoph Hellwig wrote: > > On Wed, Jun 04, 2025 at 06:59:09PM -0700, Dan Williams wrote: > >> +/* return normal pages backed by the page allocator */ > >> +static inline struct page *vm_normal_gfp_pmd(struct vm_area_struct *vma, > >> + unsigned long addr, pmd_t pmd) > >> +{ > >> + struct page *page = vm_normal_page_pmd(vma, addr, pmd); > >> + > >> + if (!is_devdax_page(page) && !is_fsdax_page(page)) > >> + return page; > >> + return NULL; > > > > If you go for this make it more straight forward by having the > > normal path in the main flow: > > > > if (is_devdax_page(page) || is_fsdax_page(page)) > > return NULL; > > return page; > > +1 > > But I'd defer introducing that for now if avoidable. I find the naming > rather ... suboptimal :) Agree, that was a "for lack of a better term" suggestion, but the suggestion is indeed lacking.
Powered by blists - more mailing lists