linux-kernel - Re: [PATCH v14 0/5] DMA-BUF Heaps (destaging ION)

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Nov 2019 11:21:21 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Pekka Paalanen <ppaalanen@...il.com>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Hillf Danton <hdanton@...a.com>,
        Sudipto Paul <Sudipto.Paul@....com>,
        Sandeep Patil <sspatil@...gle.com>,
        Vincent Donnefort <Vincent.Donnefort@....com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        Liam Mark <lmark@...eaurora.org>,
        Christoph Hellwig <hch@...radead.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "Andrew F . Davis" <afd@...com>,
        Hridya Valsaraju <hridya@...gle.com>,
        Pratik Patel <pratikp@...eaurora.org>
Subject: Re: [PATCH v14 0/5] DMA-BUF Heaps (destaging ION)

On Mon, Nov 4, 2019 at 12:18 AM Pekka Paalanen <ppaalanen@...il.com> wrote:
> On Fri,  1 Nov 2019 21:42:33 +0000
> John Stultz <john.stultz@...aro.org> wrote:
>
> > This again? I know!
> >
> > Apologies to all who hoped I'd stop bothering them with this
> > patch set, but I ran afoul of the DRM tree rules by not
> > getting the userland patches properly reviewed prior to the
> > patches landing (I mistakenly was waiting for the patches to
> > land upstream before pushing the userland patches). Thus,
> > these were correctly reverted from the drm-misc-next tree.
>
> Hi John,
>
> mind, you have to get userland patches reviewed and accepted but *not
> pushed*.
>
> You cannot push/merge userland patches before the kernel patches have
> properly landed, that bit you got right. But the supposedly confusing
> bit is that for kernel patches to land, the userspace patches must be
> reviewed and accepted first.
>
> I just wanted to clarify this since you wrote "before pushing the
> userland patches" above.

Yea. Sorry, "pushed" isn't a very clear term. In AOSP, one must push a
patch to Gerrit before it is reviewed.
However, once something is reviewed it usually is merged immediately
(pending automated precommit testing).

So I tend to use the term "pushed for review" as submitting patches
for review as ready to be merged. In this case, technically I had
actually "pushed" the changes to Gerrit, but hadn't added anyone to
review, to ensure the patches were not' accidentally reviewed and
merged.
But If you look at the Gerrit log now, you'll see I've added reviewers
and provided a note explicitly to not merge the changes.

So apologies for the confusion. I do believe I understand the
requirement now, and am doing my best to adhere to them.

That said, given different userland projects use different approaches,
I do find it a little strange on the insistence that userland patches
cannot be merged to their project before the kernel changes land.
Obviously no interface is final and any userland that does so has some
risk that it will change and break, but there are many cases where
distros support new features in their userland not yet merged
upstream.  Ensuring there is a real opensource user for the kernel
feature is important, but I'm not sure I understand why the kernel is
dictating rules as to how userspace merges code.

thanks
-john