On 09/03, Andrii Nakryiko wrote: > > On Sat, Aug 31, 2024 at 9:19 AM Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > I was thinking about another seq counter incremented in register(), so > > that handler_chain() can detect the race with uprobe_register() and skip > > unapply_uprobe() in this case. This is what Peter did in one of his series. > > Still changes the current behaviour, but not too much. > > We could do that, but then worst case, when we do detect registration > race, what do we do? Do nothing and skip unapply_uprobe(). > But as you said, this all can/should be addressed as a follow up > discussion. Yes, yes, > You mentioned some clean ups you wanted to do, let's > discuss all that as part of that? Yes, sure. And please note that in reply to myself I also mentioned that I am stupid and these cleanups can't help to change/improve this behaviour ;) > > The only in-kernel user of UPROBE_HANDLER_REMOVE is perf, and it is fine. > > > > Well, BPF program can accidentally trigger this as well, but that's a > bug, we should fix it ASAP in the bpf tree. not sure, but... > > And in general, this change makes the API less "flexible". > > it maybe makes a weird and too-flexible case a bit more work to > implement. Because if consumer want to be that flexible, they can > still define filter that will be coordinated between filter() and > handler() implementation. perhaps, but lets discuss this later, on top of your series. > > But once again, I agree that it would be better to apply your series first, > > then add the fixes in (unlikely) case it breaks something. > > Yep, agreed, thanks! Will send a new version ASAP, so we have a common > base to work on top of. Thanks. Hopefully Peter will queue your V5 soon. Oleg.
