1. 04 Jul, 2019 2 commits
  2. 03 Jul, 2019 4 commits
  3. 02 Jul, 2019 2 commits
    • Linus Walleij's avatar
      gpio/spi: Fix spi-gpio regression on active high CS · fbbf145a
      Linus Walleij authored
      I ran into an intriguing bug caused by
      commit ""spi: gpio: Don't request CS GPIO in DT use-case"
      affecting all SPI GPIO devices with an active high
      chip select line.
      
      The commit switches the CS gpio handling over to the GPIO
      core, which will parse and handle "cs-gpios" from the OF
      node without even calling down to the driver to get the
      job done.
      
      However the GPIO core handles the standard bindings in
      Documentation/devicetree/bindings/spi/spi-controller.yaml
      that specifies that active high CS needs to be specified
      using "spi-cs-high" in the DT node.
      
      The code in drivers/spi/spi-gpio.c never respected this
      and never tried to inspect subnodes to see if they contained
      "spi-cs-high" like the gpiolib OF quirks does. Instead the
      only way to get an active high CS was to tag it in the
      device tree using the flags cell such as
      cs-gpios = <&gpio 4 GPIO_ACTIVE_HIGH>;
      
      This alters the quirks to not inspect the subnodes of SPI
      masters on "spi-gpio" for the standard attribute "spi-cs-high",
      making old device trees work as expected.
      
      This semantic is a bit ambigous, but just allowing the
      flags on the GPIO descriptor to modify polarity is what
      the kernel at large mostly uses so let's encourage that.
      
      Fixes: 249e2632 ("spi: gpio: Don't request CS GPIO in DT use-case")
      Cc: Andrey Smirnov <andrew.smirnov@gmail.com>
      Cc: linux-gpio@vger.kernel.org
      Cc: linux-spi@vger.kernel.org
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      fbbf145a
    • Jiri Kosina's avatar
      ftrace/x86: Anotate text_mutex split between... · 074376ac
      Jiri Kosina authored
      ftrace/x86: Anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
      
      ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the
      corresponding release is happening in ftrace_arch_code_modify_post_process().
      
      This has already been documented in the code, but let's also make the fact
      that this is intentional clear to the semantic analysis tools such as sparse.
      
      Link: http://lkml.kernel.org/r/nycvar.YFH.7.76.1906292321170.27227@cbobk.fhfr.pm
      
      Fixes: 39611265 ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()")
      Fixes: d5b844a2 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      074376ac
  4. 01 Jul, 2019 1 commit
    • Christian Brauner's avatar
      fork: return proper negative error code · 28dd29c0
      Christian Brauner authored
      Make sure to return a proper negative error code from copy_process()
      when anon_inode_getfile() fails with CLONE_PIDFD.
      Otherwise _do_fork() will not detect an error and get_task_pid() will
      operator on a nonsensical pointer:
      
      R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006dbc2c
      R13: 00007ffc15fbb0ff R14: 00007ff07e47e9c0 R15: 0000000000000000
      kasan: CONFIG_KASAN_INLINE enabled
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] PREEMPT SMP KASAN
      CPU: 1 PID: 7990 Comm: syz-executor290 Not tainted 5.2.0-rc6+ #9
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
      RIP: 0010:get_task_pid+0xe1/0x210 kernel/pid.c:372
      Code: 89 ff e8 62 27 5f 00 49 8b 07 44 89 f1 4c 8d bc c8 90 01 00 00 eb 0c
      e8 0d fe 25 00 49 81 c7 38 05 00 00 4c 89 f8 48 c1 e8 03 <80> 3c 18 00 74
      08 4c 89 ff e8 31 27 5f 00 4d 8b 37 e8 f9 47 12 00
      RSP: 0018:ffff88808a4a7d78 EFLAGS: 00010203
      RAX: 00000000000000a7 RBX: dffffc0000000000 RCX: ffff888088180600
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff88808a4a7d90 R08: ffffffff814fb3a8 R09: ffffed1015d66bf8
      R10: ffffed1015d66bf8 R11: 1ffff11015d66bf7 R12: 0000000000041ffc
      R13: 1ffff11011494fbc R14: 0000000000000000 R15: 000000000000053d
      FS:  00007ff07e47e700(0000) GS:ffff8880aeb00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000004b5100 CR3: 0000000094df2000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        _do_fork+0x1b9/0x5f0 kernel/fork.c:2360
        __do_sys_clone kernel/fork.c:2454 [inline]
        __se_sys_clone kernel/fork.c:2448 [inline]
        __x64_sys_clone+0xc1/0xd0 kernel/fork.c:2448
        do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:301
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Link: https://lore.kernel.org/lkml/000000000000e0dc0d058c9e7142@google.com
      Reported-and-tested-by: syzbot+002e636502bc4b64eb5c@syzkaller.appspotmail.com
      Fixes: 6fd2fe49 ("copy_process(): don't use ksys_close() on cleanups")
      Cc: Jann Horn <jannh@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarChristian Brauner <christian@brauner.io>
      28dd29c0
  5. 30 Jun, 2019 3 commits
  6. 29 Jun, 2019 28 commits