1. 05 May, 2016 1 commit
  2. 19 Apr, 2016 2 commits
    • Boris Brezillon's avatar
      mtd: create an mtd_ooblayout_ops struct to ease ECC layout definition · adbbc3bc
      Boris Brezillon authored
      ECC layout definitions are currently exposed using the nand_ecclayout
      struct which embeds oobfree and eccpos arrays with predefined size.
      This approach was acceptable when NAND chips were providing relatively
      small OOB regions, but MLC and TLC now provide OOB regions of several
      hundreds of bytes, which implies a non negligible overhead for everybody
      even those who only need to support legacy NANDs.
      Create an mtd_ooblayout_ops interface providing the same functionality
      (expose the ECC and oobfree layout) without the need for this huge
      The mtd->ecclayout is now deprecated and should be replaced by the
      equivalent mtd_ooblayout_ops. In the meantime we provide a wrapper around
      the ->ecclayout field to ease migration to this new model.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
    • Boris Brezillon's avatar
      mtd: use mtd_ooblayout_xxx() helpers where appropriate · c2b78452
      Boris Brezillon authored
      The mtd_ooblayout_xxx() helper functions have been added to avoid direct
      accesses to the ecclayout field, and thus ease for future reworks.
      Use these helpers in all places where the oobfree[] and eccpos[] arrays
      where directly accessed.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
  3. 29 Sep, 2015 1 commit
    • Brian Norris's avatar
      mtd: provide proper 32/64-bit compat_ioctl() support for BLKPG · 53bb724f
      Brian Norris authored
      After a bit of poking around wondering why my 32-bit user-space can't
      seem to send a proper ioctl(BLKPG) to an MTD on my 64-bit kernel
      (ARM64), I noticed that struct blkpg_ioctl_arg is actually pretty
      unsuitable for use in the ioctl() ABI, due to its use of raw pointers,
      and its lack of alignment/packing restrictions (32-bit arch'es tend to
      pack the 4 fields into 4 32-bit words, whereas 64-bit arch'es would add
      padding after the third int, and make this 6 32-bit words).
      Anyway, this means BLKPG deserves some special compat_ioctl handling. Do
      the conversion in a small shim for MTD.
      block/compat_ioctl.c already has compat support for the block subsystem,
      but it does so by a re-marshalling data to/from user-space (see
      compat_blkpg_ioctl()). Personally, I think this approach is cleaner.
      Tested only on MTD, with an ARM32 user space on an ARM64 kernel.
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  4. 20 Jan, 2015 1 commit
  5. 19 Aug, 2014 1 commit
  6. 20 May, 2014 1 commit
    • Geert Uytterhoeven's avatar
      mtd: Fix warning in access_ok() parameter passing · f62cde49
      Geert Uytterhoeven authored
      On m68k, where access_ok() doesn't cast the address parameter:
      drivers/mtd/mtdchar.c: In function 'mtdchar_write_ioctl':
      drivers/mtd/mtdchar.c:575:4: warning: passing argument 2 of 'access_ok' makes pointer from integer without a cast [enabled by default]
      arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but argument is of type '__u64'
      drivers/mtd/mtdchar.c:576:4: warning: passing argument 2 of 'access_ok' makes pointer from integer without a cast [enabled by default]
      arch/m68k/include/asm/uaccess_mm.h:17:90: note: expected 'const void *' but argument is of type '__u64'
      The address parameter of access_ok() is really a userspace pointer.
      On most architectures, access_ok() is a macro that casts the address
      parameter, hiding issues in its users.
      Move around and use the existing usr_data and usr_oob temporary variables
      to kill the warnings. Add a few "consts", and make more use of the
      temporaries while we're at it.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
  7. 10 Mar, 2014 2 commits
  8. 11 Nov, 2013 1 commit
  9. 07 Nov, 2013 1 commit
  10. 29 Jun, 2013 1 commit
  11. 19 Apr, 2013 2 commits
  12. 05 Apr, 2013 3 commits
    • Artem Bityutskiy's avatar
      mtd: merge mtdchar module with mtdcore · 660685d9
      Artem Bityutskiy authored
      The MTD subsystem has historically tried to be as configurable as possible. The
      side-effect of this is that its configuration menu is rather large, and we are
      gradually shrinking it. For example, we recently merged partitions support with
      the mtdcore.
      This patch does the next step - it merges the mtdchar module to mtdcore. And in
      this case this is not only about eliminating too fine-grained separation and
      simplifying the configuration menu. This is also about eliminating seemingly
      useless kernel module.
      Indeed, mtdchar is a module that allows user-space making use of MTD devices
      via /dev/mtd* character devices. If users do not enable it, they simply cannot
      use MTD devices at all. They cannot read or write the flash contents. Is it a
      sane and useful setup? I believe not. And everyone just enables mtdchar.
      Having mtdchar separate is also a little bit harmful. People sometimes miss the
      fact that they need to enable an additional configuration option to have
      user-space MTD interfaces, and then they wonder why on earth the kernel does
      not allow using the flash? They spend time asking around.
      Thus, let's just get rid of this module and make it part of mtd core.
      Note, mtdchar had additional configuration option to enable OTP interfaces,
      which are present on some flashes. I removed that option as well - it saves a
      really tiny amount space.
      [dwmw2: Strictly speaking, you can mount file systems on MTD devices just
              fine without the mtdchar (or mtdblock) devices; you just can't do
              other manipulations directly on the underlying device. But still I
              agree that it makes sense to make this unconditional. And Yay! we
              get to kill off an instance of checking CONFIG_foo_MODULE, which is
              an abomination that should never happen.]
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
    • Artem Bityutskiy's avatar
      mtd: mtdchar: use proper kernel print level · 57ae2b60
      Artem Bityutskiy authored
      We normally use 'pr_err()' for error messages, not 'pr_notice()'.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
    • Uwe Kleine-König's avatar
      mtd: mtdchar: handle chips that have user otp but no factory otp · 5dc63fa2
      Uwe Kleine-König authored
      Before this patch mtd_read_fact_prot_reg was used to check availability
      for both MTD_OTP_FACTORY and MTD_OTP_USER access. This made accessing
      user otp for chips that don't have a factory otp area impossible. So use
      the right wrapper depending on the intended area to be accessed.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  13. 03 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
  14. 09 Oct, 2012 2 commits
    • David Woodhouse's avatar
      mtd: Disable mtdchar mmap on MMU systems · f5cf8f07
      David Woodhouse authored
      This code was broken because it assumed that all MTD devices were map-based.
      Disable it for now, until it can be fixed properly for the next merge window.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
    • Konstantin Khlebnikov's avatar
      mm: kill vma flag VM_RESERVED and mm->reserved_vm counter · 314e51b9
      Konstantin Khlebnikov authored
      A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA,
      currently it lost original meaning but still has some effects:
       | effect                 | alternative flags
      1| account as reserved_vm | VM_IO
      2| skip in core dump      | VM_IO, VM_DONTDUMP
      3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      4| do not mlock           | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP
      This patch removes reserved_vm counter from mm_struct.  Seems like nobody
      cares about it, it does not exported into userspace directly, it only
      reduces total_vm showed in proc.
      Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP.
      remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP.
      remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP.
      [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup]
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Carsten Otte <cotte@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Kentaro Takeda <takedakn@nttdata.co.jp>
      Cc: Matt Helsley <matthltc@us.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  15. 28 Sep, 2012 1 commit
    • Linus Torvalds's avatar
      mtdchar: fix offset overflow detection · 9c603e53
      Linus Torvalds authored
      Sasha Levin has been running trinity in a KVM tools guest, and was able
      to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
      the memory type).  The call trace showed that it was mtdchar_mmap() that
      created an invalid remap_pfn_range().
      The problem is that mtdchar_mmap() does various really odd and subtle
      things with the vma page offset etc, and uses the wrong types (and the
      wrong overflow) detection for it.
      For example, the page offset may well be 32-bit on a 32-bit
      architecture, but after shifting it up by PAGE_SHIFT, we need to use a
      potentially 64-bit resource_size_t to correctly hold the full value.
      Also, we need to check that the vma length plus offset doesn't overflow
      before we check that it is smaller than the length of the mtdmap region.
      This fixes things up and tries to make the code a bit easier to read.
      Reported-and-tested-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Acked-by: default avatarSuresh Siddha <suresh.b.siddha@intel.com>
      Acked-by: default avatarArtem Bityutskiy <dedekind1@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: linux-mtd@lists.infradead.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 07 May, 2012 1 commit
    • Will Newton's avatar
      mtd: fix oops in dataflash driver · 7a84477c
      Will Newton authored
      I'm seeing an oops in mtd_dataflash.c with Linux 3.3. What appears to
      be happening is that otp_select_filemode calls mtd_read_fact_prot_reg
      with -1 for offset and length and a NULL buffer to test if OTP
      operations are supported. This finds its way down to otp_read in
      mtd_dataflash.c and causes an oops when memcpying the returned data
      into the NULL buf.
      None of the checks in otp_read catches the negative length and offset.
      Changing the length of the dummy read to 0 prevents the oops.
      Cc: stable@kernel.org [3.3+]
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  17. 08 Apr, 2012 1 commit
  18. 31 Mar, 2012 1 commit
  19. 26 Mar, 2012 1 commit
    • Artem Bityutskiy's avatar
      mtd: add leading underscore to all mtd functions · 3c3c10bb
      Artem Bityutskiy authored
      This patch renames all MTD functions by adding a "_" prefix:
      mtd->erase -> mtd->_erase
      mtd->read_oob -> mtd->_read_oob
      The reason is that we are re-working the MTD API and from now on it is
      an error to use MTD function pointers directly - we have a corresponding
      API call for every pointer. By adding a leading "_" we achieve the following:
      1. Make sure we convert every direct pointer users
      2. A leading "_" suggests that this interface is internal and it becomes
         less likely that people will use them directly
      3. Make sure all the out-of-tree modules stop compiling and the owners
         spot the big API change and amend them.
      Signed-off-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
  20. 23 Mar, 2012 1 commit
  21. 09 Jan, 2012 14 commits