1. 06 3月, 2019 39 次提交
    • K
      drm/amd/powerplay: OD setting fix on Vega10 · 8c5571b9
      Kenneth Feng 提交于
      [ Upstream commit 6d87dc97eb3341de3f7b1efa3156cb0e014f4a96 ]
      
      gfxclk for OD setting is limited to 1980M for non-acg
      ASICs of Vega10
      Signed-off-by: NKenneth Feng <kenneth.feng@amd.com>
      Reviewed-by: NEvan Quan <evan.quan@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c5571b9
    • X
      locking/rwsem: Fix (possible) missed wakeup · 9ad6216e
      Xie Yongji 提交于
      [ Upstream commit e158488be27b157802753a59b336142dc0eb0380 ]
      
      Because wake_q_add() can imply an immediate wakeup (cmpxchg failure
      case), we must not rely on the wakeup being delayed. However, commit:
      
        e3851390 ("locking/rwsem: Rework zeroing reader waiter->task")
      
      relies on exactly that behaviour in that the wakeup must not happen
      until after we clear waiter->task.
      
      [ peterz: Added changelog. ]
      Signed-off-by: NXie Yongji <xieyongji@baidu.com>
      Signed-off-by: NZhang Yu <zhangyu31@baidu.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: e3851390 ("locking/rwsem: Rework zeroing reader waiter->task")
      Link: https://lkml.kernel.org/r/1543495830-2644-1-git-send-email-xieyongji@baidu.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9ad6216e
    • P
      futex: Fix (possible) missed wakeup · 2368e6d3
      Peter Zijlstra 提交于
      [ Upstream commit b061c38bef43406df8e73c5be06cbfacad5ee6ad ]
      
      We must not rely on wake_q_add() to delay the wakeup; in particular
      commit:
      
        1d0dcb3a ("futex: Implement lockless wakeups")
      
      moved wake_q_add() before smp_store_release(&q->lock_ptr, NULL), which
      could result in futex_wait() waking before observing ->lock_ptr ==
      NULL and going back to sleep again.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 1d0dcb3a ("futex: Implement lockless wakeups")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2368e6d3
    • P
      sched/wake_q: Fix wakeup ordering for wake_q · 653a1dbc
      Peter Zijlstra 提交于
      [ Upstream commit 4c4e3731564c8945ac5ac90fc2a1e1f21cb79c92 ]
      
      Notable cmpxchg() does not provide ordering when it fails, however
      wake_q_add() requires ordering in this specific case too. Without this
      it would be possible for the concurrent wakeup to not observe our
      prior state.
      
      Andrea Parri provided:
      
        C wake_up_q-wake_q_add
      
        {
      	int next = 0;
      	int y = 0;
        }
      
        P0(int *next, int *y)
        {
      	int r0;
      
      	/* in wake_up_q() */
      
      	WRITE_ONCE(*next, 1);   /* node->next = NULL */
      	smp_mb();               /* implied by wake_up_process() */
      	r0 = READ_ONCE(*y);
        }
      
        P1(int *next, int *y)
        {
      	int r1;
      
      	/* in wake_q_add() */
      
      	WRITE_ONCE(*y, 1);      /* wake_cond = true */
      	smp_mb__before_atomic();
      	r1 = cmpxchg_relaxed(next, 1, 2);
        }
      
        exists (0:r0=0 /\ 1:r1=0)
      
        This "exists" clause cannot be satisfied according to the LKMM:
      
        Test wake_up_q-wake_q_add Allowed
        States 3
        0:r0=0; 1:r1=1;
        0:r0=1; 1:r1=0;
        0:r0=1; 1:r1=1;
        No
        Witnesses
        Positive: 0 Negative: 3
        Condition exists (0:r0=0 /\ 1:r1=0)
        Observation wake_up_q-wake_q_add Never 0 3
      Reported-by: NYongji Xie <elohimes@gmail.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Waiman Long <longman@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      653a1dbc
    • P
      sched/wait: Fix rcuwait_wake_up() ordering · 5024f0a2
      Prateek Sood 提交于
      [ Upstream commit 6dc080eeb2ba01973bfff0d79844d7a59e12542e ]
      
      For some peculiar reason rcuwait_wake_up() has the right barrier in
      the comment, but not in the code.
      
      This mistake has been observed to cause a deadlock in the following
      situation:
      
          P1					P2
      
          percpu_up_read()			percpu_down_write()
            rcu_sync_is_idle() // false
      					  rcu_sync_enter()
      					  ...
            __percpu_up_read()
      
      [S] ,-  __this_cpu_dec(*sem->read_count)
          |   smp_rmb();
      [L] |   task = rcu_dereference(w->task) // NULL
          |
          |				    [S]	    w->task = current
          |					    smp_mb();
          |				    [L]	    readers_active_check() // fail
          `-> <store happens here>
      
      Where the smp_rmb() (obviously) fails to constrain the store.
      
      [ peterz: Added changelog. ]
      Signed-off-by: NPrateek Sood <prsood@codeaurora.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NAndrea Parri <andrea.parri@amarulasolutions.com>
      Acked-by: NDavidlohr Bueso <dbueso@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 8f95c90c ("sched/wait, RCU: Introduce rcuwait machinery")
      Link: https://lkml.kernel.org/r/1543590656-7157-1-git-send-email-prsood@codeaurora.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5024f0a2
    • B
      mac80211: fix miscounting of ttl-dropped frames · a2887f6f
      Bob Copeland 提交于
      [ Upstream commit a0dc02039a2ee54fb4ae400e0b755ed30e73e58c ]
      
      In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl'
      counter when we decrement the ttl to zero.  For unicast frames
      destined for other hosts, we stop processing the frame at that point.
      
      For multicast frames, we do not rebroadcast it in this case, but we
      do pass the frame up the stack to process it on this STA.  That
      doesn't match the usual definition of "dropped," so don't count
      those as such.
      
      With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a
      peer in a ttl=1 network no longer increments the counter rapidly.
      Signed-off-by: NBob Copeland <bobcopeland@fb.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a2887f6f
    • N
      staging: rtl8723bs: Fix build error with Clang when inlining is disabled · bbc300c8
      Nathan Chancellor 提交于
      [ Upstream commit 97715058b70da1262fd07798c8b2e3e894f759dd ]
      
      When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
      '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
      Clang failed at the modpost stage:
      
      ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
      ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
      ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
      
      These functions were marked as extern inline, meaning that if inlining
      doesn't happen, the function will be undefined, as it is above.
      
      This happens to work with GCC because the '-fno-inline-functions' option
      respects the __inline attribute so all instances of these functions are
      inlined as expected and the definition doesn't actually matter. However,
      with Clang and '-fno-inline-functions', a function has to be marked with
      the __always_inline attribute to be considered for inlining, which none
      of these functions are. Clang tries to find the symbol definition
      elsewhere as it was told and fails, which trickles down to modpost.
      
      To make sure that this code compiles regardless of compiler and make the
      intention of the code clearer, use 'static' to ensure these functions
      are always defined, regardless of inlining. Additionally, silence a
      checkpatch warning by switching from '__inline' to 'inline'.
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bbc300c8
    • A
      drivers: thermal: int340x_thermal: Fix sysfs race condition · a99e0377
      Aaron Hill 提交于
      [ Upstream commit 129699bb8c7572106b5bbb2407c2daee4727ccad ]
      
      Changes since V1:
      * Use dev_info instead of printk
      * Use dev_warn instead of BUG_ON
      
      Previously, sysfs_create_group was called before all initialization had
      fully run - specifically, before pci_set_drvdata was called. Since the
      sysctl group is visible to userspace as soon as sysfs_create_group
      returns, a small window of time existed during which a process could read
      from an uninitialized/partially-initialized device.
      
      This commit moves the creation of the sysctl group to after all
      initialized is completed. This ensures that it's impossible for
      userspace to read from a sysctl file before initialization has fully
      completed.
      
      To catch any future regressions, I've added a check to ensure
      that proc_thermal_emum_mode is never PROC_THERMAL_NONE when a process
      tries to read from a sysctl file. Previously, the aforementioned race
      condition could result in the 'else' branch
      running while PROC_THERMAL_NONE was set,
      leading to a null pointer deference.
      Signed-off-by: NAaron Hill <aa1ronham@gmail.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a99e0377
    • V
      ARC: show_regs: lockdep: avoid page allocator... · 4749ffdf
      Vineet Gupta 提交于
      [ Upstream commit ab6c03676cb190156603cf4c5ecf97aa406c9c53 ]
      
      and use smaller/on-stack buffer instead
      
      The motivation for this change was lockdep splat like below.
      
      | potentially unexpected fatal signal 11.
      | BUG: sleeping function called from invalid context at ../mm/page_alloc.c:4317
      | in_atomic(): 1, irqs_disabled(): 0, pid: 57, name: segv
      | no locks held by segv/57.
      | Preemption disabled at:
      | [<8182f17e>] get_signal+0x4a6/0x7c4
      | CPU: 0 PID: 57 Comm: segv Not tainted 4.17.0+ #23
      |
      | Stack Trace:
      |  arc_unwind_core.constprop.1+0xd0/0xf4
      |  __might_sleep+0x1f6/0x234
      |  __get_free_pages+0x174/0xca0
      |  show_regs+0x22/0x330
      |  get_signal+0x4ac/0x7c4     # print_fatal_signals() -> preempt_disable()
      |  do_signal+0x30/0x224
      |  resume_user_mode_begin+0x90/0xd8
      
      So signal handling core calls show_regs() with preemption disabled but
      an ensuing GFP_KERNEL page allocator call is flagged by lockdep.
      
      We could have switched to GFP_NOWAIT, but turns out that is not enough
      anways and eliding page allocator call leads to less code and
      instruction traces to sift thru when debugging pesky crashes.
      
      FWIW, this patch doesn't cure the lockdep splat (which next patch does).
      Reviewed-by: NWilliam Kucharski <william.kucharski@oracle.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4749ffdf
    • E
      ARC: fix __ffs return value to avoid build warnings · 4e34dd37
      Eugeniy Paltsev 提交于
      [ Upstream commit 4e868f8419cb4cb558c5d428e7ab5629cef864c7 ]
      
      |  CC      mm/nobootmem.o
      |In file included from ./include/asm-generic/bug.h:18:0,
      |                 from ./arch/arc/include/asm/bug.h:32,
      |                 from ./include/linux/bug.h:5,
      |                 from ./include/linux/mmdebug.h:5,
      |                 from ./include/linux/gfp.h:5,
      |                 from ./include/linux/slab.h:15,
      |                 from mm/nobootmem.c:14:
      |mm/nobootmem.c: In function '__free_pages_memory':
      |./include/linux/kernel.h:845:29: warning: comparison of distinct pointer types lacks a cast
      |   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
      |                             ^
      |./include/linux/kernel.h:859:4: note: in expansion of macro '__typecheck'
      |   (__typecheck(x, y) && __no_side_effects(x, y))
      |    ^~~~~~~~~~~
      |./include/linux/kernel.h:869:24: note: in expansion of macro '__safe_cmp'
      |  __builtin_choose_expr(__safe_cmp(x, y), \
      |                        ^~~~~~~~~~
      |./include/linux/kernel.h:878:19: note: in expansion of macro '__careful_cmp'
      | #define min(x, y) __careful_cmp(x, y, <)
      |                   ^~~~~~~~~~~~~
      |mm/nobootmem.c:104:11: note: in expansion of macro 'min'
      |   order = min(MAX_ORDER - 1UL, __ffs(start));
      
      Change __ffs return value from 'int' to 'unsigned long' as it
      is done in other implementations (like asm-generic, x86, etc...)
      to avoid build-time warnings in places where type is strictly
      checked.
      
      As __ffs may return values in [0-31] interval changing return
      type to unsigned is valid.
      Signed-off-by: NEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4e34dd37
    • Y
      irqchip/gic-v3-mbi: Fix uninitialized mbi_lock · 0655618d
      Yang Yingliang 提交于
      [ Upstream commit c530bb8a726a37811e9fb5d68cd6b5408173b545 ]
      
      The mbi_lock mutex is left uninitialized, so let's use DEFINE_MUTEX
      to initialize it statically.
      
      Fixes: 50528752 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller")
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0655618d
    • G
      selftests: gpio-mockup-chardev: Check asprintf() for error · f352e84e
      Geert Uytterhoeven 提交于
      [ Upstream commit 508cacd7da6659ae7b7bdd0a335f675422277758 ]
      
      With gcc 7.3.0:
      
          gpio-mockup-chardev.c: In function ‘get_debugfs’:
          gpio-mockup-chardev.c:62:3: warning: ignoring return value of ‘asprintf’, declared with attribute warn_unused_result [-Wunused-result]
             asprintf(path, "%s/gpio", mnt_fs_get_target(fs));
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Handle asprintf() failures to fix this.
      Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f352e84e
    • F
      selftests: seccomp: use LDLIBS instead of LDFLAGS · 357d9c7a
      Fathi Boudra 提交于
      [ Upstream commit 5bbc73a841d7f0bbe025a342146dde462a796a5a ]
      
      seccomp_bpf fails to build due to undefined reference errors:
      
       aarch64-linaro-linux-gcc --sysroot=/build/tmp-rpb-glibc/sysroots/hikey
       -O2 -pipe -g -feliminate-unused-debug-types -Wl,-no-as-needed -Wall
       -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lpthread seccomp_bpf.c -o
       /build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf
       /tmp/ccrlR3MW.o: In function `tsync_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1920: undefined reference to `sem_post'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1920: undefined reference to `sem_post'
       /tmp/ccrlR3MW.o: In function `TSYNC_setup':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1863: undefined reference to `sem_init'
       /tmp/ccrlR3MW.o: In function `TSYNC_teardown':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1904: undefined reference to `sem_destroy'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1897: undefined reference to `pthread_kill'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1898: undefined reference to `pthread_cancel'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1899: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_siblings_fail_prctl':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1978: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1990: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1992: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_with_ancestor':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2016: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2032: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2034: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_two_sibling_want_nnp':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2046: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2058: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2060: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_with_no_filter':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2073: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2098: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2100: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_with_one_divergence':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2125: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2143: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2145: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
       /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_not_under_filter':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2169: undefined reference to `sem_wait'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2202: undefined reference to `pthread_join'
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2227: undefined reference to `pthread_join'
       /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
       /usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941: undefined reference to `pthread_create'
      
      It's GNU Make and linker specific.
      
      The default Makefile rule looks like:
      
      $(CC) $(CFLAGS) $(LDFLAGS) $@ $^ $(LDLIBS)
      
      When linking is done by gcc itself, no issue, but when it needs to be passed
      to proper ld, only LDLIBS follows and then ld cannot know what libs to link
      with.
      
      More detail:
      https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
      
      LDFLAGS
      Extra flags to give to compilers when they are supposed to invoke the linker,
      ‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable
      instead.
      
      LDLIBS
      Library flags or names given to compilers when they are supposed to invoke the
      linker, ‘ld’. LOADLIBES is a deprecated (but still supported) alternative to
      LDLIBS. Non-library linker flags, such as -L, should go in the LDFLAGS
      variable.
      
      https://lkml.org/lkml/2010/2/10/362
      
      tools/perf: libraries must come after objects
      
      Link order matters, use LDLIBS instead of LDFLAGS to properly link against
      libpthread.
      Signed-off-by: NFathi Boudra <fathi.boudra@linaro.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      357d9c7a
    • A
      phy: ath79-usb: Fix the main reset name to match the DT binding · eecde0a0
      Alban Bedel 提交于
      [ Upstream commit 827cb0323928952c0db9515aba9d534fb1285b3f ]
      
      I submitted this driver several times before it got accepted. The
      first series hasn't been accepted but the DTS binding did made it.
      I then made a second series that added generic reset support to the
      PHY core, this in turn required a change to the DT binding. This
      second series seemed to have been ignored, so I did a third one
      without the change to the PHY core and the DT binding update, and this
      last attempt finally made it.
      
      But two months later the DT binding update from the second series has
      been integrated too. So now the driver doesn't match the binding and
      the only DTS using it. This patch fix the driver to match the new
      binding.
      Signed-off-by: NAlban Bedel <albeu@free.fr>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eecde0a0
    • A
      phy: ath79-usb: Fix the power on error path · e55af638
      Alban Bedel 提交于
      [ Upstream commit 009808154c69c48d5b41fc8cf5ad5ab5704efd8f ]
      
      In the power on function the error path doesn't return the suspend
      override to its proper state. It should should deassert this reset
      line to enable the suspend override.
      Signed-off-by: NAlban Bedel <albeu@free.fr>
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e55af638
    • A
      selftests/vm/gup_benchmark.c: match gup struct to kernel · fc8176da
      Alison Schofield 提交于
      [ Upstream commit 91cd63d320f84dcbf21d4327f31f7e1f85adebd0 ]
      
      An expansion field was added to the kernel copy of this structure for
      future use. See mm/gup_benchmark.c.
      
      Add the same expansion field here, so that the IOCTL command decodes
      correctly. Otherwise, it fails with EINVAL.
      Signed-off-by: NAlison Schofield <alison.schofield@intel.com>
      Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fc8176da
    • S
      ASoC: imx-audmux: change snprintf to scnprintf for possible overflow · 7bba7aff
      Silvio Cesare 提交于
      [ Upstream commit c407cd008fd039320d147088b52d0fa34ed3ddcb ]
      
      Change snprintf to scnprintf. There are generally two cases where using
      snprintf causes problems.
      
      1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
      In this case, if snprintf would have written more characters than what the
      buffer size (SIZE) is, then size will end up larger than SIZE. In later
      uses of snprintf, SIZE - size will result in a negative number, leading
      to problems. Note that size might already be too large by using
      size = snprintf before the code reaches a case of size += snprintf.
      
      2) If size is ultimately used as a length parameter for a copy back to user
      space, then it will potentially allow for a buffer overflow and information
      disclosure when size is greater than SIZE. When the size is used to index
      the buffer directly, we can have memory corruption. This also means when
      size = snprintf... is used, it may also cause problems since size may become
      large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
      configuration.
      
      The solution to these issues is to use scnprintf which returns the number of
      characters actually written to the buffer, so the size variable will never
      exceed SIZE.
      Signed-off-by: NSilvio Cesare <silvio.cesare@gmail.com>
      Cc: Timur Tabi <timur@kernel.org>
      Cc: Nicolin Chen <nicoleotsuka@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Xiubo Li <Xiubo.Lee@gmail.com>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Acked-by: NNicolin Chen <nicoleotsuka@gmail.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7bba7aff
    • S
      ASoC: dapm: change snprintf to scnprintf for possible overflow · 9500ecb9
      Silvio Cesare 提交于
      [ Upstream commit e581e151e965bf1f2815dd94620b638fec4d0a7e ]
      
      Change snprintf to scnprintf. There are generally two cases where using
      snprintf causes problems.
      
      1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
      In this case, if snprintf would have written more characters than what the
      buffer size (SIZE) is, then size will end up larger than SIZE. In later
      uses of snprintf, SIZE - size will result in a negative number, leading
      to problems. Note that size might already be too large by using
      size = snprintf before the code reaches a case of size += snprintf.
      
      2) If size is ultimately used as a length parameter for a copy back to user
      space, then it will potentially allow for a buffer overflow and information
      disclosure when size is greater than SIZE. When the size is used to index
      the buffer directly, we can have memory corruption. This also means when
      size = snprintf... is used, it may also cause problems since size may become
      large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
      configuration.
      
      The solution to these issues is to use scnprintf which returns the number of
      characters actually written to the buffer, so the size variable will never
      exceed SIZE.
      Signed-off-by: NSilvio Cesare <silvio.cesare@gmail.com>
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Dan Carpenter <dan.carpenter@oracle.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9500ecb9
    • S
      ASoC: rt5682: Fix PLL source register definitions · 375a9673
      Shuming Fan 提交于
      [ Upstream commit ee7ea2a9a318a89d21b156dc75e54d53904bdbe5 ]
      
      Fix typo which causes headphone no sound while using BCLK
      as PLL source.
      Signed-off-by: NShuming Fan <shumingf@realtek.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      375a9673
    • P
      x86/mm/mem_encrypt: Fix erroneous sizeof() · 7ff77864
      Peng Hao 提交于
      [ Upstream commit bf7d28c53453ea904584960de55e33e03b9d93b1 ]
      
      Using sizeof(pointer) for determining the size of a memset() only works
      when the size of the pointer and the size of type to which it points are
      the same. For pte_t this is only true for 64bit and 32bit-NONPAE. On 32bit
      PAE systems this is wrong as the pointer size is 4 byte but the PTE entry
      is 8 bytes. It's actually not a real world issue as this code depends on
      64bit, but it's wrong nevertheless.
      
      Use sizeof(*p) for correctness sake.
      
      Fixes: aad98391 ("x86/mm/encrypt: Simplify sme_populate_pgd() and sme_populate_pgd_large()")
      Signed-off-by: NPeng Hao <peng.hao2@zte.com.cn>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: dave.hansen@linux.intel.com
      Cc: peterz@infradead.org
      Cc: luto@kernel.org
      Link: https://lkml.kernel.org/r/1546065252-97996-1-git-send-email-peng.hao2@zte.com.cnSigned-off-by: NSasha Levin <sashal@kernel.org>
      7ff77864
    • S
      genirq: Make sure the initial affinity is not empty · 17fab891
      Srinivas Ramana 提交于
      [ Upstream commit bddda606ec76550dd63592e32a6e87e7d32583f7 ]
      
      If all CPUs in the irq_default_affinity mask are offline when an interrupt
      is initialized then irq_setup_affinity() can set an empty affinity mask for
      a newly allocated interrupt.
      
      Fix this by falling back to cpu_online_mask in case the resulting affinity
      mask is zero.
      Signed-off-by: NSrinivas Ramana <sramana@codeaurora.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: linux-arm-msm@vger.kernel.org
      Link: https://lkml.kernel.org/r/1545312957-8504-1-git-send-email-sramana@codeaurora.orgSigned-off-by: NSasha Levin <sashal@kernel.org>
      17fab891
    • A
      selftests: rtc: rtctest: add alarm test on minute boundary · 7746dd64
      Alexandre Belloni 提交于
      [ Upstream commit 7b3027728f4d4f6763f4d7e771acfc9424cdd0e6 ]
      
      Unfortunately, some RTC don't have a second resolution for alarm so also
      test for alarm on a minute boundary.
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7746dd64
    • A
      selftests: rtc: rtctest: fix alarm tests · 2409a869
      Alexandre Belloni 提交于
      [ Upstream commit fdac94489c4d247088b3885875b39b3e1eb621ef ]
      
      Return values for select are not checked properly and timeouts may not be
      detected.
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NShuah Khan <shuah@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2409a869
    • D
      usb: gadget: Potential NULL dereference on allocation error · 4670e839
      Dan Carpenter 提交于
      [ Upstream commit df28169e1538e4a8bcd8b779b043e5aa6524545c ]
      
      The source_sink_alloc_func() function is supposed to return error
      pointers on error.  The function is called from usb_get_function() which
      doesn't check for NULL returns so it would result in an Oops.
      
      Of course, in the current kernel, small allocations always succeed so
      this doesn't affect runtime.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4670e839
    • Z
      usb: dwc3: gadget: Fix the uninitialized link_state when udc starts · 08c937f9
      Zeng Tao 提交于
      [ Upstream commit 88b1bb1f3b88e0bf20b05d543a53a5b99bd7ceb6 ]
      
      Currently the link_state is uninitialized and the default value is 0(U0)
      before the first time we start the udc, and after we start the udc then
       stop the udc, the link_state will be undefined.
      We may have the following warnings if we start the udc again with
      an undefined link_state:
      
      WARNING: CPU: 0 PID: 327 at drivers/usb/dwc3/gadget.c:294 dwc3_send_gadget_ep_cmd+0x304/0x308
      dwc3 100e0000.hidwc3_0: wakeup failed --> -22
      [...]
      Call Trace:
      [<c010f270>] (unwind_backtrace) from [<c010b3d8>] (show_stack+0x10/0x14)
      [<c010b3d8>] (show_stack) from [<c034a4dc>] (dump_stack+0x84/0x98)
      [<c034a4dc>] (dump_stack) from [<c0118000>] (__warn+0xe8/0x100)
      [<c0118000>] (__warn) from [<c0118050>](warn_slowpath_fmt+0x38/0x48)
      [<c0118050>] (warn_slowpath_fmt) from [<c0442ec0>](dwc3_send_gadget_ep_cmd+0x304/0x308)
      [<c0442ec0>] (dwc3_send_gadget_ep_cmd) from [<c0445e68>](dwc3_ep0_start_trans+0x48/0xf4)
      [<c0445e68>] (dwc3_ep0_start_trans) from [<c0446750>](dwc3_ep0_out_start+0x64/0x80)
      [<c0446750>] (dwc3_ep0_out_start) from [<c04451c0>](__dwc3_gadget_start+0x1e0/0x278)
      [<c04451c0>] (__dwc3_gadget_start) from [<c04452e0>](dwc3_gadget_start+0x88/0x10c)
      [<c04452e0>] (dwc3_gadget_start) from [<c045ee54>](udc_bind_to_driver+0x88/0xbc)
      [<c045ee54>] (udc_bind_to_driver) from [<c045f29c>](usb_gadget_probe_driver+0xf8/0x140)
      [<c045f29c>] (usb_gadget_probe_driver) from [<bf005424>](gadget_dev_desc_UDC_store+0xac/0xc4 [libcomposite])
      [<bf005424>] (gadget_dev_desc_UDC_store [libcomposite]) from[<c023d8e0>] (configfs_write_file+0xd4/0x160)
      [<c023d8e0>] (configfs_write_file) from [<c01d51e8>] (__vfs_write+0x1c/0x114)
      [<c01d51e8>] (__vfs_write) from [<c01d5ff4>] (vfs_write+0xa4/0x168)
      [<c01d5ff4>] (vfs_write) from [<c01d6d40>] (SyS_write+0x3c/0x90)
      [<c01d6d40>] (SyS_write) from [<c0107400>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: NZeng Tao <prime.zeng@hisilicon.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      08c937f9
    • B
      usb: dwc3: gadget: synchronize_irq dwc irq in suspend · 03a5d4d5
      Bo He 提交于
      [ Upstream commit 01c10880d24291a96a4ab0da773e3c5ce4d12da8 ]
      
      We see dwc3 endpoint stopped by unwanted irq during
      suspend resume test, which is caused dwc3 ep can't be started
      with error "No Resource".
      
      Here, add synchronize_irq before suspend to sync the
      pending IRQ handlers complete.
      Signed-off-by: NBo He <bo.he@intel.com>
      Signed-off-by: NYu Wang <yu.y.wang@intel.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      03a5d4d5
    • D
      thermal: int340x_thermal: Fix a NULL vs IS_ERR() check · f29024c0
      Dan Carpenter 提交于
      [ Upstream commit 3fe931b31a4078395c1967f0495dcc9e5ec6b5e3 ]
      
      The intel_soc_dts_iosf_init() function doesn't return NULL, it returns
      error pointers.
      
      Fixes: 4d0dd6c1 ("Thermal/int340x/processor_thermal: Enable auxiliary DTS for Braswell")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f29024c0
    • M
      clk: vc5: Abort clock configuration without upstream clock · fc1073df
      Marek Vasut 提交于
      [ Upstream commit 2137a109a5e39c2bdccfffe65230ed3fadbaac0e ]
      
      In case the upstream clock are not set, which can happen in case the
      VC5 has no valid upstream clock, the $src variable is used uninited
      by regmap_update_bits(). Check for this condition and return -EINVAL
      in such case.
      
      Note that in case the VC5 has no valid upstream clock, the VC5 can
      not operate correctly. That is a hardware property of the VC5. The
      internal oscilator present in some VC5 models is also considered
      upstream clock.
      Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
      Cc: Alexey Firago <alexey_firago@mentor.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: linux-renesas-soc@vger.kernel.org
      [sboyd@kernel.org: Added comment about probe preventing this from
      happening in the first place]
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fc1073df
    • L
      clk: sysfs: fix invalid JSON in clk_dump · 71943c38
      Lubomir Rintel 提交于
      [ Upstream commit c6e909972ef87aa2a479269f46b84126f99ec6db ]
      
      Add a missing comma so that the output is valid JSON format again.
      
      Fixes: 9fba738a ("clk: add duty cycle support")
      Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      71943c38
    • D
      clk: tegra: dfll: Fix a potential Oop in remove() · acc934f5
      Dan Carpenter 提交于
      [ Upstream commit d39eca547f3ec67140a5d765a426eb157b978a59 ]
      
      If tegra_dfll_unregister() fails then "soc" is an error pointer.  We
      should just return instead of dereferencing it.
      
      Fixes: 1752c9ee ("clk: tegra: dfll: Fix drvdata overwriting issue")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      acc934f5
    • Y
      ASoC: Variable "val" in function rt274_i2c_probe() could be uninitialized · 651023ed
      Yizhuo 提交于
      [ Upstream commit 8c3590de0a378c2449fc1aec127cc693632458e4 ]
      
      Inside function rt274_i2c_probe(), if regmap_read() function
      returns -EINVAL, then local variable "val" leaves uninitialized
      but used in if statement. This is potentially unsafe.
      Signed-off-by: NYizhuo <yzhai003@ucr.edu>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      651023ed
    • D
      ALSA: compress: prevent potential divide by zero bugs · e7b2f9f2
      Dan Carpenter 提交于
      [ Upstream commit 678e2b44c8e3fec3afc7202f1996a4500a50be93 ]
      
      The problem is seen in the q6asm_dai_compr_set_params() function:
      
      	ret = q6asm_map_memory_regions(dir, prtd->audio_client, prtd->phys,
      				       (prtd->pcm_size / prtd->periods),
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      				       prtd->periods);
      
      In this code prtd->pcm_size is the buffer_size and prtd->periods comes
      from params->buffer.fragments.  If we allow the number of fragments to
      be zero then it results in a divide by zero bug.  One possible fix would
      be to use prtd->pcm_count directly instead of using the division to
      re-calculate it.  But I decided that it doesn't really make sense to
      allow zero fragments.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e7b2f9f2
    • R
      ASoC: Intel: Haswell/Broadwell: fix setting for .dynamic field · a4964959
      Rander Wang 提交于
      [ Upstream commit 906a9abc5de73c383af518f5a806f4be2993a0c7 ]
      
      For some reason this field was set to zero when all other drivers use
      .dynamic = 1 for front-ends. This change was tested on Dell XPS13 and
      has no impact with the existing legacy driver. The SOF driver also works
      with this change which enables it to override the fixed topology.
      Signed-off-by: NRander Wang <rander.wang@linux.intel.com>
      Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a4964959
    • K
      drm/msm: Unblock writer if reader closes file · 5a700533
      Kristian H. Kristensen 提交于
      [ Upstream commit 99c66bc051e7407fe0bf0607b142ec0be1a1d1dd ]
      
      Prevents deadlock when fifo is full and reader closes file.
      Signed-off-by: NKristian H. Kristensen <hoegsberg@chromium.org>
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5a700533
    • J
      scsi: libsas: Fix rphy phy_identifier for PHYs with end devices attached · 0f978ec3
      John Garry 提交于
      commit ffeafdd2bf0b280d67ec1a47ea6287910d271f3f upstream.
      
      The sysfs phy_identifier attribute for a sas_end_device comes from the rphy
      phy_identifier value.
      
      Currently this is not being set for rphys with an end device attached, so
      we see incorrect symlinks from systemd disk/by-path:
      
      root@localhost:~# ls -l /dev/disk/by-path/
      total 0
      lrwxrwxrwx 1 root root  9 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0 -> ../../sdb
      lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part2 -> ../../sdb2
      lrwxrwxrwx 1 root root 10 Feb 13 12:26 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy0-lun-0-part3 -> ../../sdc3
      
      Indeed, each sas_end_device phy_identifier value is 0:
      
      root@localhost:/# more sys/class/sas_device/end_device-0\:0\:2/phy_identifier
      0
      root@localhost:/# more sys/class/sas_device/end_device-0\:0\:10/phy_identifier
      0
      
      This patch fixes the discovery code to set the phy_identifier.  With this,
      we now get proper symlinks:
      
      root@localhost:~# ls -l /dev/disk/by-path/
      total 0
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy10-lun-0 -> ../../sdg
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy11-lun-0 -> ../../sdh
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy2-lun-0 -> ../../sda
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy2-lun-0-part1 -> ../../sda1
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0 -> ../../sdb
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0-part1 -> ../../sdb1
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy3-lun-0-part2 -> ../../sdb2
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0 -> ../../sdc
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part1 -> ../../sdc1
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part2 -> ../../sdc2
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy4-lun-0-part3 -> ../../sdc3
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy5-lun-0 -> ../../sdd
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0 -> ../../sde
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part1 -> ../../sde1
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part2 -> ../../sde2
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy7-lun-0-part3 -> ../../sde3
      lrwxrwxrwx 1 root root  9 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0 -> ../../sdf
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part1 -> ../../sdf1
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part2 -> ../../sdf2
      lrwxrwxrwx 1 root root 10 Feb 13 11:53 platform-HISI0162:01-sas-exp0x500e004aaaaaaa1f-phy8-lun-0-part3 -> ../../sdf3
      
      Fixes: 2908d778 ("[SCSI] aic94xx: new driver")
      Reported-by: Ndann frazier <dann.frazier@canonical.com>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Reviewed-by: NJason Yan <yanaijie@huawei.com>
      Tested-by: Ndann frazier <dann.frazier@canonical.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0f978ec3
    • T
      mac80211: Change default tx_sk_pacing_shift to 7 · a7c6cf3b
      Toke Høiland-Jørgensen 提交于
      commit 5c14a4d05f68415af9e41a4e667d1748d41d1baf upstream.
      
      When we did the original tests for the optimal value of sk_pacing_shift, we
      came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
      two, so when picking the shift value I erred on the size of less buffering
      and picked 4 ms instead of 8. This was probably wrong; those 2 ms of extra
      buffering makes a larger difference than I thought.
      
      So, change the default pacing shift to 7, which corresponds to 8 ms of
      buffering. The point of diminishing returns really kicks in after 8 ms, and
      so having this as a default should cut down on the need for extensive
      per-device testing and overrides needed in the drivers.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      a7c6cf3b
    • L
      genirq/matrix: Improve target CPU selection for managed interrupts. · 765c30b3
      Long Li 提交于
      [ Upstream commit e8da8794a7fd9eef1ec9a07f0d4897c68581c72b ]
      
      On large systems with multiple devices of the same class (e.g. NVMe disks,
      using managed interrupts), the kernel can affinitize these interrupts to a
      small subset of CPUs instead of spreading them out evenly.
      
      irq_matrix_alloc_managed() tries to select the CPU in the supplied cpumask
      of possible target CPUs which has the lowest number of interrupt vectors
      allocated.
      
      This is done by searching the CPU with the highest number of available
      vectors. While this is correct for non-managed CPUs it can select the wrong
      CPU for managed interrupts. Under certain constellations this results in
      affinitizing the managed interrupts of several devices to a single CPU in
      a set.
      
      The book keeping of available vectors works the following way:
      
       1) Non-managed interrupts:
      
          available is decremented when the interrupt is actually requested by
          the device driver and a vector is assigned. It's incremented when the
          interrupt and the vector are freed.
      
       2) Managed interrupts:
      
          Managed interrupts guarantee vector reservation when the MSI/MSI-X
          functionality of a device is enabled, which is achieved by reserving
          vectors in the bitmaps of the possible target CPUs. This reservation
          decrements the available count on each possible target CPU.
      
          When the interrupt is requested by the device driver then a vector is
          allocated from the reserved region. The operation is reversed when the
          interrupt is freed by the device driver. Neither of these operations
          affect the available count.
      
          The reservation persist up to the point where the MSI/MSI-X
          functionality is disabled and only this operation increments the
          available count again.
      
      For non-managed interrupts the available count is the correct selection
      criterion because the guaranteed reservations need to be taken into
      account. Using the allocated counter could lead to a failing allocation in
      the following situation (total vector space of 10 assumed):
      
      		 CPU0	CPU1
       available:	    2	   0
       allocated:	    5	   3   <--- CPU1 is selected, but available space = 0
       managed reserved:  3	   7
      
       while available yields the correct result.
      
      For managed interrupts the available count is not the appropriate
      selection criterion because as explained above the available count is not
      affected by the actual vector allocation.
      
      The following example illustrates that. Total vector space of 10
      assumed. The starting point is:
      
      		 CPU0	CPU1
       available:	    5	   4
       allocated:	    2	   3
       managed reserved:  3	   3
      
       Allocating vectors for three non-managed interrupts will result in
       affinitizing the first two to CPU0 and the third one to CPU1 because the
       available count is adjusted with each allocation:
      
      		  CPU0	CPU1
       available:	     5	   4	<- Select CPU0 for 1st allocation
       --> allocated:	     3	   3
      
       available:	     4	   4	<- Select CPU0 for 2nd allocation
       --> allocated:	     4	   3
      
       available:	     3	   4	<- Select CPU1 for 3rd allocation
       --> allocated:	     4	   4
      
       But the allocation of three managed interrupts starting from the same
       point will affinitize all of them to CPU0 because the available count is
       not affected by the allocation (see above). So the end result is:
      
      		  CPU0	CPU1
       available:	     5	   4
       allocated:	     5	   3
      
      Introduce a "managed_allocated" field in struct cpumap to track the vector
      allocation for managed interrupts separately. Use this information to
      select the target CPU when a vector is allocated for a managed interrupt,
      which results in more evenly distributed vector assignments. The above
      example results in the following allocations:
      
      		 CPU0	CPU1
       managed_allocated: 0	   0	<- Select CPU0 for 1st allocation
       --> allocated:	    3	   3
      
       managed_allocated: 1	   0	<- Select CPU1 for 2nd allocation
       --> allocated:	    3	   4
      
       managed_allocated: 1	   1	<- Select CPU0 for 3rd allocation
       --> allocated:	    4	   4
      
      The allocation of non-managed interrupts is not affected by this change and
      is still evaluating the available count.
      
      The overall distribution of interrupt vectors for both types of interrupts
      might still not be perfectly even depending on the number of non-managed
      and managed interrupts in a system, but due to the reservation guarantee
      for managed interrupts this cannot be avoided.
      
      Expose the new field in debugfs as well.
      
      [ tglx: Clarified the background of the problem in the changelog and
        	described it independent of NVME ]
      Signed-off-by: NLong Li <longli@microsoft.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Michael Kelley <mikelley@microsoft.com>
      Link: https://lkml.kernel.org/r/20181106040000.27316-1-longli@linuxonhyperv.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      765c30b3
    • D
      irq/matrix: Spread managed interrupts on allocation · 8cae7757
      Dou Liyang 提交于
      [ Upstream commit 76f99ae5b54d48430d1f0c5512a84da0ff9761e0 ]
      
      Linux spreads out the non managed interrupt across the possible target CPUs
      to avoid vector space exhaustion.
      
      Managed interrupts are treated differently, as for them the vectors are
      reserved (with guarantee) when the interrupt descriptors are initialized.
      
      When the interrupt is requested a real vector is assigned. The assignment
      logic uses the first CPU in the affinity mask for assignment. If the
      interrupt has more than one CPU in the affinity mask, which happens when a
      multi queue device has less queues than CPUs, then doing the same search as
      for non managed interrupts makes sense as it puts the interrupt on the
      least interrupt plagued CPU. For single CPU affine vectors that's obviously
      a NOOP.
      
      Restructre the matrix allocation code so it does the 'best CPU' search, add
      the sanity check for an empty affinity mask and adapt the call site in the
      x86 vector management code.
      
      [ tglx: Added the empty mask check to the core and improved change log ]
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: hpa@zytor.com
      Link: https://lkml.kernel.org/r/20180908175838.14450-2-dou_liyang@163.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cae7757
    • D
      irq/matrix: Split out the CPU selection code into a helper · 2948b887
      Dou Liyang 提交于
      [ Upstream commit 8ffe4e61c06a48324cfd97f1199bb9838acce2f2 ]
      
      Linux finds the CPU which has the lowest vector allocation count to spread
      out the non managed interrupts across the possible target CPUs, but does
      not do so for managed interrupts.
      
      Split out the CPU selection code into a helper function for reuse. No
      functional change.
      Signed-off-by: NDou Liyang <douly.fnst@cn.fujitsu.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: hpa@zytor.com
      Link: https://lkml.kernel.org/r/20180908175838.14450-1-dou_liyang@163.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2948b887
  2. 27 2月, 2019 1 次提交