Re: [PATCH 17/30] mm: prefer vma_[start,end]_pgoff() to vma->vm_pgoff in kernel/
Gregory Price <[email protected]>
| Newsgroups | dev.linux.lists.nvdimm,dev.linux.lists.damon,dev.linux.lists.iommu,org.freedesktop.lists.dri-devel,org.kernel.vger.kvm,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-parisc,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-sgx,org.kernel.vger.linux-tegra,org.kernel.vger.linux-trace-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <ak_C_o2ehS17Q5HV@gourry-fedora-PF4VCD3F> |
On Thu, Jul 02, 2026 at 12:30:59PM +0100, Lorenzo Stoakes wrote:
>
...
> static inline unsigned long vma_offset(const struct vm_area_struct *vma,
> const unsigned long address)
> {
> /* Retains page offset and tags. */
> return address - vma->vm_start;
> }
>
...
> And I'm not sure it's really all that useful. Perhaps retaining vma_offset()
> would be though.
>
Silly question:
What's the purpose of retaining tags in a non-address value?
That sounds like there's fragility just waiting to be broken.
(I presume you are talking about things like ARM MTE and such, right?)
> This is one that I think makes more sense.
>
> But in general, I'd rather hold off from yet more churn here.
>
> I'm making these changes to establish a basis for virtual page offsets
> introduced in [0], rather than just cleaning up in general.
>
I agree with this. If the refactors here suddenly have to think about
corner cases on things like tags, that's better resolved separately.
~Gregory