1. 06 4月, 2019 26 次提交
    • D
      mm, swap: bounds check swap_info array accesses to avoid NULL derefs · ed3345a6
      Daniel Jordan 提交于
      [ Upstream commit c10d38cc8d3e43f946b6c2bf4602c86791587f30 ]
      
      Dan Carpenter reports a potential NULL dereference in
      get_swap_page_of_type:
      
        Smatch complains that the NULL checks on "si" aren't consistent.  This
        seems like a real bug because we have not ensured that the type is
        valid and so "si" can be NULL.
      
      Add the missing check for NULL, taking care to use a read barrier to
      ensure CPU1 observes CPU0's updates in the correct order:
      
           CPU0                           CPU1
           alloc_swap_info()              if (type >= nr_swapfiles)
             swap_info[type] = p              /* handle invalid entry */
             smp_wmb()                    smp_rmb()
             ++nr_swapfiles               p = swap_info[type]
      
      Without smp_rmb, CPU1 might observe CPU0's write to nr_swapfiles before
      CPU0's write to swap_info[type] and read NULL from swap_info[type].
      
      Ying Huang noticed other places in swapfile.c don't order these reads
      properly.  Introduce swap_type_to_swap_info to encourage correct usage.
      
      Use READ_ONCE and WRITE_ONCE to follow the Linux Kernel Memory Model
      (see tools/memory-model/Documentation/explanation.txt).
      
      This ordering need not be enforced in places where swap_lock is held
      (e.g.  si_swapinfo) because swap_lock serializes updates to nr_swapfiles
      and the swap_info array.
      
      Link: http://lkml.kernel.org/r/20190131024410.29859-1-daniel.m.jordan@oracle.com
      Fixes: ec8acf20 ("swap: add per-partition lock for swapfile")
      Signed-off-by: NDaniel Jordan <daniel.m.jordan@oracle.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Suggested-by: N"Huang, Ying" <ying.huang@intel.com>
      Reviewed-by: NAndrea Parri <andrea.parri@amarulasolutions.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Omar Sandoval <osandov@fb.com>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Shaohua Li <shli@kernel.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ed3345a6
    • Q
      mm/page_ext.c: fix an imbalance with kmemleak · 4c6d7dc7
      Qian Cai 提交于
      [ Upstream commit 0c81585499601acd1d0e1cbf424cabfaee60628c ]
      
      After offlining a memory block, kmemleak scan will trigger a crash, as
      it encounters a page ext address that has already been freed during
      memory offlining.  At the beginning in alloc_page_ext(), it calls
      kmemleak_alloc(), but it does not call kmemleak_free() in
      free_page_ext().
      
          BUG: unable to handle kernel paging request at ffff888453d00000
          PGD 128a01067 P4D 128a01067 PUD 128a04067 PMD 47e09e067 PTE 800ffffbac2ff060
          Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
          CPU: 1 PID: 1594 Comm: bash Not tainted 5.0.0-rc8+ #15
          Hardware name: HP ProLiant DL180 Gen9/ProLiant DL180 Gen9, BIOS U20 10/25/2017
          RIP: 0010:scan_block+0xb5/0x290
          Code: 85 6e 01 00 00 48 b8 00 00 30 f5 81 88 ff ff 48 39 c3 0f 84 5b 01 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 0f 85 87 01 00 00 <4c> 8b 3b e8 f3 0c fa ff 4c 39 3d 0c 6b 4c 01 0f 87 08 01 00 00 4c
          RSP: 0018:ffff8881ec57f8e0 EFLAGS: 00010082
          RAX: 0000000000000000 RBX: ffff888453d00000 RCX: ffffffffa61e5a54
          RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff888453d00000
          RBP: ffff8881ec57f920 R08: fffffbfff4ed588d R09: fffffbfff4ed588c
          R10: fffffbfff4ed588c R11: ffffffffa76ac463 R12: dffffc0000000000
          R13: ffff888453d00ff9 R14: ffff8881f80cef48 R15: ffff8881f80cef48
          FS:  00007f6c0e3f8740(0000) GS:ffff8881f7680000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: ffff888453d00000 CR3: 00000001c4244003 CR4: 00000000001606a0
          Call Trace:
           scan_gray_list+0x269/0x430
           kmemleak_scan+0x5a8/0x10f0
           kmemleak_write+0x541/0x6ca
           full_proxy_write+0xf8/0x190
           __vfs_write+0xeb/0x980
           vfs_write+0x15a/0x4f0
           ksys_write+0xd2/0x1b0
           __x64_sys_write+0x73/0xb0
           do_syscall_64+0xeb/0xaaa
           entry_SYSCALL_64_after_hwframe+0x44/0xa9
          RIP: 0033:0x7f6c0dad73b8
          Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 65 63 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
          RSP: 002b:00007ffd5b863cb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
          RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007f6c0dad73b8
          RDX: 0000000000000005 RSI: 000055a9216e1710 RDI: 0000000000000001
          RBP: 000055a9216e1710 R08: 000000000000000a R09: 00007ffd5b863840
          R10: 000000000000000a R11: 0000000000000246 R12: 00007f6c0dda9780
          R13: 0000000000000005 R14: 00007f6c0dda4740 R15: 0000000000000005
          Modules linked in: nls_iso8859_1 nls_cp437 vfat fat kvm_intel kvm irqbypass efivars ip_tables x_tables xfs sd_mod ahci libahci igb i2c_algo_bit libata i2c_core dm_mirror dm_region_hash dm_log dm_mod efivarfs
          CR2: ffff888453d00000
          ---[ end trace ccf646c7456717c5 ]---
          Kernel panic - not syncing: Fatal exception
          Shutting down cpus with NMI
          Kernel Offset: 0x24c00000 from 0xffffffff81000000 (relocation range:
          0xffffffff80000000-0xffffffffbfffffff)
          ---[ end Kernel panic - not syncing: Fatal exception ]---
      
      Link: http://lkml.kernel.org/r/20190227173147.75650-1-cai@lca.pwSigned-off-by: NQian Cai <cai@lca.pw>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c6d7dc7
    • P
      mm/cma.c: cma_declare_contiguous: correct err handling · f555b008
      Peng Fan 提交于
      [ Upstream commit 0d3bd18a5efd66097ef58622b898d3139790aa9d ]
      
      In case cma_init_reserved_mem failed, need to free the memblock
      allocated by memblock_reserve or memblock_alloc_range.
      
      Quote Catalin's comments:
        https://lkml.org/lkml/2019/2/26/482
      
      Kmemleak is supposed to work with the memblock_{alloc,free} pair and it
      ignores the memblock_reserve() as a memblock_alloc() implementation
      detail. It is, however, tolerant to memblock_free() being called on
      a sub-range or just a different range from a previous memblock_alloc().
      So the original patch looks fine to me. FWIW:
      
      Link: http://lkml.kernel.org/r/20190227144631.16708-1-peng.fan@nxp.comSigned-off-by: NPeng Fan <peng.fan@nxp.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NMike Rapoport <rppt@linux.ibm.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f555b008
    • Q
      mm/sparse: fix a bad comparison · 7b287c47
      Qian Cai 提交于
      [ Upstream commit d778015ac95bc036af73342c878ab19250e01fe1 ]
      
      next_present_section_nr() could only return an unsigned number -1, so
      just check it specifically where compilers will convert -1 to unsigned
      if needed.
      
        mm/sparse.c: In function 'sparse_init_nid':
        mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
               ((section_nr >= 0) &&    \
                            ^~
        mm/sparse.c:478:2: note: in expansion of macro
        'for_each_present_section_nr'
          for_each_present_section_nr(pnum_begin, pnum) {
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
        mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
               ((section_nr >= 0) &&    \
                            ^~
        mm/sparse.c:497:2: note: in expansion of macro
        'for_each_present_section_nr'
          for_each_present_section_nr(pnum_begin, pnum) {
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
        mm/sparse.c: In function 'sparse_init':
        mm/sparse.c:200:20: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
               ((section_nr >= 0) &&    \
                            ^~
        mm/sparse.c:520:2: note: in expansion of macro
        'for_each_present_section_nr'
          for_each_present_section_nr(pnum_begin + 1, pnum_end) {
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Link: http://lkml.kernel.org/r/20190228181839.86504-1-cai@lca.pw
      Fixes: c4e1be9e ("mm, sparsemem: break out of loops early")
      Signed-off-by: NQian Cai <cai@lca.pw>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7b287c47
    • J
      perf c2c: Fix c2c report for empty numa node · aea8c971
      Jiri Olsa 提交于
      [ Upstream commit e34c940245437f36d2c492edd1f8237eff391064 ]
      
      Ravi Bangoria reported that we fail with an empty NUMA node with the
      following message:
      
        $ lscpu
        NUMA node0 CPU(s):
        NUMA node1 CPU(s):   0-4
      
        $ sudo ./perf c2c report
        node/cpu topology bugFailed setup nodes
      
      Fix this by detecting the empty node and keeping its CPU set empty.
      Reported-by: NNageswara R Sastry <nasastry@in.ibm.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jonas Rabenstein <jonas.rabenstein@studium.uni-erlangen.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190305152536.21035-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      aea8c971
    • K
      x86/hyperv: Fix kernel panic when kexec on HyperV · c3f28d59
      Kairui Song 提交于
      [ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]
      
      After commit 68bb7bfb ("X86/Hyper-V: Enable IPI enlightenments"),
      kexec fails with a kernel panic:
      
      kexec_core: Starting new kernel
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v3.0 03/02/2018
      RIP: 0010:0xffffc9000001d000
      
      Call Trace:
       ? __send_ipi_mask+0x1c6/0x2d0
       ? hv_send_ipi_mask_allbutself+0x6d/0xb0
       ? mp_save_irq+0x70/0x70
       ? __ioapic_read_entry+0x32/0x50
       ? ioapic_read_entry+0x39/0x50
       ? clear_IO_APIC_pin+0xb8/0x110
       ? native_stop_other_cpus+0x6e/0x170
       ? native_machine_shutdown+0x22/0x40
       ? kernel_kexec+0x136/0x156
      
      That happens if hypercall based IPIs are used because the hypercall page is
      reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
      which invokes the hypercall and dereferences the unusable page.
      
      To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
      any misuse, IPI sending will fall back to the non hypercall based
      method. This only happens on kexec / kdump so just setting the pointer to
      NULL is good enough.
      
      Fixes: 68bb7bfb ("X86/Hyper-V: Enable IPI enlightenments")
      Signed-off-by: NKairui Song <kasong@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Sasha Levin <sashal@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: devel@linuxdriverproject.org
      Link: https://lkml.kernel.org/r/20190306111827.14131-1-kasong@redhat.comSigned-off-by: NSasha Levin <sashal@kernel.org>
      c3f28d59
    • L
      iio: adc: fix warning in Qualcomm PM8xxx HK/XOADC driver · 3e8d6221
      Linus Torvalds 提交于
      [ Upstream commit e0f0ae838a25464179d37f355d763f9ec139fc15 ]
      
      The pm8xxx_get_channel() implementation is unclear, and causes gcc to
      suddenly generate odd warnings.  The trigger for the warning (at least
      for me) was the entirely unrelated commit 79a4e91d1bb2 ("device.h: Add
      __cold to dev_<level> logging functions"), which apparently changes gcc
      code generation in the caller function enough to cause this:
      
        drivers/iio/adc/qcom-pm8xxx-xoadc.c: In function ‘pm8xxx_xoadc_probe’:
        drivers/iio/adc/qcom-pm8xxx-xoadc.c:633:8: warning: ‘ch’ may be used uninitialized in this function [-Wmaybe-uninitialized]
          ret = pm8xxx_read_channel_rsv(adc, ch, AMUX_RSV4,
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                   &read_nomux_rsv4, true);
                   ~~~~~~~~~~~~~~~~~~~~~~~
        drivers/iio/adc/qcom-pm8xxx-xoadc.c:426:27: note: ‘ch’ was declared here
          struct pm8xxx_chan_info *ch;
                                   ^~
      
      because gcc for some reason then isn't able to see that the termination
      condition for the "for( )" loop in that function is also the condition
      for returning NULL.
      
      So it's not _actually_ uninitialized, but the function is admittedly
      just unnecessarily oddly written.
      
      Simplify and clarify the function, making gcc also see that it always
      returns a valid initialized value.
      
      Cc: Joe Perches <joe@perches.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Andy Gross <andy.gross@linaro.org>
      Cc: David Brown <david.brown@linaro.org>
      Cc: Jonathan Cameron <jic23@kernel.org>
      Cc: Hartmut Knaack <knaack.h@gmx.de>
      Cc: Lars-Peter Clausen <lars@metafoo.de>
      Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3e8d6221
    • X
      scsi: hisi_sas: Fix a timeout race of driver internal and SMP IO · e27cced3
      Xiang Chen 提交于
      [ Upstream commit 4790595723d4b833b18c994973d39f9efb842887 ]
      
      For internal IO and SMP IO, there is a time-out timer for them. In the
      timer handler, it checks whether IO is done according to the flag
      task->task_state_lock.
      
      There is an issue which may cause system suspended: internal IO or SMP IO
      is sent, but at that time because of hardware exception (such as inject
      2Bit ECC error), so IO is not completed and also not timeout. But, at that
      time, the SAS controller reset occurs to recover system. It will release
      the resource and set the status of IO to be SAS_TASK_STATE_DONE, so when IO
      timeout, it will never complete the completion of IO and wait for ever.
      
      [  729.123632] Call trace:
      [  729.126791] [<ffff00000808655c>] __switch_to+0x94/0xa8
      [  729.133106] [<ffff000008d96e98>] __schedule+0x1e8/0x7fc
      [  729.138975] [<ffff000008d974e0>] schedule+0x34/0x8c
      [  729.144401] [<ffff000008d9b000>] schedule_timeout+0x1d8/0x3cc
      [  729.150690] [<ffff000008d98218>] wait_for_common+0xdc/0x1a0
      [  729.157101] [<ffff000008d98304>] wait_for_completion+0x28/0x34
      [  729.165973] [<ffff000000dcefb4>] hisi_sas_internal_task_abort+0x2a0/0x424 [hisi_sas_test_main]
      [  729.176447] [<ffff000000dd18f4>] hisi_sas_abort_task+0x244/0x2d8 [hisi_sas_test_main]
      [  729.185258] [<ffff000008971714>] sas_eh_handle_sas_errors+0x1c8/0x7b8
      [  729.192391] [<ffff000008972774>] sas_scsi_recover_host+0x130/0x398
      [  729.199237] [<ffff00000894d8a8>] scsi_error_handler+0x148/0x5c0
      [  729.206009] [<ffff0000080f4118>] kthread+0x10c/0x138
      [  729.211563] [<ffff0000080855dc>] ret_from_fork+0x10/0x18
      
      To solve the issue, callback function task_done of those IOs need to be
      called when on SAS controller reset.
      Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e27cced3
    • J
      scsi: hisi_sas: Set PHY linkrate when disconnected · fce6aeaf
      John Garry 提交于
      [ Upstream commit efdcad62e7b8a02fcccc5ccca57806dce1482ac8 ]
      
      When the PHY comes down, we currently do not set the negotiated linkrate:
      
      root@(none)$ pwd
      /sys/class/sas_phy/phy-0:0
      root@(none)$ more enable
      1
      root@(none)$ more negotiated_linkrate
      12.0 Gbit
      root@(none)$ echo 0 > enable
      root@(none)$ more negotiated_linkrate
      12.0 Gbit
      root@(none)$
      
      This patch fixes the driver code to set it properly when the PHY comes
      down.
      
      If the PHY had been enabled, then set unknown; otherwise, flag as disabled.
      
      The logical place to set the negotiated linkrate for this scenario is PHY
      down routine, which is called from the PHY down ISR.
      
      However, it is not possible to know if the PHY comes down due to PHY
      disable or loss of link, as sas_phy.enabled member is not set until after
      the transport disable routine is complete, which races with the PHY down
      ISR.
      
      As an imperfect solution, use sas_phy_data.enable as the flag to know if
      the PHY is down due to disable. It's imperfect, as sas_phy_data is internal
      to libsas.
      
      I can't see another way without adding a new field to hisi_sas_phy and
      managing it, or changing SCSI SAS transport.
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      fce6aeaf
    • S
      libbpf: force fixdep compilation at the start of the build · e21f655c
      Stanislav Fomichev 提交于
      [ Upstream commit 8e2688876c7f7073d925e1f150e86b8ed3338f52 ]
      
      libbpf targets don't explicitly depend on fixdep target, so when
      we do 'make -j$(nproc)', there is a high probability, that some
      objects will be built before fixdep binary is available.
      
      Fix this by running sub-make; this makes sure that fixdep dependency
      is properly accounted for.
      
      For the same issue in perf, see commit abb26210 ("perf tools: Force
      fixdep compilation at the start of the build").
      
      Before:
      
      $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/
      
      Auto-detecting system features:
      ...                        libelf: [ on  ]
      ...                           bpf: [ on  ]
      
        HOSTCC   /tmp/bld/fixdep.o
        CC       /tmp/bld/libbpf.o
        CC       /tmp/bld/bpf.o
        CC       /tmp/bld/btf.o
        CC       /tmp/bld/nlattr.o
        CC       /tmp/bld/libbpf_errno.o
        CC       /tmp/bld/str_error.o
        CC       /tmp/bld/netlink.o
        CC       /tmp/bld/bpf_prog_linfo.o
        CC       /tmp/bld/libbpf_probes.o
        CC       /tmp/bld/xsk.o
        HOSTLD   /tmp/bld/fixdep-in.o
        LINK     /tmp/bld/fixdep
        LD       /tmp/bld/libbpf-in.o
        LINK     /tmp/bld/libbpf.a
        LINK     /tmp/bld/libbpf.so
        LINK     /tmp/bld/test_libbpf
      
      $ head /tmp/bld/.libbpf.o.cmd
       # cannot find fixdep (/usr/local/google/home/sdf/src/linux/xxx//fixdep)
       # using basic dep data
      
      /tmp/bld/libbpf.o: libbpf.c /usr/include/stdc-predef.h \
       /usr/include/stdlib.h /usr/include/features.h \
       /usr/include/x86_64-linux-gnu/sys/cdefs.h \
       /usr/include/x86_64-linux-gnu/bits/wordsize.h \
       /usr/include/x86_64-linux-gnu/gnu/stubs.h \
       /usr/include/x86_64-linux-gnu/gnu/stubs-64.h \
       /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h \
      
      After:
      
      $ rm -rf /tmp/bld; mkdir /tmp/bld; make -j$(nproc) O=/tmp/bld -C tools/lib/bpf/
      
      Auto-detecting system features:
      ...                        libelf: [ on  ]
      ...                           bpf: [ on  ]
      
        HOSTCC   /tmp/bld/fixdep.o
        HOSTLD   /tmp/bld/fixdep-in.o
        LINK     /tmp/bld/fixdep
        CC       /tmp/bld/libbpf.o
        CC       /tmp/bld/bpf.o
        CC       /tmp/bld/nlattr.o
        CC       /tmp/bld/btf.o
        CC       /tmp/bld/libbpf_errno.o
        CC       /tmp/bld/str_error.o
        CC       /tmp/bld/netlink.o
        CC       /tmp/bld/bpf_prog_linfo.o
        CC       /tmp/bld/libbpf_probes.o
        CC       /tmp/bld/xsk.o
        LD       /tmp/bld/libbpf-in.o
        LINK     /tmp/bld/libbpf.a
        LINK     /tmp/bld/libbpf.so
        LINK     /tmp/bld/test_libbpf
      
      $ head /tmp/bld/.libbpf.o.cmd
      cmd_/tmp/bld/libbpf.o := gcc -Wp,-MD,/tmp/bld/.libbpf.o.d -Wp,-MT,/tmp/bld/libbpf.o -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Werror -Wall -fPIC -I. -I/usr/local/google/home/sdf/src/linux/tools/include -I/usr/local/google/home/sdf/src/linux/tools/arch/x86/include/uapi -I/usr/local/google/home/sdf/src/linux/tools/include/uapi -fvisibility=hidden -D"BUILD_STR(s)=$(pound)s" -c -o /tmp/bld/libbpf.o libbpf.c
      
      source_/tmp/bld/libbpf.o := libbpf.c
      
      deps_/tmp/bld/libbpf.o := \
        /usr/include/stdc-predef.h \
        /usr/include/stdlib.h \
        /usr/include/features.h \
        /usr/include/x86_64-linux-gnu/sys/cdefs.h \
        /usr/include/x86_64-linux-gnu/bits/wordsize.h \
      
      Fixes: 7c422f55 ("tools build: Build fixdep helper from perf and basic libs")
      Reported-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e21f655c
    • A
      enic: fix build warning without CONFIG_CPUMASK_OFFSTACK · 60483306
      Arnd Bergmann 提交于
      [ Upstream commit 43d281662fdb46750d49417559b71069f435298d ]
      
      The enic driver relies on the CONFIG_CPUMASK_OFFSTACK feature to
      dynamically allocate a struct member, but this is normally intended for
      local variables.
      
      Building with clang, I get a warning for a few locations that check the
      address of the cpumask_var_t:
      
      drivers/net/ethernet/cisco/enic/enic_main.c:122:22: error: address of array 'enic->msix[i].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
      
      As far as I can tell, the code is still correct, as the truth value of
      the pointer is what we need in this configuration. To get rid of
      the warning, use cpumask_available() instead of checking the
      pointer directly.
      
      Fixes: 322cf7e3 ("enic: assign affinity hint to interrupts")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      60483306
    • N
      net: stmmac: Avoid sometimes uninitialized Clang warnings · 9ec4860d
      Nathan Chancellor 提交于
      [ Upstream commit df103170854e87124ee7bdd2bca64b178e653f97 ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:495:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:532:3: warning: variable 'ns' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:741:3: warning: variable 'sec_inc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
      
      Clang is concerned with the use of stmmac_do_void_callback (which
      stmmac_get_timestamp and stmmac_config_sub_second_increment wrap),
      as it may fail to initialize these values if the if condition was ever
      false (meaning the callbacks don't exist). It's not wrong because the
      callbacks (get_timestamp and config_sub_second_increment respectively)
      are the ones that initialize the variables. While it's unlikely that the
      callbacks are ever going to disappear and make that condition false, we
      can easily avoid this warning by zero initialize the variables.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/384Suggested-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9ec4860d
    • C
      sysctl: handle overflow for file-max · b227f157
      Christian Brauner 提交于
      [ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]
      
      Currently, when writing
      
        echo 18446744073709551616 > /proc/sys/fs/file-max
      
      /proc/sys/fs/file-max will overflow and be set to 0.  That quickly
      crashes the system.
      
      This commit sets the max and min value for file-max.  The max value is
      set to long int.  Any higher value cannot currently be used as the
      percpu counters are long ints and not unsigned integers.
      
      Note that the file-max value is ultimately parsed via
      __do_proc_doulongvec_minmax().  This function does not report error when
      min or max are exceeded.  Which means if a value largen that long int is
      written userspace will not receive an error instead the old value will be
      kept.  There is an argument to be made that this should be changed and
      __do_proc_doulongvec_minmax() should return an error when a dedicated min
      or max value are exceeded.  However this has the potential to break
      userspace so let's defer this to an RFC patch.
      
      Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.ioSigned-off-by: NChristian Brauner <christian@brauner.io>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Luis Chamberlain <mcgrof@kernel.org>
      Cc: Waiman Long <longman@redhat.com>
      [christian@brauner.io: v4]
        Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.ioSigned-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b227f157
    • L
      include/linux/relay.h: fix percpu annotation in struct rchan · d6ad08aa
      Luc Van Oostenryck 提交于
      [ Upstream commit 62461ac2e5b6520b6d65fc6d7d7b4b8df4b848d8 ]
      
      The percpu member of this structure is declared as:
      	struct ... ** __percpu member;
      So its type is:
      	__percpu pointer to pointer to struct ...
      
      But looking at how it's used, its type should be:
      	pointer to __percpu pointer to struct ...
      and it should thus be declared as:
      	struct ... * __percpu *member;
      
      So fix the placement of '__percpu' in the definition of this
      structures.
      
      This silents a few Sparse's warnings like:
      	warning: incorrect type in initializer (different address spaces)
      	  expected void const [noderef] <asn:3> *__vpp_verify
      	  got struct sched_domain **
      
      Link: http://lkml.kernel.org/r/20190118144902.79065-1-luc.vanoostenryck@gmail.com
      Fixes: 017c59c0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
      Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Cc: Jens Axboe <axboe@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d6ad08aa
    • R
      gpio: gpio-omap: fix level interrupt idling · 4c96500e
      Russell King 提交于
      [ Upstream commit d01849f7deba81f4959fd9e51bf20dbf46987d1c ]
      
      Tony notes that the GPIO module does not idle when level interrupts are
      in use, as the wakeup appears to get stuck.
      
      After extensive investigation, it appears that the wakeup will only be
      cleared if the interrupt status register is cleared while the interrupt
      is enabled. However, we are currently clearing it with the interrupt
      disabled for level-based interrupts.
      
      It is acknowledged that this observed behaviour conflicts with a
      statement in the TRM:
      
      CAUTION
        After servicing the interrupt, the status bit in the interrupt status
        register (GPIOi.GPIO_IRQSTATUS_0 or GPIOi.GPIO_IRQSTATUS_1) must be
        reset and the interrupt line released (by setting the corresponding
        bit of the interrupt status register to 1) before enabling an
        interrupt for the GPIO channel in the interrupt-enable register
        (GPIOi.GPIO_IRQSTATUS_SET_0 or GPIOi.GPIO_IRQSTATUS_SET_1) to prevent
        the occurrence of unexpected interrupts when enabling an interrupt
        for the GPIO channel.
      
      However, this does not appear to be a practical problem.
      
      Further, as reported by Grygorii Strashko <grygorii.strashko@ti.com>,
      the TI Android kernel tree has an earlier similar patch as "GPIO: OMAP:
      Fix the sequence to clear the IRQ status" saying:
      
       if the status is cleared after disabling the IRQ then sWAKEUP will not
       be cleared and gates the module transition
      
      When we unmask the level interrupt after the interrupt has been handled,
      enable the interrupt and only then clear the interrupt. If the interrupt
      is still pending, the hardware will re-assert the interrupt status.
      
      Should the caution note in the TRM prove to be a problem, we could
      use a clear-enable-clear sequence instead.
      
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      [tony@atomide.com: updated comments based on an earlier TI patch]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Acked-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c96500e
    • T
      net/mlx5: Avoid panic when setting vport mac, getting vport config · 8c50ab86
      Tonghao Zhang 提交于
      [ Upstream commit 6e77c413e8e73d0f36b5358b601389d75ec4451c ]
      
      If we try to set VFs mac address on a VF (not PF) net device,
      the kernel will be crash. The commands are show as below:
      
      $ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs
      $ ip link set $MLX_VF0 vf 0 mac 00:11:22:33:44:00
      
      [exception RIP: mlx5_eswitch_set_vport_mac+41]
      [ffffb8b7079e3688] do_setlink at ffffffff8f67f85b
      [ffffb8b7079e37a8] __rtnl_newlink at ffffffff8f683778
      [ffffb8b7079e3b68] rtnl_newlink at ffffffff8f683a63
      [ffffb8b7079e3b90] rtnetlink_rcv_msg at ffffffff8f67d812
      [ffffb8b7079e3c10] netlink_rcv_skb at ffffffff8f6b88ab
      [ffffb8b7079e3c60] netlink_unicast at ffffffff8f6b808f
      [ffffb8b7079e3ca0] netlink_sendmsg at ffffffff8f6b8412
      [ffffb8b7079e3d18] sock_sendmsg at ffffffff8f6452f6
      [ffffb8b7079e3d30] ___sys_sendmsg at ffffffff8f645860
      [ffffb8b7079e3eb0] __sys_sendmsg at ffffffff8f647a38
      [ffffb8b7079e3f38] do_syscall_64 at ffffffff8f00401b
      [ffffb8b7079e3f50] entry_SYSCALL_64_after_hwframe at ffffffff8f80008c
      
      and
      
      [exception RIP: mlx5_eswitch_get_vport_config+12]
      [ffffa70607e57678] mlx5e_get_vf_config at ffffffffc03c7f8f [mlx5_core]
      [ffffa70607e57688] do_setlink at ffffffffbc67fa59
      [ffffa70607e577a8] __rtnl_newlink at ffffffffbc683778
      [ffffa70607e57b68] rtnl_newlink at ffffffffbc683a63
      [ffffa70607e57b90] rtnetlink_rcv_msg at ffffffffbc67d812
      [ffffa70607e57c10] netlink_rcv_skb at ffffffffbc6b88ab
      [ffffa70607e57c60] netlink_unicast at ffffffffbc6b808f
      [ffffa70607e57ca0] netlink_sendmsg at ffffffffbc6b8412
      [ffffa70607e57d18] sock_sendmsg at ffffffffbc6452f6
      [ffffa70607e57d30] ___sys_sendmsg at ffffffffbc645860
      [ffffa70607e57eb0] __sys_sendmsg at ffffffffbc647a38
      [ffffa70607e57f38] do_syscall_64 at ffffffffbc00401b
      [ffffa70607e57f50] entry_SYSCALL_64_after_hwframe at ffffffffbc80008c
      
      Fixes: a8d70a05 ("net/mlx5: E-Switch, Disallow vlan/spoofcheck setup if not being esw manager")
      Cc: Eli Cohen <eli@mellanox.com>
      Signed-off-by: NTonghao Zhang <xiangxia.m.yue@gmail.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Acked-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8c50ab86
    • T
      net/mlx5: Avoid panic when setting vport rate · 3bddc614
      Tonghao Zhang 提交于
      [ Upstream commit 24319258660a84dd77f4be026a55b10a12524919 ]
      
      If we try to set VFs rate on a VF (not PF) net device, the kernel
      will be crash. The commands are show as below:
      
      $ echo 2 > /sys/class/net/$MLX_PF0/device/sriov_numvfs
      $ ip link set $MLX_VF0 vf 0 max_tx_rate 2 min_tx_rate 1
      
      If not applied the first patch ("net/mlx5: Avoid panic when setting
      vport mac, getting vport config"), the command:
      
      $ ip link set $MLX_VF0 vf 0 rate 100
      
      can also crash the kernel.
      
      [ 1650.006388] RIP: 0010:mlx5_eswitch_set_vport_rate+0x1f/0x260 [mlx5_core]
      [ 1650.007092]  do_setlink+0x982/0xd20
      [ 1650.007129]  __rtnl_newlink+0x528/0x7d0
      [ 1650.007374]  rtnl_newlink+0x43/0x60
      [ 1650.007407]  rtnetlink_rcv_msg+0x2a2/0x320
      [ 1650.007484]  netlink_rcv_skb+0xcb/0x100
      [ 1650.007519]  netlink_unicast+0x17f/0x230
      [ 1650.007554]  netlink_sendmsg+0x2d2/0x3d0
      [ 1650.007592]  sock_sendmsg+0x36/0x50
      [ 1650.007625]  ___sys_sendmsg+0x280/0x2a0
      [ 1650.007963]  __sys_sendmsg+0x58/0xa0
      [ 1650.007998]  do_syscall_64+0x5b/0x180
      [ 1650.009438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: c9497c98 ("net/mlx5: Add support for setting VF min rate")
      Cc: Mohamad Haj Yahia <mohamad@mellanox.com>
      Signed-off-by: NTonghao Zhang <xiangxia.m.yue@gmail.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Acked-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3bddc614
    • D
      tracing: kdb: Fix ftdump to not sleep · b73c7d02
      Douglas Anderson 提交于
      [ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ]
      
      As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
      BUG for "sleeping function called from invalid context".
      
      kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
      atomic context.  A very simple solution for this is to add allocation
      flags to ring_buffer_read_prepare() so kdb can call it without
      triggering the allocation error.  This patch does that.
      
      Note that in the original email thread about this, it was suggested
      that perhaps the solution for kdb was to either preallocate the buffer
      ahead of time or create our own iterator.  I'm hoping that this
      alternative of adding allocation flags to ring_buffer_read_prepare()
      can be considered since it means I don't need to duplicate more of the
      core trace code into "trace_kdb.c" (for either creating my own
      iterator or re-preparing a ring allocator whose memory was already
      allocated).
      
      NOTE: another option for kdb is to actually figure out how to make it
      reuse the existing ftrace_dump() function and totally eliminate the
      duplication.  This sounds very appealing and actually works (the "sr
      z" command can be seen to properly dump the ftrace buffer).  The
      downside here is that ftrace_dump() fully consumes the trace buffer.
      Unless that is changed I'd rather not use it because it means "ftdump
      | grep xyz" won't be very useful to search the ftrace buffer since it
      will throw away the whole trace on the first grep.  A future patch to
      dump only the last few lines of the buffer will also be hard to
      implement.
      
      [1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
      
      Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.orgReported-by: NBrian Norris <briannorris@chromium.org>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b73c7d02
    • C
      f2fs: fix to avoid deadlock in f2fs_read_inline_dir() · d7391962
      Chao Yu 提交于
      [ Upstream commit aadcef64b22f668c1a107b86d3521d9cac915c24 ]
      
      As Jiqun Li reported in bugzilla:
      
      https://bugzilla.kernel.org/show_bug.cgi?id=202883
      
      sometimes, dead lock when make system call SYS_getdents64 with fsync() is
      called by another process.
      
      monkey running on android9.0
      
      1.  task 9785 held sbi->cp_rwsem and waiting lock_page()
      2.  task 10349 held mm_sem and waiting sbi->cp_rwsem
      3. task 9709 held lock_page() and waiting mm_sem
      
      so this is a dead lock scenario.
      
      task stack is show by crash tools as following
      
      crash_arm64> bt ffffffc03c354080
      PID: 9785   TASK: ffffffc03c354080  CPU: 1   COMMAND: "RxIoScheduler-3"
      >> #7 [ffffffc01b50fac0] __lock_page at ffffff80081b11e8
      
      crash-arm64> bt 10349
      PID: 10349  TASK: ffffffc018b83080  CPU: 1   COMMAND: "BUGLY_ASYNC_UPL"
      >> #3 [ffffffc01f8cfa40] rwsem_down_read_failed at ffffff8008a93afc
           PC: 00000033  LR: 00000000  SP: 00000000  PSTATE: ffffffffffffffff
      
      crash-arm64> bt 9709
      PID: 9709   TASK: ffffffc03e7f3080  CPU: 1   COMMAND: "IntentService[A"
      >> #3 [ffffffc001e67850] rwsem_down_read_failed at ffffff8008a93afc
      >> #8 [ffffffc001e67b80] el1_ia at ffffff8008084fc4
           PC: ffffff8008274114  [compat_filldir64+120]
           LR: ffffff80083584d4  [f2fs_fill_dentries+448]
           SP: ffffffc001e67b80  PSTATE: 80400145
          X29: ffffffc001e67b80  X28: 0000000000000000  X27: 000000000000001a
          X26: 00000000000093d7  X25: ffffffc070d52480  X24: 0000000000000008
          X23: 0000000000000028  X22: 00000000d43dfd60  X21: ffffffc001e67e90
          X20: 0000000000000011  X19: ffffff80093a4000  X18: 0000000000000000
          X17: 0000000000000000  X16: 0000000000000000  X15: 0000000000000000
          X14: ffffffffffffffff  X13: 0000000000000008  X12: 0101010101010101
          X11: 7f7f7f7f7f7f7f7f  X10: 6a6a6a6a6a6a6a6a   X9: 7f7f7f7f7f7f7f7f
           X8: 0000000080808000   X7: ffffff800827409c   X6: 0000000080808000
           X5: 0000000000000008   X4: 00000000000093d7   X3: 000000000000001a
           X2: 0000000000000011   X1: ffffffc070d52480   X0: 0000000000800238
      >> #9 [ffffffc001e67be0] f2fs_fill_dentries at ffffff80083584d0
           PC: 0000003c  LR: 00000000  SP: 00000000  PSTATE: 000000d9
          X12: f48a02ff X11: d4678960 X10: d43dfc00  X9: d4678ae4
           X8: 00000058  X7: d4678994  X6: d43de800  X5: 000000d9
           X4: d43dfc0c  X3: d43dfc10  X2: d46799c8  X1: 00000000
           X0: 00001068
      
      Below potential deadlock will happen between three threads:
      Thread A		Thread B		Thread C
      - f2fs_do_sync_file
       - f2fs_write_checkpoint
        - down_write(&sbi->node_change) -- 1)
      			- do_page_fault
      			 - down_write(&mm->mmap_sem) -- 2)
      			  - do_wp_page
      			   - f2fs_vm_page_mkwrite
      						- getdents64
      						 - f2fs_read_inline_dir
      						  - lock_page -- 3)
        - f2fs_sync_node_pages
         - lock_page -- 3)
      			    - __do_map_lock
      			     - down_read(&sbi->node_change) -- 1)
      						  - f2fs_fill_dentries
      						   - dir_emit
      						    - compat_filldir64
      						     - do_page_fault
      						      - down_read(&mm->mmap_sem) -- 2)
      
      Since f2fs_readdir is protected by inode.i_rwsem, there should not be
      any updates in inode page, we're safe to lookup dents in inode page
      without its lock held, so taking off the lock to improve concurrency
      of readdir and avoid potential deadlock.
      Reported-by: NJiqun Li <jiqun.li@unisoc.com>
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d7391962
    • C
      f2fs: fix to adapt small inline xattr space in __find_inline_xattr() · 198c9985
      Chao Yu 提交于
      [ Upstream commit 2c28aba8b2e2a51749fa66e01b68e1cd5b53e022 ]
      
      With below testcase, we will fail to find existed xattr entry:
      
      1. mkfs.f2fs -O extra_attr -O flexible_inline_xattr /dev/zram0
      2. mount -t f2fs -o inline_xattr_size=1 /dev/zram0 /mnt/f2fs/
      3. touch /mnt/f2fs/file
      4. setfattr -n "user.name" -v 0 /mnt/f2fs/file
      5. getfattr -n "user.name" /mnt/f2fs/file
      
      /mnt/f2fs/file: user.name: No such attribute
      
      The reason is for inode which has very small inline xattr size,
      __find_inline_xattr() will fail to traverse any entry due to first
      entry may not be loaded from xattr node yet, later, we may skip to
      check entire xattr datas in __find_xattr(), result in such wrong
      condition.
      
      This patch adds condition to check such case to avoid this issue.
      Signed-off-by: NChao Yu <yuchao0@huawei.com>
      Signed-off-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      198c9985
    • M
      h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux- · 56bb66c5
      Masahiro Yamada 提交于
      [ Upstream commit fc2b47b55f17fd996f7a01975ce1c33c2f2513f6 ]
      
      It believe it is a bad idea to hardcode a specific compiler prefix
      that may or may not be installed on a user's system. It is annoying
      when testing features that should not require compilers at all.
      
      For example, mrproper, headers_install, etc. should work without
      any compiler.
      
      They look like follows on my machine.
      
      $ make ARCH=h8300 mrproper
      ./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
      ./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
      make: h8300-unknown-linux-gcc: Command not found
      make: h8300-unknown-linux-gcc: Command not found
        [ a bunch of the same error messages continue ]
      
      $ make ARCH=h8300 headers_install
      ./scripts/gcc-version.sh: line 26: h8300-unknown-linux-gcc: command not found
      ./scripts/gcc-version.sh: line 27: h8300-unknown-linux-gcc: command not found
      make: h8300-unknown-linux-gcc: Command not found
        HOSTCC  scripts/basic/fixdep
      make: h8300-unknown-linux-gcc: Command not found
        WRAP    arch/h8300/include/generated/uapi/asm/kvm_para.h
        [ snip ]
      
      The solution is to delete this line, or to use cc-cross-prefix like
      some architectures do. I chose the latter as a moderate fixup.
      
      I added an alternative 'h8300-linux-' because it is available at:
      
      https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      56bb66c5
    • A
      CIFS: fix POSIX lock leak and invalid ptr deref · 2938651d
      Aurelien Aptel 提交于
      [ Upstream commit bc31d0cdcfbadb6258b45db97e93b1c83822ba33 ]
      
      We have a customer reporting crashes in lock_get_status() with many
      "Leaked POSIX lock" messages preceeding the crash.
      
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x56 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       Leaked POSIX lock on dev=0x0:0x53 ...
       POSIX: fl_owner=ffff8900e7b79380 fl_flags=0x1 fl_type=0x1 fl_pid=20709
       Leaked POSIX lock on dev=0x0:0x4b ino...
       Leaked locks on dev=0x0:0x4b ino=0xf911400000029:
       POSIX: fl_owner=ffff89f41c870e00 fl_flags=0x1 fl_type=0x1 fl_pid=19592
       stack segment: 0000 [#1] SMP
       Modules linked in: binfmt_misc msr tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag rpcsec_gss_krb5 arc4 ecb auth_rpcgss nfsv4 md4 nfs nls_utf8 lockd grace cifs sunrpc ccm dns_resolver fscache af_packet iscsi_ibft iscsi_boot_sysfs vmw_vsock_vmci_transport vsock xfs libcrc32c sb_edac edac_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg ansi_cprng vmw_balloon aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev pcspkr vmxnet3 i2c_piix4 vmw_vmci shpchp fjes processor button ac btrfs xor raid6_pq sr_mod cdrom ata_generic sd_mod ata_piix vmwgfx crc32c_intel drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm serio_raw ahci libahci drm libata vmw_pvscsi sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
      
       Supported: Yes
       CPU: 6 PID: 28250 Comm: lsof Not tainted 4.4.156-94.64-default #1
       Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
       task: ffff88a345f28740 ti: ffff88c74005c000 task.ti: ffff88c74005c000
       RIP: 0010:[<ffffffff8125dcab>]  [<ffffffff8125dcab>] lock_get_status+0x9b/0x3b0
       RSP: 0018:ffff88c74005fd90  EFLAGS: 00010202
       RAX: ffff89bde83e20ae RBX: ffff89e870003d18 RCX: 0000000049534f50
       RDX: ffffffff81a3541f RSI: ffffffff81a3544e RDI: ffff89bde83e20ae
       RBP: 0026252423222120 R08: 0000000020584953 R09: 000000000000ffff
       R10: 0000000000000000 R11: ffff88c74005fc70 R12: ffff89e5ca7b1340
       R13: 00000000000050e5 R14: ffff89e870003d30 R15: ffff89e5ca7b1340
       FS:  00007fafd64be800(0000) GS:ffff89f41fd00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000001c80018 CR3: 000000a522048000 CR4: 0000000000360670
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Stack:
        0000000000000208 ffffffff81a3d6b6 ffff89e870003d30 ffff89e870003d18
        ffff89e5ca7b1340 ffff89f41738d7c0 ffff89e870003d30 ffff89e5ca7b1340
        ffffffff8125e08f 0000000000000000 ffff89bc22b67d00 ffff88c74005ff28
       Call Trace:
        [<ffffffff8125e08f>] locks_show+0x2f/0x70
        [<ffffffff81230ad1>] seq_read+0x251/0x3a0
        [<ffffffff81275bbc>] proc_reg_read+0x3c/0x70
        [<ffffffff8120e456>] __vfs_read+0x26/0x140
        [<ffffffff8120e9da>] vfs_read+0x7a/0x120
        [<ffffffff8120faf2>] SyS_read+0x42/0xa0
        [<ffffffff8161cbc3>] entry_SYSCALL_64_fastpath+0x1e/0xb7
      
      When Linux closes a FD (close(), close-on-exec, dup2(), ...) it calls
      filp_close() which also removes all posix locks.
      
      The lock struct is initialized like so in filp_close() and passed
      down to cifs
      
      	...
              lock.fl_type = F_UNLCK;
              lock.fl_flags = FL_POSIX | FL_CLOSE;
              lock.fl_start = 0;
              lock.fl_end = OFFSET_MAX;
      	...
      
      Note the FL_CLOSE flag, which hints the VFS code that this unlocking
      is done for closing the fd.
      
      filp_close()
        locks_remove_posix(filp, id);
          vfs_lock_file(filp, F_SETLK, &lock, NULL);
            return filp->f_op->lock(filp, cmd, fl) => cifs_lock()
              rc = cifs_setlk(file, flock, type, wait_flag, posix_lck, lock, unlock, xid);
                rc = server->ops->mand_unlock_range(cfile, flock, xid);
                if (flock->fl_flags & FL_POSIX && !rc)
                        rc = locks_lock_file_wait(file, flock)
      
      Notice how we don't call locks_lock_file_wait() which does the
      generic VFS lock/unlock/wait work on the inode if rc != 0.
      
      If we are closing the handle, the SMB server is supposed to remove any
      locks associated with it. Similarly, cifs.ko frees and wakes up any
      lock and lock waiter when closing the file:
      
      cifs_close()
        cifsFileInfo_put(file->private_data)
      	/*
      	 * Delete any outstanding lock records. We'll lose them when the file
      	 * is closed anyway.
      	 */
      	down_write(&cifsi->lock_sem);
      	list_for_each_entry_safe(li, tmp, &cifs_file->llist->locks, llist) {
      		list_del(&li->llist);
      		cifs_del_lock_waiters(li);
      		kfree(li);
      	}
      	list_del(&cifs_file->llist->llist);
      	kfree(cifs_file->llist);
      	up_write(&cifsi->lock_sem);
      
      So we can safely ignore unlocking failures in cifs_lock() if they
      happen with the FL_CLOSE flag hint set as both the server and the
      client take care of it during the actual closing.
      
      This is not a proper fix for the unlocking failure but it's safe and
      it seems to prevent the lock leakages and crashes the customer
      experiences.
      Signed-off-by: NAurelien Aptel <aaptel@suse.com>
      Signed-off-by: NNeilBrown <neil@brown.name>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2938651d
    • R
      tty/serial: atmel: RS485 HD w/DMA: enable RX after TX is stopped · 442d5d17
      Razvan Stefanescu 提交于
      commit 69646d7a3689fbe1a65ae90397d22ac3f1b8d40f upstream.
      
      In half-duplex operation, RX should be started after TX completes.
      
      If DMA is used, there is a case when the DMA transfer completes but the
      TX FIFO is not emptied, so the RX cannot be restarted just yet.
      
      Use a boolean variable to store this state and rearm TX interrupt mask
      to be signaled again that the transfer finished. In interrupt transmit
      handler this variable is used to start RX. A warning message is generated
      if RX is activated before TX fifo is cleared.
      
      Fixes: b389f173 ("tty/serial: atmel: RS485 half duplex w/DMA: enable
      RX after TX is done")
      Signed-off-by: NRazvan Stefanescu <razvan.stefanescu@microchip.com>
      Acked-by: NRichard Genoud <richard.genoud@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      442d5d17
    • R
      tty/serial: atmel: Add is_half_duplex helper · b6b4bcb4
      Razvan Stefanescu 提交于
      commit f3040983132bf3477acd45d2452a906e67c2fec9 upstream.
      
      Use a helper function to check that a port needs to use half duplex
      communication, replacing several occurrences of multi-line bit checking.
      
      Fixes: b389f173 ("tty/serial: atmel: RS485 half duplex w/DMA: enable RX after TX is done")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NRazvan Stefanescu <razvan.stefanescu@microchip.com>
      Acked-by: NRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      b6b4bcb4
    • Z
      ext4: cleanup bh release code in ext4_ind_remove_space() · 2dbc7c66
      zhangyi (F) 提交于
      commit 5e86bdda41534e17621d5a071b294943cae4376e upstream.
      
      Currently, we are releasing the indirect buffer where we are done with
      it in ext4_ind_remove_space(), so we can see the brelse() and
      BUFFER_TRACE() everywhere.  It seems fragile and hard to read, and we
      may probably forget to release the buffer some day.  This patch cleans
      up the code by putting of the code which releases the buffers to the
      end of the function.
      Signed-off-by: Nzhangyi (F) <yi.zhang@huawei.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Cc: Jari Ruusu <jari.ruusu@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2dbc7c66
    • W
      arm64: debug: Don't propagate UNKNOWN FAR into si_code for debug signals · bd62f1fe
      Will Deacon 提交于
      commit b9a4b9d084d978f80eb9210727c81804588b42ff upstream.
      
      FAR_EL1 is UNKNOWN for all debug exceptions other than those caused by
      taking a hardware watchpoint. Unfortunately, if a debug handler returns
      a non-zero value, then we will propagate the UNKNOWN FAR value to
      userspace via the si_addr field of the SIGTRAP siginfo_t.
      
      Instead, let's set si_addr to take on the PC of the faulting instruction,
      which we have available in the current pt_regs.
      
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      bd62f1fe
  2. 03 4月, 2019 14 次提交