linux-ext4 - Re: [GIT PULL] vfs: improve DAX behavior for 5.8, part 3

lists.openwall.net		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" <darrick.wong@...cle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Darrick J. Wong" <djwong@...nel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-xfs <linux-xfs@...r.kernel.org>,
        Dave Chinner <david@...morbit.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Eric Sandeen <sandeen@...deen.net>,
        Christoph Hellwig <hch@....de>,
        linux-ext4 <linux-ext4@...r.kernel.org>,
        "Theodore Ts'o" <tytso@....edu>, ira.weiny@...el.com
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 <djwong@...nel.org> 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. :/

--D


>                 Linus