[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZoQFXlfLMzF9hiLU@bombadil.infradead.org>
Date: Tue, 2 Jul 2024 06:49:18 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
Mike Rapoport <rppt@...nel.org>
Cc: Christoph Hellwig <hch@....de>, david@...morbit.com,
willy@...radead.org, chandan.babu@...cle.com, djwong@...nel.org,
brauner@...nel.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, yang@...amperecomputing.com,
linux-mm@...ck.org, john.g.garry@...cle.com,
linux-fsdevel@...r.kernel.org, hare@...e.de, p.raghav@...sung.com,
gost.dev@...sung.com, cl@...amperecomputing.com,
linux-xfs@...r.kernel.org, Zi Yan <zi.yan@...t.com>
Subject: Re: [PATCH v8 06/10] iomap: fix iomap_dio_zero() for fs bs > system
page size
On Tue, Jul 02, 2024 at 10:15:56AM +0000, Pankaj Raghav (Samsung) wrote:
> > > + set_memory_ro((unsigned long)page_address(zero_page_64k),
> > > + 1U << ZERO_PAGE_64K_ORDER);
> >
> > What's the point of the set_memory_ro here? Yes, we won't write to
> > it, but it's hardly an attack vector and fragments the direct map.
>
> That is a good point. Darrick suggested why not add a ro tag as we don't
> write to it but I did not know the consequence of direct map
> fragmentation when this is added. So probably there is no value calling
> set_memory_ro here.
Mike Rapoport already did the thankless hard work to evaluate if direct
map fragmentation is something which causes a performance issue and it
is not [0]. Either way, this is a *one* time thing, not something that
happens as often as other things which aggrevate direct map fragmentation
like eBPF, and so from my perspective there is no issue to using, if
we want set_memory_ro().
[0] https://lwn.net/Articles/931406/
Luis
Powered by blists - more mailing lists