linux-kernel - Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock

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: <20120313121034.GA15543@elte.hu>
Date:	Tue, 13 Mar 2012 13:10:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Russell King <rmk@....linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [GIT PULL/NEXT] sched/arch: Introduce the
 finish_arch_post_lock_switch() scheduler callback

* Ingo Molnar <mingo@...e.hu> wrote:

> [...]
> 
> Having a patch applied to an old scheduler tree that is barely 
> out of -rc1 and then pushing it out into linux-next at -rc8, 
> without even checking how it integrates with upstream, barely 
> a few days before the merge window is just plain stupid.

So, while I cannot know what Linus will think and do once he 
gets such a conflict (my guess is that he'd just fix it up 
silently - it's really trivial), I can tell you what the 
conflict told *me*: that the communication channels between the 
ARM tree and the scheduler tree are not in the best of shape.

And that is what worried me enough to write a reply while 
recognizing that PeterZ acked the patch - not the triviality of 
the patch or the triviality of the conflict.

And dammit, I have the right and the duty to be concerned about 
a conflict in the scheduler code if I see it for the first time, 
not just Linus. Conflicts aren't magically just for Linus to be 
interested and act upon, they can occasionally be informative at 
subsystem maintainer levels just as well - like here...

What we should not do in terms of conflict avoidance are 
*excessive* cross-subsystem merges: for example you 
indiscriminately merging the totality of all pending scheduler 
changes into the ARM tree and thus forcing Linus's hand in terms 
of not being able to reject to pull the scheduler tree.

But if I got it right, working together on a trivial, 
well-isolated callback patch to make life easier is not frowned 
upon by Linus at all ...

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/