Re: [PATCH v6 07/15] digest_cache: Allow registration of digest list parsers

[Roberto Sassu]

On Thu, 2024-11-28 at 12:40 -0800, Luis Chamberlain wrote:
> On Thu, Nov 28, 2024 at 09:23:57AM +0100, Roberto Sassu wrote:
> > On Wed, 2024-11-27 at 11:53 -0800, Luis Chamberlain wrote:
> > > On Wed, Nov 27, 2024 at 10:51:11AM +0100, Roberto Sassu wrote:
> > > > For eBPF programs we are also in a need for a better way to
> > > > measure/appraise them.
> > > 
> > > I am confused now, I was under the impression this "Integrity Digest
> > > Cache" is just a special thing for LSMs, and so I was under the
> > > impression that kernel_read_file() lsm hook already would take care
> > > of eBPF programs.
> > 
> > Yes, the problem is that eBPF programs are transformed in user space
> > before they are sent to the kernel:
> > 
> > https://lwn.net/Articles/977394/
> 
> That issue seems to be orthogonal to your eandeavor though, which just
> supplements LSMS, right?

Yes, correct, the Integrity Digest Cache would be used to search
whatever digest was calculated by LSMs.

Thanks

Roberto

> Anyway, in case this helps:
> 
> The Rust folks faced some slighty related challenges with our CRC
> validations for symbols, our CRC are slapped on with genksyms but this
> relies on the source code and with Rust the compiler may do final
> touches to data. And so DWARF is being used [1].
> 
> Although I am not sure of the state of eBPF DWARF support, there is also
> BTF support [0] and most distros are relying on it to make live introspection 
> easier, and the output is much smaller. So could DWARF or BTF information
> from eBPF programs be used by the verifier in similar way to verify eBPF
> programs?
> 
> Note that to support BTF implicates DWARF and the leap of faith for Rust
> modversions support is that most distros will support DWARF, and so BTF
> can become the norm [2].
> 
> [0] https://www.kernel.org/doc/html/latest/bpf/btf.html
> [1] https://lwn.net/Articles/986892/
> [2] https://lwn.net/Articles/991719/
> 
>   Luis

Re: [PATCH] docs: media: document media multi-committers rules and process

[Mauro Carvalho Chehab]

Em Thu, 28 Nov 2024 21:07:07 +0200
Laurent Pinchart  escreveu:

> > With that in mind, every committer has duties of reviewing other
> > developer's patches submitted for the drivers that they're listed as
> > a maintainer at the MAINTAINERS file entries.  
> 
> I'm sorry but that's not a multi-committer model, it's a co-maintenance
> model. If that's what you really want we can reopen the discussion and
> start anew, but I don't think it's a good idea.
> 
> As I said before, if it increases my work load, I don't want commit
> rights. I'll keep sending pull requests, you'll have to keep processing
> them, and patches will be merged slower. It will be a lose-lose
> situation for everybody, you, me, contributors and users.
> 
> Starting with a situation where we are understaffed and trying to solve
> it by putting more work on the few people who currently keep the
> subsystem alive doesn't sound like a winning strategy. 

After sleeping over it, I agree that you're partially right on this.

Doing timely reviews is orthogonal of being a committer. What defines
if you need to do timely reviews is if you're listed or not at the
MAINTANERS file as "M:" - e.g. if the developer is a maintainer
(on its broader sense) or not. This applies for both PR and MR workflows.

Still, if one is not fulfilling its duty as maintainer, he may end
losing maintainership status and the corresponding committer rights.

I wrote a separate patch to make it clear. See below.

Thanks,
Mauro

---

[PATCH] docs: media: profile: make it clearer about maintainership duties

During the review of the media committes profile, it was noticed
that the responsibility for timely review patches was not clear:
such review is expected that all developers listed at MAINTAINERS
with the "M:" tag (e.g. "maintainers" on its broad sense).

This is orthogonal of being a media committer or not. Such duty
is implied at:

Documentation/admin-guide/reporting-issues.rst

and at the MAINTAINERS header, when it says that even when the
status is "odd fixes", the patches will flow in.

So, let make it explicit at the maintainer-entry-profile that
maintainers need to do timely reviews.

