On Sat, Aug 31, 2024 at 06:19:15PM +0200, Oleg Nesterov wrote: > On 08/30, Andrii Nakryiko wrote: > > > > On Fri, Aug 30, 2024 at 1:21 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > > > I'll probably write another email (too late for me today), but I agree > > > that "avoid register_rwsem in handler_chain" is obviously a good goal, > > > lets discuss the possible cleanups or even fixlets later, when this > > > series is already applied. > > > > > > > Sounds good. It seems like I'll need another revision due to missing > > include, so if there is any reasonably straightforward clean up we > > should do, I can just incorporate that into my series. > > 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. > > But see below, > > > I still think it's fine, tbh. > > and perhaps you are right, > > > Which uprobe user violates this contract > > in the kernel? > > The only in-kernel user of UPROBE_HANDLER_REMOVE is perf, and it is fine. > > But there are out-of-tree users, say systemtap, I have no idea if this > change can affect them. > > And in general, this change makes the API less "flexible". > > 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. FWIW I (strongly) agree with merging this change and fixing the rest as follow up thanks, jirka > > But. Since you are going to send another version, may I ask you to add a > note into the changelog to explain that this patch assumes (and enforces) > the rule about handler/filter consistency? > > Oleg. >
