linux-kernel - Re: Re: [GIT PULL V2] Changes for 4.8

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] [day] [month] [year] [list]

Message-ID: <c7090a7a-a2e7-39fa-7edb-74b3d2526295@suse.com>
Date:	Thu, 11 Aug 2016 15:23:28 +0200
From:	Juergen Gross <jgross@...e.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Re: [GIT PULL V2] Changes for 4.8

On 27/07/16 19:03, Linus Torvalds wrote:
> On Tue, Jul 26, 2016 at 8:59 PM, Juergen Gross <jgross@...e.com> wrote:
>>
>> Support calling functions on dedicated physical cpu
>>
>> Some hardware (e.g. Dell Studio laptops) require special functions to
>> be called on physical cpu 0 in order to avoid occasional hangs. When
>> running as dom0 under Xen this could be achieved only via special boot
>> parameters (vcpu pinning) limiting the hypervisor in it's scheduling
>> decisions.
>>
>> This patch series is adding a generic function to be able to temporarily
>> pin a (virtual) cpu to a dedicated physical cpu for executing above
>> mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
>> requiring this functionality are modified accordingly.
>>
>> Unfortunately 2 of the 6 patches got no Acks as the maintainers didn't
>> react in spite of multiple pings and resends. The core modification in
>> the scheduler got an Ack from Peter and multiple tests showed no
>> regressions.
>>
>> As the series is touching multiple subsystems I couldn't find anyone
>> willing to take the series via his tree (I tried Ingo, Thomas, Peter).
> 
> Thanks, this explanation was exactly what I was looking for.
> 
> I'm still at two minds whether I'd prefer this kind of thing to come
> in through the x86 maintainers, or possibly the virtualization people
> who would actually use this. Or whether I'll just take it directly.
> 
> I will take another look later when I've gotten rid of the big initial
> flood of pull requests.

Did you already decide what you want to do?

Thanks,

Juergen