Re: [patch v5 2/8] add prctl task isolation prctl docs and samples

[Marcelo Tosatti]

On Wed, Oct 27, 2021 at 02:38:06PM +0200, Frederic Weisbecker wrote:
> > +- activation state:
> > +
> > +        The activation state (whether activate/inactive) of the task
> 
> active/inactive ?

Fixed.

> > +        This feature allows quiescing select kernel activities on
> 
> selected?

Fixed.

> > +                - Bit ISOL_INHERIT_CONF: Inherit task isolation configuration.
> > +                  This is the stated written via prctl(PR_ISOL_CFG_SET, ...).
> 
> state

Fixed.

> > +        The 'pmask' argument specifies the location of an 8 byte mask
> > +        containing which features should be activated. Features whose
> > +        bits are cleared will be deactivated. The possible
> > +        bits for this mask are:
> > +
> > +                - ``ISOL_F_QUIESCE``:
> > +
> > +                Activate quiescing of background kernel activities.
> > +                Quiescing happens on return to userspace from this
> > +                system call, and on return from subsequent
> > +                system calls (unless quiesce_oneshot_mask is configured,
> > +                see below).
> > +
> > +        If the arg3 argument is non-zero, it specifies a pointer to::
> > +
> > +         struct task_isol_activate_control {
> > +                 __u64 flags;
> > +                 __u64 quiesce_oneshot_mask;
> 
> So you are using an entire argument here to set a single feature (ISOL_F_QUIESCE).

Yes, but there is room at "struct task_isol_activate_control" for other features 
to use (and additional space in the remaining prctl arguments, if necessary).

> It looks like the oneshot VS every syscall behaviour should be defined at
> configuration time for individual ISOL_F_QUIESCE features.

It seems one-shot selection is dependent on the 
application logic:

	configure task isolation
	enable oneshot quiescing of kernel activities
	do {
		process data (no system calls)
		if (event) {
			process event with syscalls
			enable oneshot quiescing of kernel activities
		}
       } while (!exit_condition);

Considering configuration performed outside the application (by chisol),
is the administrator supposed to know the internals of the application
at this level ?

What if the application desires to use one-shot in a section
(of code) and "all syscalls" for another section.

> Also do we want that to always apply to all syscalls? Should we expect corner
> cases with some of them? 

What type of corner cases do you think of? 

> What about exceptions and interrupts?

Should move the isolation_exit_to_user_mode_prepare call from
__syscall_exit_to_user_mode_work to exit_to_user_mode_prepare.
Good point.

About your question. Think so, because otherwise: 

     enable oneshot quiescing of kernel activities
     do {
             process data (no system calls)	    <--- 1. IRQ/exception
             if (event) {
                     process event with syscalls
                     enable oneshot quiescing of kernel activities
             }
     } while (exit_condition == false);


If either an interrupt or exception occurs at point 1 above, userspace
might not be notified, and the interrupt/exception handler might 
change state in the kernel which makes the current CPU a target
for IPIs, for example changing per-CPU vm statistics.

> My wild guess is that we need to leave room for future flexibility. Either open
> some configuration space on ISOL_F_QUIESCE for that or create a seperate
> ISOL_F_QUIESCE_ONESHOT.

See above about oneshot being application dependent.

> 
> Other than that, the general interface looks good! Now time for me to
> look at the implementation...

OK, thanks.