On Fri, Nov 30, 2018 at 2:34 PM Logan Gunthorpe logang@deltatee.com wrote:
On 2018-11-30 3:28 p.m., Dan Williams wrote:
On Fri, Nov 30, 2018 at 2:19 PM Logan Gunthorpe logang@deltatee.com wrote:
Hey,
On 2018-11-29 11:51 a.m., Dan Williams wrote:
Got it, let me see how bad moving arch_remove_memory() turns out, sounds like a decent approach to coordinate multiple users of a single ref.
I've put together a patch set[1] that fixes all the users of devm_memremap_pages() without moving arch_remove_memory(). It's pretty clean except for the p2pdma case which is fairly tricky but I don't think there's an easy way around that.
The solution I'm trying is to introduce a devm_memremap_pages_remove() that each user can call after they have called percpu_ref_exit(), it's just crashing for me currently...
Ok, that's probably less of a clean up for other users, but sounds like it would be less tricky for p2pdma. I'd have to create a list of all pgmaps, but that's not so hard and doesn't create any nasty races to consider like my current solution.
If you come up with a better solution that's great, otherwise let me know and I'll do some clean up and more testing and send this set to the lists. Though, we might need to wait for your patch to land before we can properly send the fix to it (the first patch in my series)...
I'd say go ahead and send it. We can fix p2pdma as a follow-on. Send it to Andrew as a patch relative to the current -next tree.
Ok, though, how do I reference the current patch in Andrew's tree? Or does it matter?
I would just let Andrew know that this applies incrementally to "mm-hmm-mark-hmm_devmem_add-add_resource-export_symbol_gpl.patch" in his tree. You can't specify Fixes: tags for pending patches in -mm. Andrew may choose to squash the change into the existing patch, which may be the best outcome for not exposing a bisect regression point for p2pdma.