linux-kernel - Re: [PATCH v2] sched/fair: Do not set skip buddy up the sched hierarchy

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, 17 Dec 2019 22:00:12 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Josh Don <joshdon@...gle.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH v2] sched/fair: Do not set skip buddy up the sched
 hierarchy

On Tue, Dec 17, 2019 at 09:42:44PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 17, 2019 at 11:58:28AM -0800, Josh Don wrote:
> > > Ingo, Peter, what do you think ?
> > 
> > I could add the Co-developed-by tag if that would be sufficient here.
> > As a side note, I'm also looking at upstreaming our other sched
> > fixes/patches, and some of these have the same issue with respect to
> > the original author.  How would you prefer I handle these in general?
> 
> These internal patches that you have, don't they have a SoB on from the
> original author?
> 
> Ingo, Greg, how do we handle patches where the original Author has
> vanished/left etc and no SoB is present?
> 
> Now, in this case we know Venki was with Google in the US, and the US
> allows/has copyright assignment to employers and therefore any old SoB
> from a Google person should probably be sufficient, but that argument
> doesn't work in general (Germany for example doesn't allow copyright
> assignment/transfer).

Most Google kernel work is "work for hire" from what I have heard.

But the copyright of the patch really doesn't matter if the patch is
under the GPLv2 (obviously here), then anyone can send it in and put
their s-o-b on it.  The fact that it's someone from the same company is
good enough to let us know who to track down and kick if something
breaks with the patch, which is all we really need :)

hope this helps,

greg k-h