linux.git/drivers/char/mem.c, branch v5.12

Merge tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm

2021-02-23T01:45:02+00:00

Pull follow_pfn() updates from Daniel Vetter:
 "Fixes around VM_FPNMAP and follow_pfn:

   - replace mm/frame_vector.c by get_user_pages in misc/habana and
     drm/exynos drivers, then move that into media as it's sole user

   - close race in generic_access_phys

   - s390 pci ioctl fix of this series landed in 5.11 already

   - properly revoke iomem mappings (/dev/mem, pci files)"

* tag 'topic/iomem-mmap-vs-gup-2021-02-22' of git://anongit.freedesktop.org/drm/drm:
  PCI: Revoke mappings like devmem
  PCI: Also set up legacy files only after sysfs init
  sysfs: Support zapping of binary attr mmaps
  resource: Move devmem revoke code to resource framework
  /dev/mem: Only set filp->f_mapping
  PCI: Obey iomem restrictions for procfs mmap
  mm: Close race in generic_access_phys
  media: videobuf2: Move frame_vector into media subsystem
  mm/frame-vector: Use FOLL_LONGTERM
  misc/habana: Use FOLL_LONGTERM for userptr
  misc/habana: Stop using frame_vector helpers
  drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
  drm/exynos: Stop using frame_vector helpers

MIPS: mm:remove function __uncached_access()

2021-01-27T20:52:01+00:00

MIPS can now use the default uncached_access like other archs.

Signed-off-by: Yanteng Si 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Thomas Bogendoerfer

resource: Move devmem revoke code to resource framework

2021-01-12T13:26:31+00:00

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.

During review Jason spotted that barriers are used somewhat
inconsistently. Fix that up while we shuffle this code, since it
doesn't have an actual impact at runtime. Otherwise no semantic and
behavioural changes intended, just code extraction and adjusting
comments and names.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
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 
Cc: Greg Kroah-Hartman 
Cc: Daniel Vetter 
Cc: David Hildenbrand 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20201127164131.2244124-11-daniel.vetter@ffwll.ch

/dev/mem: Only set filp->f_mapping

2021-01-12T13:26:31+00:00

When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.

But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, since in e.g. drivers/gpu we
don't do that. Per Dan this seems to be copypasta from places which do
care about pagecache consistency, but not needed. Hence remove it for
slightly less confusion.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
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
Reviewed-by: Dan Williams 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20201127164131.2244124-10-daniel.vetter@ffwll.ch

/dev/zero: fixups for ->read

2020-09-07T08:46:35+00:00

Reported the cleared bytes in case of a partial clear_user instead
of -EFAULT, and remove a pointless conditional, as cleared must be
non-zero by the time we hit the signal_pending check.

Reported-by: Rasmus Villemoes 
Signed-off-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20200907082700.2057137-1-hch@lst.de
Signed-off-by: Greg Kroah-Hartman

/dev/zero: also implement ->read

2020-09-03T17:50:47+00:00

Christophe reported a major speedup due to avoiding the iov_iter
overhead, so just add this trivial function.  Note that /dev/zero
already implements both an iter and non-iter writes so this just
makes it more symmetric.

Tested-by: Christophe Leroy 
Signed-off-by: Christoph Hellwig 
Link: https://lore.kernel.org/r/20200903155922.1111551-1-hch@lst.de
Signed-off-by: Greg Kroah-Hartman

treewide: Use fallthrough pseudo-keyword

2020-08-23T22:36:59+00:00

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva

/dev/mem: Add missing memory barriers for devmem_inode

2020-07-23T07:47:13+00:00

WRITE_ONCE() isn't the correct way to publish a pointer to a data
structure, since it doesn't include a write memory barrier.  Therefore
other tasks may see that the pointer has been set but not see that the
pointed-to memory has finished being initialized yet.  Instead a
primitive with "release" semantics is needed.

Use smp_store_release() for this.

The use of READ_ONCE() on the read side is still potentially correct if
there's no control dependency, i.e. if all memory being "published" is
transitively reachable via the pointer itself.  But this pairing is
somewhat confusing and error-prone.  So just upgrade the read side to
smp_load_acquire() so that it clearly pairs with smp_store_release().

Cc: Arnd Bergmann 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Matthew Wilcox 
Cc: Russell King 
Cc: Andrew Morton 
Fixes: 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the region")
Signed-off-by: Eric Biggers 
Cc: stable 
Acked-by: Dan Williams 
Link: https://lore.kernel.org/r/20200716060553.24618-1-ebiggers@kernel.org
Signed-off-by: Greg Kroah-Hartman

maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault

2020-06-17T17:57:41+00:00

Better describe what these functions do.

Suggested-by: Linus Torvalds 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Linus Torvalds

/dev/mem: Revoke mappings when a driver claims the region

2020-05-27T09:10:05+00:00

Close the hole of holding a mapping over kernel driver takeover event of
a given address range.

Commit 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
introduced CONFIG_IO_STRICT_DEVMEM with the goal of protecting the
kernel against scenarios where a /dev/mem user tramples memory that a
kernel driver owns. However, this protection only prevents *new* read(),
write() and mmap() requests. Established mappings prior to the driver
calling request_mem_region() are left alone.

Especially with persistent memory, and the core kernel metadata that is
stored there, there are plentiful scenarios for a /dev/mem user to
violate the expectations of the driver and cause amplified damage.

Teach request_mem_region() to find and shoot down active /dev/mem
mappings that it believes it has successfully claimed for the exclusive
use of the driver. Effectively a driver call to request_mem_region()
becomes a hole-punch on the /dev/mem device.

The typical usage of unmap_mapping_range() is part of
truncate_pagecache() to punch a hole in a file, but in this case the
implementation is only doing the "first half" of a hole punch. Namely it
is just evacuating current established mappings of the "hole", and it
relies on the fact that /dev/mem establishes mappings in terms of
absolute physical address offsets. Once existing mmap users are
invalidated they can attempt to re-establish the mapping, or attempt to
continue issuing read(2) / write(2) to the invalidated extent, but they
will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can
block those subsequent accesses.

Cc: Arnd Bergmann 
Cc: Ingo Molnar 
Cc: Kees Cook 
Cc: Matthew Wilcox 
Cc: Russell King 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Fixes: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Dan Williams 
Reviewed-by: Kees Cook 
Link: https://lore.kernel.org/r/159009507306.847224.8502634072429766747.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Greg Kroah-Hartman