Seth Forshee seth.forshee at canonical.com
Thu Apr 9 18:16:50 UTC 2020

On Thu, Apr 09, 2020 at 03:13:03PM -0300, Thadeu Lima de Souza Cascardo wrote:
> On Thu, Apr 09, 2020 at 12:55:10PM -0500, Seth Forshee wrote:
> > On Wed, Apr 08, 2020 at 06:06:18PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > > This option should not be set, under risk of causing regression for
> > > userspace. This has been tested that updateconfigs won't fail after getting
> > > this applied.
> > 
> > The problem I see here is that during our normal config review workflow
> > the option would naturally get removed from the annotations file, so
> > we'll have to somehow remember that this option is special and should be
> > kept around even though the tools will try to remove it. That seems very
> > error prone.
> > 
> > I guess for stable this approach works, since changes to the annotations
> > file are manual. I think we need to find a better solution for unstable.
> > 
> > Looking at unstable, it appears the only way this option could get
> > selected is if VIRT_CPU_ACCOUNTING_GEN is enabled. Maybe we could
> > enforce this option instead? I know this is also somewhat fragile,
> > though I think it's somewhat less fragile than what you're proposing.
> > Otherwise it seems like we need to enhance our annotations to better
> > support a non-selectable option that we want to have enforced.
> > 
> > Seth
> Yes, this has all made me think more about how we are considering
> changes to how we enforce the annotations file, and yes, that some
> options are more special than others.
> On the other hand, the case here is about kernel behavior in respect to
> some userspace code, and that needs to be gated by a userspace test,
> just like we do for many other things. I will work on a test for this
> particular bug, which I think is more important than doing the
> annotations properly.
> I would rather not enforce VIRT_CPU_ACCOUNTING_GEN because of this. We
> want to enforce CONTEXT_TRACKING_FORCE, and this is just not right the
> same as enforcing USB_OTG_FSM only because it selects USB_OTG. I will
> let you decide what to do for unstable, but maybe should be applied to
> focal and the stable releases?

Yeah, I'm ok with applying to focal and the stables. I just don't think
it's sustainable to relying on everyone to remember to keep that
annotation around in devel kernels when the tools try to delete it. We
either need to improve the tools, or as you say have a test case in

More information about the kernel-team mailing list