Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20231018184613.tphd3grenbxwgy2v@quack3> <ZTDtAiDRuPcS2Vwd@smile.fi.intel.com>
 <20231019101854.yb5gurasxgbdtui5@quack3> <ZTEap8A1W3IIY7Bg@smile.fi.intel.com>
 <ZTFAzuE58mkFbScV@smile.fi.intel.com> <20231019164240.lhg5jotsh6vfuy67@treble>
 <ZTFh0NeYtvgcjSv8@smile.fi.intel.com> <CAHk-=wjXG52UNKCwwEU1A+QWHYfvKOieV0uFOpPkLR0NSvOjtg@mail.gmail.com>
 <CAHk-=whis2BJF2fv1xySAg2NTQ+C5fViNSGkLNCOqGzi-3y+8w@mail.gmail.com>
 <ZTFxEcjo4d6vXbo5@smile.fi.intel.com> <ZTFydEbdEYlxOxc1@smile.fi.intel.com>
In-Reply-To: <ZTFydEbdEYlxOxc1@smile.fi.intel.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 19 Oct 2023 11:43:47 -0700
Message-ID: <CAHk-=wh_gbZE_ZsQ6+9gSPdXfoCtmuK-MFmBkO3ywMKFQEvb6g@mail.gmail.com>
Subject: Re: [GIT PULL] ext2, quota, and udf fixes for 6.6-rc1
To:     Andy Shevchenko <andriy.shevchenko@intel.com>
Cc:     Josh Poimboeuf <jpoimboe@kernel.org>, Jan Kara <jack@suse.cz>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Kees Cook <keescook@chromium.org>,
        Ferry Toth <ftoth@exalondelft.nl>,
        linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 19 Oct 2023 at 11:16, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> Meanwhile a wild idea, can it be some git (automatic) conflict resolution that
> makes that merge affect another (not related to the main contents of the merge)
> files? Like upstream has one base, the merge has another which is older/newer
> in the history?

I already looked at any obvious case of that.

The only quota-related issue on the other side is an obvious
one-liner: commit 86be6b8bd834 ("quota: Check presence of quota
operation structures instead of ->quota_read and ->quota_write
callbacks").

It didn't affect the merge, because it was not related to  any of the
changes that came in from the quota branch (it was physically close to
the change that used lockdep_assert_held_write() instead of a
WARN_ON_ONCE(down_read_trylock()) sequence, but it is unrelated to
it).

I guess you could try reverting that one-liner after the merge, but I
_really_ don't think it is at all relevant.

What *would* probably be interesting is to start at the pre-merge
state, and rebase the code that got merged in. And then bisect *that*
series.

IOW, with the merge that triggers your bisection being commit
1500e7e0726e, do perhaps something like this:

  # Name the states before the merge
  git branch pre-merge 1500e7e0726e^
  git branch jan-state 1500e7e0726e^2

  # Now double-check that this works for you, of course.
  # Just to be safe...
  git checkout pre-merge
  .. test-build and test-boot this with the bad config ..

  # Then, let's create a new branch that is
  # the rebased version of Jan's state:
  git checkout -b jan-rebased jan-state
  git rebase pre-merge

  # Verify that the tree is the same as the merge
  git diff 1500e7e0726e

  # Ok, that was empty, so do a bisect on this
  # rebased history
  git bisect start
  git bisect bad
  git bisect good pre-merge

.. and see what commit it *now* claims is the bad commit.

Would you be willing to do this? It should be only a few bisects,
since Jan's branch only brought in 17 commits that the above rebases
into this test branch. So four or five bisections should pinpoint the
exact point where it goes bad.

Of course, since this is apparently about some "random code generation
issue", that exact point still may not be very interesting.

                Linus