1. 26 7月, 2019 40 次提交
    • P
      x86/atomic: Fix smp_mb__{before,after}_atomic() · 9e0bcb59
      Peter Zijlstra 提交于
      [ Upstream commit 69d927bba39517d0980462efc051875b7f4db185 ]
      
      Recent probing at the Linux Kernel Memory Model uncovered a
      'surprise'. Strongly ordered architectures where the atomic RmW
      primitive implies full memory ordering and
      smp_mb__{before,after}_atomic() are a simple barrier() (such as x86)
      fail for:
      
      	*x = 1;
      	atomic_inc(u);
      	smp_mb__after_atomic();
      	r0 = *y;
      
      Because, while the atomic_inc() implies memory order, it
      (surprisingly) does not provide a compiler barrier. This then allows
      the compiler to re-order like so:
      
      	atomic_inc(u);
      	*x = 1;
      	smp_mb__after_atomic();
      	r0 = *y;
      
      Which the CPU is then allowed to re-order (under TSO rules) like:
      
      	atomic_inc(u);
      	r0 = *y;
      	*x = 1;
      
      And this very much was not intended. Therefore strengthen the atomic
      RmW ops to include a compiler barrier.
      
      NOTE: atomic_{or,and,xor} and the bitops already had the compiler
      barrier.
      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>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9e0bcb59
    • K
      perf/x86/intel/uncore: Handle invalid event coding for free-running counter · dd0260fd
      Kan Liang 提交于
      [ Upstream commit 543ac280b3576c0009e8c0fcd4d6bfc9978d7bd0 ]
      
      Counting with invalid event coding for free-running counter may cause
      OOPs, e.g. uncore_iio_free_running_0/event=1/.
      
      Current code only validate the event with free-running event format,
      event=0xff,umask=0xXY. Non-free-running event format never be checked
      for the PMU with free-running counters.
      
      Add generic hw_config() to check and reject the invalid event coding
      for free-running PMU.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.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>
      Cc: acme@kernel.org
      Cc: eranian@google.com
      Fixes: 0f519f03 ("perf/x86/intel/uncore: Support IIO free-running counters on SKX")
      Link: https://lkml.kernel.org/r/1556672028-119221-2-git-send-email-kan.liang@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dd0260fd
    • Q
      sched/fair: Fix "runnable_avg_yN_inv" not used warnings · 7fc96cd2
      Qian Cai 提交于
      [ Upstream commit 509466b7d480bc5d22e90b9fbe6122ae0e2fbe39 ]
      
      runnable_avg_yN_inv[] is only used in kernel/sched/pelt.c but was
      included in several other places because they need other macros all
      came from kernel/sched/sched-pelt.h which was generated by
      Documentation/scheduler/sched-pelt. As the result, it causes compilation
      a lot of warnings,
      
        kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined but not used [-Wunused-const-variable=]
        kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined but not used [-Wunused-const-variable=]
        kernel/sched/sched-pelt.h:4:18: warning: 'runnable_avg_yN_inv' defined but not used [-Wunused-const-variable=]
        ...
      
      Silence it by appending the __maybe_unused attribute for it, so all
      generated variables and macros can still be kept in the same file.
      Signed-off-by: NQian Cai <cai@lca.pw>
      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>
      Link: https://lkml.kernel.org/r/1559596304-31581-1-git-send-email-cai@lca.pwSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7fc96cd2
    • G
      sched/core: Add __sched tag for io_schedule() · d8b7db6c
      Gao Xiang 提交于
      [ Upstream commit e3b929b0a184edb35531153c5afcaebb09014f9d ]
      
      Non-inline io_schedule() was introduced in:
      
        commit 10ab5643 ("sched/core: Separate out io_schedule_prepare() and io_schedule_finish()")
      
      Keep in line with io_schedule_timeout(), otherwise "/proc/<pid>/wchan" will
      report io_schedule() rather than its callers when waiting for IO.
      Reported-by: NJilong Kou <koujilong@huawei.com>
      Signed-off-by: NGao Xiang <gaoxiang25@huawei.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Miao Xie <miaoxie@huawei.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 10ab5643 ("sched/core: Separate out io_schedule_prepare() and io_schedule_finish()")
      Link: https://lkml.kernel.org/r/20190603091338.2695-1-gaoxiang25@huawei.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d8b7db6c
    • N
      xfrm: fix sa selector validation · 930655b0
      Nicolas Dichtel 提交于
      [ Upstream commit b8d6d0079757cbd1b69724cfd1c08e2171c68cee ]
      
      After commit b38ff4075a80, the following command does not work anymore:
      $ ip xfrm state add src 10.125.0.2 dst 10.125.0.1 proto esp spi 34 reqid 1 \
        mode tunnel enc 'cbc(aes)' 0xb0abdba8b782ad9d364ec81e3a7d82a1 auth-trunc \
        'hmac(sha1)' 0xe26609ebd00acb6a4d51fca13e49ea78a72c73e6 96 flag align4
      
      In fact, the selector is not mandatory, allow the user to provide an empty
      selector.
      
      Fixes: b38ff4075a80 ("xfrm: Fix xfrm sel prefix length validation")
      CC: Anirudh Gupta <anirudh.gupta@sophos.com>
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      930655b0
    • T
      blkcg, writeback: dead memcgs shouldn't contribute to writeback ownership arbitration · b7d66bbc
      Tejun Heo 提交于
      [ Upstream commit 6631142229005e1b1c311a09efe9fb3cfdac8559 ]
      
      wbc_account_io() collects information on cgroup ownership of writeback
      pages to determine which cgroup should own the inode.  Pages can stay
      associated with dead memcgs but we want to avoid attributing IOs to
      dead blkcgs as much as possible as the association is likely to be
      stale.  However, currently, pages associated with dead memcgs
      contribute to the accounting delaying and/or confusing the
      arbitration.
      
      Fix it by ignoring pages associated with dead memcgs.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b7d66bbc
    • B
      block: null_blk: fix race condition for null_del_dev · c8f75e75
      Bob Liu 提交于
      [ Upstream commit 7602843fd873cae43a444b83b14dfdd114a9659c ]
      
      Dulicate call of null_del_dev() will trigger null pointer error like below.
      The reason is a race condition between nullb_device_power_store() and
      nullb_group_drop_item().
      
        CPU#0                         CPU#1
        ----------------              -----------------
        do_rmdir()
         >configfs_rmdir()
          >client_drop_item()
           >nullb_group_drop_item()
                                      nullb_device_power_store()
      				>null_del_dev()
      
            >test_and_clear_bit(NULLB_DEV_FL_UP
             >null_del_dev()
             ^^^^^
             Duplicated null_dev_dev() triger null pointer error
      
      				>clear_bit(NULLB_DEV_FL_UP
      
      The fix could be keep the sequnce of clear NULLB_DEV_FL_UP and null_del_dev().
      
      [  698.613600] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
      [  698.613608] #PF error: [normal kernel read fault]
      [  698.613611] PGD 0 P4D 0
      [  698.613619] Oops: 0000 [#1] SMP PTI
      [  698.613627] CPU: 3 PID: 6382 Comm: rmdir Not tainted 5.0.0+ #35
      [  698.613631] Hardware name: LENOVO 20LJS2EV08/20LJS2EV08, BIOS R0SET33W (1.17 ) 07/18/2018
      [  698.613644] RIP: 0010:null_del_dev+0xc/0x110 [null_blk]
      [  698.613649] Code: 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b eb 97 e8 47 bb 2a e8 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <8b> 77 18 48 89 fb 4c 8b 27 48 c7 c7 40 57 1e c1 e8 bf c7 cb e8 48
      [  698.613654] RSP: 0018:ffffb887888bfde0 EFLAGS: 00010286
      [  698.613659] RAX: 0000000000000000 RBX: ffff9d436d92bc00 RCX: ffff9d43a9184681
      [  698.613663] RDX: ffffffffc11e5c30 RSI: 0000000068be6540 RDI: 0000000000000000
      [  698.613667] RBP: ffffb887888bfdf0 R08: 0000000000000001 R09: 0000000000000000
      [  698.613671] R10: ffffb887888bfdd8 R11: 0000000000000f16 R12: ffff9d436d92bc08
      [  698.613675] R13: ffff9d436d94e630 R14: ffffffffc11e5088 R15: ffffffffc11e5000
      [  698.613680] FS:  00007faa68be6540(0000) GS:ffff9d43d14c0000(0000) knlGS:0000000000000000
      [  698.613685] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  698.613689] CR2: 0000000000000018 CR3: 000000042f70c002 CR4: 00000000003606e0
      [  698.613693] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  698.613697] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  698.613700] Call Trace:
      [  698.613712]  nullb_group_drop_item+0x50/0x70 [null_blk]
      [  698.613722]  client_drop_item+0x29/0x40
      [  698.613728]  configfs_rmdir+0x1ed/0x300
      [  698.613738]  vfs_rmdir+0xb2/0x130
      [  698.613743]  do_rmdir+0x1c7/0x1e0
      [  698.613750]  __x64_sys_rmdir+0x17/0x20
      [  698.613759]  do_syscall_64+0x5a/0x110
      [  698.613768]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      Signed-off-by: NBob Liu <bob.liu@oracle.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c8f75e75
    • Y
      net: hns3: fix for skb leak when doing selftest · 1a3706d8
      Yunsheng Lin 提交于
      [ Upstream commit 8f9eed1a8791b83eb1c54c261d68424717e4111e ]
      
      If hns3_nic_net_xmit does not return NETDEV_TX_BUSY when doing
      a loopback selftest, the skb is not freed in hns3_clean_tx_ring
      or hns3_nic_net_xmit, which causes skb not freed problem.
      
      This patch fixes it by freeing skb when hns3_nic_net_xmit does
      not return NETDEV_TX_OK.
      
      Fixes: c39c4d98 ("net: hns3: Add mac loopback selftest support in hns3 driver")
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1a3706d8
    • M
      qed: iWARP - Fix tc for MPA ll2 connection · 6a47a42f
      Michal Kalderon 提交于
      [ Upstream commit cb94d52b93c74fe1f2595734fabeda9f8ae891ee ]
      
      The driver needs to assign a lossless traffic class for the MPA ll2
      connection to ensure no packets are dropped when returning from the
      driver as they will never be re-transmitted by the peer.
      
      Fixes: ae3488ff ("qed: Add ll2 connection for processing unaligned MPA packets")
      Signed-off-by: NAriel Elior <ariel.elior@marvell.com>
      Signed-off-by: NMichal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6a47a42f
    • A
      x86/cpufeatures: Add FDP_EXCPTN_ONLY and ZERO_FCS_FDS · 670fb965
      Aaron Lewis 提交于
      [ Upstream commit cbb99c0f588737ec98c333558922ce47e9a95827 ]
      
      Add the CPUID enumeration for Intel's de-feature bits to accommodate
      passing these de-features through to kvm guests.
      
      These de-features are (from SDM vol 1, section 8.1.8):
       - X86_FEATURE_FDP_EXCPTN_ONLY: If CPUID.(EAX=07H,ECX=0H):EBX[bit 6] = 1, the
         data pointer (FDP) is updated only for the x87 non-control instructions that
         incur unmasked x87 exceptions.
       - X86_FEATURE_ZERO_FCS_FDS: If CPUID.(EAX=07H,ECX=0H):EBX[bit 13] = 1, the
         processor deprecates FCS and FDS; it saves each as 0000H.
      Signed-off-by: NAaron Lewis <aaronlewis@google.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Reviewed-by: NJim Mattson <jmattson@google.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Frederic Weisbecker <frederic@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: marcorr@google.com
      Cc: Peter Feiner <pfeiner@google.com>
      Cc: pshier@google.com
      Cc: Robert Hoo <robert.hu@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190605220252.103406-1-aaronlewis@google.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      670fb965
    • W
      rcu: Force inlining of rcu_read_lock() · 366ae49e
      Waiman Long 提交于
      [ Upstream commit 6da9f775175e516fc7229ceaa9b54f8f56aa7924 ]
      
      When debugging options are turned on, the rcu_read_lock() function
      might not be inlined. This results in lockdep's print_lock() function
      printing "rcu_read_lock+0x0/0x70" instead of rcu_read_lock()'s caller.
      For example:
      
      [   10.579995] =============================
      [   10.584033] WARNING: suspicious RCU usage
      [   10.588074] 4.18.0.memcg_v2+ #1 Not tainted
      [   10.593162] -----------------------------
      [   10.597203] include/linux/rcupdate.h:281 Illegal context switch in
      RCU read-side critical section!
      [   10.606220]
      [   10.606220] other info that might help us debug this:
      [   10.606220]
      [   10.614280]
      [   10.614280] rcu_scheduler_active = 2, debug_locks = 1
      [   10.620853] 3 locks held by systemd/1:
      [   10.624632]  #0: (____ptrval____) (&type->i_mutex_dir_key#5){.+.+}, at: lookup_slow+0x42/0x70
      [   10.633232]  #1: (____ptrval____) (rcu_read_lock){....}, at: rcu_read_lock+0x0/0x70
      [   10.640954]  #2: (____ptrval____) (rcu_read_lock){....}, at: rcu_read_lock+0x0/0x70
      
      These "rcu_read_lock+0x0/0x70" strings are not providing any useful
      information.  This commit therefore forces inlining of the rcu_read_lock()
      function so that rcu_read_lock()'s caller is instead shown.
      Signed-off-by: NWaiman Long <longman@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      366ae49e
    • J
      ASoC: meson: axg-tdm: fix sample clock inversion · 1fb3ce14
      Jerome Brunet 提交于
      [ Upstream commit cb36ff785e868992e96e8b9e5a0c2822b680a9e2 ]
      
      The content of SND_SOC_DAIFMT_FORMAT_MASK is a number, not a bitfield,
      so the test to check if the format is i2s is wrong. Because of this the
      clock setting may be wrong. For example, the sample clock gets inverted
      in DSP B mode, when it should not.
      
      Fix the lrclk invert helper function
      
      Fixes: 1a11d88f ("ASoC: meson: add tdm formatter base driver")
      Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1fb3ce14
    • R
      x86/cpu: Add Ice Lake NNPI to Intel family · 32df4043
      Rajneesh Bhardwaj 提交于
      [ Upstream commit e32d045cd4ba06b59878323e434bad010e78e658 ]
      
      Add the CPUID model number of Ice Lake Neural Network Processor for Deep
      Learning Inference (ICL-NNPI) to the Intel family list. Ice Lake NNPI uses
      model number 0x9D and this will be documented in a future version of Intel
      Software Development Manual.
      Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: bp@suse.de
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: platform-driver-x86@vger.kernel.org
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linux PM <linux-pm@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20190606012419.13250-1-rajneesh.bhardwaj@linux.intel.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      32df4043
    • O
      selinux: fix empty write to keycreate file · 914026d5
      Ondrej Mosnacek 提交于
      [ Upstream commit 464c258aa45b09f16aa0f05847ed8895873262d9 ]
      
      When sid == 0 (we are resetting keycreate_sid to the default value), we
      should skip the KEY__CREATE check.
      
      Before this patch, doing a zero-sized write to /proc/self/keycreate
      would check if the current task can create unlabeled keys (which would
      usually fail with -EACCESS and generate an AVC). Now it skips the check
      and correctly sets the task's keycreate_sid to 0.
      
      Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1719067
      
      Tested using the reproducer from the report above.
      
      Fixes: 4eb582cf ("[PATCH] keys: add a way to store the appropriate context for newly-created keys")
      Reported-by: NKir Kolyshkin <kir@sacred.ru>
      Signed-off-by: NOndrej Mosnacek <omosnace@redhat.com>
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      914026d5
    • M
      media: s5p-mfc: fix reading min scratch buffer size on MFC v6/v7 · 10e3788e
      Marek Szyprowski 提交于
      [ Upstream commit be22203aec440c1761ce8542c2636ac6c8951e3a ]
      
      MFC v6 and v7 has no register to read min scratch buffer size, so it has
      to be read conditionally only if hardware supports it. This fixes following
      NULL pointer exception on SoCs with MFC v6/v7:
      
      8<--- cut here ---
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = f25837f9
      [00000000] *pgd=bd93d835
      Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      Modules linked in: btmrvl_sdio btmrvl bluetooth mwifiex_sdio mwifiex ecdh_generic ecc
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      PC is at s5p_mfc_get_min_scratch_buf_size+0x30/0x3c
      LR is at s5p_mfc_get_min_scratch_buf_size+0x28/0x3c
      ...
      [<c074f998>] (s5p_mfc_get_min_scratch_buf_size) from [<c0745bc0>] (s5p_mfc_irq+0x814/0xa5c)
      [<c0745bc0>] (s5p_mfc_irq) from [<c019a218>] (__handle_irq_event_percpu+0x64/0x3f8)
      [<c019a218>] (__handle_irq_event_percpu) from [<c019a5d8>] (handle_irq_event_percpu+0x2c/0x7c)
      [<c019a5d8>] (handle_irq_event_percpu) from [<c019a660>] (handle_irq_event+0x38/0x5c)
      [<c019a660>] (handle_irq_event) from [<c019ebc4>] (handle_fasteoi_irq+0xc4/0x180)
      [<c019ebc4>] (handle_fasteoi_irq) from [<c0199270>] (generic_handle_irq+0x24/0x34)
      [<c0199270>] (generic_handle_irq) from [<c0199888>] (__handle_domain_irq+0x7c/0xec)
      [<c0199888>] (__handle_domain_irq) from [<c04ac298>] (gic_handle_irq+0x58/0x9c)
      [<c04ac298>] (gic_handle_irq) from [<c0101ab0>] (__irq_svc+0x70/0xb0)
      Exception stack(0xe73ddc60 to 0xe73ddca8)
      ...
      [<c0101ab0>] (__irq_svc) from [<c01967d8>] (console_unlock+0x5a8/0x6a8)
      [<c01967d8>] (console_unlock) from [<c01981d0>] (vprintk_emit+0x118/0x2d8)
      [<c01981d0>] (vprintk_emit) from [<c01983b0>] (vprintk_default+0x20/0x28)
      [<c01983b0>] (vprintk_default) from [<c01989b4>] (printk+0x30/0x54)
      [<c01989b4>] (printk) from [<c07500b8>] (s5p_mfc_init_decode_v6+0x1d4/0x284)
      [<c07500b8>] (s5p_mfc_init_decode_v6) from [<c07230d0>] (vb2_start_streaming+0x24/0x150)
      [<c07230d0>] (vb2_start_streaming) from [<c0724e4c>] (vb2_core_streamon+0x11c/0x15c)
      [<c0724e4c>] (vb2_core_streamon) from [<c07478b8>] (vidioc_streamon+0x64/0xa0)
      [<c07478b8>] (vidioc_streamon) from [<c0709640>] (__video_do_ioctl+0x28c/0x45c)
      [<c0709640>] (__video_do_ioctl) from [<c0709bc8>] (video_usercopy+0x260/0x8a4)
      [<c0709bc8>] (video_usercopy) from [<c02b3820>] (do_vfs_ioctl+0xb0/0x9fc)
      [<c02b3820>] (do_vfs_ioctl) from [<c02b41a0>] (ksys_ioctl+0x34/0x58)
      [<c02b41a0>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      Exception stack(0xe73ddfa8 to 0xe73ddff0)
      ...
      ---[ end trace 376cf5ba6e0bee93 ]---
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      10e3788e
    • V
      bpf: silence warning messages in core · 7c10f894
      Valdis Klētnieks 提交于
      [ Upstream commit aee450cbe482a8c2f6fa5b05b178ef8b8ff107ca ]
      
      Compiling kernel/bpf/core.c with W=1 causes a flood of warnings:
      
      kernel/bpf/core.c:1198:65: warning: initialized field overwritten [-Woverride-init]
       1198 | #define BPF_INSN_3_TBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = true
            |                                                                 ^~~~
      kernel/bpf/core.c:1087:2: note: in expansion of macro 'BPF_INSN_3_TBL'
       1087 |  INSN_3(ALU, ADD,  X),   \
            |  ^~~~~~
      kernel/bpf/core.c:1202:3: note: in expansion of macro 'BPF_INSN_MAP'
       1202 |   BPF_INSN_MAP(BPF_INSN_2_TBL, BPF_INSN_3_TBL),
            |   ^~~~~~~~~~~~
      kernel/bpf/core.c:1198:65: note: (near initialization for 'public_insntable[12]')
       1198 | #define BPF_INSN_3_TBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = true
            |                                                                 ^~~~
      kernel/bpf/core.c:1087:2: note: in expansion of macro 'BPF_INSN_3_TBL'
       1087 |  INSN_3(ALU, ADD,  X),   \
            |  ^~~~~~
      kernel/bpf/core.c:1202:3: note: in expansion of macro 'BPF_INSN_MAP'
       1202 |   BPF_INSN_MAP(BPF_INSN_2_TBL, BPF_INSN_3_TBL),
            |   ^~~~~~~~~~~~
      
      98 copies of the above.
      
      The attached patch silences the warnings, because we *know* we're overwriting
      the default initializer. That leaves bpf/core.c with only 6 other warnings,
      which become more visible in comparison.
      Signed-off-by: NValdis Kletnieks <valdis.kletnieks@vt.edu>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7c10f894
    • S
      regmap: fix bulk writes on paged registers · b01bf44c
      Srinivas Kandagatla 提交于
      [ Upstream commit db057679de3e9e6a03c1bcd5aee09b0d25fd9f5b ]
      
      On buses like SlimBus and SoundWire which does not support
      gather_writes yet in regmap, A bulk write on paged register
      would be silently ignored after programming page.
      This is because local variable 'ret' value in regmap_raw_write_impl()
      gets reset to 0 once page register is written successfully and the
      code below checks for 'ret' value to be -ENOTSUPP before linearising
      the write buffer to send to bus->write().
      
      Fix this by resetting the 'ret' value to -ENOTSUPP in cases where
      gather_writes() is not supported or single register write is
      not possible.
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b01bf44c
    • R
      gpio: omap: ensure irq is enabled before wakeup · 544cd592
      Russell King 提交于
      [ Upstream commit c859e0d479b3b4f6132fc12637c51e01492f31f6 ]
      
      Documentation states:
      
        NOTE: There must be a correlation between the wake-up enable and
        interrupt-enable registers. If a GPIO pin has a wake-up configured
        on it, it must also have the corresponding interrupt enabled (on
        one of the two interrupt lines).
      
      Ensure that this condition is always satisfied by enabling the detection
      events after enabling the interrupt, and disabling the detection before
      disabling the interrupt.  This ensures interrupt/wakeup events can not
      happen until both the wakeup and interrupt enables correlate.
      
      If we do any clearing, clear between the interrupt enable/disable and
      trigger setting.
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      544cd592
    • R
      gpio: omap: fix lack of irqstatus_raw0 for OMAP4 · ddeef7a0
      Russell King 提交于
      [ Upstream commit 64ea3e9094a1f13b96c33244a3fb3a0f45690bd2 ]
      
      Commit 384ebe1c ("gpio/omap: Add DT support to GPIO driver") added
      the register definition tables to the gpio-omap driver. Subsequently to
      that commit, commit 4e962e89 ("gpio/omap: remove cpu_is_omapxxxx()
      checks from *_runtime_resume()") added definitions for irqstatus_raw*
      registers to the legacy OMAP4 definitions, but missed the DT
      definitions.
      
      This causes an unintentional change of behaviour for the 1.101 errata
      workaround on OMAP4 platforms. Fix this oversight.
      
      Fixes: 4e962e89 ("gpio/omap: remove cpu_is_omapxxxx() checks from *_runtime_resume()")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ddeef7a0
    • E
      iommu: Fix a leak in iommu_insert_resv_region · 79644b60
      Eric Auger 提交于
      [ Upstream commit ad0834dedaa15c3a176f783c0373f836e44b4700 ]
      
      In case we expand an existing region, we unlink
      this latter and insert the larger one. In
      that case we should free the original region after
      the insertion. Also we can immediately return.
      
      Fixes: 6c65fb31 ("iommu: iommu_get_group_resv_regions")
      Signed-off-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      79644b60
    • K
      media: fdp1: Support M3N and E3 platforms · f2a4624b
      Kieran Bingham 提交于
      [ Upstream commit 4e8c120de9268fc26f583268b9d22e7d37c4595f ]
      
      New Gen3 R-Car platforms incorporate the FDP1 with an updated version
      register. No code change is required to support these targets, but they
      will currently report an error stating that the device can not be
      identified.
      
      Update the driver to match against the new device types.
      Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
      Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f2a4624b
    • O
      media: uvcvideo: Fix access to uninitialized fields on probe error · 63e53991
      Oliver Neukum 提交于
      [ Upstream commit 11a087f484bf15ff65f0a9f277aa5a61fd07ed2a ]
      
      We need to check whether this work we are canceling actually is
      initialized.
      Signed-off-by: NOliver Neukum <oneukum@suse.com>
      Reported-by: syzbot+2e1ef9188251d9cc7944@syzkaller.appspotmail.com
      Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      63e53991
    • X
      irqchip/meson-gpio: Add support for Meson-G12A SoC · c844f4da
      Xingyu Chen 提交于
      [ Upstream commit c64a9e804ccf86eb202bfd1c6a8c5233c75a0431 ]
      
      The Meson-G12A SoC uses the same GPIO interrupt controller IP block as the
      other Meson SoCs, A totle of 100 pins can be spied on, which is the sum of:
      
      - 223:100 undefined (no interrupt)
      - 99:97   3 pins on bank GPIOE
      - 96:77   20 pins on bank GPIOX
      - 76:61   16 pins on bank GPIOA
      - 60:53   8 pins on bank GPIOC
      - 52:37   16 pins on bank BOOT
      - 36:28   9 pins on bank GPIOH
      - 27:12   16 pins on bank GPIOZ
      - 11:0    12 pins in the AO domain
      Signed-off-by: NXingyu Chen <xingyu.chen@amlogic.com>
      Signed-off-by: NJianxin Pan <jianxin.pan@amlogic.com>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c844f4da
    • T
      perf report: Fix OOM error in TUI mode on s390 · eac8b39d
      Thomas Richter 提交于
      [ Upstream commit 8a07aa4e9b7b0222129c07afff81634a884b2866 ]
      
      Debugging a OOM error using the TUI interface revealed this issue
      on s390:
      
      [tmricht@m83lp54 perf]$ cat /proc/kallsyms |sort
      ....
      00000001119b7158 B radix_tree_node_cachep
      00000001119b8000 B __bss_stop
      00000001119b8000 B _end
      000003ff80002850 t autofs_mount	[autofs4]
      000003ff80002868 t autofs_show_options	[autofs4]
      000003ff80002a98 t autofs_evict_inode	[autofs4]
      ....
      
      There is a huge gap between the last kernel symbol
      __bss_stop/_end and the first kernel module symbol
      autofs_mount (from autofs4 module).
      
      After reading the kernel symbol table via functions:
      
       dso__load()
       +--> dso__load_kernel_sym()
            +--> dso__load_kallsyms()
      	   +--> __dso_load_kallsyms()
      	        +--> symbols__fixup_end()
      
      the symbol __bss_stop has a start address of 1119b8000 and
      an end address of 3ff80002850, as can be seen by this debug statement:
      
        symbols__fixup_end __bss_stop start:0x1119b8000 end:0x3ff80002850
      
      The size of symbol __bss_stop is 0x3fe6e64a850 bytes!
      It is the last kernel symbol and fills up the space until
      the first kernel module symbol.
      
      This size kills the TUI interface when executing the following
      code:
      
        process_sample_event()
          hist_entry_iter__add()
            hist_iter__report_callback()
              hist_entry__inc_addr_samples()
                symbol__inc_addr_samples(symbol = __bss_stop)
                  symbol__cycles_hist()
                     annotated_source__alloc_histograms(...,
      				                symbol__size(sym),
      		                                ...)
      
      This function allocates memory to save sample histograms.
      The symbol_size() marco is defined as sym->end - sym->start, which
      results in above value of 0x3fe6e64a850 bytes and
      the call to calloc() in annotated_source__alloc_histograms() fails.
      
      The histgram memory allocation might fail, make this failure
      no-fatal and continue processing.
      
      Output before:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
        __symbol__inc_addr_samples(875): ENOMEM! sym->name=__bss_stop,
      		start=0x1119b8000, addr=0x2aa0005eb08, end=0x3ff80002850,
      		func: 0
      problem adding hist entry, skipping event
      0x938b8 [0x8]: failed to process type: 68 [Cannot allocate memory]
      [tmricht@m83lp54 perf]$
      
      Output after:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
         symbol__inc_addr_samples map:0x1597830 start:0x110730000 end:0x3ff80002850
         symbol__hists notes->src:0x2aa2a70 nr_hists:1
         symbol__inc_addr_samples sym:unlink_anon_vmas src:0x2aa2a70
         __symbol__inc_addr_samples: addr=0x11094c69e
         0x11094c670 unlink_anon_vmas: period++ [addr: 0x11094c69e, 0x2e, evidx=0]
         	=> nr_samples: 1, period: 526008
      [tmricht@m83lp54 perf]$
      
      There is no error about failed memory allocation and the TUI interface
      shows all entries.
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/90cb5607-3e12-5167-682d-978eba7dafa8@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eac8b39d
    • T
      perf test 6: Fix missing kvm module load for s390 · be32a9dc
      Thomas Richter 提交于
      [ Upstream commit 53fe307dfd309e425b171f6272d64296a54f4dff ]
      
      Command
      
         # perf test -Fv 6
      
      fails with error
      
         running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse
          event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint'
          event syntax error: 'kvm-s390:kvm_s390_create_vm'
                               \___ unknown tracepoint
      
      when the kvm module is not loaded or not built in.
      
      Fix this by adding a valid function which tests if the module
      is loaded. Loaded modules (or builtin KVM support) have a
      directory named
        /sys/kernel/debug/tracing/events/kvm-s390
      for this tracepoint.
      
      Check for existence of this directory.
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20190604053504.43073-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      be32a9dc
    • M
      perf cs-etm: Properly set the value of 'old' and 'head' in snapshot mode · 3662d8bc
      Mathieu Poirier 提交于
      [ Upstream commit e45c48a9a4d20ebc7b639a62c3ef8f4b08007027 ]
      
      This patch adds the necessary intelligence to properly compute the value
      of 'old' and 'head' when operating in snapshot mode.  That way we can
      get the latest information in the AUX buffer and be compatible with the
      generic AUX ring buffer mechanic.
      
      Tester notes:
      
      > Leo, have you had the chance to test/review this one? Suzuki?
      
      Sure.  I applied this patch on the perf/core branch (with latest
      commit 3e4fbf36c1e3 'perf augmented_raw_syscalls: Move reading
      filename to the loop') and passed testing with below steps:
      
        # perf record -e cs_etm/@tmc_etr0/ -S -m,64 --per-thread ./sort &
        [1] 19097
        Bubble sorting array of 30000 elements
      
        # kill -USR2 19097
        # kill -USR2 19097
        # kill -USR2 19097
        [ perf record: Woken up 4 times to write data ]
        [ perf record: Captured and wrote 0.753 MB perf.data ]
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Tested-by: NLeo Yan <leo.yan@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190605161633.12245-1-mathieu.poirier@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3662d8bc
    • S
      ipset: Fix memory accounting for hash types on resize · ac510285
      Stefano Brivio 提交于
      [ Upstream commit 11921796f4799ca9c61c4b22cc54d84aa69f8a35 ]
      
      If a fresh array block is allocated during resize, the current in-memory
      set size should be increased by the size of the block, not replaced by it.
      
      Before the fix, adding entries to a hash set type, leading to a table
      resize, caused an inconsistent memory size to be reported. This becomes
      more obvious when swapping sets with similar sizes:
      
        # cat hash_ip_size.sh
        #!/bin/sh
        FAIL_RETRIES=10
      
        tries=0
        while [ ${tries} -lt ${FAIL_RETRIES} ]; do
        	ipset create t1 hash:ip
        	for i in `seq 1 4345`; do
        		ipset add t1 1.2.$((i / 255)).$((i % 255))
        	done
        	t1_init="$(ipset list t1|sed -n 's/Size in memory: \(.*\)/\1/p')"
      
        	ipset create t2 hash:ip
        	for i in `seq 1 4360`; do
        		ipset add t2 1.2.$((i / 255)).$((i % 255))
        	done
        	t2_init="$(ipset list t2|sed -n 's/Size in memory: \(.*\)/\1/p')"
      
        	ipset swap t1 t2
        	t1_swap="$(ipset list t1|sed -n 's/Size in memory: \(.*\)/\1/p')"
        	t2_swap="$(ipset list t2|sed -n 's/Size in memory: \(.*\)/\1/p')"
      
        	ipset destroy t1
        	ipset destroy t2
        	tries=$((tries + 1))
      
        	if [ ${t1_init} -lt 10000 ] || [ ${t2_init} -lt 10000 ]; then
        		echo "FAIL after ${tries} tries:"
        		echo "T1 size ${t1_init}, after swap ${t1_swap}"
        		echo "T2 size ${t2_init}, after swap ${t2_swap}"
        		exit 1
        	fi
        done
        echo "PASS"
        # echo -n 'func hash_ip4_resize +p' > /sys/kernel/debug/dynamic_debug/control
        # ./hash_ip_size.sh
        [ 2035.018673] attempt to resize set t1 from 10 to 11, t 00000000fe6551fa
        [ 2035.078583] set t1 resized from 10 (00000000fe6551fa) to 11 (00000000172a0163)
        [ 2035.080353] Table destroy by resize 00000000fe6551fa
        FAIL after 4 tries:
        T1 size 9064, after swap 71128
        T2 size 71128, after swap 9064
      Reported-by: NNOYB <JunkYardMail1@Frontier.com>
      Fixes: 9e41f26a ("netfilter: ipset: Count non-static extension memory for userspace")
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ac510285
    • R
      net: sfp: add mutex to prevent concurrent state checks · c7bf2df4
      Robert Hancock 提交于
      [ Upstream commit 2158e856f56bb762ef90f3ec244d41a519826f75 ]
      
      sfp_check_state can potentially be called by both a threaded IRQ handler
      and delayed work. If it is concurrently called, it could result in
      incorrect state management. Add a st_mutex to protect the state - this
      lock gets taken outside of code that checks and handle state changes, and
      the existing sm_mutex nests inside of it.
      Suggested-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NRobert Hancock <hancock@sedsystems.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c7bf2df4
    • B
      RAS/CEC: Fix pfn insertion · fa4059c5
      Borislav Petkov 提交于
      [ Upstream commit 6d8e294bf5f0e85c34e8b14b064e2965f53f38b0 ]
      
      When inserting random PFNs for debugging the CEC through
      (debugfs)/ras/cec/pfn, depending on the return value of pfn_set(),
      multiple values get inserted per a single write.
      
      That is because simple_attr_write() interprets a retval of 0 as
      success and claims the whole input. However, pfn_set() returns the
      cec_add_elem() value, which, if > 0 and smaller than the whole input
      length, makes glibc continue issuing the write syscall until there's
      input left:
      
        pfn_set
        simple_attr_write
        debugfs_attr_write
        full_proxy_write
        vfs_write
        ksys_write
        do_syscall_64
        entry_SYSCALL_64_after_hwframe
      
      leading to those repeated calls.
      
      Return 0 to fix that.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fa4059c5
    • J
      s390/qdio: handle PENDING state for QEBSM devices · 99dcd701
      Julian Wiedmann 提交于
      [ Upstream commit 04310324c6f482921c071444833e70fe861b73d9 ]
      
      When a CQ-enabled device uses QEBSM for SBAL state inspection,
      get_buf_states() can return the PENDING state for an Output Queue.
      get_outbound_buffer_frontier() isn't prepared for this, and any PENDING
      buffer will permanently stall all further completion processing on this
      Queue.
      
      This isn't a concern for non-QEBSM devices, as get_buf_states() for such
      devices will manually turn PENDING buffers into EMPTY ones.
      
      Fixes: 104ea556 ("qdio: support asynchronous delivery of storage blocks")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      99dcd701
    • R
      net: axienet: Fix race condition causing TX hang · a76f32cb
      Robert Hancock 提交于
      [ Upstream commit 7de44285c1f69ccfbe8be1d6a16fcd956681fee6 ]
      
      It is possible that the interrupt handler fires and frees up space in
      the TX ring in between checking for sufficient TX ring space and
      stopping the TX queue in axienet_start_xmit. If this happens, the
      queue wake from the interrupt handler will occur before the queue is
      stopped, causing a lost wakeup and the adapter's transmit hanging.
      
      To avoid this, after stopping the queue, check again whether there is
      sufficient space in the TX ring. If so, wake up the queue again.
      Signed-off-by: NRobert Hancock <hancock@sedsystems.ca>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a76f32cb
    • F
      net: fec: Do not use netdev messages too early · 9d643358
      Fabio Estevam 提交于
      [ Upstream commit a19a0582363b9a5f8ba812f34f1b8df394898780 ]
      
      When a valid MAC address is not found the current messages
      are shown:
      
      fec 2188000.ethernet (unnamed net_device) (uninitialized): Invalid MAC address: 00:00:00:00:00:00
      fec 2188000.ethernet (unnamed net_device) (uninitialized): Using random MAC address: aa:9f:25:eb:7e:aa
      
      Since the network device has not been registered at this point, it is better
      to use dev_err()/dev_info() instead, which will provide cleaner log
      messages like these:
      
      fec 2188000.ethernet: Invalid MAC address: 00:00:00:00:00:00
      fec 2188000.ethernet: Using random MAC address: aa:9f:25:eb:7e:aa
      
      Tested on a imx6dl-pico-pi board.
      Signed-off-by: NFabio Estevam <festevam@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9d643358
    • A
      crypto: inside-secure - do not rely on the hardware last bit for result descriptors · 403c4392
      Antoine Tenart 提交于
      [ Upstream commit 89332590427235680236b9470e851afc49b3caa1 ]
      
      When performing a transformation the hardware is given result
      descriptors to save the result data. Those result descriptors are
      batched using a 'first' and a 'last' bit. There are cases were more
      descriptors than needed are given to the engine, leading to the engine
      only using some of them, and not setting the last bit on the last
      descriptor we gave. This causes issues were the driver and the hardware
      aren't in sync anymore about the number of result descriptors given (as
      the driver do not give a pool of descriptor to use for any
      transformation, but a pool of descriptors to use *per* transformation).
      
      This patch fixes it by attaching the number of given result descriptors
      to the requests, and by using this number instead of the 'last' bit
      found on the descriptors to process them.
      Signed-off-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      403c4392
    • B
      net: stmmac: modify default value of tx-frames · 50331c64
      Biao Huang 提交于
      [ Upstream commit d2facb4b3983425f6776c24dd678a82dbe673773 ]
      
      the default value of tx-frames is 25, it's too late when
      passing tstamp to stack, then the ptp4l will fail:
      
      ptp4l -i eth0 -f gPTP.cfg -m
      ptp4l: selected /dev/ptp0 as PTP clock
      ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE
      ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE
      ptp4l: port 1: link up
      ptp4l: timed out while polling for tx timestamp
      ptp4l: increasing tx_timestamp_timeout may correct this issue,
             but it is likely caused by a driver bug
      ptp4l: port 1: send peer delay response failed
      ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
      
      ptp4l tests pass when changing the tx-frames from 25 to 1 with
      ethtool -C option.
      It should be fine to set tx-frames default value to 1, so ptp4l will pass
      by default.
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      50331c64
    • B
      net: stmmac: dwmac4: fix flow control issue · 1a0a837a
      Biao Huang 提交于
      [ Upstream commit ee326fd01e79dfa42014d55931260b68b9fa3273 ]
      
      Current dwmac4_flow_ctrl will not clear
      GMAC_RX_FLOW_CTRL_RFE/GMAC_RX_FLOW_CTRL_RFE bits,
      so MAC hw will keep flow control on although expecting
      flow control off by ethtool. Add codes to fix it.
      
      Fixes: 477286b5 ("stmmac: add GMAC4 core support")
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1a0a837a
    • J
      perf jvmti: Address gcc string overflow warning for strncpy() · 713737ca
      Jiri Olsa 提交于
      [ Upstream commit 279ab04dbea1370d2eac0f854270369ccaef8a44 ]
      
      We are getting false positive gcc warning when we compile with gcc9 (9.1.1):
      
           CC       jvmti/libjvmti.o
         In file included from /usr/include/string.h:494,
                          from jvmti/libjvmti.c:5:
         In function ‘strncpy’,
             inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
         /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
           106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
               |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
         jvmti/libjvmti.c:165:26: note: length computed here
           165 |   size_t file_name_len = strlen(file_name);
               |                          ^~~~~~~~~~~~~~~~~
         cc1: all warnings being treated as errors
      
      As per Arnaldo's suggestion use strlcpy(), which does the same thing and keeps
      gcc silent.
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190531131321.GB1281@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      713737ca
    • M
      arm64: mm: make CONFIG_ZONE_DMA32 configurable · fb83987c
      Miles Chen 提交于
      [ Upstream commit 0c1f14ed12262f45a3af1d588e4d7bd12438b8f5 ]
      
      This change makes CONFIG_ZONE_DMA32 defuly y and allows users
      to overwrite it only when CONFIG_EXPERT=y.
      
      For the SoCs that do not need CONFIG_ZONE_DMA32, this is the
      first step to manage all available memory by a single
      zone(normal zone) to reduce the overhead of multiple zones.
      
      The change also fixes a build error when CONFIG_NUMA=y and
      CONFIG_ZONE_DMA32=n.
      
      arch/arm64/mm/init.c:195:17: error: use of undeclared identifier 'ZONE_DMA32'
                      max_zone_pfns[ZONE_DMA32] = PFN_DOWN(max_zone_dma_phys());
      
      Change since v1:
      1. only expose CONFIG_ZONE_DMA32 when CONFIG_EXPERT=y
      2. remove redundant IS_ENABLED(CONFIG_ZONE_DMA32)
      
      Cc: Robin Murphy <robin.murphy@arm.com>
      Signed-off-by: NMiles Chen <miles.chen@mediatek.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fb83987c
    • A
      cpupower : frequency-set -r option misses the last cpu in related cpu list · c360eb59
      Abhishek Goel 提交于
      [ Upstream commit 04507c0a9385cc8280f794a36bfff567c8cc1042 ]
      
      To set frequency on specific cpus using cpupower, following syntax can
      be used :
      cpupower -c #i frequency-set -f #f -r
      
      While setting frequency using cpupower frequency-set command, if we use
      '-r' option, it is expected to set frequency for all cpus related to
      cpu #i. But it is observed to be missing the last cpu in related cpu
      list. This patch fixes the problem.
      Signed-off-by: NAbhishek Goel <huntbag@linux.vnet.ibm.com>
      Reviewed-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c360eb59
    • W
      net: hns3: set ops to null when unregister ad_dev · cac30320
      Weihang Li 提交于
      [ Upstream commit 594a81b39525f0a17e92c2e0b167ae1400650380 ]
      
      The hclge/hclgevf and hns3 module can be unloaded independently,
      when hclge/hclgevf unloaded firstly, the ops of ae_dev should
      be set to NULL, otherwise it will cause an use-after-free problem.
      
      Fixes: 38caee9d ("net: hns3: Add support of the HNAE3 framework")
      Signed-off-by: NWeihang Li <liweihang@hisilicon.com>
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      cac30320
    • K
      media: wl128x: Fix some error handling in fm_v4l2_init_video_device() · 35407917
      Kefeng Wang 提交于
      [ Upstream commit 69fbb3f47327d959830c94bf31893972b8c8f700 ]
      
      X-Originating-IP: [10.175.113.25]
      X-CFilter-Loop: Reflected
      The fm_v4l2_init_video_device() forget to unregister v4l2/video device
      in the error path, it could lead to UAF issue, eg,
      
        BUG: KASAN: use-after-free in atomic64_read include/asm-generic/atomic-instrumented.h:836 [inline]
        BUG: KASAN: use-after-free in atomic_long_read include/asm-generic/atomic-long.h:28 [inline]
        BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0x92/0x690 kernel/locking/mutex.c:1206
        Read of size 8 at addr ffff8881e84a7c70 by task v4l_id/3659
      
        CPU: 1 PID: 3659 Comm: v4l_id Not tainted 5.1.0 #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0xa9/0x10e lib/dump_stack.c:113
         print_address_description+0x65/0x270 mm/kasan/report.c:187
         kasan_report+0x149/0x18d mm/kasan/report.c:317
         atomic64_read include/asm-generic/atomic-instrumented.h:836 [inline]
         atomic_long_read include/asm-generic/atomic-long.h:28 [inline]
         __mutex_unlock_slowpath+0x92/0x690 kernel/locking/mutex.c:1206
         fm_v4l2_fops_open+0xac/0x120 [fm_drv]
         v4l2_open+0x191/0x390 [videodev]
         chrdev_open+0x20d/0x570 fs/char_dev.c:417
         do_dentry_open+0x700/0xf30 fs/open.c:777
         do_last fs/namei.c:3416 [inline]
         path_openat+0x7c4/0x2a90 fs/namei.c:3532
         do_filp_open+0x1a5/0x2b0 fs/namei.c:3563
         do_sys_open+0x302/0x490 fs/open.c:1069
         do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x7f8180c17c8e
        ...
        Allocated by task 3642:
         set_track mm/kasan/common.c:87 [inline]
         __kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497
         fm_drv_init+0x13/0x1000 [fm_drv]
         do_one_initcall+0xbc/0x47d init/main.c:901
         do_init_module+0x1b5/0x547 kernel/module.c:3456
         load_module+0x6405/0x8c10 kernel/module.c:3804
         __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
         do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
        Freed by task 3642:
         set_track mm/kasan/common.c:87 [inline]
         __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459
         slab_free_hook mm/slub.c:1429 [inline]
         slab_free_freelist_hook mm/slub.c:1456 [inline]
         slab_free mm/slub.c:3003 [inline]
         kfree+0xe1/0x270 mm/slub.c:3958
         fm_drv_init+0x1e6/0x1000 [fm_drv]
         do_one_initcall+0xbc/0x47d init/main.c:901
         do_init_module+0x1b5/0x547 kernel/module.c:3456
         load_module+0x6405/0x8c10 kernel/module.c:3804
         __do_sys_finit_module+0x162/0x190 kernel/module.c:3898
         do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Add relevant unregister functions to fix it.
      
      Cc: Hans Verkuil <hans.verkuil@cisco.com>
      Reported-by: NHulk Robot <hulkci@huawei.com>
      Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      35407917