On Tue, Jul 9, 2024 at 2:33 PM Oleg Nesterov <o...@redhat.com> wrote: > > On 07/09, Andrii Nakryiko wrote: > > > > On Tue, Jul 9, 2024 at 11:49 AM Oleg Nesterov <o...@redhat.com> wrote: > > > > > > > Yep, that would be unfortunate (just like SIGILL sent when uretprobe > > > > detects "improper" stack pointer progression, for example), > > > > > > In this case we a) assume that user-space tries to fool the kernel and > > > > Well, it's a bad assumption. User space might just be using fibers and > > managing its own stack. > > Do you mean something like the "go" language? >
No, I think it was C++ application. I think we have some uses of fibers in which an application does its own user-space scheduling and manages stack in user space. But it's basically the same class of problems that you'd get with Go, yes. > Yes, not supported. And from the kernel perspective it still looks as if > user-space tries to fool the kernel. I mean, if you insert a ret-probe, > the kernel assumes that it "owns" the stack, if nothing else the kernel > has to change the ret-address on stack. > > I agree, this is not good. But again, what else the kernel can do in > this case? Not that I'm proposing this, but kernel could probably maintain a lookup table keyed by thread stack pointer, instead of maintaining implicit stack (but that would probably be more expensive). With some limits and stuff this probably would work fine. > > > > Not really expected, and that is why the "TODO" comment in _unregister() > > > was never implemented. Although the real reason is that we are lazy ;) > > > > Worked fine for 10+ years, which says something ;) > > Or may be it doesn't but we do not know because this code doesn't do > uprobe_warn() ;) sure :) > > Oleg. >
