From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DC5E40B6F9 for ; Fri, 14 Aug 2026 09:29:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786699801; cv=none; b=a3ULk4ndE4EyS9v/9I28IWfHk04JB9tAmWWFyKvluXxN6q49mvEeBx0Kw6MUXBxdxwGEGZxLLkddyuMTKzCzbtPz7XgCrBPOR2h72ChNGtZvwvYjeZoJSJBiE8GOt5KfEqbNf2EaiU+giMGA5OPs6uIsTzep+q999cf2e4IbWRU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786699801; c=relaxed/simple; bh=cc6BU9wWtNhMKlYaqjnRDY4Z6b0gpNlJgqvNyY8GnW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aGwcTk6IGr0NE1PuWsra0dY+mFkSWWh2juWaPmpkxH+LFy7fvpH/mb9n1rzEBXQacmqNkb5beMt4hCcDrDnBCilg6JhMtSuUPjM3XHQNh59+Glw5NeGsgZjlXWXo/wR8oyFroOA0f1PhuiAYMIFPkvN2HLaJF5KC0dkWVKxJG60= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bnMCXQUy; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bnMCXQUy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B93B1F000E9; Fri, 14 Aug 2026 09:29:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786699799; bh=pR+WbG5AZxnbq3/8UA85wA3JdOFTvne7kZZjVo/Xlg0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=bnMCXQUylHNat1G2X/LJDp7I9cE2lm1aNs8Yo8h6MZOcjOaQTRYaohoOipPc8YLzp Y7JbwJ3e+V6j9xRMZNj3bdF+5fJFIwICK7FkX2QvoLw7WyK+HytseJ+i0LDL/BT22y YsMdiJPywOZ5KuNyvJ5uS6jk97Qt8DJWBdk3vCMQyauHEpmauMEDWpcgW6H/DPxbmz 6aJTMbguYtX1vm0j2jnoVF6WD+DSFu1qLphQj9YchEwUMYSNOToaIoJ8qBchj8k3xC Fzp65OdRIcW/EYDvOGUzPPJbgQuZYiQ2NMeV8cZtkUcRIa7vxzqPhKEkNF/UwGN+V8 cIMrocxDL0rqw== Date: Fri, 14 Aug 2026 10:29:41 +0100 From: "Lorenzo Stoakes (ARM)" To: Matthew Brost Cc: Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Roman Gushchin Subject: fixing sashiko failure to apply (was Re: [PATCH v5 00/16] mm/rmap: index MAP_PRIVATE file-backed folios by anonymous pgoff) Message-ID: References: <20260813-b4-scalable-cow-virt-pgoff-v5-0-c21581c0c3c8@kernel.org> <20260813115346.2aaad419a351341a4f5f3ae0@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [ trim cc list ] +cc Roman On Fri, Aug 14, 2026 at 02:13:51AM -0700, Matthew Brost wrote: > On Fri, Aug 14, 2026 at 10:01:19AM +0100, Lorenzo Stoakes (ARM) wrote: > > On Thu, Aug 13, 2026 at 11:53:46AM -0700, Andrew Morton wrote: > > > You'll be mortified to hear that Sashiko wasn't able to find anything > > > to which to apply this. > > > > :)) > > > > Well, when it's right it's useful, when it's wrong or suggesting unrelated > > what-nots it's less useful :>) > > > > Questioning your assumptions is useful, even when they turn out to be wrong. > Show more lines > > > I do locally put things through claude + Chris Mason's prompts a lot, I > > don't always invoke local sashiko as it's very slow and token-heavy or has > > been so far, but am planning to do that more also in future. > > > > Yes, it's kind of odd that Sashiko burns more tokens than a full day of > breakfast, lunch, and dinner service. Running Sashiko is a bottleneck in > my workflow, so I'll defer to others on this list. Yup, not sure if there are recommended configs for something saner :) Maybe Roman has some advice on that? > > > > > > > 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 :) > > Matt > -- Cheers, Lorenzo