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]

Message-ID: <20160708073046.GA2859@gmail.com>
Date:	Fri, 8 Jul 2016 09:30:46 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Frederic Weisbecker <fweisbec@...il.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"

* 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?

Thanks,

	Ingo