Re: fixing sashiko failure to apply (was Re: [PATCH v5 00/16] mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff)

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Aug 14, 2026 at 10:19:10PM -0400, Zi Yan wrote:
> <snip>
> >> >>
> >> >>>>
> >> >>>> Sashiko can be guided with a base-commit: tag but I'm not sure how to
> >> >>>> tell it what tree/branch to try, or even if that's necessary.  Perhaps
> >> >>>> someone can figure this out sometime.
> >> >>>
> >> >>> b4 gives a base commit, but I think because the trees are rebased it ends
> >> >>> up being the incorrect one.
> >> >>>
> >> >>> Not sure what the solution is!
> >> >>>
> >> >>
> >> >> We have seen this on the Xe list (our list is based on drm-tip),
> >> >> typically with cross-subsystem patches. Some cross-subsystem patches
> >> >> apply and run correctly, while others do not but public CI flows run
> >> >> based on drm-tip. I do not have a bisect or a clear understanding of
> >> >> what works and what doesn't, but I think it would be very useful if the
> >> >> community could better understand the root cause.
> >> >
> >> > As Mike said, mm-unstable/mm-new is heavily rebased and also carries the old
> >> > version of the series before the new one is applied, so it's super unclear what
> >> > the base commit should be there.
> >> >
> >> > But in general, I wonder if it's possible that we could tell sashiko
> >> > after-the-fact what base commit to look at once the series is in, or re-trigger
> >> > it somehow once it's in-tree?
> >> >
> >> > Roman - any suggestions on what we could do to help sashiko find things?
> >> >
> >> > (Once mm-next is in place everything with change again, but can address that
> >> > then :)
> >>
> >> I can implement any reasonable logic here, the problem is that my understanding is
> >> the current mm process is a bit vague here. Which likely will be also an issue for the mm ci.
> >> I’ll merge a support for b4-like dependencies specification soon.
> >
> > Yeah I suspect things might be tricky with mm given the rebases honestly.
> >
> >>
> >> Re re-starting with manual selection it’s on my todo list, but maybe a bit lfurther away, as it requires
> >> an authorization, etc.
> >
> > Yeah that's the fly in the ointment I guess for many things like giving instant
> > feedback on accuracy, well you want to make sure the person giving it is who you
> > think they are :)
> >
> > Probably an email -> author with magic link or something but thinking through
> > how to avoid abuse/spam/rate limiting everything etc. is surely all a pain :)
>
> If b4 is used, the cover letter comes with a fixed change-id. That can
> be a good id for new patch series replacement. For patches do not use
> b4, authors can add their own change-id. Without change-id, if the new
> version comes with a link to the prior version, that can be helpful too.
> If none is present, author email + patch title might be the last resort.
> But I think we need to encourage authors to provide some id for their
> patches to make replacement easier instead of spending too much effort
> on identifying different patch versions.

Agree, but with mm constantly rebasing these hashes become potentially less
useful :)

>
> --
> Best Regards,
> Yan, Zi
>

--
Cheers, Lorenzo