* Re: linux-next: manual merge of the l2-mtd tree with the vfs tree
From: Stephen Rothwell @ 2012-03-13 15:13 UTC (permalink / raw)
To: dedekind1; +Cc: Stefan Roese, linux-next, linux-kernel, Al Viro, Joe Perches
In-Reply-To: <1331649633.3595.70.camel@sauron.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
Hi Artem,
On Tue, 13 Mar 2012 16:40:33 +0200 Artem Bityutskiy <dedekind1@gmail.com> wrote:
>
> Thanks. Although I do not see the latest l2-mtd.git tree in the master
> branch of linux-next, I see some old version of it. E.g., the jffs2
> changes are not there.
I just checked and the master branch on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git is
8ca39b0 "Add linux-next specific files for 20120313" as I would expect it
to be and the top of the l2-mtd tree that was merged into that is
4331c79c6895 "mtd: do not use plain 0 as NULL".
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the vfs tree
From: Artem Bityutskiy @ 2012-03-13 14:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Stefan Roese, linux-next, linux-kernel, Al Viro, Joe Perches
In-Reply-To: <20120313141859.302878a8e2246979c288440d@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
On Tue, 2012-03-13 at 14:18 +1100, Stephen Rothwell wrote:
> Hi Artem,
>
> Today's linux-next merge of the l2-mtd tree got a conflict in
> fs/jffs2/fs.c between commit de071e1a7466 ("switch open-coded instances
> of d_make_root() to new helper") from the vfs tree and commit
> ab9b393d6ee8 ("jffs2: Convert most D1/D2 macros to jffs2_dbg") from the
> l2-mtd tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Thanks. Although I do not see the latest l2-mtd.git tree in the master
branch of linux-next, I see some old version of it. E.g., the jffs2
changes are not there.
--
Best Regards,
Artem Bityutskiy
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 13:31 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313130427.GC2174@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> > Instead you first pushed back on *me*, then you claimed that
> > you are not responsible for what you pull, then you started
> > zapping
>
> No I did not. What I said was that I'm not responsible for
> the points at which people choose to base their patches, which
> is something entirely different. [...]
What are you talking about?
Firstly, in general *every single bit* of what you pull,
including the base, the patch titles, the commit logs, the
signoff chain, etc. is all part of the picture and you
absolutely should require your contributors and submaintainers
to do a fine job with all that.
No ifs and whens about that - it all becomes your responsibility
as well when you decide to pull from people.
Instead you are now teaching them the exact *opposite*: for
example you have just declared that you don't feel responsible
for the base kernel ...
Using a sane base is IMHO part of Git pull 101. Teaching
contributors or submaintainers to not use too old base kernels
(or too new ones, for example during the merge window) is an
important part of the picture.
A basic rule for bases is to either use the previous stable
kernel release, of if that's not possible then use the freshest
-rc available at the time of the commit - which by my quick look
should have been about -rc6, not -rc3.
Secondly, my other problem was that this all surfaced today, at
-rc8 time, shortly before the merge window, a very busy period
of time.
If this was committed a month ago, if you indeed saw the
conflict earlier proves *more* workflow breakage IMO: you pushed
it upstream despite being aware of it being the result of a
slightly suboptimal base, without asking whether the scheduler
folks are still fine with all that?
Thirdly, all this totally ignores the issue you still have not
answered: why did you leave PeterZ public lkml question about
this unanswered:
http://lkml.org/lkml/2012/2/16/232
PeterZ's request to put this into a separate branch was totally
reasonable IMHO - and could have avoided this long thread,
amongst other things. Instead you've mixed it with other bits.
Really, my quick impression is that you should learn to push
back downstream a bit, especially as I didn't even ask for a
rebase, a revert or anything other drastic.
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 13:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313124433.GA15333@elte.hu>
On Tue, Mar 13, 2012 at 01:44:33PM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > > Look into the fine conflict report Russell: it conflicts with
> > > *Linus's* tree, because it's based off some random
> > > barely-beyond-rc1 development window -rc3 base. Even at the
> > > commit date of Feb 27 we had a more stable base tree available -
> > > and especially when you pulled it, several weeks down the line,
> > > -rc3 was not a defensible base for the integrated result.
> >
> > I'm not going to ask someone to rebase their patches after
> > they've been fully tested on a set of platforms. [...]
>
> That's a new argument which might be a valid concern in general
> *if you make that decision when you pull the tree* - but you
> should admit that you werent even aware of the conflict and of
> the root cause behind it, let alone be in the position to
> consider whether a rebase is justified in that case ...
No Ingo. I was aware of the conflict, because when I merged it into
my test tree, I got that conflict and fixed it up myself before I
tested the frigging thing.
> So I think you are just making this up on the fly.
If you think that, we have nothing further to discuss. But I know
I'm right, because:
commit e3507976ee7ad0a58fa68ce919a7acfcfec28e3b
Merge: 4c17fe7 8cee1aa
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date: Thu Mar 8 09:51:31 2012 +0000
Merge branch 'intr-ctxsw' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux
Conflicts:
kernel/sched/core.c
http://ftp.arm.linux.org.uk/git/?p=linux-next.git;a=commitdiff;h=e350797
(which is _not_ in a public branch, and is _only_ accessible via knowing
the commit id.)
Oh look, March 8th. Oh, that's last Thursday. Oh, maybe I did merge
it a while back after all, maybe I'm not making this crap up. Maybe
I did know about the conflict but didn't think anything of it because
it was soo trivial.
> Instead you first pushed back on *me*, then you claimed that you
> are not responsible for what you pull, then you started zapping
No I did not. What I said was that I'm not responsible for the points
at which people choose to base their patches, which is something entirely
different. Unlike you, I have _no_ _problem_ with pulling work based on
_any_ -rc, or indeed any commit whatsoever - provided it's been tested
and it merges relatively cleanly with the branch I'm pulling it into.
> patches and claiming that you will never pull them again,
> blaming it all on me.
I'm only blaming this thread on you, precisely because you're making a
mountain out of a mole hill. There's no problem here. Really. At all.
You're just blowing it out of all proportion making it into some huge big
issue. _That_ alone is the whole reason why I've dropped Catalins patches.
I don't want to be subjected to your rants over this. Instead, _you_ can
deal with this patch set and deal with the other conflicts which git can
resolve automatically.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 13:02 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313123634.GB2174@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
> >
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> >
> > > Why am _I_ responsible for which kernel version _Catalin_ used
> > > for _his_ patches when _he_ committed them?
> >
> > If you then pull that tree from him and push it out to
> > linux-next? Then *of course* you are responsible, it was your
> > decision to pull it.
> >
> > I frequently reject pulls from subsystem maintainers on similar
> > (and sometimes lesser) grounds - because such mistakes tend to
> > compound with time.
> >
> > The thing is, if you do Git pulls from someone then you must be
> > absolutely anal about it, because you cannot really fix things
> > up after the fact. The people you pull from must be your
> > extended arms, they must be doing an equal or better job than
> > you. That gives a basis of trust.
> >
> > Once that is established, you can be permissive about mistakes.
> >
> > But arguing that you are not responsible for what you pull is
> > absolutely grotesque and establishes a new low for this
> > discussion really...
> >
> > Also, as I told you in the very first mail, I am *fine* with
> > this having happened, so you having zapped the commits is
> > indefensible IMO. Mistakes do happen and the patch is fine
> > technically and sfr and Linus could have handled the trivial
> > conflict. What I suggested was to do it a bit better in the
> > future. Is that too much to ask for?
> >
> > > You're insane. Totally.
> >
> > I think you owe me an apology :-(
>
> I owe you nothing. From where I stand, I did nothing wrong.
Well, even ignoring the arguments you hurled several ad hominems
at me while I wrote none.
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 12:44 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313121707.GA2174@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> > Look into the fine conflict report Russell: it conflicts with
> > *Linus's* tree, because it's based off some random
> > barely-beyond-rc1 development window -rc3 base. Even at the
> > commit date of Feb 27 we had a more stable base tree available -
> > and especially when you pulled it, several weeks down the line,
> > -rc3 was not a defensible base for the integrated result.
>
> I'm not going to ask someone to rebase their patches after
> they've been fully tested on a set of platforms. [...]
That's a new argument which might be a valid concern in general
*if you make that decision when you pull the tree* - but you
should admit that you werent even aware of the conflict and of
the root cause behind it, let alone be in the position to
consider whether a rebase is justified in that case ...
( Paradoxially, rebasing is exactly what *you* ended up forcing
others to do. I have not asked you or Catalin to rebase any
existing commit. I merely asked about future plans. )
So I think you are just making this up on the fly. Really, if I
push back on you in a 100% *permissive* fashion, and if my
complaint is justified, then the proper response is for you to
push back on your contributors - while we can keep all commits
in place.
Instead you first pushed back on *me*, then you claimed that you
are not responsible for what you pull, then you started zapping
patches and claiming that you will never pull them again,
blaming it all on me.
Again, a storm in a teacup IMO.
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 12:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313122053.GA17549@elte.hu>
On Tue, Mar 13, 2012 at 01:20:53PM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > Why am _I_ responsible for which kernel version _Catalin_ used
> > for _his_ patches when _he_ committed them?
>
> If you then pull that tree from him and push it out to
> linux-next? Then *of course* you are responsible, it was your
> decision to pull it.
>
> I frequently reject pulls from subsystem maintainers on similar
> (and sometimes lesser) grounds - because such mistakes tend to
> compound with time.
>
> The thing is, if you do Git pulls from someone then you must be
> absolutely anal about it, because you cannot really fix things
> up after the fact. The people you pull from must be your
> extended arms, they must be doing an equal or better job than
> you. That gives a basis of trust.
>
> Once that is established, you can be permissive about mistakes.
>
> But arguing that you are not responsible for what you pull is
> absolutely grotesque and establishes a new low for this
> discussion really...
>
> Also, as I told you in the very first mail, I am *fine* with
> this having happened, so you having zapped the commits is
> indefensible IMO. Mistakes do happen and the patch is fine
> technically and sfr and Linus could have handled the trivial
> conflict. What I suggested was to do it a bit better in the
> future. Is that too much to ask for?
>
> > You're insane. Totally.
>
> I think you owe me an apology :-(
I owe you nothing. From where I stand, I did nothing wrong.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 12:20 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313120014.GB13220@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> Why am _I_ responsible for which kernel version _Catalin_ used
> for _his_ patches when _he_ committed them?
If you then pull that tree from him and push it out to
linux-next? Then *of course* you are responsible, it was your
decision to pull it.
I frequently reject pulls from subsystem maintainers on similar
(and sometimes lesser) grounds - because such mistakes tend to
compound with time.
The thing is, if you do Git pulls from someone then you must be
absolutely anal about it, because you cannot really fix things
up after the fact. The people you pull from must be your
extended arms, they must be doing an equal or better job than
you. That gives a basis of trust.
Once that is established, you can be permissive about mistakes.
But arguing that you are not responsible for what you pull is
absolutely grotesque and establishes a new low for this
discussion really...
Also, as I told you in the very first mail, I am *fine* with
this having happened, so you having zapped the commits is
indefensible IMO. Mistakes do happen and the patch is fine
technically and sfr and Linus could have handled the trivial
conflict. What I suggested was to do it a bit better in the
future. Is that too much to ask for?
> You're insane. Totally.
I think you owe me an apology :-(
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 12:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313115640.GA27378@elte.hu>
On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
> Look into the fine conflict report Russell: it conflicts with
> *Linus's* tree, because it's based off some random
> barely-beyond-rc1 development window -rc3 base. Even at the
> commit date of Feb 27 we had a more stable base tree available -
> and especially when you pulled it, several weeks down the line,
> -rc3 was not a defensible base for the integrated result.
I'm not going to ask someone to rebase their patches after they've been
fully tested on a set of platforms. It has been stated many times that
rebasing invalidates the testing that the patches have been subjected
to, and these have been tested by several different people on a range
of platforms.
It seems what _you_ care more about is having nice clean git trees and
proper git flow at the detriment to dealing with tested changes.
The fact of the matter is that I took a set of well tested patches into
my tree which _you_ were copied on multiple times, that Peter Z. was
aware of what was happening, and which trivially conflict with some other
change which happened along the way. Such a trivial conflict does _NOT_
justify rebasing the patch set, thereby invalidating all the testing that
has done.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 12:10 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313115640.GA27378@elte.hu>
* Ingo Molnar <mingo@elte.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
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 12:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313115640.GA27378@elte.hu>
On Tue, Mar 13, 2012 at 12:56:40PM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > >
> > > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > > >
> > > > > As I said it in my first mail, doing that is unnecessary -
> > > > > but if you insist on being difficult then Catalin, feel free
> > > > > to pull the patch from tip:sched/arch:
> > > >
> > > > Nope, I'm not taking the tree anymore, [...]
> > >
> > > So instead of saying "sure, lets avoid conflicts next time
> > > around" you are now *refusing* to take technically perfectly
> > > fine patches just because another maintainer asked you to use a
> > > different workflow for future patches? Wow ...
> >
> > No, I'm pissed off at how you're treating me over this trivial issue,
> > so I'm taking the easy way out and getting out of the way. If you want
> > to run your bit of the tree with idiotic rules about zero conflicts,
> > and "git solutions" then that's your perogative. Just don't expect
> > other people to play with you.
> >
> > The fact of the matter is that Peter Z. was fully aware of what was
> > happening. He was aware that he'd been asked for his ack for that
> > patch (because I'd explicitly asked Peter for it, but not by email) -
> > and he provided his ack for that patch to Catalin:
> >
> > http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
> >
> > Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
> >
> > http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
> >
> > I pulled it into my tree for testing, and pushed it out in the last
> > couple of days.
> >
> > Moreover, these kinds of trivial conflicts are the type of things which
> > Linus wants to see between trees. It allows him to get a feel for what's
> > going on, and makes Linus feel like he's more on top of things. Linus
> > said that he would like to see these trivial conflicts (he said so to me
> > in an email dated 15th Jan 2011).
> >
> > So please, stop your insistance on this zero conflict crap.
>
> While I still think this is a storm in a teacup, I think you are
> subtly misunderstanding Linus's position about conflicts and you
> are seriously misrepresenting my request and my position as
> well:
>
> The thing is, most conflicts are fine in general. So on one hand
> you are right, we *do* allow and quite often *keep* conflicts in
> place even within our own topic branches.
>
> Those are *real* conflicts that Linus would arguably be
> interested in: two teams working on two things in parallel that
> somehow conflict at the code level content-wise or concept-wise
> - high level maintainers rightfully are curious about those
> kinds of conflicts because while often they are just fine, it
> might also be the canary of possible workflow problems or it
> might also be the canary of the code being shaped in some
> inefficient way.
>
> On the other hand, this particular conflict you pushed to
> linux-next is *neither*, and this is what got my attention. This
> is a plain *STUPID* conflict.
>
> Look into the fine conflict report Russell: it conflicts with
> *Linus's* tree, because it's based off some random
> barely-beyond-rc1 development window -rc3 base. Even at the
> commit date of Feb 27 we had a more stable base tree available -
> and especially when you pulled it, several weeks down the line,
> -rc3 was not a defensible base for the integrated result.
>
> 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.
>
> While nothing of what you talked to PeterZ is visible in the
> public record, I'm quite sure had you asked him about what base
> kernel to use, he'd have suggested something much more stable
> ...
Why am _I_ responsible for which kernel version _Catalin_ used for _his_
patches when _he_ committed them?
You're insane. Totally.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 11:56 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313112729.GA25835@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> >
> > > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > > >
> > > > As I said it in my first mail, doing that is unnecessary -
> > > > but if you insist on being difficult then Catalin, feel free
> > > > to pull the patch from tip:sched/arch:
> > >
> > > Nope, I'm not taking the tree anymore, [...]
> >
> > So instead of saying "sure, lets avoid conflicts next time
> > around" you are now *refusing* to take technically perfectly
> > fine patches just because another maintainer asked you to use a
> > different workflow for future patches? Wow ...
>
> No, I'm pissed off at how you're treating me over this trivial issue,
> so I'm taking the easy way out and getting out of the way. If you want
> to run your bit of the tree with idiotic rules about zero conflicts,
> and "git solutions" then that's your perogative. Just don't expect
> other people to play with you.
>
> The fact of the matter is that Peter Z. was fully aware of what was
> happening. He was aware that he'd been asked for his ack for that
> patch (because I'd explicitly asked Peter for it, but not by email) -
> and he provided his ack for that patch to Catalin:
>
> http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
>
> Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
>
> http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
>
> I pulled it into my tree for testing, and pushed it out in the last
> couple of days.
>
> Moreover, these kinds of trivial conflicts are the type of things which
> Linus wants to see between trees. It allows him to get a feel for what's
> going on, and makes Linus feel like he's more on top of things. Linus
> said that he would like to see these trivial conflicts (he said so to me
> in an email dated 15th Jan 2011).
>
> So please, stop your insistance on this zero conflict crap.
While I still think this is a storm in a teacup, I think you are
subtly misunderstanding Linus's position about conflicts and you
are seriously misrepresenting my request and my position as
well:
The thing is, most conflicts are fine in general. So on one hand
you are right, we *do* allow and quite often *keep* conflicts in
place even within our own topic branches.
Those are *real* conflicts that Linus would arguably be
interested in: two teams working on two things in parallel that
somehow conflict at the code level content-wise or concept-wise
- high level maintainers rightfully are curious about those
kinds of conflicts because while often they are just fine, it
might also be the canary of possible workflow problems or it
might also be the canary of the code being shaped in some
inefficient way.
On the other hand, this particular conflict you pushed to
linux-next is *neither*, and this is what got my attention. This
is a plain *STUPID* conflict.
Look into the fine conflict report Russell: it conflicts with
*Linus's* tree, because it's based off some random
barely-beyond-rc1 development window -rc3 base. Even at the
commit date of Feb 27 we had a more stable base tree available -
and especially when you pulled it, several weeks down the line,
-rc3 was not a defensible base for the integrated result.
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.
While nothing of what you talked to PeterZ is visible in the
public record, I'm quite sure had you asked him about what base
kernel to use, he'd have suggested something much more stable
...
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 11:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313101859.GA2626@elte.hu>
On Tue, Mar 13, 2012 at 11:19:00AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> > >
> > > As I said it in my first mail, doing that is unnecessary -
> > > but if you insist on being difficult then Catalin, feel free
> > > to pull the patch from tip:sched/arch:
> >
> > Nope, I'm not taking the tree anymore, [...]
>
> So instead of saying "sure, lets avoid conflicts next time
> around" you are now *refusing* to take technically perfectly
> fine patches just because another maintainer asked you to use a
> different workflow for future patches? Wow ...
No, I'm pissed off at how you're treating me over this trivial issue,
so I'm taking the easy way out and getting out of the way. If you want
to run your bit of the tree with idiotic rules about zero conflicts,
and "git solutions" then that's your perogative. Just don't expect
other people to play with you.
The fact of the matter is that Peter Z. was fully aware of what was
happening. He was aware that he'd been asked for his ack for that
patch (because I'd explicitly asked Peter for it, but not by email) -
and he provided his ack for that patch to Catalin:
http://lists.arm.linux.org.uk/lurker/message/20120227.144813.5614e7f8.en.html
Catalin sent a pull request to me, copying Peter Z on the 27th Feb:
http://lists.arm.linux.org.uk/lurker/message/20120227.164502.6b58a37e.en.html
I pulled it into my tree for testing, and pushed it out in the last
couple of days.
Moreover, these kinds of trivial conflicts are the type of things which
Linus wants to see between trees. It allows him to get a feel for what's
going on, and makes Linus feel like he's more on top of things. Linus
said that he would like to see these trivial conflicts (he said so to me
in an email dated 15th Jan 2011).
So please, stop your insistance on this zero conflict crap.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Catalin Marinas @ 2012-03-13 11:11 UTC (permalink / raw)
To: Ingo Molnar
Cc: Russell King, Linus Torvalds, Stephen Rothwell,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra
In-Reply-To: <20120313092649.GA15406@elte.hu>
Hi Ingo,
On Tue, Mar 13, 2012 at 09:26:49AM +0000, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but
> if you insist on being difficult then Catalin, feel free to pull
> the patch from tip:sched/arch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch
>
> HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
>
> it's v3.3-rc7 based so it will generate no conflict with
> linux-next. It only contains this commit so you can use it
> without pulling in other pending scheduler changes.
Thanks for merging the scheduler hook.
So I'll send Russell another pull request after the 3.4-rc1, containing
only ARM patches. The only drawback is that the removal of
__ARCH_WANT_INTERRUPTS_ON_CTXSW will have to wait another release cycle.
--
Catalin
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 10:19 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313095020.GA13220@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> >
> > As I said it in my first mail, doing that is unnecessary -
> > but if you insist on being difficult then Catalin, feel free
> > to pull the patch from tip:sched/arch:
>
> Nope, I'm not taking the tree anymore, [...]
So instead of saying "sure, lets avoid conflicts next time
around" you are now *refusing* to take technically perfectly
fine patches just because another maintainer asked you to use a
different workflow for future patches? Wow ...
Regardless of the imperfect workflow I certainly find Catalin's
work useful technically, so I'll send his preparatory commit to
Linus in this merge window - I hope you will see sense later and
won't block his subsequent ARM patches...
> [...] you've refused to behave in a reasonable way. Your
> problem to sort out now.
For the record, that's utter nonsense:
- *You* failed to reply on the public thread to sort this out
properly in the Git space, avoiding conflicts naturally:
http://lkml.org/lkml/2012/2/16/232
While generally we don't mind conflicts, I do mind
*avoidable* conflicts - and this was such a case.
- *You* created a conflict by taking a tree that patched some
rather old version of the scheduler, shortly before the merge
window, when maintainer capacity is the shortest. PeterZ
is a nice guy who will agree to just about any approach, but
I'm quite sure he did not tell you to do *that* ;-)
- *You* replied to me in a rather dismissive and increasingly
obnoxious style when I inquired about it constructively:
http://lkml.org/lkml/2012/3/13/79
There were several easy solutions - I cannot believe that we are
still arguing this:
- it literally took me two minutes to create a proper Git
solution, it's not rocket science. You could have done it, or
I could have done it for you (as I have done it).
- Or you could have replied to the public thread, explaining
why that is not desirable.
- Or you could have said "sure thing, lets do it that way next
time around".
Thanks,
Ingo
^ permalink raw reply
* Re: [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Russell King @ 2012-03-13 9:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313092649.GA15406@elte.hu>
On Tue, Mar 13, 2012 at 10:26:49AM +0100, Ingo Molnar wrote:
> As I said it in my first mail, doing that is unnecessary - but
> if you insist on being difficult then Catalin, feel free to pull
> the patch from tip:sched/arch:
Nope, I'm not taking the tree anymore, you've refused to behave in a
reasonable way. Your problem to sort out now.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* linux-next: Tree for Mar 13
From: Stephen Rothwell @ 2012-03-13 9:41 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 53076 bytes --]
Hi all,
Changes since 20120309:
New tree: drivers-x86
There are quite a few conflicts caused by the same patches (as opposed to
commits) appearing in more than one tree.
The arm tree gained a conflict against Linus' tree.
The tegra tree gained a conflict against the arm tree.
The pci tree still has its build failure, for which I applied a patch, and
gained a conflict against the powerpc tree.
The net-next treee lost its conflict.
The l2-mtd tree gained a conflict against the vfs tree.
The slave-dma tree gained a conflict against Linus' tree.
The mmc tree gained a conflict against the s5p tree.
The devicetree tree gained a conflict against the powerpc tree.
The tip tree gained a conflict against the drm tree.
The uprobes tree gained conflicts against the tip tree and a build
failure so I used the version from next-20120309.
The oprofile tree gained a conflict against the tip tree.
The drivers-x86 tree gained a conflict against the tip tree.
The driver-core tree lost a conflict.
The usb tree lost a conflict.
The moduleh tree lost its merge fixup patch.
The arm-soc tree gained conflicts against the omap-dss2, sound and arm trees.
The akpm tree lost several patches that turned up elsewhere (notably the
resurrected drivers-x86 tree) and gained a conflict against the powerpc
tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 188 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (fde7d90 Linux 3.3-rc7)
Merging fixes/master (88ebdda Merge tag 'for-3.3' of git://openrisc.net/jonas/linux)
Merging kbuild-current/rc-fixes (42f1c01 coccicheck: change handling of C={1,2} when M= is set)
Merging arm-current/fixes (a0feb6d ARM: 7358/1: perf: add PMU hotplug notifier)
Merging m68k-current/for-linus (2a35350 m68k: Fix assembler constraint to prevent overeager gcc optimisation)
Merging powerpc-merge/merge (c2ea377 Merge remote-tracking branch 'origin/master' into merge)
Merging 52xx-and-virtex-current/powerpc/merge (c49f878 dtc/powerpc: remove obsolete .gitignore entries)
Merging sparc/master (e51e07e sparc32: forced setting of mode of sun4m per-cpu timers)
Merging scsi-rc-fixes/master (41f8ad7 [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576)
Merging net/master (930c514 dql: Fix undefined jiffies)
Merging sound-current/for-linus (8de5d6f ALSA: hdspm - Provide ioctl_compat)
Merging pci-current/for-linus (4949be1 PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled)
Merging wireless/master (3780d03 rt2x00: fix random stalls)
Merging driver-core.current/driver-core-linus (fde7d90 Linux 3.3-rc7)
Merging tty.current/tty-linus (fde7d90 Linux 3.3-rc7)
Merging usb.current/usb-linus (fde7d90 Linux 3.3-rc7)
Merging staging.current/staging-linus (fde7d90 Linux 3.3-rc7)
Merging char-misc.current/char-misc-linus (fde7d90 Linux 3.3-rc7)
Merging cpufreq-current/fixes (6139b65 Merge branch 'for_3.4/cpufreq' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into fixes)
Merging input-current/for-linus (19d57d3 Input: wacom - fix 3rd-gen Bamboo MT when 4+ fingers are in use)
Merging md-current/for-linus (7a90484 md/raid10: fix assembling of arrays with replacement devices.)
Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix)
Merging crypto-current/master (f8f54e1 crypto: mv_cesa - fix final callback not ignoring input data)
Merging ide/master (0ab3d8b cy82c693: fix PCI device selection)
Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6)
Merging devicetree-current/devicetree/merge (29f141f Merge branch 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux into devicetree/merge)
Merging spi-current/spi/merge (a5ab629 Fix section mismatch in spi-pl022.c)
Merging gpio-current/gpio/merge (7e3a70f gpio: Add missing spin_lock_init in gpio-ml-ioh driver)
Merging arm/for-next (67791cc Merge branch 'acorn' into for-next)
CONFLICT (content): Merge conflict in kernel/sched/core.c
Merging arm-perf/for-next/perf (cdd2a5b Merge branches 'perf/updates' and 'perf/fixes' into for-next/perf)
Merging davinci/davinci-next (fe0d422 Linux 3.0-rc6)
Merging samsung/next-samsung (9edb240 ARM: H1940/RX1950: Change default LED triggers)
Merging s5p/for-next (4789017 Merge branch 'next/soc-exynos5250-arch' into for-next)
Merging tegra/for-next (1233655 Merge branch 'for-3.4/cleanup-and-fixes' into for-next)
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Makefile
Merging xilinx/arm-next (b85a3ef ARM: Xilinx: Adding Xilinx board support)
Merging blackfin/for-linus (e651fe5 Blackfin: wire up new process_vm syscalls)
Merging c6x/for-linux-next (fde7d90 Linux 3.3-rc7)
Merging cris/for-next (ea78f5b CRIS: Update documentation)
Merging quilt/hexagon (110b372 Remove unneeded include of version.h from arch/hexagon/include/asm/spinlock_types.h)
CONFLICT (content): Merge conflict in arch/hexagon/Kconfig
Merging ia64/next (15839b4 [IA64] Fix a couple of warnings for EXPORT_SYMBOL)
Merging m68k/for-next (2a35350 m68k: Fix assembler constraint to prevent overeager gcc optimisation)
Merging m68knommu/for-next (ae909ea m68knommu: factor more common ColdFire cpu reset code)
Merging microblaze/next (8597559 Merge tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6)
Merging mips/mips-for-linux-next (2fea377 Merge branch 'fixes-for-linus' into mips-for-linux-next)
Merging openrisc/for-upstream (fa8d9d7 OpenRISC: Remove memory_start/end prototypes)
Merging parisc/for-next (c60dc74 Merge branch 'fixes' into for-next)
Merging powerpc/next (aba0eb8 Merge branch 'eeh' into next)
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
Merging 4xx/next (ef88e39 powerpc: fix compile error with 85xx/p1010rdb.c)
Merging 52xx-and-virtex/powerpc/next (c1395f4 dtc/powerpc: remove obsolete .gitignore entries)
Merging galak/next (ef88e39 powerpc: fix compile error with 85xx/p1010rdb.c)
Merging s390/features (f5bfa15 [S390] Ensure that vmcore_info pointer is never accessed directly)
Merging sparc-next/master (e9b57cc sparc: Use vsprintf extention %pf with builtin_return_address)
Merging tile/master (0c90547 arch/tile: use new generic {enable,disable}_percpu_irq() routines)
Merging unicore32/unicore32 (0994695 Merge branch 'akpm' (aka "Andrew's patch-bomb, take two"))
Merging ceph/master (83eb26a ceph: ensure prealloc_blob is in place when removing xattr)
Merging cifs/master (d575146 CIFS: Do not kmalloc under the flocks spinlock)
Merging configfs/linux-next (b930c26 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs)
Merging ecryptfs/next (6cfd4b4 ecryptfs: remove the second argument of k[un]map_atomic())
CONFLICT (content): Merge conflict in fs/ecryptfs/ecryptfs_kernel.h
Merging ext3/for_next (e703c20 ext3: fix start and len arguments handling in ext3_trim_fs())
Merging ext4/dev (24a1c12 ext4: check for zero length extent)
Merging fuse/for-next (4273b79 fuse: O_DIRECT support for files)
Merging gfs2/master (58a7d5f GFS2: call gfs2_write_alloc_required for each chunk)
Merging logfs/master (fde7d90 Linux 3.3-rc7)
Merging nfs/linux-next (9a3ba43 NFSv4: Rate limit the state manager warning messages)
Merging nfsd/nfsd-next (8546ee5 nfsd4: make sure set CB_PATH_DOWN sequence flag set)
Merging ocfs2/linux-next (9392557 ocfs2: avoid unaligned access to dqc_bitmap)
Merging omfs/for-next (976d167 Linux 3.1-rc9)
Merging squashfs/master (4b0180a Squashfs: add mount time sanity check for block_size and block_log match)
Merging v9fs/for-next (5bdad93 9p: statfs should not override server f_type)
Merging ubifs/linux-next (5a1f36c UBIFS: improve error messages)
Merging xfs/for-next (4b217ed quota: make Q_XQUOTASYNC a noop)
CONFLICT (content): Merge conflict in fs/xfs/xfs_trans_dquot.c
Merging vfs/for-next (9161999 fs: initial qnx6fs addition)
Merging pci/linux-next (63ab387 x86/PCI: add spinlock held check to 'pcibios_fwaddrmap_lookup()')
CONFLICT (modify/delete): arch/powerpc/platforms/iseries/pci.c deleted in HEAD and modified in pci/linux-next. Version pci/linux-next of arch/powerpc/platforms/iseries/pci.c left in tree.
CONFLICT (content): Merge conflict in arch/powerpc/include/asm/ppc-pci.h
CONFLICT (content): Merge conflict in arch/mips/pci/pci.c
$ git rm -f arch/powerpc/platforms/iseries/pci.c
Applying: powerpc/PCI: fix up for mismatch between resource_size_t and pointer size
Merging hid/for-next (b6560ea Merge branch 'multitouch' into for-next)
Merging quilt/i2c (b750167 i2c: Update the FSF address)
Merging bjdooks-i2c/next-i2c (fc84fe1 Merge branch 'for_3.3/i2c/misc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for-33/i2c/omap)
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-omap.c
Merging i2c-embedded/i2c-embedded/for-next (bbceeee i2c-eg20t: Remove write-only variables)
Merging quilt/jdelvare-hwmon (064628b hwmon: Add MCP3021 ADC driver)
Merging hwmon-staging/hwmon-next (745b155 hwmon: (jc42) Remove unnecessary device IDs)
Merging quilt/kernel-doc (7e7b32a Update quilt tree location for Documentation/ patches.)
Merging docs/docs-move (5c24d8b Merge branch 'docs/docbook/drm' of git://github.com/mfwitten/linux into docs-move)
Merging v4l-dvb/master (704f8b9 Merge /home/v4l/v4l/patchwork)
Merging kbuild/for-next (17c0999 Merge branch 'kbuild/misc' into kbuild/for-next)
Merging kconfig/for-next (eae1c36 Merge branch 'kconfig/for-linus-2' into kconfig/for-next)
Merging libata/NEXT (3f1581f sata_fsl: add support for interrupt coalsecing feature)
Merging infiniband/for-next (5ad19b0 Merge branches 'cma', 'cxgb3', 'cxgb4', 'ehca', 'iser', 'mad', 'nes', 'qib', 'srp' and 'srpt' into for-next)
Merging acpi/next (71ad90e ACPICA: Fix regression in FADT revision checks)
Merging cpupowerutils/master (f166033 cpupower tools: add install target to the debug tools' makefiles)
Merging ieee1394/for-next (6f6f92d Merge branch 'master' into for-next)
Merging ubi/linux-next (898e567 UBI: fix eraseblock picking criteria)
Merging dlm/next (7210cb7 dlm: fix slow rsb search in dir recovery)
Merging scsi/master (cd8df93 [SCSI] qla4xxx: Update driver version to 5.02.00-k15)
Merging target-updates/for-next (9765b1f target: Bump core version to v4.1.0-rc2-ml + fabric versions)
Merging target-merge/for-next-merge (b3fd3cc tcm_qla2xxx: Add >= 24xx series fabric module for target-core)
Merging ibft/linux-next (935a9fe ibft: Fix finding IBFT ACPI table on UEFI)
Merging isci/all (4af617a Merge branch 'devel' into all)
CONFLICT (content): Merge conflict in include/scsi/sas_ata.h
CONFLICT (content): Merge conflict in include/scsi/libsas.h
CONFLICT (content): Merge conflict in include/linux/libata.h
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_scsi_host.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_internal.h
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_init.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_expander.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_event.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_discover.c
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_ata.c
CONFLICT (content): Merge conflict in drivers/scsi/isci/request.h
CONFLICT (content): Merge conflict in drivers/scsi/isci/registers.h
CONFLICT (content): Merge conflict in drivers/scsi/isci/port.h
CONFLICT (content): Merge conflict in drivers/scsi/isci/port.c
CONFLICT (content): Merge conflict in drivers/scsi/isci/phy.c
CONFLICT (content): Merge conflict in drivers/scsi/isci/init.c
CONFLICT (content): Merge conflict in drivers/scsi/isci/host.c
CONFLICT (content): Merge conflict in drivers/ata/libata-scsi.c
Merging slave-dma/next (5170c05 Revert "drivers/dma: linux/module.h included twice")
CONFLICT (content): Merge conflict in drivers/mmc/host/atmel-mci.c
CONFLICT (modify/delete): arch/arm/include/asm/hardware/pl330.h deleted in slave-dma/next and modified in HEAD. Version HEAD of arch/arm/include/asm/hardware/pl330.h left in tree.
CONFLICT (modify/delete): arch/arm/common/pl330.c deleted in slave-dma/next and modified in HEAD. Version HEAD of arch/arm/common/pl330.c left in tree.
$ git rm -f arch/arm/common/pl330.c arch/arm/include/asm/hardware/pl330.h
Applying: DMA: PL330: update for code movement
Merging dmaengine/next (d07a74a dmaengine: fix missing 'cnt' in ?: in dmatest)
Merging net-next/master (058bd4d net: Convert printks to pr_<level>)
Merging wireless-next/master (5d6a1b0 mac80211: set basic rates earlier)
Merging bluetooth/master (44e612b Bluetooth: Check FINDING state in interleaved discovery)
Merging mtd/master (3c3e51d Merge ../linux-2.6 to bring in 3.3-rc fixes already merged)
Merging l2-mtd/master (4331c79 mtd: do not use plain 0 as NULL)
CONFLICT (content): Merge conflict in fs/jffs2/fs.c
CONFLICT (content): Merge conflict in drivers/mtd/chips/cfi_cmdset_0002.c
Merging crypto/master (8940426 crypto: twofish-x86_64/i586 - set alignmask to zero)
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/fuse.c
Merging sound/for-next (6a24a6a Merge branch 'topic/asoc' into for-next)
CONFLICT (content): Merge conflict in sound/soc/mxs/mxs-pcm.h
CONFLICT (content): Merge conflict in sound/soc/imx/imx-pcm-dma-mx2.c
Merging sound-asoc/for-next (700e510 Merge branch 'for-3.4' into asoc-next)
Merging cpufreq/next (fd0ef7a [CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling)
CONFLICT (content): Merge conflict in drivers/cpufreq/Kconfig.arm
Merging quilt/rr (2a22b63 cpumask: remove old cpu_*_map.)
CONFLICT (content): Merge conflict in arch/arm/kernel/kprobes.c
Merging input/next (05b7b84 Merge branch 'for-next' of github.com:rydberg/linux into next)
Merging input-mt/for-next (7491f3d bcm5974: Add pointer and buttonpad properties)
Merging block/for-next (7622d14 Merge branch 'for-3.4/drivers' into for-next)
Merging quilt/device-mapper (7714fd2 The thin metadata format can only make use of a device that is <= THIN_METADATA_MAX_SECTORS (currently 15.9375 GB). Therefore, there is no practical benefit to using a larger device.)
Merging embedded/master (4744b43 embedded: fix vc_translate operator precedence)
Merging firmware/master (6e03a20 firmware: speed up request_firmware(), v3)
Merging pcmcia/master (80af9e6 pcmcia at91_cf: fix raw gpio number usage)
CONFLICT (content): Merge conflict in drivers/pcmcia/soc_common.c
Merging battery/master (913272b Merge git://git.infradead.org/users/cbou/battery-urgent)
Merging mmc/mmc-next (1c352c3 mmc: sdhci-s3c: Enable runtime power management)
CONFLICT (content): Merge conflict in include/linux/mmc/host.h
CONFLICT (content): Merge conflict in drivers/mmc/host/sdhci-s3c.c
CONFLICT (content): Merge conflict in drivers/mmc/host/atmel-mci.c
CONFLICT (content): Merge conflict in drivers/mmc/core/host.h
CONFLICT (content): Merge conflict in drivers/mmc/core/core.c
Merging kgdb/kgdb-next (0e997a4 KDB: Fix usability issues relating to the 'enter' key.)
Merging slab/for-next (b80b6c0 Merge branch 'slab/next' into for-next)
Merging uclinux/for-next (5e442a4 Revert "proc: fix races against execve() of /proc/PID/fd**")
Merging md/for-next (2d9dcfb md/bitmap: ensure to load bitmap when creating via sysfs.)
Merging mfd/for-next (2f5f89b mfd: Fix pm8606 build failure)
CONFLICT (content): Merge conflict in drivers/mfd/ab8500-core.c
Merging drm/drm-next (8346532 Merge branch 'drm-gma500-alanc' into drm-core-next)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ringbuffer.c
Merging fbdev/fbdev-next (c2bc0a7 video:uvesafb: notice user when we failed to save hardware state)
Merging viafb/viafb-next (838ac78 viafb: avoid refresh and mode lookup in set_par)
Merging omap_dss2/for-next (001b7f3 ARM: OMAP2+: Fix compile error when FB_OMAP2 is not set)
Merging regulator/for-next (a52401b Merge branch 'regulator-drivers' into regulator-next)
Merging security/next (f67dabb KEYS: testing wrong bit for KEY_FLAG_REVOKED)
Merging selinux/master (a9ab18a selinux: include flow.h where used rather than get it indirectly)
Merging lblnet/master (7e27d6e Linux 2.6.35-rc3)
Merging watchdog/linux-next (fddcd0c watchdog: nowayout is bool)
Merging dwmw2-iommu/master (c3b92c8 Linux 3.1)
Merging iommu/next (2698648 Merge branches 'iommu/fixes', 'arm/tegra' and 'x86/amd' into next)
Merging osd/linux-next (0aa436b exofs: Cap on the memcpy() size)
Merging jc_docs/docs-next (5c050fb docs: update the development process document)
Merging trivial/for-next (cd635af usb: gadget: Kconfig: fix typo for 'different')
CONFLICT (content): Merge conflict in fs/jffs2/compr.c
CONFLICT (content): Merge conflict in drivers/watchdog/pnx4008_wdt.c
Merging audit/for-next (dcd6c92 Linux 3.3-rc1)
Merging pm/linux-next (58b594b PM / Sleep: JBD and JBD2 missing set_freezable())
Merging apm/for-next (b4a133d Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm)
Merging fsnotify/for-next (ef9bf3b fanotify: only destroy a mark if both its mask and its ignored_mask are cleared)
Merging edac/linux_next (4d096ca MAINTAINERS: add an entry for Edac Sandy Bridge driver)
Merging edac-amd/for-next (305f1c3 Merge branch '3.3-pci_device_id' into edac-for-next)
Merging devicetree/devicetree/next (0f22dd3 of: Only compile OF_DYNAMIC on PowerPC pseries and iseries)
CONFLICT (content): Merge conflict in include/linux/of.h
CONFLICT (modify/delete): arch/powerpc/platforms/iseries/Kconfig deleted in HEAD and modified in devicetree/devicetree/next. Version devicetree/devicetree/next of arch/powerpc/platforms/iseries/Kconfig left in tree.
$ git rm -f arch/powerpc/platforms/iseries/Kconfig
Merging spi/spi/next (9af4acc spi: release lock on error path in spi_pump_messages())
Merging tip/auto-latest (981ca5d Merge branch 'x86/cleanups' into auto-latest)
CONFLICT (content): Merge conflict in include/net/sock.h
CONFLICT (content): Merge conflict in arch/x86/platform/mrst/mrst.c
CONFLICT (modify/delete): arch/powerpc/platforms/iseries/setup.c deleted in HEAD and modified in tip/auto-latest. Version tip/auto-latest of arch/powerpc/platforms/iseries/setup.c left in tree.
CONFLICT (modify/delete): arch/m68k/kernel/process_no.c deleted in HEAD and modified in tip/auto-latest. Version tip/auto-latest of arch/m68k/kernel/process_no.c left in tree.
CONFLICT (modify/delete): arch/m68k/kernel/process_mm.c deleted in HEAD and modified in tip/auto-latest. Version tip/auto-latest of arch/m68k/kernel/process_mm.c left in tree.
$ git rm -f arch/m68k/kernel/process_no.c arch/m68k/kernel/process_mm.c arch/powerpc/platforms/iseries/setup.c
Applying: sched/rt: Use schedule_preempt_disabled() in m68k
Applying: staging: disable the sep driver due to breakage
Merging rcu/rcu/next (1cc8596 rcu: Stop spurious warnings from synchronize_sched_expedited)
Merging cputime/cputime (c3e0ef9 [S390] fix cputime overflow in uptime_proc_show)
Merging uprobes/for-next (b2c676f uprobes/core: handle breakpoint and singlestep exception.)
CONFLICT (add/add): Merge conflict in kernel/events/uprobes.c
CONFLICT (content): Merge conflict in kernel/events/Makefile
CONFLICT (add/add): Merge conflict in include/linux/uprobes.h
CONFLICT (add/add): Merge conflict in arch/x86/kernel/uprobes.c
CONFLICT (content): Merge conflict in arch/x86/kernel/traps.c
CONFLICT (content): Merge conflict in arch/x86/kernel/signal.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/perf_event_intel_ds.c
CONFLICT (add/add): Merge conflict in arch/x86/include/asm/uprobes.h
CONFLICT (content): Merge conflict in arch/x86/include/asm/compat.h
$ git reset --hard HEAD^
Merging refs/next/20120309/uprobes
CONFLICT (content): Merge conflict in kernel/fork.c
CONFLICT (add/add): Merge conflict in kernel/events/uprobes.c
CONFLICT (content): Merge conflict in kernel/events/Makefile
CONFLICT (add/add): Merge conflict in include/linux/uprobes.h
CONFLICT (content): Merge conflict in fs/signalfd.c
CONFLICT (content): Merge conflict in fs/eventpoll.c
CONFLICT (add/add): Merge conflict in arch/x86/kernel/uprobes.c
CONFLICT (add/add): Merge conflict in arch/x86/include/asm/uprobes.h
[master a0acd95] Merge commit 'refs/next/20120309/uprobes'
Merging cgroup/for-next (3ce3230 cgroup: Walk task list under tasklist_lock in cgroup_enable_task_cg_list)
CONFLICT (content): Merge conflict in block/blk-cgroup.c
Merging kmemleak/kmemleak (d65b4e9 Linux 3.3-rc3)
Merging kvm/linux-next (5c53b75 KVM: nVMX: Fix erroneous exception bitmap check)
Merging oprofile/for-next (b9e7f8e Merge branches 'oprofile/urgent' and 'oprofile/core' into oprofile/master)
CONFLICT (content): Merge conflict in tools/perf/util/header.h
CONFLICT (content): Merge conflict in tools/perf/util/header.c
Merging xen/upstream/xen (59e9a6b Merge branch 'upstream/ticketlock-cleanup' into upstream/xen)
CONFLICT (content): Merge conflict in arch/x86/include/asm/cmpxchg.h
Merging xen-two/linux-next (de34b60 Merge branch 'stable/for-linus-3.4' into linux-next)
Merging xen-pvhvm/linux-next (b056b6a xen: suspend: remove xen_hvm_suspend)
Merging percpu/for-next (adb7950 percpu: fix __this_cpu_{sub,inc,dec}_return() definition)
Merging workqueues/for-next (e06ffa1 workqueue: use percpu allocator for cwq on UP)
Merging drivers-x86/linux-next (2d23b05 panasonic-laptop: avoid overflow in acpi_pcc_hotkey_add())
CONFLICT (content): Merge conflict in arch/x86/platform/mrst/mrst.c
CONFLICT (content): Merge conflict in arch/x86/platform/geode/Makefile
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging hwpoison/hwpoison (46e387b Merge branch 'hwpoison-hugepages' into hwpoison)
Merging sysctl/master (4e75732 sysctl: Don't call sysctl_follow_link unless we are a link.)
CONFLICT (content): Merge conflict in fs/proc/proc_sysctl.c
Merging regmap/for-next (f5910f3 Merge branch 'regmap-core' into regmap-next)
CONFLICT (content): Merge conflict in sound/soc/imx/phycore-ac97.c
CONFLICT (rename/rename): Rename "arch/arm/plat-mxc/audmux-v2.c"->"sound/soc/imx/imx-audmux.c" in branch "HEAD" rename "arch/arm/plat-mxc/audmux-v2.c"->"arch/arm/plat-mxc/audmux.c" in "regmap/for-next"
CONFLICT (content): Merge conflict in sound/soc/imx/eukrea-tlv320.c
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/Makefile
CONFLICT (content): Merge conflict in arch/arm/plat-mxc/Kconfig
CONFLICT (content): Merge conflict in arch/arm/mach-imx/Kconfig
$ git rm -f arch/arm/plat-mxc/audmux.c
$ git rm -f arch/arm/plat-mxc/audmux-v2.c
Merging hsi/for-next (43139a6 HSI: hsi_char: Update ioctl-number.txt)
Merging driver-core/driver-core-next (04bf301 regulator: Support driver probe deferral)
CONFLICT (content): Merge conflict in include/linux/pci.h
CONFLICT (content): Merge conflict in drivers/base/driver.c
Merging tty/tty-next (8289621 vt: NULL dereference in vt_do_kdsk_ioctl())
CONFLICT (content): Merge conflict in drivers/isdn/gigaset/interface.c
CONFLICT (content): Merge conflict in arch/ia64/hp/sim/simserial.c
Merging usb/usb-next (f7a0d42 Merge 3.3-rc7 into usb-next)
CONFLICT (add/add): Merge conflict in drivers/net/usb/qmi_wwan.c
Merging staging/staging-next (4d3bfdd staging: tidspbridge: remove nldr_init() and nldr_exit())
Merging char-misc/char-misc-next (b222258 misc: bmp085: Use unsigned long to store jiffies)
Merging tmem/linux-next (b05b561 Merge branch 'devel/frontswap.v13' into linux-next)
Applying: mm: frontswap: update for security_vm_enough_memory API change
Merging writeback/writeback-for-next (b3f14b0 writeback: Remove outdated comment)
Merging arm-dt/devicetree/arm-next (ede338f dt: add documentation of ARM dt boot interface)
Merging hwspinlock/linux-next (8b37fcf hwspinlock: add MAINTAINERS entries)
Merging pinctrl/for-next (70b3637 pinctrl: fix error path in pinconf_map_to_setting())
Merging moduleh/for-sfr (9e1c4a5 Merge branch 'device-3.4' into for-sfr)
CONFLICT (content): Merge conflict in include/linux/mfd/abx500/ab8500.h
CONFLICT (content): Merge conflict in drivers/usb/dwc3/dwc3-omap.c
Merging vhost/linux-next (1e05b62 sh: use the the PCI channels's io_map_base)
Merging kmap_atomic/kmap_atomic (23a000f feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal)
CONFLICT (content): Merge conflict in drivers/staging/zram/zram_drv.c
CONFLICT (content): Merge conflict in drivers/staging/zcache/zcache-main.c
CONFLICT (content): Merge conflict in drivers/scsi/storvsc_drv.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/intel/e1000e/netdev.c
Merging modem-shm/for-next (3cff1cc caif_shm: Add CAIF driver for Shared memory for M7400)
Merging memblock/memblock-kill-early_node_map (7bd0b0f memblock: Reimplement memblock allocation using reverse free area iterator)
Merging remoteproc/for-next (e12bc14 remoteproc: s/big switch/lookup table/)
CONFLICT (content): Merge conflict in include/linux/virtio_ids.h
Merging irqdomain/irqdomain/next (e7cc3ac dt: fix twl4030 for non-dt compile on x86)
CONFLICT (content): Merge conflict in arch/powerpc/sysdev/mpic.c
CONFLICT (modify/delete): arch/powerpc/platforms/iseries/irq.c deleted in HEAD and modified in irqdomain/irqdomain/next. Version irqdomain/irqdomain/next of arch/powerpc/platforms/iseries/irq.c left in tree.
CONFLICT (content): Merge conflict in arch/c6x/Kconfig
CONFLICT (content): Merge conflict in arch/arm/common/gic.c
$ git rm -f arch/powerpc/platforms/iseries/irq.c
Merging gpio/gpio/next (81b279d gpio/davinci: fix enabling unbanked GPIO IRQs)
CONFLICT (content): Merge conflict in include/linux/mfd/tps65910.h
Merging arm-soc/for-next (cf8c142 Revert "Merge branch 'io-cleanup-for-3.4' of git://sources.calxeda.com/kernel/linux into next/cleanup2")
CONFLICT (content): Merge conflict in drivers/regulator/Makefile
CONFLICT (content): Merge conflict in drivers/regulator/Kconfig
CONFLICT (modify/delete): arch/arm/plat-versatile/localtimer.c deleted in HEAD and modified in arm-soc/for-next. Version arm-soc/for-next of arch/arm/plat-versatile/localtimer.c left in tree.
CONFLICT (modify/delete): arch/arm/plat-mxc/audmux-v1.c deleted in HEAD and modified in arm-soc/for-next. Version arm-soc/for-next of arch/arm/plat-mxc/audmux-v1.c left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-vexpress/ct-ca9x4.c
CONFLICT (content): Merge conflict in arch/arm/mach-ux500/timer.c
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Makefile
CONFLICT (modify/delete): arch/arm/mach-s3c2440/common.h deleted in HEAD and modified in arm-soc/for-next. Version arm-soc/for-next of arch/arm/mach-s3c2440/common.h left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/board-omap4panda.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap1/board-palmz71.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap1/board-palmtt.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap1/board-osk.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap1/board-nokia770.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap1/board-ams-delta.c
CONFLICT (content): Merge conflict in arch/arm/mach-imx/mm-imx5.c
CONFLICT (content): Merge conflict in arch/arm/mach-imx/mm-imx3.c
CONFLICT (content): Merge conflict in arch/arm/Kconfig
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
$ git rm -f arch/arm/plat-mxc/audmux-v1.c arch/arm/mach-s3c2440/common.h arch/arm/plat-versatile/localtimer.c
Merging kvmtool/master (20082f5 kvm tools: Fix realpath() error checking)
Merging dma-mapping/dma-mapping-next (6cc2bf1 common: DMA-mapping: add NON-CONSISTENT attribute)
Merging dma-buf/for-next (ab006e7 dma-buf: add dma_data_direction to unmap dma_buf_op)
Merging ktest/for-next (be405f9 ktest: Add INGORE_ERRORS to ignore warnings in boot up)
Merging cpuidle-cons/cpuidle_consol_pull (bd7fd2a SH: shmobile: Consolidate time keeping and irq enable)
CONFLICT (content): Merge conflict in drivers/cpuidle/cpuidle.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/cpuidle.c
Merging scsi-post-merge/merge-base:master ()
$ git checkout akpm
Applying: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
Applying: acerhdf: add support for Aspire 1410 BIOS v1.3314
Applying: acerhdf: add support for new hardware
Applying: acerhdf: lowered default temp fanon/fanoff values
Applying: arch/x86/platform/iris/iris.c: register a platform device and a platform driver
Applying: intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
Applying: x86, olpc: add debugfs interface for EC commands
Applying: x86: use this_cpu_xxx to replace percpu_xxx funcs
Applying: x86-use-this_cpu_xxx-to-replace-percpu_xxx-funcs-fix
Applying: x86: change percpu_read_stable() to this_cpu_read_stable()
Applying: x86-change-percpu_read_stable-to-this_cpu_read_stable-fix
Applying: arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
Applying: avr32: don't mask signals in the error path
Applying: avr32: use set_current_blocked() in handle_signal/sys_rt_sigreturn
Applying: avr32: use block_sigmask()
Applying: drivers/media/video/uvc/uvc_driver.c: use linux/atomic.h
Applying: Hexagon: use set_current_blocked() and block_sigmask()
Applying: drivers/idle/intel_idle.c: fix confusing code identation
Applying: tile: use set_current_blocked() and block_sigmask()
Applying: hrtimers: Special-case zero length sleeps
Applying: hpet: factor timer allocate from open
Applying: ia64: use set_current_blocked() and block_sigmask()
Applying: headers_check: recursively search for linux/types.h inclusion
Applying: microblaze: don't reimplement force_sigsegv()
Applying: microblaze: no need to reset handler if SA_ONESHOT
Applying: microblaze: fix signal masking
Applying: microblaze: use set_current_blocked() and block_sigmask()
Applying: MIPS: use set_current_blocked() and block_sigmask()
Applying: score: don't mask signals if we fail to setup signal stack
Applying: score: use set_current_blocked() and block_sigmask()
Applying: drivers/thermal/thermal_sys.c: fix build warning
Applying: thermal_sys: remove unnecessary line continuations
Applying: thermal_sys: remove obfuscating used-once macros
Applying: thermal_sys: kernel style cleanups
Applying: thermal_sys: convert printks to pr_<level>
Applying: thermal: add support for thermal sensor present on SPEAr13xx machines
Applying: thermal-add-support-for-thermal-sensor-present-on-spear13xx-machines-fix
Applying: thermal-add-support-for-thermal-sensor-present-on-spear13xx-machines-fix-fix
Applying: thermal/spear_thermal: Add compilation dependency on PLAT_SPEAR
Applying: thermal/spear_thermal: replace readl/writel with lighter _relaxed variants
Applying: thermal: spear13xx: checking for NULL instead of IS_ERR()
Applying: unicore32: use block_sigmask()
Applying: net/netfilter/nfnetlink_acct.c: use linux/atomic.h
Applying: blackfin: use set_current_blocked() and block_sigmask()
Applying: ocfs2: use find_last_bit()
Applying: ocfs2: use bitmap_weight()
Applying: parisc: use set_current_blocked() and block_sigmask()
Applying: xtensa: don't reimplement force_sigsegv()
Applying: xtensa: no need to reset handler if SA_ONESHOT
Applying: xtensa: don't mask signals if we fail to setup signal stack
Applying: xtensa: use set_current_blocked() and block_sigmask()
Applying: sparc: use block_sigmask()
Applying: mm, oom: avoid looping when chosen thread detaches its mm
Applying: mm, oom: fold oom_kill_task() into oom_kill_process()
Applying: mm, oom: do not emit oom killer warning if chosen thread is already exiting
Applying: mm, oom: introduce independent oom killer ratelimit state
Applying: mm: add rss counters consistency check
Applying: mm/vmscan.c: cleanup with s/reclaim_mode/isolate_mode/
Applying: mm: make get_mm_counter static-inline
Applying: mm: vmscan: fix misused nr_reclaimed in shrink_mem_cgroup_zone()
Applying: mm: make swapin readahead skip over holes
Applying: make-swapin-readahead-skip-over-holes-fix
Applying: vmscan: reclaim at order 0 when compaction is enabled
Applying: vmscan: kswapd carefully call compaction
Applying: vmscan-kswapd-carefully-call-compaction-fix
Applying: vmscan: only defer compaction for failed order and higher
Applying: compact_pgdat: workaround lockdep warning in kswapd
Applying: mm: compaction: make compact_control order signed
Applying: mm-compaction-make-compact_control-order-signed-fix
Applying: hugetlbfs: fix hugetlb_get_unmapped_area()
Applying: hugetlb: remove prev_vma from hugetlb_get_unmapped_area_topdown()
Applying: hugetlb: try to search again if it is really needed
Applying: hugetlb-try-to-search-again-if-it-is-really-needed-fix
Applying: mm: do not reset cached_hole_size when vma is unmapped
Applying: mm: search from free_area_cache for the bigger size
Applying: pagemap: avoid splitting thp when reading /proc/pid/pagemap
Applying: thp: optimize away unnecessary page table locking
Applying: fix mremap bug of failing to split thp
Applying: thp-optimize-away-unnecessary-page-table-locking-fix-checkpatch-fixes
Applying: pagemap: export KPF_THP
Applying: pagemap: document KPF_THP and make page-types aware of it
Applying: pagemap: introduce data structure for pagemap entry
Applying: mm: replace PAGE_MIGRATION with IS_ENABLED(CONFIG_MIGRATION)
Applying: mm: vmscan: forcibly scan highmem if there are too many buffer_heads pinning highmem
Applying: mm: move buffer_heads_over_limit check up
Applying: mm-vmscan-forcibly-scan-highmem-if-there-are-too-many-buffer_heads-pinning-highmem-fix-fix
Applying: mm: hugetlb: defer freeing pages when gathering surplus pages
Applying: rmap: anon_vma_prepare: Reduce code duplication by calling anon_vma_chain_link
Applying: vmscan: handle isolated pages with lru lock released
Applying: thp: documentation: 'transparent_hugepage=' can also be specified on cmdline
Applying: mm: hugetlb: bail out unmapping after serving reference page
Applying: mm: hugetlb: cleanup duplicated code in unmapping vm range
Applying: procfs: mark thread stack correctly in proc/<pid>/maps
Applying: mm, oom: force oom kill on sysrq+f
Applying: tmpfs: security xattr setting on inode creation
Applying: thp: allow a hwpoisoned head page to be put back to LRU
Applying: mm: fix move/migrate_pages() race on task struct
Applying: mm-fix-move-migrate_pages-race-on-task-struct-checkpatch-fixes
Applying: mm: drain percpu lru add/rotate page-vectors on cpu hot-unplug
Applying: bootmem/sparsemem: remove limit constraint in alloc_bootmem_section
Applying: bootmem-sparsemem-remove-limit-constraint-in-alloc_bootmem_section-fix
Applying: ksm: clean up page_trans_compound_anon_split()
Applying: ksm: cleanup: introduce ksm_check_mm()
Applying: ksm-cleanup-introduce-ksm_check_mm-fix
Applying: hugetlbfs: avoid taking i_mutex from hugetlbfs_read()
Applying: mm: don't set __GFP_WRITE on ramfs/sysfs writes
Applying: mm: use global_dirty_limit in throttle_vm_writeout()
Applying: mm: fix page-faults detection in swap-token logic
Applying: mm: add extra free kbytes tunable
Applying: mm-add-extra-free-kbytes-tunable-update
Applying: mm-add-extra-free-kbytes-tunable-update-checkpatch-fixes
Applying: memcg: replace MEM_CONT by MEM_RES_CTLR
Applying: memcg: replace mem and mem_cont stragglers
Applying: memcg: lru_size instead of MEM_CGROUP_ZSTAT
Applying: memcg: enum lru_list lru
Applying: memcg: remove redundant returns
Applying: memcg: remove unnecessary thp check in page stat accounting
Applying: idr: make idr_get_next() good for rcu_read_lock()
Applying: cgroup: revert ss_id_lock to spinlock
Applying: memcg: let css_get_next() rely upon rcu_read_lock()
Applying: memcg: remove PCG_CACHE page_cgroup flag
Applying: memcg-remove-pcg_cache-page_cgroup-flag-checkpatch-fixes
Applying: memcg: remove PCG_CACHE page_cgroup flag fix
Applying: memcg: kill dead prev_priority stubs
Applying: memcg: remove EXPORT_SYMBOL(mem_cgroup_update_page_stat)
Applying: memcg: simplify move_account() check
Applying: memcg-simplify-move_account-check-fix
Applying: memcg: remove PCG_MOVE_LOCK flag from page_cgroup
Applying: memcg: use new logic for page stat accounting
Applying: memcg-use-new-logic-for-page-stat-accounting-fix
Applying: memcg: fix deadlock by avoiding stat lock when anon
Applying: memcg: remove PCG_FILE_MAPPED
Applying: memcg-remove-pcg_file_mapped-fix
Applying: memcg: remove PCG_FILE_MAPPED fix cosmetic fix
Applying: memcg: remove PCG_CACHE page_cgroup flag fix2
Applying: memcg: fix performance of mem_cgroup_begin_update_page_stat()
Applying: memcg-fix-performance-of-mem_cgroup_begin_update_page_stat-fix
Applying: mm/memcontrol.c: s/stealed/stolen/
Applying: mm/memcontrol.c: remove redundant BUG_ON() in mem_cgroup_usage_unregister_event()
Applying: mm/memcontrol.c: remove unnecessary 'break' in mem_cgroup_read()
Applying: frv: use set_current_blocked() and block_sigmask()
Applying: sh: no need to reset handler if SA_ONESHOT
Applying: sh: use set_current_blocked() and block_sigmask()
Applying: h8300: use set_current_blocked() and block_sigmask()
Applying: alpha: use set_current_blocked() and block_sigmask()
Applying: m32r: use set_current_blocked() and block_sigmask()
Applying: m68k: use set_current_blocked() and block_sigmask()
Applying: mn10300: use set_current_blocked() and block_sigmask()
Applying: C6X: use set_current_blocked() and block_sigmask()
Applying: cpuidle: add a sysfs entry to disable specific C state for debug purpose.
Applying: cris: use set_current_blocked() and block_sigmask()
Applying: cris: select GENERIC_ATOMIC64
Applying: um: don't restore current->blocked on error
Applying: um: use set_current_blocked() and block_sigmask()
Applying: magic.h: move some FS magic numbers into magic.h
Applying: nmi watchdog: do not use cpp symbol in Kconfig
Applying: ceph, cifs, nfs, fuse: boolean and / or confusion
Applying: net: use this_cpu_xxx replace percpu_xxx funcs
Applying: percpu: remove percpu_xxx() functions
Applying: percpu-remove-percpu_xxx-functions-fix
Applying: headers: include linux/types.h where appropriate
Applying: consolidate WARN_...ONCE() static variables
Applying: Remove remaining bits of io_remap_page_range()
Applying: prctl: add PR_{SET,GET}_CHILD_SUBREAPER to allow simple process supervision
Applying: prctl-add-pr_setget_child_subreaper-to-allow-simple-process-supervision-fix
Applying: prctl-add-pr_setget_child_subreaper-to-allow-simple-process-supervision-fix-fix
Applying: kernel/exit.c: if init dies, log a signal which killed it, if any
Applying: kernel-exitc-if-init-dies-log-a-signal-which-killed-it-if-any-fix
Applying: powerpc/eeh: remove eeh_event_handler()->daemonize()
CONFLICT (content): Merge conflict in arch/powerpc/platforms/pseries/eeh_event.c
Applying: vfs: increment iversion when a file is truncated
Applying: brlocks/lglocks: cleanups
Applying: vfs: correctly set the dir i_mutex lockdep class
Applying: seq_file: fix mishandling of consecutive pread() invocations.
Applying: fs: symlink restrictions on sticky directories
Applying: fs-symlink-restrictions-on-sticky-directories-fix-2
Applying: fs: hardlink creation restrictions
Applying: fs-hardlink-creation-restrictions-fix
Applying: fs: hardlink creation restriction cleanup
Applying: get_maintainer: use a default "unknown" S: status/role
Applying: MAINTAINERS: fix REMOTEPROC F: typo
Applying: MAINTAINERS: Update MCA section
Applying: MAINTAINERS: update git urls for 2.6 deletions
Applying: MAINTAINERS: add status to ALPHA architecture
Applying: MAINTAINERS: Add "S: Maintained" to clkdev and clk sections
Applying: backlight: convert backlight i2c drivers to module_i2c_driver
Applying: backlight: convert backlight spi drivers to module_spi_driver
Applying: drivers/video/backlight/wm831x_bl.c: use devm_ functions
Applying: drivers/video/backlight: use devm_ functions
Applying: drivers/video/backlight/adp5520_bl.c: use devm_ functions
Applying: backlight: new backlight driver for LP855x devices
Applying: backlight: lp855x_bl: Add missing mutex_unlock in lp855x_read_byte error path
Applying: backlight/lp855x_bl.c: check platform data in lp855x_probe()
Applying: backlight/lp855x_bl.c: small cleanups
Applying: lp855x-bl: remove unnecessary platform data
Applying: lp855x-bl: remove unnecessary headers
Applying: backlight: add driver for Bachmann's ot200
Applying: backlight-add-driver-for-bachmanns-ot200-fix
Applying: backlight: add support for Pandora backlight
Applying: backlight-add-support-for-pandora-backlight-v2
Applying: backlight: convert platform_lcd to dev_pm_ops
Applying: backlight: fix ot200_bl build
Applying: bitops: rename for_each_set_bit_cont() in favor of analogous list.h function
Applying: bitops: remove for_each_set_bit_cont()
Applying: regmap: cope with bitops API change (for_each_set_bit_cont)
Applying: bitops: introduce for_each_clear_bit()
Applying: mtd: use for_each_clear_bit()
Applying: s390/char: use for_each_clear_bit()
Applying: uwb: use for_each_clear_bit()
Applying: x86: use for_each_clear_bit_from()
Applying: drivers/leds/leds-lp5521.c: fix typo
Applying: drivers/leds/leds-tca6507.c: cleanup error handling in tca6507_probe()
Applying: drivers/leds/leds-tca6507.c: remove obsolete cleanup for clientdata
Applying: drivers/leds/leds-lp5521.c: add 'name' in the lp5521_led_config
Applying: drivers/leds/leds-lp5521.c: add 'update_config' in the lp5521_platform_data
Applying: drivers/leds/leds-lp5521.c: support led pattern data
Applying: leds-lp5521-support-led-pattern-data-checkpatch-fixes
Applying: drivers/leds/leds-lp5521.c: redefinition of register bits
Applying: drivers/leds/leds-lp5521.c: ret may be uninitialized
Applying: drivers/leds/leds-lp5523.c: constify some data
Applying: drivers/leds: add driver for PCA9633 I2C chip
Applying: drivers-leds-add-driver-for-pca9663-i2c-chip-fix
Applying: drivers-leds-add-driver-for-pca9663-i2c-chip-fix-2
Applying: drivers/leds/leds-pca9633.c: fix kcalloc parameters swapped
Applying: drivers/leds/leds-gpio.c: use linux/gpio.h rather than asm/gpio.h
Applying: leds-lm3530: set the max_brightness to 127
Applying: leds-lm3530: replace i2c_client with led_classdev
Applying: leds-lm3530-replace-i2c_client-with-led_classdev-fix
Applying: leds-lm3530: support pwm input mode
Applying: leds-lm3530: remove LM3530_ALS_ZONE_REG code
Applying: leds-lm3530: replace pltfm with pdata
Applying: drivers/leds/leds-pca9633.c: remove unused 'adapter' variable
Applying: drivers/leds/leds-lm3530.c: move the code setting gen_config to one place
Applying: drivers-leds-leds-lm3530c-move-the-code-setting-gen_config-to-one-place-fix
Applying: string: memchr_inv speed improvements
Applying: prio_tree: remove unnecessary code in prio_tree_replace
Applying: prio_tree: cleanup prio_tree_left()/prio_tree_right()
Applying: prio_tree: simplify prio_tree_expand()
Applying: prio_tree: introduce prio_set_parent()
Applying: include/ and checkpatch: prefer __scanf to __attribute__((format(scanf,...)
Applying: checkpatch: add some --strict coding style checks
Applying: checkpatch-add-some-strict-coding-style-checks-v3
Applying: checkpatch.pl: be silent when -q and --ignore is given
Applying: checkpatch: catch [ ... ] usage when not at the beginning of definition
Applying: checkpatch: allow simple character constants in #defines
Applying: checkpatch: handle string concatenation in simple #defines
Applying: checkpatch: high precedence operators do not require additional parentheses in #defines
Applying: checkpatch: add [] to type extensions
Applying: checkpatch: add --strict tests for braces, comments and casts
Applying: checkpatch: add --strict test for strings split across multiple lines
Applying: crc32: remove two instances of trailing whitespaces
Applying: crc32: move long comment about crc32 fundamentals to Documentation/
Applying: crc32-move-long-comment-about-crc32-fundamentals-to-documentation-fix
Applying: crc32: simplify unit test code
Applying: crc32: miscellaneous cleanups
Applying: crc32: fix mixing of endian-specific types
Applying: crc32: make CRC_*_BITS definition correspond to actual bit counts
Applying: crc32: add slice-by-8 algorithm to existing code
Applying: crc32: optimize loop counter for x86
Applying: crc32: add note about this patchset to crc32.c
Applying: crc32: bolt on crc32c
Applying: crc32: Don't reference unnecessary crc32 tables in single-bit mode
Applying: crypto: crc32c should use library implementation
Applying: crc32: add self-test code for crc32c
Applying: crc32: select an algorithm via Kconfig
Applying: epoll: comment the funky #ifdef
Applying: epoll: remove unneeded variable in reverse_path_check()
Applying: init/do_mounts.c: create /root if it does not exist
Applying: rtc-spear: fix for balancing the enable_irq_wake in Power Mgmt
Applying: rtc/spear: fix for RTC_AIE_ON and RTC_AIE_OFF ioctl errors
Applying: rtc/rtc-spear: call platform_set_drvdata() before registering rtc device
Applying: rtc: convert rtc spi drivers to module_spi_driver
Applying: rtc: convert rtc i2c drivers to module_i2c_driver
Applying: MIPS: add RTC support for loongson1B
Applying: drivers/rtc/rtc-twl.c: optimize IRQ bit access
Applying: drivers/rtc/rtc-twl.c: enable RTC irrespective of its prior state
Applying: drivers/rtc/rtc-twl.c: simplify RTC interrupt clearing
Applying: drivers/rtc/rtc-twl.c: return correct RTC event from ISR
Applying: drivers/rtc: remove IRQF_DISABLED
Applying: drivers/rtc/rtc-pm8xxx.c: make pm8xxx_rtc_pm_ops static
Applying: drivers/rtc/rtc-max8925.c: fix max8925_rtc_read_alarm() return value error
Applying: drivers/rtc/rtc-max8925.c: fix alarm->enabled mistake in max8925_rtc_read_alarm/max8925_rtc_set_alarm
Applying: rtc: driver for DA9052/53 PMIC v1
Applying: rtc-rtc-driver-for-da9052-53-pmic-v1-fix
Applying: rtc: ds1307: refactor chip_desc table
Applying: rtc: ds1307: simplify irq setup code
Applying: rtc: ds1307: comment and format cleanup
Applying: rtc: ds1307: generalise ram size and offset
Applying: rtc: fix rtc-ds1307 printk format warning
Applying: ptrace: the killed tracee should not enter the syscall
Applying: ptrace: don't send SIGTRAP on exec if SEIZED
Applying: ptrace: don't modify flags on PTRACE_SETOPTIONS failure
Applying: ptrace: simplify PTRACE_foo constants and PTRACE_SETOPTIONS code
Applying: ptrace: make PTRACE_SEIZE set ptrace options specified in 'data' parameter
Applying: ptrace: renumber PTRACE_EVENT_STOP so that future new options and events can match
Applying: ptrace: remove PTRACE_SEIZE_DEVEL bit
Applying: signal: give SEND_SIG_FORCED more power to beat SIGNAL_UNKILLABLE
Applying: signal: cosmetic, s/from_ancestor_ns/force/ in prepare_signal() paths
Applying: signal: oom_kill_task: use SEND_SIG_FORCED instead of force_sig()
Applying: signal: zap_pid_ns_processes: s/SEND_SIG_NOINFO/SEND_SIG_FORCED/
Applying: usermodehelper: use UMH_WAIT_PROC consistently
Applying: usermodehelper: introduce umh_complete(sub_info)
Applying: usermodehelper: implement UMH_KILLABLE
Applying: usermodehelper: kill umh_wait, renumber UMH_* constants
Applying: usermodehelper: ____call_usermodehelper() doesn't need do_exit()
Applying: kmod: introduce call_modprobe() helper
Applying: kmod: make __request_module() killable
Applying: kmod: avoid deadlock from recursive kmod call
Applying: kmod-avoid-deadlock-by-recursive-kmod-call-fix
Applying: fs/proc/kcore.c: make get_sparsemem_vmemmap_info() static
Applying: proc: speedup /proc/stat handling
Applying: procfs: add num_to_str() to speed up /proc/stat
Applying: procfs-add-num_to_str-to-speed-up-proc-stat-fix
Applying: procfs: avoid breaking the ABI in /proc/stat
Applying: procfs: speed up /proc/pid/stat, statm
Applying: procfs-speed-up-proc-pid-stat-statm-checkpatch-fixes
Applying: proc: clean up /proc/<pid>/environ handling
Applying: seq_file: add seq_set_overflow(), seq_overflow()
Applying: seq_file-add-seq_set_overflow-seq_overflow-fix
Applying: smp: introduce a generic on_each_cpu_mask() function
Applying: arm: move arm over to generic on_each_cpu_mask
Applying: tile: move tile to use generic on_each_cpu_mask
Applying: smp: add func to IPI cpus based on parameter func
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-fix
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-update
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-update-fix
Applying: smp: add func to IPI cpus based on parameter func
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-v9-fix
Applying: slub: only IPI CPUs that have per cpu obj to flush
Applying: fs: only send IPI to invalidate LRU BH when needed
Applying: mm: only IPI CPUs to drain local pages if they exist
Applying: mm-only-ipi-cpus-to-drain-local-pages-if-they-exist-update
Applying: mm-only-ipi-cpus-to-drain-local-pages-if-they-exist-v9
Applying: lib/cpumask.c: remove __any_online_cpu()
Applying: arch/ia64: remove references to cpu_*_map
Applying: kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations
Applying: ipc/sem.c: alternatives to preempt_disable()
Applying: ipc: provide generic compat versions of IPC syscalls
Applying: ipmi: decrease the IPMI message transaction time in interrupt mode
Applying: ipmi: increase KCS timeouts
Applying: ipmi: use a tasklet for handling received messages
Applying: ipmi: fix message handling during panics
Applying: ipmi: simplify locking
Applying: ipmi: use locks on watchdog timeout set on reboot
Applying: sysctl: use bitmap library functions
Applying: pidns: add reboot_pid_ns() to handle the reboot syscall
Applying: pidns-add-reboot_pid_ns-to-handle-the-reboot-syscall-fix
Applying: pidns-add-reboot_pid_ns-to-handle-the-reboot-syscall-checkpatch-fixes
Applying: fs/proc/namespaces.c: prevent crash when ns_entries[] is empty
Applying: selftests: launch individual selftests from the main Makefile
Applying: selftests/Makefile: make `run_tests' depend on `all'
Applying: mm: move page-types.c from Documentation to tools/vm
Applying: mm: move slabinfo.c to tools/vm
Applying: mm: move hugepage test examples to tools/testing/selftests/vm
Applying: move-hugepage-test-examples-to-tools-testing-selftests-vm-fix
Applying: move-hugepage-test-examples-to-tools-testing-selftests-vm-fix-fix
Applying: sysctl: make kernel.ns_last_pid control dependent on CHECKPOINT_RESTORE
Applying: fs, proc: introduce /proc/<pid>/task/<tid>/children entry
Applying: syscalls, x86: add __NR_kcmp syscall
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8-fix
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8-fix-2
Applying: c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat
Applying: c/r: prctl: extend PR_SET_MM to set up more mm_struct entries
Applying: ramoops: use pstore interface
Applying: ramoops: fix printk format warnings
Applying: notify_change(): check that i_mutex is held
Merging akpm (c60072d notify_change(): check that i_mutex is held)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [GIT PULL/NEXT] sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
From: Ingo Molnar @ 2012-03-13 9:26 UTC (permalink / raw)
To: Russell King
Cc: Linus Torvalds, Stephen Rothwell, linux-next, linux-kernel,
Catalin Marinas, Peter Zijlstra
In-Reply-To: <20120313090040.GE27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> >
> > > Sorry, you're blaming the wrong person. I got the commit via
> > > a pull, not via a patch.
> >
> > This is the most idiotic excuse I've ever read.
>
> Sod this crap, I'm dropping Catalin's patches. [...]
As I said it in my first mail, doing that is unnecessary - but
if you insist on being difficult then Catalin, feel free to pull
the patch from tip:sched/arch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/arch
HEAD: 01f23e1630 sched/arch: Introduce the finish_arch_post_lock_switch() scheduler callback
it's v3.3-rc7 based so it will generate no conflict with
linux-next. It only contains this commit so you can use it
without pulling in other pending scheduler changes.
This is the trivial and easy Git based topic branch approach
PeterZ asked Russell a month ago to consider:
http://lkml.org/lkml/2012/2/16/232
which request Russell sadly ignored.
In any case, Catalin's ARM work is not blocked in any fashion.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 9:11 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313090612.GA22820@elte.hu>
Oh and one last thing. I'm never going to take any patch which touches
the scheduler ever again, no matter how trivial. If that means people
can't get their patches in, then that's not my loss - that's your loss.
Especially when they're removing a special case from the scheduler -
which I hasten to add was requested by PeterZ.
I really don't care what you have to say in reply, I'm no longer listening
to objectionable people like you who make a mountain out of a mole hill.
On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > >
> > > > Please check your mailbox:
> > > >
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > > Peter Zijlstra <peterz@infradead.org>,
> > > > Will Deacon <will.deacon@arm.com>,
> > > > Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > > scheduler hook
> > >
> > > Btw., are you losing emails? Because the reply from peterz to
> > > those patches, a month ago, was pretty clear:
> > >
> > > > > Russell, what's the status of these patches? I'd like to see
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some
> > > > > other patches on top.
> > >
> > > You never replied to PeterZ's request, you just ignored this
> > > scheduler maintainer request and you just did it in some
> > > random way that was most convenient to you many weeks after
> > > the thread died down, ignoring everyone else's concerns - a
> > > pretty usual pattern from you I have to say.
> >
> > Sigh. You know, people communicate via other methods from
> > time to time. How the hell do you think PeterZ provided his
> > ack for the patch?
>
> He provided it via email to lkml:
>
> http://lkml.org/lkml/2012/2/27/210
>
> But he asked *you* to do a proper Git space solution:
>
> http://lkml.org/lkml/2012/2/16/232
>
> You *never* replied to that request that I can see, you just
> ignored it, why?
>
> This discussion shows that you seem to have basic reading
> comprehension problems.
>
> Thanks,
>
> Ingo
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-13 9:10 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Oleg Nesterov, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev, Gavin Shan
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
arch/powerpc/platforms/pseries/eeh_event.c between commit 29f8bf1b7f79
("powerpc/pseries: Cleanup comments in EEH aux components") from the
powerpc tree and commit "powerpc/eeh: remove eeh_event_handler()
->daemonize()" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/powerpc/platforms/pseries/eeh_event.c
index 4a47525,a6d33c8..0000000
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@@ -56,10 -58,10 +56,10 @@@ DEFINE_MUTEX(eeh_event_mutex)
static int eeh_event_handler(void * dummy)
{
unsigned long flags;
- struct eeh_event *event;
- struct pci_dn *pdn;
+ struct eeh_event *event;
+ struct eeh_dev *edev;
- daemonize("eehd");
+ set_task_comm(current, "eehd");
set_current_state(TASK_INTERRUPTIBLE);
spin_lock_irqsave(&eeh_eventlist_lock, flags);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 9:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313090612.GA22820@elte.hu>
From: Catalin Marinas <catalin.marinas@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
Peter Zijlstra <peterz@infradead.org>
Subject: [GIT PULL] ARM: Remove the __ARCH_WANT_INTERRUPTS_ON_CTXSW
definition
Delivery-date: Mon, 27 Feb 2012 16:45:17 +0000
Hi Russell,
Could you please pull the context switching patches for ARM, together
with a generic hook acked by PeterZ?
Thanks,
On Tue, Mar 13, 2012 at 10:06:12AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> > >
> > > * Russell King <rmk@arm.linux.org.uk> wrote:
> > >
> > > > Please check your mailbox:
> > > >
> > > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > > Peter Zijlstra <peterz@infradead.org>,
> > > > Will Deacon <will.deacon@arm.com>,
> > > > Frank Rowand <frank.rowand@am.sony.com>
> > > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > > scheduler hook
> > >
> > > Btw., are you losing emails? Because the reply from peterz to
> > > those patches, a month ago, was pretty clear:
> > >
> > > > > Russell, what's the status of these patches? I'd like to see
> > > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > > >
> > > > > probably ask Ingo to pull your tree so that I can stack some
> > > > > other patches on top.
> > >
> > > You never replied to PeterZ's request, you just ignored this
> > > scheduler maintainer request and you just did it in some
> > > random way that was most convenient to you many weeks after
> > > the thread died down, ignoring everyone else's concerns - a
> > > pretty usual pattern from you I have to say.
> >
> > Sigh. You know, people communicate via other methods from
> > time to time. How the hell do you think PeterZ provided his
> > ack for the patch?
>
> He provided it via email to lkml:
>
> http://lkml.org/lkml/2012/2/27/210
>
> But he asked *you* to do a proper Git space solution:
>
> http://lkml.org/lkml/2012/2/16/232
>
> You *never* replied to that request that I can see, you just
> ignored it, why?
I talked to peterz by other means. He gave his ack after that message was
sent. He was fully aware of what was happening.
> This discussion shows that you seem to have basic reading
> comprehension problems.
And your a fucking idiot too. Go to hell Ingo and stop being an utter
prat.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 9:06 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313085847.GD27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
> >
> > * Russell King <rmk@arm.linux.org.uk> wrote:
> >
> > > Please check your mailbox:
> > >
> > > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > > Peter Zijlstra <peterz@infradead.org>,
> > > Will Deacon <will.deacon@arm.com>,
> > > Frank Rowand <frank.rowand@am.sony.com>
> > > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > > scheduler hook
> >
> > Btw., are you losing emails? Because the reply from peterz to
> > those patches, a month ago, was pretty clear:
> >
> > > > Russell, what's the status of these patches? I'd like to see
> > > > them land in 3.4 if possible. I'm fine either way, I'll
> > > >
> > > > probably ask Ingo to pull your tree so that I can stack some
> > > > other patches on top.
> >
> > You never replied to PeterZ's request, you just ignored this
> > scheduler maintainer request and you just did it in some
> > random way that was most convenient to you many weeks after
> > the thread died down, ignoring everyone else's concerns - a
> > pretty usual pattern from you I have to say.
>
> Sigh. You know, people communicate via other methods from
> time to time. How the hell do you think PeterZ provided his
> ack for the patch?
He provided it via email to lkml:
http://lkml.org/lkml/2012/2/27/210
But he asked *you* to do a proper Git space solution:
http://lkml.org/lkml/2012/2/16/232
You *never* replied to that request that I can see, you just
ignored it, why?
This discussion shows that you seem to have basic reading
comprehension problems.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 9:00 UTC (permalink / raw)
To: Ingo Molnar, Linus Torvalds
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313085628.GB6991@elte.hu>
On Tue, Mar 13, 2012 at 09:56:28AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > Sorry, you're blaming the wrong person. I got the commit via
> > a pull, not via a patch.
>
> This is the most idiotic excuse I've ever read.
Sod this crap, I'm dropping Catalin's patches. Deal with the fucking thing
yourself. Catalin, sorry, put some people are just total idiots over
simple merge conflicts and blow things totally out of proportion.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Russell King @ 2012-03-13 8:58 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313084803.GA6991@elte.hu>
On Tue, Mar 13, 2012 at 09:48:03AM +0100, Ingo Molnar wrote:
>
> * Russell King <rmk@arm.linux.org.uk> wrote:
>
> > Please check your mailbox:
> >
> > Date: Fri, 20 Jan 2012 17:42:27 +0000
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
> > Cc: Russell King <linux@arm.linux.org.uk>, Ingo Molnar <mingo@elte.hu>,
> > Peter Zijlstra <peterz@infradead.org>,
> > Will Deacon <will.deacon@arm.com>,
> > Frank Rowand <frank.rowand@am.sony.com>
> > Subject: [PATCH v3 1/6] sched: Introduce the finish_arch_post_lock_switch()
> > scheduler hook
>
> Btw., are you losing emails? Because the reply from peterz to
> those patches, a month ago, was pretty clear:
>
> > > Russell, what's the status of these patches? I'd like to see
> > > them land in 3.4 if possible. I'm fine either way, I'll
> > >
> > > probably ask Ingo to pull your tree so that I can stack some
> > > other patches on top.
>
> You never replied to PeterZ's request, you just ignored this
> scheduler maintainer request and you just did it in some random
> way that was most convenient to you many weeks after the thread
> died down, ignoring everyone else's concerns - a pretty usual
> pattern from you I have to say.
Sigh. You know, people communicate via other methods from time to time.
How the hell do you think PeterZ provided his ack for the patch?
Stop looking for people to blame. Instead, if you failed to communicate
about how you wanted to handle the patch, blame yourself instead.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the arm tree with Linus' tree
From: Ingo Molnar @ 2012-03-13 8:56 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, linux-next, linux-kernel, Catalin Marinas,
Peter Zijlstra
In-Reply-To: <20120313084713.GB27560@flint.arm.linux.org.uk>
* Russell King <rmk@arm.linux.org.uk> wrote:
> Sorry, you're blaming the wrong person. I got the commit via
> a pull, not via a patch.
This is the most idiotic excuse I've ever read.
Dammit, don't pull code you don't maintain and which you have
not checked the background of, *especially* not if the
originating discussion very clearly asked *you* to do it in
another way.
We were modifying that very code in this development cycle, in
the scheduler tree - a fact highlighted by the conflict - which
you could have seen yourself, had you even attempted to
test-merge your tree to linux-next ...
Let me quote PeterZ again:
> > Russell, what's the status of these patches? I'd like to see
> > them land in 3.4 if possible. I'm fine either way, I'll
> >
> > probably ask Ingo to pull your tree so that I can stack some
> > other patches on top.
Russell, read and reply to your mail in a timely and reliable
fashion, that will avoid such mixups in the future.
> If that's how you want to run your bit of the kernel, then
> please be more responsive when you're sent patches and say how
> you want to handle things. Don't ignore patches and then blame
> people when conflicts happen.
Stop blaming others for your own mistakes, one of the the
scheduler maintainers replied to the patches a month ago, in an
absolutely constructive fashion:
http://lkml.org/lkml/2012/2/16/232
You never replied to PeterZ that I can see.
Again, fortunately it's not a big deal right now - both the
commit and the conflict is trivial - but your current attitute
towards applying patches and following discussions is rather sad
and could cause bigger problems in the future.
Thanks,
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox