Re: [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
From: Suren Baghdasaryan <surenb@google.com>
Date: 2023-01-25 17:23:29
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-fbdev, linux-fsdevel, linux-media, linux-mediatek, linux-perf-users, linux-rdma, linux-s390, linux-samsung-soc, linux-scsi, linux-staging, linux-tegra, linux-um, linux-usb, linux-xfs, lkml, loongarch, netdev, nvdimm, selinux, sparclinux, target-devel, xen-devel
On Wed, Jan 25, 2023 at 9:08 AM Michal Hocko [off-list ref] wrote:
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote:quoted
On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team [off-list ref] wrote:quoted
On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote:quoted
Replace indirect modifications to vma->vm_flags with calls to modifier functions to be able to track flag changes and to keep vma locking correctness. Add a BUG_ON check in ksm_madvise() to catch indirect vm_flags modification attempts.Those BUG_ONs scream to much IMHO. KSM is an MM internal code so I gueess we should be willing to trust it.Yes, but I really want to prevent an indirect misuse since it was not easy to find these. If you feel strongly about it I will remove them or if you have a better suggestion I'm all for it.You can avoid that by making flags inaccesible directly, right?
Ah, you mean Peter's suggestion of using __private? I guess that would cover it. I'll drop these BUG_ONs in the next version. Thanks!
-- Michal Hocko SUSE Labs