Re: [RFC] in-kernel rseq

[Shrikanth Hegde]

Hi Heiko.

On 4/15/26 2:21 PM, Heiko Carstens wrote:
> On Fri, Apr 10, 2026 at 11:27:50PM +0530, Shrikanth Hegde wrote:
> > Hi Peter,
> >
> > On 2/23/26 10:08 PM, Peter Zijlstra wrote:
> > > Hi,
> > >
> > > It has come to my attention that various people are struggling with
> > > preempt_disable()+preempt_enable() costs for various architectures.
> > >
> > > Mostly in relation to things like this_cpu_ and or local_.
> > >
> > > The below is a very crude (and broken, more on that below) POC.
> > >
> > > So the 'main' advantage of this over preempt_disable()/preempt_enable(),
> > > it on the preempt_enable() side, this elides the whole conditional and
> > > call schedule() nonsense.
> >
> > This might be a very stupid question.
> >
> > Why not just call preempt_enable_no_resched instead?
> >
> > this_cpu operations would have disabled preemption so the per_cpu
> > structures are protected from thread migration right? intention
> > here is likely not to call schedule. No?
>
> Doing that would make it unpredictable when the kernel is preempted for
> cases where TIF_PREEMPT is set while within a code section which has
> preemption disabled and where preemption is enabled again without checking
> for TIF_PREEMPT.


Ok. I discussed this with peter too. Likely we need to do something using paca.
I will go through your implementation.

While there, maybe move preempt count to paca too which has been long pending.
atleast for ppc64.