Re: [PATCH v4 tip/perf/core 0/4] uprobes,mm: speculative lockless VMA-to-uprobe lookup
From: Ingo Molnar <mingo@kernel.org>
Date: 2024-11-21 09:33:43
Also in:
bpf, linux-arm-kernel, linux-mm, lkml
* Andrii Nakryiko [off-list ref] wrote:
Is this about Liao's siglock patch set? We are at v4 (!) already (see [0]) with Oleg's Acked-by added.
AFAICS you didn't Cc: me to -v3 and -v4 - and while I'll generally see those patches too, eventually, there's a delay.
quoted
Andrii did get some other uprobes scalability work merged in v6.13: - Switch to RCU Tasks Trace flavor for better performance (Andrii Nakryiko) - Massively increase uretprobe SMP scalability by SRCU-protecting the uretprobe lifetime (Andrii Nakryiko) So we've certainly not been ignoring his patches, to the contrary ...Yes, and as I mentioned, this one is a) ready, reviewed, tested and b) complements the other work you mention.
Sorry, but patchsets that didn't even build a few weeks before the development window closed are generally pushed further down the backlog. Think of this as rate-limiting the risk of potentially broken code entering the kernel. You can avoid this problem by doing more testing, or by accepting that sometimes one more cycle is needed to get your patchsets merged.
[...] It removes mmap_lock which limits scalability of the rest of the work. Is there some rule that I get to land only two patch sets in a single release?
Your facetous question and the hostile tone of your emails is not appreciated. Me pointing out that two other patchsets of yours got integrated simply demonstrates how your original complaint of an 'ignore list' is not just unprofessional on its face, but also demonstrably unfair:
quoted
quoted
quoted
I'm not sure what's going on here, this patch set seems to be in some sort of "ignore list" on Peter's side with no indication on its destiny.
Trying to pressure maintainers over a patchset that recently had build failures isn't going to get your patches applied faster. Thanks, Ingo