On Thu, Sep 4, 2025 at 4:26 AM Oleg Nesterov <[email protected]> wrote: > > On 09/04, Jiri Olsa wrote: > > > > On Thu, Sep 04, 2025 at 10:49:50AM +0200, Oleg Nesterov wrote: > > > On 09/03, Jiri Olsa wrote: > > > > > > > > On Wed, Sep 03, 2025 at 01:26:48PM +0200, Oleg Nesterov wrote: > > > > > On 09/02, Jiri Olsa wrote: > > > > > > > > > > > > If user decided to take execution elsewhere, it makes little sense > > > > > > to execute the original instruction, so let's skip it. > > > > > > > > > > Exactly. > > > > > > > > > > So why do we need all these "is_unique" complications? Only a single > > > > > is_unique/exclusive consumer can change regs->ip, so I guess > > > > > handle_swbp() > > > > > can just do > > > > > > > > > > handler_chain(uprobe, regs); > > > > > if (instruction_pointer(regs) != bp_vaddr) > > > > > goto out; > > > > > > > > hum, that's what I did in rfc [1] but I thought you did not like that > > > > [2] > > > > > > > > [1] > > > > https://lore.kernel.org/bpf/[email protected]/ > > > > [2] https://lore.kernel.org/bpf/[email protected]/ > > > > > > > > I guess I misunderstood your reply [2], I'd be happy to drop the > > > > unique/exclusive flag > > > > > > Well, but that rfc didn't introduce the exclusive consumers, and I think > > > we agree that even with these changes the non-exclusive consumers must > > > never change regs->ip? > > > > ok, got excited too soon.. so you meant getting rid of is_unique > > check only for this patch and have just change below.. but keep > > the unique/exclusive flag from patch#1 > > Yes, this is what I meant, > > > IIUC Andrii would remove the unique flag completely? > > Lets wait for Andrii...
Not Andrii, but I see only negatives in this extra flag. It doesn't add any safety or guardrails. No need to pollute uapi with pointless flags.
