Sorry I must have given completely the wrong idea I had *NO* suggestion of taking the patches from my attachment. It was just to show how I resolved the nominated mainline changes to the 3.0.y tree.
Please try this exact order to check out the stable tree and apply the changes. I just did this and it worked for me. git co -b fixes-stable-3.0.y remotes/stable/linux-3.0.y git cherry-pick be768912a49b10b68e96fbd8fa3cab0adfbd3091 git cherry-pick 2bbc6942273b5b3097bd265d82227bdd84b351b2 * Now this one has a conflict - but is easily resolved: git cherry-pick a4ac9fea016fc5c09227eb479bd35e34978323a4 - Replace the variable realloc_head in mainline patch with add_head in 3.0.y stable branch (two lines). On 28 September 2012 09:24, Greg KH <[email protected]> wrote: > On Fri, Sep 28, 2012 at 09:03:19AM +1000, Andrew Worsley wrote: >> I attach a diff against v3.0.43 at the end for reference - as gmail >> will expand tabs et cetera >> and I assume you would (very sensibly) only merge existing changes. > > No, I can't do that at all. Have you read the > Documentation/stable_kernel_rules.txt file for how to get patches into > the stable kernel tree? I can't take things that are not already in > Linus's tree. I believe I was following this particular rule: ---- - It or an equivalent fix must already exist in Linus' tree (upstream). ---- and using this format: ------ - If the patch requires other patches as prerequisites which can be cherry-picked than this can be specified in the following format in the sign-off area: Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: <[email protected]> # 3.3.x: fd21073: sched: Fix affinity logic Cc: <[email protected]> # 3.3.x Signed-off-by: Ingo Molnar <[email protected]> The tag sequence has the meaning of: git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit> ----- Again sorry, I never intended you to take that patch and apply it. That's why it was all one giant patch. I will give you a list of patches and nominate the order which was just in the natural historical order (oldest to newest) with the resolution described below. I can't see where it says how to handle conflicts in the cherry-picked patches but if it is a problem - just drop the last conflicting patch. Otherwise drop all of them. ..... >> Yep I did the merge directly on v3.0.42 (what I had at the time) and >> got one conflict where a variable name had changed >> which was very easy to resolve by hand. The only problem was with: >> >> a4ac9fea01 PCI : Calculate right add_size >> >> Where I had to change realloc_head variable to add_head >> >> Here's my log for 3.0.y: >> >> * 34e81ae Merge remote branch 'remotes/stable/linux-3.0.y' into >> v3.0.42-fixes .... >> * | b40aff3 PCI : Calculate right add_size >> * | 3fb7b76 PCI : ability to relocate assigned pci-resources >> * | 4d181ba PCI: honor child buses add_size in hot plug configuration .... > > I don't understand this log at all. > > Exactly what git commits, in Linus's tree, in what order, should I apply > to 3.0.y in order to get this to work? Please see the steps at the start of this e-mail or ask for more specific questions about what you want. The above log shows the order the main line patches were applied - with the last to be applied listed first (as git log normally produces). i.e. 4d181ba then 3fb7b76 and finally b40aff3 (which has the conflict) Andrew -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
