linux-kernel - Re: RISC-V Linux Port v6

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]

Message-ID: <20170712175505.GG15191@arm.com>
Date:   Wed, 12 Jul 2017 18:55:06 +0100
From:   Will Deacon <will.deacon@....com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        Olof Johansson <olof@...om.net>,
        Andrew Morton <akpm@...ux-foundation.org>, albert@...ive.com,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <mmarek@...e.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...hat.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        gregkh <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        David Miller <davem@...emloft.net>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Frédéric Weisbecker <fweisbec@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Doug Ledford <dledford@...hat.com>,
        Bart Van Assche <bart.vanassche@...disk.com>,
        sstabellini@...nel.org, Daniel Vetter <daniel.vetter@...ll.ch>,
        Michael Ellerman <mpe@...erman.id.au>,
        Mark Salter <msalter@...hat.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        James Hogan <james.hogan@...tec.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        patches@...ups.riscv.org
Subject: Re: RISC-V Linux Port v6

On Wed, Jul 12, 2017 at 09:58:01AM +0200, Arnd Bergmann wrote:
> On Wed, Jul 12, 2017 at 3:31 AM, Palmer Dabbelt <palmer@...belt.com> wrote:
> > While it's only been a day since the last patch set (which might be a bit
> > fast), I've generally been spinning new patch sets whenever I get through my
> > inbox.  For my other patch sets I've managed to get buried in a week's worth of
> > email in a few hours, but for this one it appears there's been significantly
> > less feedback so I've managed to get through everything.  I'm hoping that's a
> > good sign: either I've started to figure out what I'm doing or the code has
> > gotten better -- hopefully it doesn't mean everyone else has given up :).
> 
> I don't seem have received the last few versions, but I did get this one,
> good to see the progress!
> 
> A few general notes for the next version:
> 
> - please always include the patch version in the subject for each
>   patch, as 'git format-patch -v 7' will do.
> 
> - In the introductory mail, list the entire history since v1 if you can
>   reconstruct it. I'm pretty lost now keeping track of earlier versions
>   and what has changed compared to this one, so I'd have to start
>   reviewing from scratch.
> 
> > As it's been only a day, the changes are pretty minimal:
> >
> >  * The patch set is now based on linux-next/master, which I believe is a better
> >    base now that we're getting closer to upstream.
> 
> It's not entirely clear though. Until the end of the merge window, this is fine,
> as stuff in linux-next today is likely to end up in 4.13-rc1 on Sunday.
> However, once -rc1 is out, you should base your patches on that to
> get a bisectable patch series once it is merged. If there are conflicts
> or dependencies on other trees that get scheduled for 4.14, we have
> to see how to resolve them one at a time.
> 
> > At this point I'm not really sure how to proceed: reviews have calmed down
> > quite a bit over the last two weeks, but I'm not familiar with the Linux
> > development process enough to know how to get closer to upstream.  Is this
> > ready for inclusion into another tree?  If so, is linux-next the right tree to
> > work off of?
> 
> Without having looked at the current state of the patch series, I would
> guess that next week is a good time to ask for inclusion *in* linux-next,
> while continuing the review.

My only concern about getting this into -next is that is sets expectations
that this is going to land in the next merge window, but we're unable to
review much of the atomics, barriers and locking code because the
architecture document is being rewritten and is not yet available:

https://marc.info/?i=8709419e3d964b86b025bb35a6b55440%40HQMAIL105.nvidia.com

Will