|
Hello,
On Fri, 3 Apr 2026, Pablo Neira Ayuso wrote:
> On Fri, Apr 03, 2026 at 05:15:50PM +0300, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Tue, 31 Mar 2026, Waiman Long wrote:
> >
> > > v2:
> > > - Rebased on top of linux-next
> > >
> > > Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for preferred
> > > affinity management"), the HK_TYPE_KTHREAD housekeeping cpumask may no
> > > longer be correct in showing the actual CPU affinity of kthreads that
> > > have no predefined CPU affinity. As the ipvs networking code is still
> > > using HK_TYPE_KTHREAD, we need to make HK_TYPE_KTHREAD reflect the
> > > reality.
> > >
> > > This patch series makes HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > and uses RCU to protect access to the HK_TYPE_KTHREAD housekeeping
> > > cpumask.
> > >
> > > Waiman Long (2):
> > > sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
> > > ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
> >
> > The patchset looks good to me for nf-next, thanks!
> >
> > Acked-by: Julian Anastasov <ja@xxxxxx>
> >
> > Pablo, Florian, as a bugfix this patchset missed
> > the chance to be applied before the changes that are in
> > nf-next in ip_vs.h, there is little fuzz there. If there
> > is no chance to resolve it somehow, we can apply it
> > on top of nf-next where it now applies successfully.
>
> One way to handle this is to follow up with nf-next as you suggest,
> then send a backport that applies cleanly for -stable once it is
> released.
Lets do it this way, thanks!
> Else, let me know if I am misunderstanding.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
