On Mon, Sep 15, 2025 at 3:34 PM Andrew Morton <a...@linux-foundation.org> wrote: > > On Mon, 15 Sep 2025 09:36:31 -0700 Kalesh Singh <kaleshsi...@google.com> > wrote: > > > Hi all, > > > > This is v2 to the VMA count patch I previously posted at: > > > > https://lore.kernel.org/r/20250903232437.1454293-1-kaleshsi...@google.com/ > > > > > > I've split it into multiple patches to address the feedback. > > > > The main changes in v2 are: > > > > - Use a capacity-based check for VMA count limit, per Lorenzo. > > - Rename map_count to vma_count, per David. > > - Add assertions for exceeding the limit, per Pedro. > > - Add tests for max_vma_count, per Liam. > > - Emit a trace event for failure due to insufficient capacity for > > observability > > > > Tested on x86_64 and arm64: > > > > - Build test: > > - allyesconfig for rename > > > > - Selftests: > > cd tools/testing/selftests/mm && \ > > make && \ > > ./run_vmtests.sh -t max_vma_count > > > > (With trace_max_vma_count_exceeded enabled) > > > > - vma tests: > > cd tools/testing/vma && \ > > make && \ > > ./vma > > fwiw, there's nothing in the above which is usable in a [0/N] overview. > > While useful, the "what changed since the previous version" info isn't > a suitable thing to carry in the permanent kernel record - it's > short-term treansient stuff, not helpful to someone who is looking at > the patchset in 2029. > > Similarly, the "how it was tested" material is also useful, but it > becomes irrelevant as soon as the code hits linux-next and mainline.
Hi Andrew, Thanks for the feedback. Do you mean the cover letter was not needed in this case or that it lacked enough context? > > > Anyhow, this -rc cycle has been quite the firehose in MM and I'm > feeling a need to slow things down for additional stabilization and so > people hopefully get additional bandwidth to digest the material we've > added this far. So I think I'll just cherrypick [1/7] for now. A > great flood of positive review activity would probably make me revisit > that ;) > I understand, yes 1/7 is all we need for now, since it prevents an unrecoverable situation where we get over the limit and cannot recover as munmap() will then always fail. Thanks, Kalesh
