lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 12 Jun 2020 22:32:15 -0700
From:   "Darrick J. Wong" <>
To:     Linus Torvalds <>
Cc:     "Darrick J. Wong" <>,
        linux-fsdevel <>,
        linux-xfs <>,
        Dave Chinner <>,
        Linux Kernel Mailing List <>,
        Eric Sandeen <>,
        Christoph Hellwig <>,
        linux-ext4 <>,
        "Theodore Ts'o" <>,
Subject: Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 3

On Thu, Jun 11, 2020 at 11:00:43AM -0700, Linus Torvalds wrote:
> On Wed, Jun 10, 2020 at 7:43 PM Darrick J. Wong <> wrote:
> >
> > I did a test merge of this branch against upstream this evening and
> > there weren't any conflicts.  The first five patches in the series were
> > already in the xfs merge, so it's only the last one that should change
> > anything.  Please let us know if you have any complaints about pulling
> > this, since I can rework the branch.
> I've taken this, but I hate how the patches apparently got duplicated.
> It feels like they should have been a cleanly separated branch that
> was just pulled into whoever needed them when they were ready, rather
> than applied in two different places.
> So this is just a note for future work - duplicating the patches like
> this can cause annoyances down the line. No merge issues this time
> (they often happen when duplicate patches then have other work done on
> top of them), but things like "git bisect" now don't have quite as
> black-and-white a situation etc etc.,
> ("git bisect" will still find _one_ of the duplicate commits if it
> introduced a problem, so it's usually not a huge deal, but it can
> cause the bug to be then repeated if people revert that one, but
> nobody ever notices that the other commit that did the same thing is
> still around and it gets back-ported to stable or whatever..)
> So part of this is just in general about confusing duplicate history,
> and part of it is that the duplication can then cause later confusion.

Urgh, sorry.  I /was/ careful to make sure the patches matched, but I'll
be more careful the next time this (hopefully never) happens again. :/


>                 Linus

Powered by blists - more mailing lists