On Wed, Jun 05, 2024 at 01:47:00PM -0700, Andrii Nakryiko wrote:
> On Wed, Jun 5, 2024 at 10:57 AM Oleg Nesterov <o...@redhat.com> wrote:
> >
> > On 06/05, Andrii Nakryiko wrote:
> > >
> > > so any such
> > > limitations will cause problems, issue reports, investigation, etc.
> >
> > Agreed...
> >
> > > As one possible solution, what if we do
> > >
> > > struct return_instance {
> > > ...
> > > u64 session_cookies[];
> > > };
> > >
> > > and allocate sizeof(struct return_instance) + 8 *
> > > <num-of-session-consumers> and then at runtime pass
> > > &session_cookies[i] as data pointer to session-aware callbacks?
> >
> > I too thought about this, but I guess it is not that simple.
> >
> > Just for example. Suppose we have 2 session-consumers C1 and C2.
> > What if uprobe_unregister(C1) comes before the probed function
> > returns?
> >
> > We need something like map_cookie_to_consumer().
>
> Fair enough. The easy way to solve this is to have
>
>
> struct uprobe_session_cookie {
> int consumer_id;
> u64 cookie;
> };
>
> And add id to each new consumer when it is added to struct uprobe.
> Unfortunately, it's impossible to tell when a new consumer was added
> to the list (as a front item, but maybe we just change it to be
> appended instead of prepending) vs when the old consumer was removed,
> so in some cases we'd need to do a linear search.
also we probably need to add the flag if we want to execute the return
handler.. we can have multiple session handlers and if just one of them
returns 0 we need to install the return probe
and then when return probe hits, we need to execute only that consumer's
return handler
jirka
>
> But the good news is that in the common case we wouldn't need to
> search and the next item in session_cookies[] array would be the one
> we need.
>
> WDYT? It's still fast, and it's simpler than the shadow stack idea, IMO.
>
> P.S. Regardless, maybe we should change the order in which we insert
> consumers to uprobe? Right now uprobe consumer added later will be
> executed first, which, while not wrong, is counter-intuitive. And also
> it breaks a nice natural order when we need to match it up with stuff
> like session_cookies[] as described above.
>
> >
> > > > + /* The handler_session callback return value controls execution
> > > > of
> > > > + * the return uprobe and ret_handler_session callback.
> > > > + * 0 on success
> > > > + * 1 on failure, DO NOT install/execute the return uprobe
> > > > + * console warning for anything else
> > > > + */
> > > > + int (*handler_session)(struct uprobe_consumer *self, struct
> > > > pt_regs *regs,
> > > > + unsigned long *data);
> > > > + int (*ret_handler_session)(struct uprobe_consumer *self,
> > > > unsigned long func,
> > > > + struct pt_regs *regs, unsigned long
> > > > *data);
> > > > +
> > >
> > > We should try to avoid an alternative set of callbacks, IMO. Let's
> > > extend existing ones with `unsigned long *data`,
> >
> > Oh yes, agreed.
> >
> > And the comment about the return value looks confusing too. I mean, the
> > logic doesn't differ from the ret-code from ->handler().
> >
> > "DO NOT install/execute the return uprobe" is not true if another
> > non-session-consumer returns 0.
> >
> > Oleg.
> >
