Thread (81 messages) 81 messages, 5 authors, 2026-02-01

Re: [PATCH v4 00/54] tree-in-dcache stuff

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2026-01-30 07:02:37
Also in: linux-efi, linux-fsdevel, linux-mm, linux-usb, linuxppc-dev, ocfs2-devel, selinux

On Thu, Jan 29, 2026 at 05:16:20PM -0800, Samuel Wu wrote:
On Thu, Jan 29, 2026 at 2:52 PM Al Viro [off-list ref] wrote:
quoted
quoted
Sorry, I hadn't been clear enough: if you do
git switch --detach 1544775687f0
and build the resulting tree, does the breakage reproduce?  What I want
to do is to split e5bf5ee26663 into smaller steps and see which one
introduces the breakage, but the starting point would be verify that
there's no breakage prior to that.
Ultimately, same conclusion as before: 6.18-rc5 with patches up to
1544775687f0 works, but adding e5bf5ee26663 breaks it.
OK.  Could you take a clone of mainline repository and in there run
; git fetch git://git.kernel.org:/pub/scm/linux/kernel/git/viro/vfs.git for-wsamuel:for-wsamuel
then
; git diff for-wsamuel e5bf5ee26663
to verify that for-wsamuel is identical to tree you've seen breakage on
; git diff for-wsamuel-base 1544775687f0
to verify that for-wsamuel-base is the tree where the breakage did not reproduce
Then bisect from for-wsamuel-base to for-wsamuel.

Basically, that's the offending commit split into steps; let's try to figure
out what causes the breakage with better resolution...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help