LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Robin Murphy <email@example.com>
To: Jason Gunthorpe <firstname.lastname@example.org>,
Andrew Morton <email@example.com>
Cc: Christoph Hellwig <firstname.lastname@example.org>,
Mark Rutland <email@example.com>,
Michal Hocko <firstname.lastname@example.org>,
Dan Williams <email@example.com>
Subject: Re: [PATCH v3 0/4] Devmap cleanups + arm64 support
Date: Thu, 4 Jul 2019 21:54:36 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 2019-07-04 8:59 pm, Jason Gunthorpe wrote:
> On Thu, Jul 04, 2019 at 11:53:24AM -0700, Andrew Morton wrote:
>> On Wed, 26 Jun 2019 20:35:51 -0700 Andrew Morton <email@example.com> wrote:
>>>> Let me know and I can help orchestate this.
>>> Well. Whatever works. In this situation I'd stage the patches after
>>> linux-next and would merge them up after the prereq patches have been
>>> merged into mainline. Easy.
>> All right, what the hell just happened?
Aw crap, and I had this series chalked up as done...
> Christoph's patch series for the devmap & hmm rework finally made it
> into linux-next, sorry, it took quite a few iterations on the list to
> get all the reviews and tests, and figure out how to resolve some
> other conflicting things. So it just made it this week.
> Recall, this is the patch series I asked you about routing a few weeks
> ago, as it really exceeded the small area that hmm.git was supposed to
> cover. I think we are both caught off guard how big the conflict is!
>> A bunch of new material has just been introduced into linux-next.
>> I've partially unpicked the resulting mess, haven't dared trying to
>> compile it yet. To get this far I'll need to drop two patch series
>> and one individual patch:
> This one we discussed, and I thought we agreed would go to your 'stage
> after linux-next' flow (see above). I think the conflict was minor
I can rebase and resend tomorrow if there's an agreement on what exactly
to base it on - I'd really like to get this ticked off for 5.3 if at all
> Dan pointed to this while reviewing CH's series and said the conflicts
> would be manageable, but they are certainly larger than I expected!
> This series is the one that seems to be the really big trouble. I
> already checked all the other stuff that Stephen resolved, and it
> looks OK and managable. Just this one conflict with kernel/memremap.c
> is beyond me.
> What approach do you want to take to go forward? Here are some thoughts:
> CH has said he is away for the long weekend, so the path that involves
> the fewest people is if Dan respins the above on linux-next and it
> goes later with the arm patches above, assuming defering it for now
> has no other adverse effects on -mm.
> Pushing CH's series to -mm would need a respin on top of Dan's series
> above and would need to carry along the whole hmm.git (about 44
> patches). Signs are that this could be managed with the code currently
> in the GPU trees.
> If we give up on CH's series the hmm.git will not have conflicts,
> however we just kick the can to the next merge window where we will be
> back to having to co-ordinate amd/nouveau/rdma git trees and -mm's
> patch workflow - and I think we will be worse off as we will have
> totally given up on a git based work flow for this. :(
> Stephen used a minor conflict resolution for this one, I checked it
> carefully and it looked OK.
>> I thought you were just going to move material out of -mm and into
> Dan brought up a patch from Ira conflicting with CH's work and we did
> handle that by moving a single patch, as well I moved several hmm
> specific patches early in the cycle.
>> Didn't begin to suspect that new and quite disruptive material would
>> be introduced late in -rc7!!
> Unfortunately a non-rebasing tree like hmm.git should only get patches
> into linux-next once they are fully reviewed and done on the list. I
> did not attempt to run separately patches 'under review' into
> linux-next as you do.
> Actually I didn't even know this would benefit your workflow, rebasing
> patches on top of linux-next is not part of the git based workflow I'm
> using :(
> AFAIK Dan and CH were both tracking conflicts with linux-next, so I'd
> like to hear from Dan what he thinks about his series, maybe the
> rebase is simple & safe for him? Dan and CH were working pretty
> closely on CH's series.
next prev parent reply other threads:[~2019-07-04 20:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-23 15:03 Robin Murphy
2019-05-23 15:03 ` [PATCH v3 1/4] mm/memremap: Rename and consolidate SECTION_SIZE Robin Murphy
2019-05-23 15:03 ` [PATCH v3 2/4] mm: clean up is_device_*_page() definitions Robin Murphy
2019-05-23 15:03 ` [PATCH v3 3/4] mm: introduce ARCH_HAS_PTE_DEVMAP Robin Murphy
2019-05-23 15:03 ` [PATCH v3 4/4] arm64: mm: Implement pte_devmap support Robin Murphy
2019-05-24 18:08 ` Will Deacon
2019-05-24 18:38 ` Robin Murphy
2019-05-27 6:23 ` Anshuman Khandual
2019-05-28 13:46 ` [PATCH v3.1 " Robin Murphy
2019-05-29 10:03 ` Will Deacon
2019-06-26 7:35 ` [PATCH v3 0/4] Devmap cleanups + arm64 support Christoph Hellwig
2019-06-26 12:31 ` Mark Rutland
2019-06-26 15:38 ` Christoph Hellwig
2019-06-26 15:45 ` Jason Gunthorpe
2019-06-27 3:35 ` Andrew Morton
2019-07-04 18:53 ` Andrew Morton
2019-07-04 19:59 ` Jason Gunthorpe
2019-07-04 20:53 ` Andrew Morton
2019-07-04 21:28 ` Jason Gunthorpe
2019-07-05 15:47 ` Jason Gunthorpe
2019-07-04 20:54 ` Robin Murphy [this message]
2019-07-04 21:13 ` Andrew Morton
2019-07-05 11:16 ` Robin Murphy
2019-07-04 23:37 ` Dan Williams
2019-07-05 12:32 ` Jason Gunthorpe
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH v3 0/4] Devmap cleanups + arm64 support' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).