linux-kernel - Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

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:   Fri, 01 Dec 2017 17:47:04 -0800 (PST)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     linux-kernel@...r.kernel.org, patches@...ups.riscv.org,
        Olof Johansson <olof@...om.net>
Subject:     Re: [GIT PULL] RISC-V Cleanups and ABI Fixes for 4.15-rc2

On Fri, 01 Dec 2017 16:47:16 PST (-0800), Linus Torvalds wrote:
> On Fri, Dec 1, 2017 at 4:39 PM, Palmer Dabbelt <palmer@...ive.com> wrote:
>>
>> I've been maintaining the various cleanup patch sets I have as their own
>> branches, which I then merged together and signed.  Each merge commit
>> has a short summary of the changes, and each branch is based on your
>> latest tag (4.15-rc1, in this case).  If this isn't the right way to do
>> this then feel free to suggest something else, but it seems sane to me.
>
> The individual branches with merges look fine.
>
> What I don't really like is how very recent they are. Many of the
> commits were done today, and thus clearly were never through the 0-day
> robot etc.
>
> I don't actually think the 0day robot does RISC-V at all, at least not
> yet, so in this case it probably doesn't really matter, but in general
> I _hate_ seeing pull requests that come in on a Friday afternoon where
> a lot of the  commits clearly happened that same day. It's simply a
> sign of things likely having been rushed, which in turn often leads to
> issues down the line.

The 0-day robot doesn't do RISC-V, but we're working on getting better CI 
infrastructure setup now that we're upstream.  Olof has started running builds 
through his builder, which is where many of the fixes came from.  

I think we're probably not quite ready for the 0-day robot yet:
* We still have an allmodconfig failure, but there's a patch out to fix that.
* binutils-2.29.1 and gcc-7.2.0 have a handful of bugs that were found when 
  pushing on Linux, the next releases should have fixes for these.  We have 
  backports, so this might not be a big deal.
* There's no way to boot the kernel in an easy to automated fashion.  Our QEMU 
  port is a WIP, and I currently test our port by swapping SD cards.  This 
  might not be a big deal, since the port as it stands can't do much in the way 
  of a boot test anyway.

I'll ping kbuild-all with a better subject and figure out the right thing to 
do.

> So the structure of the history looks ok, but I hope that "very
> recently made" is a one-time thing rather than a pattern. Ok?

OK, sorry about that.  It sounds like this is a good excuse to figure out how 
we're going to stage commits in RISC-V land -- I've been a bit unprepared for 
the pace of kernel development on RISC-V, I didn't think I'd see so many people 
poking around in our port so quickly :).

If you'd like, I can let these bake for a few days?  I don't mind if they don't 
get in until rc3.  I can either ping this pull request or send another one, 
whatever's easier for you is OK for me.