From: Dan Williams <dan.j.williams@intel.com> To: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "DRI Development" <dri-devel@lists.freedesktop.org>, LKML <linux-kernel@vger.kernel.org>, "KVM list" <kvm@vger.kernel.org>, "Linux MM" <linux-mm@kvack.org>, "Linux ARM" <linux-arm-kernel@lists.infradead.org>, linux-samsung-soc <linux-samsung-soc@vger.kernel.org>, "Linux-media@vger.kernel.org" <linux-media@vger.kernel.org>, linux-s390 <linux-s390@vger.kernel.org>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>, "Daniel Vetter" <daniel.vetter@intel.com>, "Jason Gunthorpe" <jgg@ziepe.ca>, "Kees Cook" <keescook@chromium.org>, "Andrew Morton" <akpm@linux-foundation.org>, "John Hubbard" <jhubbard@nvidia.com>, "Jérôme Glisse" <jglisse@redhat.com>, "Jan Kara" <jack@suse.cz>, "Arnd Bergmann" <arnd@arndb.de>, "David Hildenbrand" <david@redhat.com>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, "Daniel Vetter" <daniel.vetter@ffwll.com> Subject: Re: [PATCH v3 14/16] resource: Move devmem revoke code to resource framework Date: Wed, 21 Oct 2020 11:59:37 -0700 [thread overview] Message-ID: <CAPcyv4gj=+SkL9LKPf1XixQkNmygp3X45n-QpxajZyM8TqKv1w@mail.gmail.com> (raw) In-Reply-To: <20201021085655.1192025-15-daniel.vetter@ffwll.ch> On Wed, Oct 21, 2020 at 1:57 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote: > > We want all iomem mmaps to consistently revoke ptes when the kernel > takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the > pci bar mmaps available through procfs and sysfs, which currently do > not revoke mappings. > > To prepare for this, move the code from the /dev/kmem driver to > kernel/resource.c. > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> > Cc: Jason Gunthorpe <jgg@ziepe.ca> > Cc: Kees Cook <keescook@chromium.org> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: John Hubbard <jhubbard@nvidia.com> > Cc: Jérôme Glisse <jglisse@redhat.com> > Cc: Jan Kara <jack@suse.cz> > Cc: Dan Williams <dan.j.williams@intel.com> > Cc: linux-mm@kvack.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-samsung-soc@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch> > Cc: David Hildenbrand <david@redhat.com> > Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.com> > -- > v3: > - add barrier for consistency and document why we don't have to check > for NULL (Jason) > --- > drivers/char/mem.c | 85 +--------------------------------- > include/linux/ioport.h | 6 +-- > kernel/resource.c | 101 ++++++++++++++++++++++++++++++++++++++++- > 3 files changed, 102 insertions(+), 90 deletions(-) > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c > index 5502f56f3655..53338aad8d28 100644 > --- a/drivers/char/mem.c > +++ b/drivers/char/mem.c > @@ -31,9 +31,6 @@ > #include <linux/uio.h> > #include <linux/uaccess.h> > #include <linux/security.h> > -#include <linux/pseudo_fs.h> > -#include <uapi/linux/magic.h> > -#include <linux/mount.h> > > #ifdef CONFIG_IA64 > # include <linux/efi.h> > @@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig) > return ret; > } > > -static struct inode *devmem_inode; > - > -#ifdef CONFIG_IO_STRICT_DEVMEM > -void revoke_devmem(struct resource *res) > -{ > - /* pairs with smp_store_release() in devmem_init_inode() */ > - struct inode *inode = smp_load_acquire(&devmem_inode); > - > - /* > - * Check that the initialization has completed. Losing the race > - * is ok because it means drivers are claiming resources before > - * the fs_initcall level of init and prevent /dev/mem from > - * establishing mappings. > - */ > - if (!inode) > - return; > - > - /* > - * The expectation is that the driver has successfully marked > - * the resource busy by this point, so devmem_is_allowed() > - * should start returning false, however for performance this > - * does not iterate the entire resource range. > - */ > - if (devmem_is_allowed(PHYS_PFN(res->start)) && > - devmem_is_allowed(PHYS_PFN(res->end))) { > - /* > - * *cringe* iomem=relaxed says "go ahead, what's the > - * worst that can happen?" > - */ > - return; > - } > - > - unmap_mapping_range(inode->i_mapping, res->start, resource_size(res), 1); > -} > -#endif > - > static int open_port(struct inode *inode, struct file *filp) > { > int rc; > @@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file *filp) > * revocations when drivers want to take over a /dev/mem mapped > * range. > */ > - filp->f_mapping = inode->i_mapping; > + filp->f_mapping = iomem_get_mapping(); > > return 0; > } > @@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t *mode) > > static struct class *mem_class; > > -static int devmem_fs_init_fs_context(struct fs_context *fc) > -{ > - return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM; > -} > - > -static struct file_system_type devmem_fs_type = { > - .name = "devmem", > - .owner = THIS_MODULE, > - .init_fs_context = devmem_fs_init_fs_context, > - .kill_sb = kill_anon_super, > -}; > - > -static int devmem_init_inode(void) > -{ > - static struct vfsmount *devmem_vfs_mount; > - static int devmem_fs_cnt; > - struct inode *inode; > - int rc; > - > - rc = simple_pin_fs(&devmem_fs_type, &devmem_vfs_mount, &devmem_fs_cnt); > - if (rc < 0) { > - pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc); > - return rc; > - } > - > - inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb); > - if (IS_ERR(inode)) { > - rc = PTR_ERR(inode); > - pr_err("Cannot allocate inode for /dev/mem: %d\n", rc); > - simple_release_fs(&devmem_vfs_mount, &devmem_fs_cnt); > - return rc; > - } > - > - /* > - * Publish /dev/mem initialized. > - * Pairs with smp_load_acquire() in revoke_devmem(). > - */ > - smp_store_release(&devmem_inode, inode); > - > - return 0; > -} > - > static int __init chr_dev_init(void) > { > int minor; > @@ -1058,8 +977,6 @@ static int __init chr_dev_init(void) > */ > if ((minor == DEVPORT_MINOR) && !arch_has_dev_port()) > continue; > - if ((minor == DEVMEM_MINOR) && devmem_init_inode() != 0) > - continue; > > device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor), > NULL, devlist[minor].name); > diff --git a/include/linux/ioport.h b/include/linux/ioport.h > index 6c2b06fe8beb..8ffb61b36606 100644 > --- a/include/linux/ioport.h > +++ b/include/linux/ioport.h > @@ -302,11 +302,7 @@ struct resource *devm_request_free_mem_region(struct device *dev, > struct resource *request_free_mem_region(struct resource *base, > unsigned long size, const char *name); > > -#ifdef CONFIG_IO_STRICT_DEVMEM > -void revoke_devmem(struct resource *res); > -#else > -static inline void revoke_devmem(struct resource *res) { }; > -#endif > +extern struct address_space *iomem_get_mapping(void); > > #endif /* __ASSEMBLY__ */ > #endif /* _LINUX_IOPORT_H */ > diff --git a/kernel/resource.c b/kernel/resource.c > index 841737bbda9e..a92fed5b9997 100644 > --- a/kernel/resource.c > +++ b/kernel/resource.c > @@ -18,12 +18,15 @@ > #include <linux/spinlock.h> > #include <linux/fs.h> > #include <linux/proc_fs.h> > +#include <linux/pseudo_fs.h> > #include <linux/sched.h> > #include <linux/seq_file.h> > #include <linux/device.h> > #include <linux/pfn.h> > #include <linux/mm.h> > +#include <linux/mount.h> > #include <linux/resource_ext.h> > +#include <uapi/linux/magic.h> > #include <asm/io.h> > > > @@ -1112,6 +1115,58 @@ resource_size_t resource_alignment(struct resource *res) > > static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait); > > +static struct inode *iomem_inode; > + > +#ifdef CONFIG_IO_STRICT_DEVMEM > +static void revoke_iomem(struct resource *res) > +{ > + /* pairs with smp_store_release() in iomem_init_inode() */ > + struct inode *inode = smp_load_acquire(&iomem_inode); > + > + /* > + * Check that the initialization has completed. Losing the race > + * is ok because it means drivers are claiming resources before > + * the fs_initcall level of init and prevent /dev/mem from How about: s,/dev/mem,iomem_get_mapping() users, ...now that this facility is generalized? > + * establishing mappings. > + */ > + if (!inode) > + return; > + > + /* > + * The expectation is that the driver has successfully marked > + * the resource busy by this point, so devmem_is_allowed() > + * should start returning false, however for performance this > + * does not iterate the entire resource range. > + */ > + if (devmem_is_allowed(PHYS_PFN(res->start)) && > + devmem_is_allowed(PHYS_PFN(res->end))) { > + /* > + * *cringe* iomem=relaxed says "go ahead, what's the > + * worst that can happen?" > + */ > + return; > + } > + > + unmap_mapping_range(inode->i_mapping, res->start, resource_size(res), 1); > +} > +struct address_space *iomem_get_mapping(void) > +{ > + /* > + * This function is only called from file open paths, hence guaranteed > + * that fs_initcalls have completed and no need to check for NULL. But > + * since revoke_iomem can be called before the initcall we still need > + * the barrier to appease checkers. > + */ > + return smp_load_acquire(&iomem_inode)->i_mapping; > +} > +#else > +static void revoke_iomem(struct resource *res) {} > +struct address_space *iomem_get_mapping(void) > +{ > + return NULL; > +} > +#endif > + > /** > * __request_region - create a new busy resource region > * @parent: parent resource descriptor > @@ -1179,7 +1234,7 @@ struct resource * __request_region(struct resource *parent, > write_unlock(&resource_lock); > > if (res && orig_parent == &iomem_resource) > - revoke_devmem(res); > + revoke_iomem(res); > > return res; > } > @@ -1713,4 +1768,48 @@ static int __init strict_iomem(char *str) > return 1; > } > > +static int iomem_fs_init_fs_context(struct fs_context *fc) > +{ > + return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM; > +} > + > +static struct file_system_type iomem_fs_type = { > + .name = "iomem", > + .owner = THIS_MODULE, > + .init_fs_context = iomem_fs_init_fs_context, > + .kill_sb = kill_anon_super, > +}; > + > +static int __init iomem_init_inode(void) > +{ > + static struct vfsmount *iomem_vfs_mount; > + static int iomem_fs_cnt; > + struct inode *inode; > + int rc; > + > + rc = simple_pin_fs(&iomem_fs_type, &iomem_vfs_mount, &iomem_fs_cnt); > + if (rc < 0) { > + pr_err("Cannot mount iomem pseudo filesystem: %d\n", rc); > + return rc; > + } > + > + inode = alloc_anon_inode(iomem_vfs_mount->mnt_sb); > + if (IS_ERR(inode)) { > + rc = PTR_ERR(inode); > + pr_err("Cannot allocate inode for iomem: %d\n", rc); > + simple_release_fs(&iomem_vfs_mount, &iomem_fs_cnt); > + return rc; > + } > + > + /* > + * Publish /dev/mem initialized. Similar potential fixup: "Publish iomem revocation inode initialized" Other than that: Reviewed-by: Dan Williams <dan.j.williams@intel.com>
next prev parent reply other threads:[~2020-10-21 18:59 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-21 8:56 [PATCH v3 00/16] follow_pfn and other iomap races Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 01/16] drm/exynos: Stop using frame_vector helpers Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 02/16] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 03/16] misc/habana: Stop using frame_vector helpers Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 04/16] misc/habana: Use FOLL_LONGTERM for userptr Daniel Vetter 2020-10-23 9:12 ` Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 05/16] mm/frame-vector: Use FOLL_LONGTERM Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 06/16] media: videobuf2: Move frame_vector into media subsystem Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 07/16] mm: Close race in generic_access_phys Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 08/16] s390/pci: Remove races against pte updates Daniel Vetter 2020-10-21 9:37 ` Niklas Schnelle 2020-10-21 13:56 ` Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 09/16] mm: Add unsafe_follow_pfn Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 10/16] media/videbuf1|2: Mark follow_pfn usage as unsafe Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 11/16] vfio/type1: Mark follow_pfn " Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 12/16] PCI: Obey iomem restrictions for procfs mmap Daniel Vetter 2020-10-21 12:50 ` Jason Gunthorpe 2020-10-21 14:42 ` Daniel Vetter 2020-10-21 15:13 ` Jason Gunthorpe 2020-10-21 15:54 ` Daniel Vetter 2020-10-21 16:37 ` Jason Gunthorpe 2020-10-21 19:24 ` Daniel Vetter 2020-10-21 23:20 ` Jason Gunthorpe 2020-10-22 7:00 ` Daniel Vetter 2020-10-22 11:43 ` Jason Gunthorpe 2020-10-22 13:04 ` Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 13/16] /dev/mem: Only set filp->f_mapping Daniel Vetter 2020-10-21 18:21 ` Dan Williams 2020-10-21 8:56 ` [PATCH v3 14/16] resource: Move devmem revoke code to resource framework Daniel Vetter 2020-10-21 18:59 ` Dan Williams [this message] 2020-10-21 19:25 ` Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 15/16] sysfs: Support zapping of binary attr mmaps Daniel Vetter 2020-10-21 8:56 ` [PATCH v3 16/16] PCI: Revoke mappings like devmem Daniel Vetter 2020-10-21 12:51 ` [PATCH v3 00/16] follow_pfn and other iomap races Jason Gunthorpe
Reply instructions: 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPcyv4gj=+SkL9LKPf1XixQkNmygp3X45n-QpxajZyM8TqKv1w@mail.gmail.com' \ --to=dan.j.williams@intel.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=daniel.vetter@ffwll.ch \ --cc=daniel.vetter@ffwll.com \ --cc=daniel.vetter@intel.com \ --cc=david@redhat.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=jack@suse.cz \ --cc=jgg@ziepe.ca \ --cc=jglisse@redhat.com \ --cc=jhubbard@nvidia.com \ --cc=keescook@chromium.org \ --cc=kvm@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-s390@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=rafael.j.wysocki@intel.com \ --subject='Re: [PATCH v3 14/16] resource: Move devmem revoke code to resource framework' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).