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: <20200526061309.GA15549@lst.de>
Date:   Tue, 26 May 2020 08:13:09 +0200
From:   Christoph Hellwig <hch@....de>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Christoph Hellwig <hch@....de>, x86@...nel.org,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-parisc@...r.kernel.org, linux-um@...ts.infradead.org,
        netdev@...r.kernel.org, bpf@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: clean up and streamline probe_kernel_* and friends v4

On Mon, May 25, 2020 at 03:19:12PM -0700, Andrew Morton wrote:
> hm.  Applying linux-next to this series generates a lot of rejects against
> powerpc:
> 
> -rw-rw-r-- 1 akpm akpm  493 May 25 15:06 arch/powerpc/kernel/kgdb.c.rej
> -rw-rw-r-- 1 akpm akpm 6461 May 25 15:06 arch/powerpc/kernel/trace/ftrace.c.rej
> -rw-rw-r-- 1 akpm akpm  447 May 25 15:06 arch/powerpc/mm/fault.c.rej
> -rw-rw-r-- 1 akpm akpm  623 May 25 15:06 arch/powerpc/perf/core-book3s.c.rej
> -rw-rw-r-- 1 akpm akpm 1408 May 25 15:06 arch/riscv/kernel/patch.c.rej
> 
> the arch/powerpc/kernel/trace/ftrace.c ones aren't very trivial.
> 
> It's -rc7.  Perhaps we should park all this until 5.8-rc1?

As this is a pre-condition for the set_fs removal I'd really like to
get the actual changes in.  All these conflicts seem to be about the
last three cleanup patches just doing renaming, so can we just skip
those three for now?  Then we can do the rename right after 5.8-rc1
when we have the least chances for conflicts.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