linux-kernel - Re: [PATCH 0/2] sched/cputime: Deltas for "replace VTIME_GEN irq time code with IRQ_TIME

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:	Fri, 8 Jul 2016 13:17:52 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Rik van Riel <riel@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, rkrcmar@...hat.com,
	Thomas Gleixner <tglx@...utronix.de>,
	Mike Galbraith <efault@....de>, wanpeng.li@...mail.com
Subject: Re: [PATCH 0/2] sched/cputime: Deltas for "replace VTIME_GEN irq
 time code with IRQ_TIME_ACCOUNTING code"

On Fri, Jul 08, 2016 at 09:30:46AM +0200, Ingo Molnar wrote:
> 
> * Rik van Riel <riel@...hat.com> wrote:
> 
> > On Thu, 2016-07-07 at 16:27 +0200, Frederic Weisbecker wrote:
> > > Hi Rick,
> > > 
> > > While reviewing your 2nd patch, I thought about these cleanups.
> > > Perhaps
> > > the first one could be merged into your patch. I let you decide.
> > 
> > I'm not convinced we want to merge cleanups and functional
> > changes into the same patch, given how convoluted the code
> > is/was.
> > 
> > Both of your patches look good though.
> > 
> > What tree should they go in through?
> 
> -tip I suspect. So my plan was the following, this series of yours:
> 
>   [PATCH v3 0/4] sched,time: fix irq time accounting with nohz_idle
> 
> ... looked almost ready, it looked like as if I could merge v4 once you sent it.
> 
> Plus Frederic submitted these two cleanups - looks like I could merge these on top 
> of your series and have them close to each other in the Git space.
> 
> And I do agree that we should keep these cleanups separate and not merge them into 
> patches that change functionality.
> 
> If your series is expected to be risky then we could make things easier to handle 
> later on if we switched around things and first made low-risk cleanups and then 
> any changes/fixes on top - do you think that's necessary in this case?

I personally think that none of this is low-risk material. Perhaps we can gather
the whole in the same tree? I can resend the series proper with my patches inside
if you like. And I have yet to review the last patch of the series.

Thanks.