On 02/27/25 at 02:16pm, Vlastimil Babka wrote: > On 2/27/25 11:24, Baoquan He wrote: > >> I guess the issue doesn't happen in practice. In any case it's out of scope > >> of the reverted commit and the revert. > > It could happen on arm64 because arm64 only has ZONE_DMA by default and > > its boundary is not fixed. I saw all zones are ZONE_DMA on arm64, I > > guess it could be easier to see a arm64 system which only has ZONE_DMA > > on node 0 and ZONE_NORMAL/MOVABLE on other nodes. > > Does it mean the ZONE_DMA is rather large then on arm64 then? In that case Hmm, means it's more likely happening on arm64 that there's only ZONE_DMA on node0 because its node/zone layout could more flexibly customized in firmware by ystem vendor, but not like x86_64 with fixed range of ZONE_DMA, ZONE_DMA32 and there's always ZONE_NORMAL in node0. > things probably works fine even if no protection is applied to it. The x86 > ones are small and thus need(ed) it much more. So I don't think we > proactively need to change anything unless there are known issues observed > in practice. I am fine if we decide to leave it since we have made clear the root cause and all the potential issues. Once known issue reported, we can do the change at that time. > > Another reason to avoid the effort is that hopefully we'll get rid of the > DMA zones anyway? They don't work all that well anyway in modern times. > Ccing Petr for awareness (due to his recent LPC talk about this topic) Thanks for telling. I noticed Petr's interesting presentation in LPC 2024, that sounds very stunning but very attractive if it's finally achieved. But I love it. I think that's a good one to vote for not touching the proctection value for now.
