linux-kernel - Re: drm pull for v5.3-rc1

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]

Date:   Wed, 7 Aug 2019 07:15:17 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Hellström (VMware) 
        <thomas@...pmail.org>, Dave Airlie <airlied@...il.com>,
        Thomas Hellstrom <thellstrom@...are.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        LKML <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Jerome Glisse <jglisse@...hat.com>,
        Jason Gunthorpe <jgg@...lanox.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Steven Price <steven.price@....com>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: drm pull for v5.3-rc1

On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
> > Has anyone looked at turning the interface inside-out?  ie something like:
> > 
> > 	struct mm_walk_state state = { .mm = mm, .start = start, .end = end, };
> > 
> > 	for_each_page_range(&state, page) {
> > 		... do something with page ...
> > 	}
> > 
> > with appropriate macrology along the lines of:
> > 
> > #define for_each_page_range(state, page)				\
> > 	while ((page = page_range_walk_next(state)))
> > 
> > Then you don't need to package anything up into structs that are shared
> > between the caller and the iterated function.
> 
> I'm not an all that huge fan of super magic macro loops.  But in this
> case I don't see how it could even work, as we get special callbacks
> for huge pages and holes, and people are trying to add a few more ops
> as well.

We could have bits in the mm_walk_state which indicate what things to return
and what things to skip.  We could (and probably should) also use different
iterator names if people actually want to iterate different things.  eg
for_each_pte_range(&state, pte) as well as for_each_page_range().