linux-kernel - Re: [GIT PULL] XArray for 4.19

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180822025040.GA12244@bombadil.infradead.org>
Date:   Tue, 21 Aug 2018 19:50:40 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-mm <linux-mm@...ck.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] XArray for 4.19

On Tue, Aug 21, 2018 at 07:09:31PM -0700, Linus Torvalds wrote:
> On Mon, Aug 13, 2018 at 9:14 AM Matthew Wilcox <willy@...radead.org> wrote:
> >
> > Please consider pulling the XArray patch set.
> 
> So this merge window has been horrible, but I was just about to start
> looking at it.
> 
> And no. I'm not going to pull this.
> 
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.

I said in the pull request ...

  There are two conflicts I wanted to flag; the first is against the
  linux-nvdimm tree.  I rebased on top of one of the branches that went
  into that tree, so if you pull my tree before linux-nvdimm, you'll get
  fifteen commits I've had no involvement with.

Dan asked me to do that so that his commit (which I had no involvement
with) would be easier to backport.  At the time I thought this was a
reasonable request; I know this API change is disruptive and I wanted
to accommodate that.  I didn't know his patch was "complete garbage";
I didn't review it.

So, should I have based just on your tree and sent you a description of
what a resolved conflict should look like?

> And since I won't be merging this, I clearly won't be merging your
> other pull request that depended on this either.

I can yank most of the patches (all but the last two, iirc) out of the
IDA patchset and submit those as a separate pull request.  Would that
be acceptable?  I'm really struggling to juggle all the pieces here to
get them merged.