From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FA9AC43467 for ; Fri, 9 Oct 2020 18:29:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8F8422284 for ; Fri, 9 Oct 2020 18:29:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="iLTsuWlJ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B8F8422284 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ECB7B6B005C; Fri, 9 Oct 2020 14:29:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA3968E0001; Fri, 9 Oct 2020 14:29:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6A706B0068; Fri, 9 Oct 2020 14:29:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id A91C36B005C for ; Fri, 9 Oct 2020 14:29:08 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 43AF08249980 for ; Fri, 9 Oct 2020 18:29:08 +0000 (UTC) X-FDA: 77353223976.04.walk97_4a0b70b271e2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 1F8C68005A7F for ; Fri, 9 Oct 2020 18:29:08 +0000 (UTC) X-HE-Tag: walk97_4a0b70b271e2 X-Filterd-Recvd-Size: 5135 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 9 Oct 2020 18:29:07 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id 33so10299517edq.13 for ; Fri, 09 Oct 2020 11:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oVIvf//qjy+hkVJdi59awFrM6IZJ9JvpO2cbPx+MdNs=; b=iLTsuWlJpjQ9lEPve4/i/wPKY7/WDc/EpLX4/nS4Vs7XATh36CjNusW0cAwcZzYVKB zc2lO4Dz7JRsbYqzp49bDWt7Nj2zjd+nQ3ChgcqgyusxmNzv8xBi0X9an51ub82xSMED ypIlohpfnHirbuqkE/mXCCbfP8pd5KhfDsovroGKCzUs8q45yo4Fd6/w1fPvA40p9Zsk Fhj1k3kJxsDCiab+2o7o95nm9iELSt9Olz0BwNfHJpYbcdvZw4q4VKPfH3rzH+ZSLvin 8ENlmZNYLWdWLsvLquEHYWK2U/S9AfZj3u8X6XmfQJoqlt/05+soeGykQWGSaZLnN0RZ i9tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oVIvf//qjy+hkVJdi59awFrM6IZJ9JvpO2cbPx+MdNs=; b=QKBIO9YL7O/LBpbLliFHnI9ml9/0JNzBVTYNnHNj+x30cdp5IQK1QKlwRNoxjBINGA gFSYWde4Fb/yUjsyrtwnBvybkD0PVFMgNgk9fbN/Wi9eJzVoCIjM1XQ13EePnZTP3k0r swXh1LGVrjcE45K+CCdN08XZ7cIEnLbdb+9iTveq8xeC2bu7gycgnocY8+X8djqtrFCj hatNB4ZdF6+slgv37vFrHCRS/mADESp3ZM6ATdsR6taE9jkziEAAoCqDZ9vif9bi6XPb ttjLK2/7zxWTXcw5qYGCwMygudp6bKZvnMaAmkn5qTgRAfERr5A12aELnRXqO3kTIfxL csQw== X-Gm-Message-State: AOAM533Y7fkVL0nJ9o89fPVgG6kMPItzSeJsIkbE6gvFfTUQ6IEifFsy 5wWRkYgaGArmQP/FrOFJ9S8z2KqoAMhT8XnG+Etq52+NLys= X-Google-Smtp-Source: ABdhPJzWk7BhJg0T57QGadQcytTP33YarvnD8YMhqI7SBWAAOvIcMevxnSHZgp/bJXzdV8lpWps/qAzI6LdBImluO+E= X-Received: by 2002:a50:d0d0:: with SMTP id g16mr559132edf.18.1602268145655; Fri, 09 Oct 2020 11:29:05 -0700 (PDT) MIME-Version: 1.0 References: <20201009075934.3509076-1-daniel.vetter@ffwll.ch> <20201009075934.3509076-15-daniel.vetter@ffwll.ch> <20201009123109.GO5177@ziepe.ca> <20201009143209.GS5177@ziepe.ca> In-Reply-To: <20201009143209.GS5177@ziepe.ca> From: Dan Williams Date: Fri, 9 Oct 2020 11:28:54 -0700 Message-ID: Subject: Re: [PATCH v2 14/17] resource: Move devmem revoke code to resource framework To: Jason Gunthorpe Cc: Daniel Vetter , DRI Development , LKML , KVM list , Linux MM , Linux ARM , linux-samsung-soc , "open list:DMA BUFFER SHARING FRAMEWORK" , linux-s390 , Daniel Vetter , Kees Cook , Andrew Morton , John Hubbard , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , Arnd Bergmann , Greg Kroah-Hartman , David Hildenbrand , "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 9, 2020 at 7:32 AM Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 04:24:45PM +0200, Daniel Vetter wrote: > > On Fri, Oct 9, 2020 at 2:31 PM Jason Gunthorpe wrote: > > > > > > On Fri, Oct 09, 2020 at 09:59:31AM +0200, Daniel Vetter wrote: > > > > > > > +struct address_space *iomem_get_mapping(void) > > > > +{ > > > > + return iomem_inode->i_mapping; > > > > > > This should pair an acquire with the release below > > > > > > > + /* > > > > + * Publish /dev/mem initialized. > > > > + * Pairs with smp_load_acquire() in revoke_iomem(). > > > > + */ > > > > + smp_store_release(&iomem_inode, inode); > > > > > > However, this seems abnormal, initcalls rarely do this kind of stuff > > > with global data.. > > > > > > The kernel crashes if this fs_initcall is raced with > > > iomem_get_mapping() due to the unconditional dereference, so I think > > > it can be safely switched to a simple assignment. > > > > Ah yes I checked this all, but forgot to correctly annotate the > > iomem_get_mapping access. For reference, see b34e7e298d7a ("/dev/mem: > > Add missing memory barriers for devmem_inode"). > > Oh yikes, so revoke_iomem can run concurrently during early boot, > tricky. It runs early because request_mem_region() can run before fs_initcall. Rather than add an unnecessary lock just arrange for the revoke to be skipped before the inode is initialized. The expectation is that any early resource reservations will block future userspace mapping attempts.