Thread (34 messages) 34 messages, 6 authors, 2023-01-26

Re: [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions

From: Matthew Wilcox <willy@infradead.org>
Date: 2023-01-25 18:39:56
Also in: alsa-devel, amd-gfx, bpf, dmaengine, dri-devel, intel-gfx, kexec, kvm, linux-acpi, linux-arch, linux-arm-msm, linux-crypto, linux-ext4, linux-fsdevel, linux-media, linux-mediatek, linux-mm, linux-perf-users, linux-rdma, linux-s390, linux-samsung-soc, linux-scsi, linux-staging, linux-tegra, linux-um, linux-usb, linux-xfs, linuxppc-dev, lkml, loongarch, netdev, nvdimm, selinux, sparclinux, target-devel, virtualization, xen-devel

On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra [off-list ref] wrote:
quoted
quoted
+     /*
+      * Flags, see mm.h.
+      * WARNING! Do not modify directly.
+      * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
+      */
+     unsigned long vm_flags;
We have __private and ACCESS_PRIVATE() to help with enforcing this.
Thanks for pointing this out, Peter! I guess for that I'll need to
convert all read accesses and provide get_vm_flags() too? That will
cause some additional churt (a quick search shows 801 hits over 248
files) but maybe it's worth it? I think Michal suggested that too in
another patch. Should I do that while we are at it?
Here's a trick I saw somewhere in the VFS:

	union {
		const vm_flags_t vm_flags;
		vm_flags_t __private __vm_flags;
	};

Now it can be read by anybody but written only by those using
ACCESS_PRIVATE.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help