From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by kanga.kvack.org (Postfix) with ESMTP id 1C0EB6B5A98 for ; Fri, 30 Nov 2018 17:48:12 -0500 (EST) Received: by mail-oi1-f198.google.com with SMTP id k76so3808836oih.13 for ; Fri, 30 Nov 2018 14:48:12 -0800 (PST) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id w8sor3471237otg.23.2018.11.30.14.48.11 for (Google Transport Security); Fri, 30 Nov 2018 14:48:11 -0800 (PST) MIME-Version: 1.0 References: <154275556908.76910.8966087090637564219.stgit@dwillia2-desk3.amr.corp.intel.com> <154275558526.76910.7535251937849268605.stgit@dwillia2-desk3.amr.corp.intel.com> <6875ca04-a36a-89ae-825b-f629ab011d47@deltatee.com> <14d6413c-b002-c152-5016-7ed659c08c24@deltatee.com> <43778343-6d43-eb43-0de0-3db6828902d0@deltatee.com> In-Reply-To: From: Dan Williams Date: Fri, 30 Nov 2018 14:47:59 -0800 Message-ID: Subject: Re: [PATCH v8 3/7] mm, devm_memremap_pages: Fix shutdown handling Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Logan Gunthorpe Cc: Andrew Morton , stable , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Christoph Hellwig , Linus Torvalds , Linux MM , Linux Kernel Mailing List , Maling list - DRI developers , Bjorn Helgaas , Stephen Bates On Fri, Nov 30, 2018 at 2:34 PM Logan Gunthorpe wrote: > > > > On 2018-11-30 3:28 p.m., Dan Williams wrote: > > On Fri, Nov 30, 2018 at 2:19 PM Logan Gunthorpe 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.