Also, while right now our focus is on granting committer rights to
maintainers, the media-committer model may evolve in the future to
accept other committers that don't have such duties.

So, make it clear at the media-committer.rst that the duties
related to reviewing patches from others are for the drivers
they are maintainers as well.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst 
b/Documentation/driver-api/media/maintainer-entry-profile.rst
index 650803c30c41..6daf71bc72c1 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -147,6 +147,11 @@ b. Committers' workflow: patches are handled by media 
committers::
 On both workflows, all patches shall be properly reviewed at
 linux-me...@vger.kernel.org before being merged at media-committers.git.
 
+Such patches will be timely-reviewed by developers listed as maintainers at
+the MAINTAINERS file. Such maintainers will follow one of the above
+workflows, e. g. they will either send a pull request or merge patches
+directly at the media-committers tree.
+
 When patches are picked by patchwork and when merged at media-committers,
 CI bots will check for errors and may provide e-mail feedback about
 patch problems. When this happens, the patch submitter must fix them
diff --git a/Documentation/driver-api/media/media-committer.rst 
b/Documentation/driver-api/media/media-committer.rst
index 1756a7af6353..a873ef84fbca 100644
--- a/Documentation/driver-api/media/media-committer.rst
+++ b/Documentation/driver-api/media/media-committer.rst
@@ -87,9 +87,9 @@ be delegating part of their maintenance tasks.
 Due to that, to become a committer or a core committer, a consensus between
 all subsystem maintainers is required, as they all need to trust a developer
 well enough to be delegated the responsibility to maintain part of the code
-and to properly review patches from third parties, in a timely manner and
-keeping the status of the reviewed code at https://patchwork.linuxtv.org
-updated.
+and to properly review patches from third parties for the drivers they are
+maintainers in a timely manner and keeping the status of the reviewed code
+at https://patchwork.linuxtv.org updated.
 
 .. Note::
 

[PATCH v2 0/2] Document the new media-committer's model

[Mauro Carvalho Chehab]

The media subsystem used to have a multi-commiter's model in the
past, but things didn't go well on that time, and we had to move to
a centralized model.

As the community has evolved, and as there are now new policies in
place like CoC, let's experiment with a multi-committers again.

The model we're using was inspired by the DRM multi-committers
model. Yet, media subsystem is different on several aspects, so the
model is not exactly the same.

The implementation will be in phases. For this phase, the goal is that 
all committers will be people listed at MAINTAINERS.

On this series,:

patch 1: updates the  media maintainer's entry profile and adds the
workflow that will be used with the new model. While here, it also
adds a missing "P:" tag at the MAINTAINERS file, pointing to it;

patch 2: adds a new document focused at the new maintainers
process. Its target is for developers that will be granted with
commit rights at the new media-maintainers.git tree. It also
contains a reference tag addition to kernel.org PGP chain
at process/maintainer-pgp-guide.rst.

---

v2: I tried to address most of the suggestions where there was an agreement
from Laurent's review and further comments. As there were several changes,
on separate threads, I could have missed something.

Mauro Carvalho Chehab (2):
  docs: media: update maintainer-entry-profile for multi-committers
  docs: media: document media multi-committers rules and process

 Documentation/driver-api/media/index.rst  |   1 +
 .../media/maintainer-entry-profile.rst| 209 ++---
 .../driver-api/media/media-committer.rst  | 278 ++
 .../process/maintainer-pgp-guide.rst  |   2 +
 MAINTAINERS   |   1 +
 5 files changed, 446 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/driver-api/media/media-committer.rst

-- 
2.47.0

[PATCH v2 2/2] docs: media: document media multi-committers rules and process

[Mauro Carvalho Chehab]

As the media subsystem will experiment with a multi-committers model,
update the Maintainer's entry profile to the new rules, and add a file
documenting the process to become a committer and to maintain such
rights.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Hans Verkuil 
---
 Documentation/driver-api/media/index.rst  |   1 +
 .../media/maintainer-entry-profile.rst|   8 +
 .../driver-api/media/media-committer.rst  | 278 ++
 .../process/maintainer-pgp-guide.rst  |   2 +
 4 files changed, 289 insertions(+)
 create mode 100644 Documentation/driver-api/media/media-committer.rst

