| Message ID | 20190114125903.24845-1-david@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: PG_reserved cleanups and documentation | expand |
On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote: > Nothing major changed since the last version. I would be happy about > additional ACKs. If there are no further comments, can this go via the > mm-tree in one chunk? > > I was recently going over all users of PG_reserved. Short story: it is > difficult and sometimes not really clear if setting/checking for > PG_reserved is only a relict from the past. Easy to break things. I > guess I now have a pretty good idea wh things are like that > nowadays and how they evolved. Any reason you skipped drivers/gpu/drm/drm_pci.c:drm_pci_alloc() and drivers/gpu/drm/drm_scatter.c:drm_legacy_sg_alloc() which both look completely bogus as-is? In fact we should probably just try to kill them off as they have very few users left.
On 15.01.19 16:38, Christoph Hellwig wrote: > On Mon, Jan 14, 2019 at 01:58:54PM +0100, David Hildenbrand wrote: >> Nothing major changed since the last version. I would be happy about >> additional ACKs. If there are no further comments, can this go via the >> mm-tree in one chunk? >> >> I was recently going over all users of PG_reserved. Short story: it is >> difficult and sometimes not really clear if setting/checking for >> PG_reserved is only a relict from the past. Easy to break things. I >> guess I now have a pretty good idea wh things are like that >> nowadays and how they evolved. > > Any reason you skipped > > drivers/gpu/drm/drm_pci.c:drm_pci_alloc() > > and > > drivers/gpu/drm/drm_scatter.c:drm_legacy_sg_alloc() > > which both look completely bogus as-is? > > In fact we should probably just try to kill them off as they have > very few users left. > I actually have patches lying around for these, however excluded them for now as I was not 100% sure about the implications ("Easy to break things"). Are you sure nobody in the system (especially somebody who does a PageReserved()) relies on this to identify e.g. MMIO pages? (e.g. ioremap on some archs, KVM code) (I am by far no DRM expert, but when I hear DMA, I tend to be careful)
On 14.01.19 13:58, David Hildenbrand wrote: > Nothing major changed since the last version. I would be happy about > additional ACKs. If there are no further comments, can this go via the > mm-tree in one chunk? For the time being, I will not add further patches to this series (as discussed in response to one question, we have to be careful dropping PG_reserved at some places). Only ACKs were added during review so far. @Andrew, how to proceed with this?
Nothing major changed since the last version. I would be happy about additional ACKs. If there are no further comments, can this go via the mm-tree in one chunk? I was recently going over all users of PG_reserved. Short story: it is difficult and sometimes not really clear if setting/checking for PG_reserved is only a relict from the past. Easy to break things. I guess I now have a pretty good idea wh things are like that nowadays and how they evolved. I had way more cleanups in this series inititally, but some architectures take PG_reserved as a way to apply a different caching strategy (for MMIO pages). So I decided to only include the most obvious changes (that are less likely to break something). So the big chunk of manual SetPageReserved users are MMIO/DMA related things on device buffers. Most notably, for device memory we will hopefully soon stop setting PG_reserved. Then the documentation has to be updated. v1 -> v2: - Minor speeling errors in "mm: better document PG_reserved" fixed - Added ACKs RFC -> v1: - Add more details to "mm: better document PG_reserved" - Add "arm64: kdump: No need to mark crashkernel pages manually PG_reserved" - Add "ia64: perfmon: Don't mark buffer pages as PG_reserved" - Added ACKs David Hildenbrand (9): agp: efficeon: no need to set PG_reserved on GATT tables s390/vdso: don't clear PG_reserved powerpc/vdso: don't clear PG_reserved riscv/vdso: don't clear PG_reserved m68k/mm: use __ClearPageReserved() arm64: kexec: no need to ClearPageReserved() arm64: kdump: No need to mark crashkernel pages manually PG_reserved ia64: perfmon: Don't mark buffer pages as PG_reserved mm: better document PG_reserved arch/arm64/kernel/machine_kexec.c | 3 +- arch/arm64/mm/init.c | 27 -------------- arch/ia64/kernel/perfmon.c | 59 +++---------------------------- arch/m68k/mm/memory.c | 2 +- arch/powerpc/kernel/vdso.c | 2 -- arch/riscv/kernel/vdso.c | 1 - arch/s390/kernel/vdso.c | 2 -- drivers/char/agp/efficeon-agp.c | 2 -- include/linux/page-flags.h | 33 +++++++++++++++-- 9 files changed, 37 insertions(+), 94 deletions(-)