linux-kernel - Re: [GIT PULL] parisc fixes for kernel v4.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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 2 Oct 2018 15:24:52 -0700
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Helge Deller <deller@....de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        John David Anglin <dave.anglin@...l.net>
Subject: Re: [GIT PULL] parisc fixes for kernel v4.19

On Tue, Oct 02, 2018 at 11:46:11PM +0200, Helge Deller wrote:
> Hi Greg,
> 
> On 02.10.2018 23:16, Greg Kroah-Hartman wrote:
> > On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> >> please pull a last set of fixes for the parisc architecture for kernel 4.19 from:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.19-3
> >>
> >> The major change is for parisc64 to use a 64-bit suseconds_t type to
> >> match what glibc expects for 64-bit userspace. It's an ABI change, but
> >> since we don't have a 64-bit userspace on parisc yet, it won't introduce
> >> a breakage.
> > 
> > Isn't it a bit "late" in the release cycle for such a change?  Why not
> > do this on the -rc1 release?
> 
> I've tagged it for stable release.
> So, it can go in now, or just wait until -rc1 and go in later.

Why is a major API change a viable stable change?  What bugfix does it
provide?

> >> Other than that we simply drop unused code and outdated gcc version
> >> checks.
> > 
> > Why are those needed now?
> 
> The patch in there which is by me changes one line simply cleans up a patch which
> went in during the 4.19 merge cycle. So it would be nice to have it
> added now before v4.19 gets released.
> The other two patches are trivial and just remove dead code.
> I rate them all as non-critical, but nice-to-have-in-v4.19. 
> 
> If you disagree I'm absolutely fine to wait with all of them 
> for the next merge window.

Normally I only let "bugfixes" into my trees at this point in time.
cleanups always wait for the next -rc1 merge window as that's what it is
there for.  So I'd recommend waiting as well.

I'm more "worried" about the api change listed above.

thanks,

greg k-h