1. 09 Jun, 2017 17 commits
  2. 07 Jun, 2017 1 commit
  3. 03 Jun, 2017 14 commits
  4. 27 May, 2017 1 commit
  5. 25 May, 2017 3 commits
    • Nick Desaulniers's avatar
      sysfs: remove signedness from sysfs_get_dirent · 89cf2a20
      Nick Desaulniers authored
      sysfs_get_dirent is usually invoked with a string literal, which
      have the type char[].  While the toplevel Makefile
      disables -Wpointer-sign, other Makefiles like
      
      arch/x86/boot/compressed/Makefile
      
      redefine KBUILD_CFLAGS. Fixes the warning:
      
      In file included from arch/x86/boot/compressed/kaslr.c:17:
      In file included from ./include/linux/module.h:17:
      In file included from ./include/linux/kobject.h:21:
      ./include/linux/sysfs.h:517:37: warning: passing 'const unsigned char *'
      to parameter of
            type 'const char *' converts between pointers to integer types
      with different sign
            [-Wpointer-sign]
              return kernfs_find_and_get(parent, name);
                                                 ^~~~
      ./include/linux/kernfs.h:462:57: note: passing argument to parameter
      'name' here
      kernfs_find_and_get(struct kernfs_node *kn, const char *name)
                                                              ^
      Signed-off-by: default avatarNick Desaulniers <nick.desaulniers@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89cf2a20
    • Peter Rajnoha's avatar
      kobject: support passing in variables for synthetic uevents · f36776fa
      Peter Rajnoha authored
      This patch makes it possible to pass additional arguments in addition
      to uevent action name when writing /sys/.../uevent attribute. These
      additional arguments are then inserted into generated synthetic uevent
      as additional environment variables.
      
      Before, we were not able to pass any additional uevent environment
      variables for synthetic uevents. This made it hard to identify such uevents
      properly in userspace to make proper distinction between genuine uevents
      originating from kernel and synthetic uevents triggered from userspace.
      Also, it was not possible to pass any additional information which would
      make it possible to optimize and change the way the synthetic uevents are
      processed back in userspace based on the originating environment of the
      triggering action in userspace. With the extra additional variables, we are
      able to pass through this extra information needed and also it makes it
      possible to synchronize with such synthetic uevents as they can be clearly
      identified back in userspace.
      
      The format for writing the uevent attribute is following:
      
          ACTION [UUID [KEY=VALUE ...]
      
      There's no change in how "ACTION" is recognized - it stays the same
      ("add", "change", "remove"). The "ACTION" is the only argument required
      to generate synthetic uevent, the rest of arguments, that this patch
      adds support for, are optional.
      
      The "UUID" is considered as transaction identifier so it's possible to
      use the same UUID value for one or more synthetic uevents in which case
      we logically group these uevents together for any userspace listeners.
      The "UUID" is expected to be in "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
      format where "x" is a hex digit. The value appears in uevent as
      "SYNTH_UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" environment variable.
      
      The "KEY=VALUE" pairs can contain alphanumeric characters only. It's
      possible to define zero or more more pairs - each pair is then delimited
      by a space character " ". Each pair appears in synthetic uevents as
      "SYNTH_ARG_KEY=VALUE" environment variable. That means the KEY name gains
      "SYNTH_ARG_" prefix to avoid possible collisions with existing variables.
      To pass the "KEY=VALUE" pairs, it's also required to pass in the "UUID"
      part for the synthetic uevent first.
      
      If "UUID" is not passed in, the generated synthetic uevent gains
      "SYNTH_UUID=0" environment variable automatically so it's possible to
      identify this situation in userspace when reading generated uevent and so
      we can still make a difference between genuine and synthetic uevents.
      Signed-off-by: default avatarPeter Rajnoha <prajnoha@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f36776fa
    • Adrian Salido's avatar
      driver core: platform: fix race condition with driver_override · 62655397
      Adrian Salido authored
      The driver_override implementation is susceptible to race condition when
      different threads are reading vs storing a different driver override.
      Add locking to avoid race condition.
      
      Fixes: 3d713e0e ("driver core: platform: add device binding path 'driver_override'")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAdrian Salido <salidoa@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      62655397
  6. 22 May, 2017 2 commits
    • Linus Torvalds's avatar
      Linux 4.12-rc2 · 08332893
      Linus Torvalds authored
      08332893
    • Linus Torvalds's avatar
      x86: fix 32-bit case of __get_user_asm_u64() · 33c9e972
      Linus Torvalds authored
      The code to fetch a 64-bit value from user space was entirely buggered,
      and has been since the code was merged in early 2016 in commit
      b2f68038 ("x86/mm/32: Add support for 64-bit __get_user() on 32-bit
      kernels").
      
      Happily the buggered routine is almost certainly entirely unused, since
      the normal way to access user space memory is just with the non-inlined
      "get_user()", and the inlined version didn't even historically exist.
      
      The normal "get_user()" case is handled by external hand-written asm in
      arch/x86/lib/getuser.S that doesn't have either of these issues.
      
      There were two independent bugs in __get_user_asm_u64():
      
       - it still did the STAC/CLAC user space access marking, even though
         that is now done by the wrapper macros, see commit 11f1a4b9
         ("x86: reorganize SMAP handling in user space accesses").
      
         This didn't result in a semantic error, it just means that the
         inlined optimized version was hugely less efficient than the
         allegedly slower standard version, since the CLAC/STAC overhead is
         quite high on modern Intel CPU's.
      
       - the double register %eax/%edx was marked as an output, but the %eax
         part of it was touched early in the asm, and could thus clobber other
         inputs to the asm that gcc didn't expect it to touch.
      
         In particular, that meant that the generated code could look like
         this:
      
              mov    (%eax),%eax
              mov    0x4(%eax),%edx
      
         where the load of %edx obviously was _supposed_ to be from the 32-bit
         word that followed the source of %eax, but because %eax was
         overwritten by the first instruction, the source of %edx was
         basically random garbage.
      
      The fixes are trivial: remove the extraneous STAC/CLAC entries, and mark
      the 64-bit output as early-clobber to let gcc know that no inputs should
      alias with the output register.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@kernel.org   # v4.8+
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      33c9e972
  7. 21 May, 2017 2 commits
    • Linus Torvalds's avatar
      Clean up x86 unsafe_get/put_user() type handling · 334a023e
      Linus Torvalds authored
      Al noticed that unsafe_put_user() had type problems, and fixed them in
      commit a7cc722f ("fix unsafe_put_user()"), which made me look more
      at those functions.
      
      It turns out that unsafe_get_user() had a type issue too: it limited the
      largest size of the type it could handle to "unsigned long".  Which is
      fine with the current users, but doesn't match our existing normal
      get_user() semantics, which can also handle "u64" even when that does
      not fit in a long.
      
      While at it, also clean up the type cast in unsafe_put_user().  We
      actually want to just make it an assignment to the expected type of the
      pointer, because we actually do want warnings from types that don't
      convert silently.  And it makes the code more readable by not having
      that one very long and complex line.
      
      [ This patch might become stable material if we ever end up back-porting
        any new users of the unsafe uaccess code, but as things stand now this
        doesn't matter for any current existing uses. ]
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      334a023e
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · f3926e4c
      Linus Torvalds authored
      Pull misc uaccess fixes from Al Viro:
       "Fix for unsafe_put_user() (no callers currently in mainline, but
        anyone starting to use it will step into that) + alpha osf_wait4()
        infoleak fix"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        osf_wait4(): fix infoleak
        fix unsafe_put_user()
      f3926e4c