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-next>] [day] [month] [year] [list]
Message-ID: <20170504224448.GA32079@kroah.com>
Date:   Thu, 4 May 2017 15:44:48 -0700
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] locking fixes

On Wed, May 03, 2017 at 11:10:07PM -0700, Linus Torvalds wrote:
> 
> 
> On May 3, 2017 22:40, "Peter Zijlstra" <peterz@...radead.org> wrote:
> 
> 
>     These people are out-of-tree dubious licensed modules, right? I really
>     _really_ don't care about those.
> 
> 
> Mainly Nvidia, I think.

nvidia said it was for "new code" they were still developing, and that
the license issue was on their side, and they fixed it up.  They also
agreed that the change was ok from their point of view.

> But the point is, you broke people's working setups.
> 
> We don't do that.

We have never guaranteed kernel api stability, but yes, this is
different from that.

Moving these from a .h to .c caused the change, I asked for this as the
original symbols were obviously GPL-only being in a .h file.  However I
understand your point, we don't want to have people any grumpier at us
than normal :)

> Perhaps equally importantly, you did it by marking *trivial* functions that are
> definitely meant for drivers as gpl-only. Which only demeans the whole concept
> that we consider the gpl-only thing to be an "internal kernel function".

These are really now low-level kernel functions, and not trivial ones
given the long long email threads on how to get them all working
properly.  This was obviously something that took a lot of time to do.

> So the change actually makes our explicitly stated arguments for why certain
> functions are special less valid, and replaced it with a stupid grandstanding
> and legally dubious "linking means it's a derived work" argument.

There's no "linking" argument here, I didn't make that.

But again, I understand the point, changing api "markings" like this
"mid-stream" isn't the nicest thing to do.  And hey, I'm trying to be
"meaner" as I think someone once told me to be that way, so I
recommended that Peter make this change :)

I'll send a patch to change these back now...

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