1. 04 Jan, 2019 1 commit
    • Linus Torvalds's avatar
      Remove 'type' argument from access_ok() function · 96d4f267
      Linus Torvalds authored
      Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
      of the user address range verification function since we got rid of the
      old racy i386-only code to walk page tables by hand.
      It existed because the original 80386 would not honor the write protect
      bit when in kernel mode, so you had to do COW by hand before doing any
      user access.  But we haven't supported that in a long time, and these
      days the 'type' argument is a purely historical artifact.
      A discussion about extending 'user_access_begin()' to do the range
      checking resulted this patch, because there is no way we're going to
      move the old VERIFY_xyz interface to that model.  And it's best done at
      the end of the merge window when I've done most of my merges, so let's
      just get this done once and for all.
      This patch was mostly done with a sed-script, with manual fix-ups for
      the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.
      There were a couple of notable cases:
       - csky still had the old "verify_area()" name as an alias.
       - the iter_iov code had magical hardcoded knowledge of the actual
         values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
         really used it)
       - microblaze used the type argument for a debug printout
      but other than those oddities this should be a total no-op patch.
      I tried to fix up all architectures, did fairly extensive grepping for
      access_ok() uses, and the changes are trivial, but I may have missed
      something.  Any missed conversion should be trivially fixable, though.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 31 Oct, 2018 3 commits
  3. 22 Aug, 2018 1 commit
  4. 01 Aug, 2018 1 commit
  5. 08 Jun, 2018 1 commit
  6. 06 Apr, 2018 1 commit
  7. 07 Feb, 2018 2 commits
    • Yury Norov's avatar
      bitmap: replace bitmap_{from,to}_u32array · 3aa56885
      Yury Norov authored
      with bitmap_{from,to}_arr32 over the kernel. Additionally to it:
      * __check_eq_bitmap() now takes single nbits argument.
      * __check_eq_u32_array is not used in new test but may be used in
        future. So I don't remove it here, but annotate as __used.
      Tested on arm64 and 32-bit BE mips.
      [arnd@arndb.de: perf: arm_dsu_pmu: convert to bitmap_from_arr32]
        Link: http://lkml.kernel.org/r/20180201172508.5739-2-ynorov@caviumnetworks.com
      [ynorov@caviumnetworks.com: fix net/core/ethtool.c]
        Link: http://lkml.kernel.org/r/20180205071747.4ekxtsbgxkj5b2fz@yury-thinkpad
      Link: http://lkml.kernel.org/r/20171228150019.27953-2-ynorov@caviumnetworks.comSigned-off-by: default avatarYury Norov <ynorov@caviumnetworks.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: David Decotigny <decot@googlers.com>,
      Cc: David S. Miller <davem@davemloft.net>,
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Yury Norov's avatar
      bitmap: new bitmap_copy_safe and bitmap_{from,to}_arr32 · c724f193
      Yury Norov authored
      This patchset replaces bitmap_{to,from}_u32array with more simple and
      standard looking copy-like functions.
      bitmap_from_u32array() takes 4 arguments (bitmap_to_u32array is similar):
       - unsigned long *bitmap, which is destination;
       - unsigned int nbits, the length of destination bitmap, in bits;
       - const u32 *buf, the source; and
       - unsigned int nwords, the length of source buffer in ints.
      In description to the function it is detailed like:
      * copy min(nbits, 32*nwords) bits from @buf to @bitmap, remaining
      * bits between nword and nbits in @bitmap (if any) are cleared.
      Having two size arguments looks unneeded and potentially dangerous.
      It is unneeded because normally user of copy-like function should take
      care of the size of destination and make it big enough to fit source
      And it is dangerous because function may hide possible error if user
      doesn't provide big enough bitmap, and data becomes silently dropped.
      That's why all copy-like functions have 1 argument for size of copying
      data, and I don't see any reason to make bitmap_from_u32array()
      One exception that comes in mind is strncpy() which also provides size
      of destination in arguments, but it's strongly argued by the possibility
      of taking broken strings in source.  This is not the case of
      There is no many real users of bitmap_{from,to}_u32array(), and they all
      very clearly provide size of destination matched with the size of
      source, so additional functionality is not used in fact. Like this:
      #define __ETHTOOL_LINK_MODE_MASK_NU32 \
      In this patch, bitmap_copy_safe and bitmap_{from,to}_arr32 are introduced.
      'Safe' in bitmap_copy_safe() stands for clearing unused bits in bitmap
      beyond last bit till the end of last word. It is useful for hardening
      API when bitmap is assumed to be exposed to userspace.
      bitmap_{from,to}_arr32 functions are replacements for
      bitmap_{from,to}_u32array. They don't take unneeded nwords argument, and
      so simpler in implementation and understanding.
      This patch suggests optimization for 32-bit systems - aliasing
      bitmap_{from,to}_arr32 to bitmap_copy_safe.
      Other possible optimization is aliasing 64-bit LE bitmap_{from,to}_arr32 to
      more generic function(s). But I didn't end up with the function that would
      be helpful by itself, and can be used to alias 64-bit LE
      bitmap_{from,to}_arr32, like bitmap_copy_safe() does. So I preferred to
      leave things as is.
      The following patch switches kernel to new API and introduces test for it.
      Discussion is here: https://lkml.org/lkml/2017/11/15/592
      [ynorov@caviumnetworks.com: rename bitmap_copy_safe to bitmap_copy_clear_tail]
        Link: http://lkml.kernel.org/r/20180201172508.5739-3-ynorov@caviumnetworks.com
      Link: http://lkml.kernel.org/r/20171228150019.27953-1-ynorov@caviumnetworks.comSigned-off-by: default avatarYury Norov <ynorov@caviumnetworks.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: David Decotigny <decot@googlers.com>,
      Cc: David S. Miller <davem@davemloft.net>,
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  8. 19 Oct, 2017 1 commit
  9. 09 Sep, 2017 1 commit
    • Yury Norov's avatar
      lib/bitmap.c: make bitmap_parselist() thread-safe and much faster · 0a5ce083
      Yury Norov authored
      Current implementation of bitmap_parselist() uses a static variable to
      save local state while setting bits in the bitmap.  It is obviously wrong
      if we assume execution in multiprocessor environment.  Fortunately, it's
      possible to rewrite this portion of code to avoid using the static
      It is also possible to set bits in the mask per-range with bitmap_set(),
      not per-bit, as it is implemented now, with set_bit(); which is way
      The important side effect of this change is that setting bits in this
      function from now is not per-bit atomic and less memory-ordered.  This is
      because set_bit() guarantees the order of memory accesses, while
      bitmap_set() does not.  I think that it is the advantage of the new
      approach, because the bitmap_parselist() is intended to initialise bit
      arrays, and user should protect the whole bitmap during initialisation if
      needed.  So protecting individual bits looks expensive and useless.  Also,
      other range-oriented functions in lib/bitmap.c don't worry much about
      With all that, setting 2k bits in map with the pattern like 0-2047:128/256
      becomes ~50 times faster after applying the patch in my testing
      environment (arm64 hosted on qemu).
      The second patch of the series adds the test for bitmap_parselist().  It's
      not intended to cover all tricky cases, just to make sure that I didn't
      screw up during rework.
      Link: http://lkml.kernel.org/r/20170807225438.16161-1-ynorov@caviumnetworks.comSigned-off-by: default avatarYury Norov <ynorov@caviumnetworks.com>
      Cc: Noam Camus <noamca@mellanox.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 10 Jul, 2017 1 commit
  11. 02 Apr, 2017 1 commit
  12. 11 Oct, 2016 1 commit
    • Noam Camus's avatar
      lib/bitmap.c: enhance bitmap syntax · 2d13e6ca
      Noam Camus authored
      Today there are platforms with many CPUs (up to 4K).  Trying to boot only
      part of the CPUs may result in too long string.
      For example lets take NPS platform that is part of arch/arc.  This
      platform have SMP system with 256 cores each with 16 HW threads (SMT
      machine) where HW thread appears as CPU to the kernel.  In this example
      there is total of 4K CPUs.  When one tries to boot only part of the HW
      threads from each core the string representing the map may be long...  For
      example if for sake of performance we decided to boot only first half of
      HW threads of each core the map will look like:
      This patch introduce new syntax to accommodate with such use case.  I
      added an optional postfix to a range of CPUs which will choose according
      to given modulo the desired range of reminders i.e.:
          <cpus range>:sed_size/group_size
      For example, above map can be described in new syntax like this:
      Note that this patch is backward compatible with current syntax.
      [akpm@linux-foundation.org: rework documentation]
      Link: http://lkml.kernel.org/r/1473579629-4283-1-git-send-email-noamca@mellanox.comSigned-off-by: default avatarNoam Camus <noamca@mellanox.com>
      Cc: David Decotigny <decot@googlers.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Pan Xinhui <xinhui@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  13. 15 Jul, 2016 1 commit
  14. 20 Feb, 2016 1 commit
  15. 10 Sep, 2015 3 commits
  16. 26 Jun, 2015 2 commits
    • Sudeep Holla's avatar
      bitmap: remove explicit newline handling using scnprintf format string · 9cf79d11
      Sudeep Holla authored
      bitmap_print_to_pagebuf uses scnprintf to copy the cpumask/list to page
      buffer.  It handles the newline and trailing null character explicitly.
      It's unnecessary and also partially duplicated as scnprintf already adds
      trailing null character.  The newline can be passed through format
      string to scnprintf.  This patch does that simplification.
      However theoretically there's one behavior difference: when the buffer
      is too small, the original code would still output '\n' at the end while
      the new code(with this patch) would just continue to print the formatted
      string.  Since this function is dealing with only page buffers, it's
      highly unlikely to hit that corner case.
      This patch will help in auditing the users of bitmap_print_to_pagebuf to
      verify that the buffer passed is large enough and get rid of it
      completely by replacing them with direct scnprintf()
      [akpm@linux-foundation.org: tweak comment]
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Suggested-by: default avatarPawel Moll <Pawel.Moll@arm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Chris Metcalf's avatar
      __bitmap_parselist: fix bug in empty string handling · 2528a8b8
      Chris Metcalf authored
      bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in
      the mask.  The same bug is visible in cpumask_parselist() since it is
      layered on top of the bitmask code, e.g.  if you boot with "isolcpus=",
      you will actually end up with cpu zero isolated.
      The bug was introduced in commit 4b060420 ("bitmap, irq: add
      smp_affinity_list interface to /proc/irq") when bitmap_parselist() was
      generalized to support userspace as well as kernelspace.
      Fixes: 4b060420 ("bitmap, irq: add smp_affinity_list interface to /proc/irq")
      Signed-off-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  17. 17 Apr, 2015 1 commit
  18. 14 Feb, 2015 12 commits
  19. 13 Feb, 2015 5 commits