diff --git a/Documentation/driver-api/media/index.rst 
b/Documentation/driver-api/media/index.rst
index d5593182a3f9..d0c725fcbc67 100644
--- a/Documentation/driver-api/media/index.rst
+++ b/Documentation/driver-api/media/index.rst
@@ -26,6 +26,7 @@ Documentation/userspace-api/media/index.rst
 :numbered:
 
 maintainer-entry-profile
+media-committer
 
 v4l2-core
 dtv-core
diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst 
b/Documentation/driver-api/media/maintainer-entry-profile.rst
index 47f15fad7f9f..650803c30c41 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -62,6 +62,9 @@ as described at Documentation/process/index.rst and to the 
Kernel
 development rules inside the Kernel documentation, including its code of
 conduct.
 
+More details about media commiters' roles and responsibilities can be
+found here: Documentation/driver-api/media/media-committer.rst.
+
 Media development tree
 --
 
@@ -195,6 +198,11 @@ shall be validated by using PGP sign, via the
 
 With the pull request workflow, pull requests shall use a GPG-signed tag.
 
+With the committers' workflow, this is ensured at the time merge request
+rights will be granted to the gitlab instance used by media-committers.git
+tree, after receiving the e-mail documented at
+:ref:`media-committer-agreement`.
+
 For more details about PGP sign, please read
 Documentation/process/maintainer-pgp-guide.rst.
 
diff --git a/Documentation/driver-api/media/media-committer.rst 
b/Documentation/driver-api/media/media-committer.rst
new file mode 100644
index ..1756a7af6353
--- /dev/null
+++ b/Documentation/driver-api/media/media-committer.rst
@@ -0,0 +1,278 @@
+Media committers
+
+
+What is a media committer?
+--
+
+A media committer is a developer who can push patches from other developers
+and their own patches to the
+`media-committers 
`_
+tree.
+
+It is a media committer's duty to ensure that their entries in the MAINTAINERS
+file are kept up-to-date, and that submitted patches for files for which
+they are listed as maintainers are timely reviewed on the mailing list,
+ideally not waiting in patchwork as ``New`` for more than one Kernel merge
+cycle, and, if accepted, applying them at the media committer's tree.
+
+These commit rights are granted with some expectation of responsibility:
+committers are people who care about the Linux Kernel as a whole and
+about the Linux media subsystem and want to help its development. It
+is also based on a trust relationship between the rest of the committers,
+maintainers and the Linux Media community.
+
+The Linux Media community, also called LinuxTV community, has its primary
+site at https://linuxtv.org.
+
+As such, a media committer is not just someone who is capable of creating
+code, but someone who has demonstrated their ability to collaborate
+with the team, get the most knowledgeable people to review code,
+contribute high-quality code, and follow through to fix issues (in code
+or tests).
+
+.. Note::
+
+   1. If a patch introduces a regression, then it is the media committer's
+  responsibility to correct that as soon as possible. Typically the
+  patch is either reverted, or an additional patch is committed that
+  fixes the regression;
+   2. if patches are fixing bugs against already released Kernels, including
+  the reverts above mentioned, the media committer shall add the needed
+  tags. Please see :ref:`Media development workflow` for more details.
+
+Becoming a media committer
+--
+
+The most important aspect of volunteering to be a committer is that you have
+demonstrated the ability to give good code reviews. So we are looking for
+whether or not we think you will be good at doing that.
+
+As such, potential committers must earn enough credibility and trust from the
+LinuxTV community. To do that, developers shall be familiar with the open
+source model and have been active in the Linux Kernel community for some time,
+and, in particular, in the media subsystem.
+
+So, in addition to actually making the code changes, you are basically
+demonstrating your:
+
+- commitme

Re: [PATCH v2 2/2] docs: media: document media multi-committers rules and process

[Ricardo Ribalda Delgado]

Minor nits here and there

On Fri, Nov 29, 2024 at 12:15 PM Mauro Carvalho Chehab
 wrote:
>
> As the media subsystem will experiment with a multi-committers model,
> update the Maintainer's entry profile to the new rules, and add a file
> documenting the process to become a committer and to maintain such
> rights.
>
> Signed-off-by: Mauro Carvalho Chehab 
> Signed-off-by: Hans Verkuil 
Reviewed-by: Ricardo Ribalda 
> ---
>  Documentation/driver-api/media/index.rst  |   1 +
>  .../media/maintainer-entry-profile.rst|   8 +
>  .../driver-api/media/media-committer.rst  | 278 ++
>  .../process/maintainer-pgp-guide.rst  |   2 +
>  4 files changed, 289 insertions(+)
>  create mode 100644 Documentation/driver-api/media/media-committer.rst
>
> diff --git a/Documentation/driver-api/media/index.rst 
> b/Documentation/driver-api/media/index.rst
> index d5593182a3f9..d0c725fcbc67 100644
> --- a/Documentation/driver-api/media/index.rst
> +++ b/Documentation/driver-api/media/index.rst
> @@ -26,6 +26,7 @@ Documentation/userspace-api/media/index.rst
>  :numbered:
>
>  maintainer-entry-profile
> +media-committer
>
>  v4l2-core
>  dtv-core
> diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst 
> b/Documentation/driver-api/media/maintainer-entry-profile.rst
> index 47f15fad7f9f..650803c30c41 100644
> --- a/Documentation/driver-api/media/maintainer-entry-profile.rst
> +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
> @@ -62,6 +62,9 @@ as described at Documentation/process/index.rst and to the 
> Kernel
>  development rules inside the Kernel documentation, including its code of
>  conduct.
>
> +More details about media commiters' roles and responsibilities can be
> +found here: Documentation/driver-api/media/media-committer.rst.
> +
>  Media development tree
>  --
>
> @@ -195,6 +198,11 @@ shall be validated by using PGP sign, via the
>
>  With the pull request workflow, pull requests shall use a GPG-signed tag.
>
> +With the committers' workflow, this is ensured at the time merge request
> +rights will be granted to the gitlab instance used by media-committers.git
> +tree, after receiving the e-mail documented at
> +:ref:`media-committer-agreement`.
I am not sure I understand this sentence correctly. I guess you mean:

With the committers workflow, this is ensured during merge request via
gitlab credentials.
Committers will be granted access to the gitlab instance used by
media-committers.git
tree, after receiving the e-mail documented at :ref:`media-committer-agreement`.


> +
>  For more details about PGP sign, please read
>  Documentation/process/maintainer-pgp-guide.rst.
>
> diff --git a/Documentation/driver-api/media/media-committer.rst 
> b/Documentation/driver-api/media/media-committer.rst
> new file mode 100644
> index ..1756a7af6353
> --- /dev/null
> +++ b/Documentation/driver-api/media/media-committer.rst
> @@ -0,0 +1,278 @@
> +Media committers
> +
> +
> +What is a media committer?
> +--
> +
> +A media committer is a developer who can push patches from other developers
> +and their own patches to the
> +`media-committers 
> `_
> +tree.
> +
> +It is a media committer's duty to ensure that their entries in the 
> MAINTAINERS
> +file are kept up-to-date, and that submitted patches for files for which
> +they are listed as maintainers are timely reviewed on the mailing list,
> +ideally not waiting in patchwork as ``New`` for more than one Kernel merge
> +cycle, and, if accepted, applying them at the media committer's tree.
> +
> +These commit rights are granted with some expectation of responsibility:
> +committers are people who care about the Linux Kernel as a whole and
> +about the Linux media subsystem and want to help its development. It
> +is also based on a trust relationship between the rest of the committers,
> +maintainers and the Linux Media community.
> +
> +The Linux Media community, also called LinuxTV community, has its primary
> +site at https://linuxtv.org.
> +
> +As such, a media committer is not just someone who is capable of creating
> +code, but someone who has demonstrated their ability to collaborate
> +with the team, get the most knowledgeable people to review code,
> +contribute high-quality code, and follow through to fix issues (in code
> +or tests).
> +
> +.. Note::
> +
> +   1. If a patch introduces a regression, then it is the media committer's
> +  responsibility to correct that as soon as possible. Typically the
> +  patch is either reverted, or an additional patch is committed that
> +  fixes the regression;
> +   2. if patches are fixing bugs against already released Kernels, including
> +  the reverts above mentioned, the media committer shall add the needed
> +  tags. Please see :ref:`Media development workflow` for more details.
> +
> +Be

Re: [RFC PATCH v3 11/15] context-tracking: Introduce work deferral infrastructure

[Valentin Schneider]

On 24/11/24 22:46, Frederic Weisbecker wrote:
> Le Fri, Nov 22, 2024 at 03:56:59PM +0100, Valentin Schneider a écrit :
>> On 20/11/24 18:30, Frederic Weisbecker wrote:
>> > Le Wed, Nov 20, 2024 at 06:10:43PM +0100, Valentin Schneider a écrit :
>> >> On 20/11/24 15:23, Frederic Weisbecker wrote:
>> >>
>> >> > Ah but there is CT_STATE_GUEST and I see the last patch also applies 
>> >> > that to
>> >> > CT_STATE_IDLE.
>> >> >
>> >> > So that could be:
>> >> >
>> >> > bool ct_set_cpu_work(unsigned int cpu, unsigned int work)
>> >> > {
>> >> >struct context_tracking *ct = per_cpu_ptr(&context_tracking, cpu);
>> >> >unsigned int old;
>> >> >bool ret = false;
>> >> >
>> >> >preempt_disable();
>> >> >
>> >> >old = atomic_read(&ct->state);
>> >> >
>> >> >/* CT_STATE_IDLE can be added to last patch here */
>> >> >if (!(old & (CT_STATE_USER | CT_STATE_GUEST))) {
>> >> >old &= ~CT_STATE_MASK;
>> >> >old |= CT_STATE_USER;
>> >> >}
>> >>
>> >> Hmph, so that lets us leverage the cmpxchg for a !CT_STATE_KERNEL check,
>> >> but we get an extra loop if the target CPU exits kernelspace not to
>> >> userspace (e.g. vcpu or idle) in the meantime - not great, not terrible.
>> >
>> > The thing is, what you read with atomic_read() should be close to reality.
>> > If it already is != CT_STATE_KERNEL then you're good (minus racy changes).
>> > If it is CT_STATE_KERNEL then you still must do a failing cmpxchg() in any 
>> > case,
>> > at least to make sure you didn't miss a context tracking change. So the 
>> > best
>> > you can do is a bet.
>> >
>> >>
>> >> At the cost of one extra bit for the CT_STATE area, with CT_STATE_KERNEL=1
>> >> we could do:
>> >>
>> >>   old = atomic_read(&ct->state);
>> >>   old &= ~CT_STATE_KERNEL;
>> >
>> > And perhaps also old |= CT_STATE_IDLE (I'm seeing the last patch now),
>> > so you at least get a chance of making it right (only ~CT_STATE_KERNEL
>> > will always fail) and CPUs usually spend most of their time idle.
>> >
>> 
>> I'm thinking with:
>> 
>> CT_STATE_IDLE= 0,
>> CT_STATE_USER= 1,
>> CT_STATE_GUEST   = 2,
>> CT_STATE_KERNEL  = 4, /* Keep that as a standalone bit */
>
> Right!
>
>> 
>> we can stick with old &= ~CT_STATE_KERNEL; and that'll let the cmpxchg
>> succeed for any of IDLE/USER/GUEST.
>
> Sure but if (old & CT_STATE_KERNEL), cmpxchg() will consistently fail.
> But you can make a bet that it has switched to CT_STATE_IDLE between
> the atomic_read() and the first atomic_cmpxchg(). This way you still have
> a tiny chance to succeed.
>
> That is:
>
>old = atomic_read(&ct->state);
>if (old & CT_STATE_KERNEl)
>   old |= CT_STATE_IDLE;
>old &= ~CT_STATE_KERNEL;
>
>
>do {
>   atomic_try_cmpxchg(...)
>
> Hmm?

But it could equally be CT_STATE_{USER, GUEST}, right? That is, if we have
all of this enabled them we assume the isolated CPUs spend the least amount
of time in the kernel, if they don't we get to blame the user.

Re: [RFC PATCH v3 11/15] context-tracking: Introduce work deferral infrastructure

[Frederic Weisbecker]

Le Fri, Nov 29, 2024 at 05:40:29PM +0100, Valentin Schneider a écrit :
> On 24/11/24 22:46, Frederic Weisbecker wrote:
> > Le Fri, Nov 22, 2024 at 03:56:59PM +0100, Valentin Schneider a écrit :
> >> On 20/11/24 18:30, Frederic Weisbecker wrote:
> >> > Le Wed, Nov 20, 2024 at 06:10:43PM +0100, Valentin Schneider a écrit :
> >> >> On 20/11/24 15:23, Frederic Weisbecker wrote:
> >> >>
> >> >> > Ah but there is CT_STATE_GUEST and I see the last patch also applies 
> >> >> > that to
> >> >> > CT_STATE_IDLE.
> >> >> >
> >> >> > So that could be:
> >> >> >
> >> >> > bool ct_set_cpu_work(unsigned int cpu, unsigned int work)
> >> >> > {
> >> >> >struct context_tracking *ct = per_cpu_ptr(&context_tracking, cpu);
> >> >> >unsigned int old;
> >> >> >bool ret = false;
> >> >> >
> >> >> >preempt_disable();
> >> >> >
> >> >> >old = atomic_read(&ct->state);
> >> >> >
> >> >> >/* CT_STATE_IDLE can be added to last patch here */
> >> >> >if (!(old & (CT_STATE_USER | CT_STATE_GUEST))) {
> >> >> >old &= ~CT_STATE_MASK;
> >> >> >old |= CT_STATE_USER;
> >> >> >}
> >> >>
> >> >> Hmph, so that lets us leverage the cmpxchg for a !CT_STATE_KERNEL check,
> >> >> but we get an extra loop if the target CPU exits kernelspace not to
> >> >> userspace (e.g. vcpu or idle) in the meantime - not great, not terrible.
> >> >
> >> > The thing is, what you read with atomic_read() should be close to 
> >> > reality.
> >> > If it already is != CT_STATE_KERNEL then you're good (minus racy 
> >> > changes).
> >> > If it is CT_STATE_KERNEL then you still must do a failing cmpxchg() in 
> >> > any case,
> >> > at least to make sure you didn't miss a context tracking change. So the 
> >> > best
> >> > you can do is a bet.
> >> >
> >> >>
> >> >> At the cost of one extra bit for the CT_STATE area, with 
> >> >> CT_STATE_KERNEL=1
> >> >> we could do:
> >> >>
> >> >>   old = atomic_read(&ct->state);
> >> >>   old &= ~CT_STATE_KERNEL;
> >> >
> >> > And perhaps also old |= CT_STATE_IDLE (I'm seeing the last patch now),
> >> > so you at least get a chance of making it right (only ~CT_STATE_KERNEL
> >> > will always fail) and CPUs usually spend most of their time idle.
> >> >
> >> 
> >> I'm thinking with:
> >> 
> >> CT_STATE_IDLE  = 0,
> >> CT_STATE_USER  = 1,
> >> CT_STATE_GUEST = 2,
> >> CT_STATE_KERNEL= 4, /* Keep that as a standalone bit */
> >
> > Right!
> >
> >> 
> >> we can stick with old &= ~CT_STATE_KERNEL; and that'll let the cmpxchg
> >> succeed for any of IDLE/USER/GUEST.
> >
> > Sure but if (old & CT_STATE_KERNEL), cmpxchg() will consistently fail.
> > But you can make a bet that it has switched to CT_STATE_IDLE between
> > the atomic_read() and the first atomic_cmpxchg(). This way you still have
> > a tiny chance to succeed.
> >
> > That is:
> >
> >old = atomic_read(&ct->state);
> >if (old & CT_STATE_KERNEl)
> >   old |= CT_STATE_IDLE;
> >old &= ~CT_STATE_KERNEL;
> >
> >
> >do {
> >   atomic_try_cmpxchg(...)
> >
> > Hmm?
> 
> But it could equally be CT_STATE_{USER, GUEST}, right? That is, if we have
> all of this enabled them we assume the isolated CPUs spend the least amount
> of time in the kernel, if they don't we get to blame the user.

Unless CONTEXT_TRACKING_WORK_IDLE=y yes.

Anyway that's just a detail that can be refined in the future. I'm fine with
just clearing CT_STATE_KERNEL and go with that.

Thanks.