1. 21 11月, 2018 40 次提交
    • A
      perf intel-pt/bts: Calculate cpumode for synthesized samples · f3de8640
      Adrian Hunter 提交于
      commit 5d4f0edaa3ac4f1844ed7c64cd2bae6f1912bac5 upstream.
      
      In the absence of a fallback, samples must provide a correct cpumode for
      the 'ip'. Do that now there is no fallback.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: stable@vger.kernel.org # 4.19
      Link: http://lkml.kernel.org/r/20181031091043.23465-6-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3de8640
    • D
      perf callchain: Honour the ordering of PERF_CONTEXT_{USER,KERNEL,etc} · 1b913453
      David S. Miller 提交于
      commit e9024d519d892b38176cafd46f68a7cdddd77412 upstream.
      
      When processing using 'perf report -g caller', which is the default, we
      ended up reverting the callchain entries received from the kernel, but
      simply reverting throws away the information that tells that from a
      point onwards the addresses are for userspace, kernel, guest kernel,
      guest user, hypervisor.
      
      The idea is that if we are walking backwards, for each cluster of
      non-cpumode entries we have to first scan backwards for the next one and
      use that for the cluster.
      
      This seems silly and more expensive than it needs to be but it is enough
      for a initial fix.
      
      The code here is really complicated because it is intimately intertwined
      with the lbr and branch handling, as well as this callchain order,
      further fixes will be needed to properly take into account the cpumode
      in those cases.
      
      Another problem with ORDER_CALLER is that the NULL "0" IP that is at the
      end of most callchains shows up at the top of the histogram because
      every callchain contains it and with ORDER_CALLER it is the first entry.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Souvik Banerjee <souvik1997@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: stable@vger.kernel.org # 4.19
      Link: https://lkml.kernel.org/n/tip-2wt3ayp6j2y2f2xowixa8y6y@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1b913453
    • T
      perf stat: Handle different PMU names with common prefix · 7b0131a0
      Thomas Richter 提交于
      commit ea1fa48c055f833eb25f0c33188feecb7002ada5 upstream.
      
      On s390 the CPU Measurement Facility for counters now supports
      2 PMUs named cpum_cf (CPU Measurement Facility for counters) and
      cpum_cf_diag (CPU Measurement Facility for diagnostic counters)
      for one and the same CPU.
      
      Running command
      
       [root@s35lp76 perf]# ./perf stat -e tx_c_tend \
      	 -- ~/mytests/cf-tx-events 1
      
       Measuring transactions
       TX_C_TABORT_NO_SPECIAL: 0 expected:0
       TX_C_TABORT_SPECIAL: 0 expected:0
       TX_C_TEND: 1 expected:1
       TX_NC_TABORT: 11 expected:11
       TX_NC_TEND: 1 expected:1
      
       Performance counter stats for '/root/mytests/cf-tx-events 1':
      
        2      tx_c_tend
      
            0.002120091 seconds time elapsed
      
            0.000121000 seconds user
            0.002127000 seconds sys
      
       [root@s35lp76 perf]#
      
      displays output which is unexpected (and wrong):
      
        2      tx_c_tend
      
      The test program definitely triggers only one transaction, as shown
      in line 'TX_C_TEND: 1 expected:1'.
      
      This is caused by the following call sequence:
      
      pmu_lookup() scans and installs a PMU.
      +--> pmu_aliases() parses all aliases in directory
      		.../<pmu-name>/events/* which are file names.
           +--> pmu_aliases_parse() Read each file in directory and create
                            an new alias entry. This is done with
                +--> perf_pmu__new_alias() and
      	       +--> __perf_pmu__new_alias() which also check for
      	                   identical alias names.
      
      After pmu_aliases() returns, a complete list of event names
      for this pmu has been created. Now function
      
      pmu_add_cpu_aliases()   is called to add the events listed in the json
      |                       files to the alias list of the cpu.
      +--> perf_pmu__find_map()  Returns a pointer to the json events.
      
      Now function pmu_add_cpu_aliases() scans through all events listed
      in the JSON files for this CPU.
      Each json event pmu name is compared with the current PMU being
      built up and if they mismatch, the json event is added to the
      current PMUs alias list.
      To avoid duplicate entries the following comparison is done:
      
      	if (!is_arm_pmu_core(name)) {
      	     pname = pe->pmu ? pe->pmu : "cpu";
      	     if (strncmp(pname, name, strlen(pname)))
      		     continue;
           }
      
      The culprit is the strncmp() function.
      
      Using current s390 PMU naming, the first PMU is 'cpum_cf'
      and a long list of events is added, among them 'tx_c_tend'
      
      When the second PMU named 'cpum_cf_diag' is added, only one event
      named 'CF_DIAG' is added by the pmu_aliases()  function.
      
      Now function pmu_add_cpu_aliases() is invoked for PMU 'cpum_cf_diag'.
      Since the CPUID string is the same for both PMUs, json file events
      for PMU named 'cpum_cf' are added to the PMU 'cpm_cf_diag'
      
      This happens because the strncmp() actually compares:
      
           strncmp("cpum_cf", "cpum_cf_diag", 6);
      
      The first parameter is the pmu name taken from the event in
      the json file. The second parameter is the pmu name of the PMU
      currently being built.
      They are different, but the length of the compare only tests the
      common prefix and this returns 0(true) when it should return false.
      
      Now all events for PMU cpum_cf are added to the alias list for pmu
      cpum_cf_diag.
      
      Later on in function parse_events_add_pmu() the event 'tx_c_end' is
      searched in all available PMUs and found twice, adding it two
      times to the evsel_list global variable which is the root
      of all events. This results in a counter value of 2 instead
      of 1.
      
      Output with this patch:
      
       [root@s35lp76 perf]# ./perf stat -e tx_c_tend \
      			-- ~/mytests/cf-tx-events 1
       Measuring transactions
       TX_C_TABORT_NO_SPECIAL: 0 expected:0
       TX_C_TABORT_SPECIAL: 0 expected:0
       TX_C_TEND: 1 expected:1
       TX_NC_TABORT: 11 expected:11
       TX_NC_TEND: 1 expected:1
      
       Performance counter stats for '/root/mytests/cf-tx-events 1':
      
                        1      tx_c_tend
      
            0.001815365 seconds time elapsed
      
            0.000123000 seconds user
            0.001756000 seconds sys
      
       [root@s35lp76 perf]#
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com>
      Reviewed-by: NSebastien Boisvert <sboisvert@gydle.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: stable@vger.kernel.org
      Fixes: 292c34c1 ("perf pmu: Fix core PMU alias list for X86 platform")
      Link: http://lkml.kernel.org/r/20181023151616.78193-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b0131a0
    • L
      perf cs-etm: Correct CPU mode for samples · 29414ff3
      Leo Yan 提交于
      commit d6c9c05fe1eb4b213b183d8a1e79416256dc833a upstream.
      
      Since commit edeb0c90 ("perf tools: Stop fallbacking to kallsyms for
      vdso symbols lookup"), the kernel address cannot be properly parsed to
      kernel symbol with command 'perf script -k vmlinux'.  The reason is
      CoreSight samples is always to set CPU mode as PERF_RECORD_MISC_USER,
      thus it fails to find corresponding map/dso in below flows:
      
        process_sample_event()
          `-> machine__resolve()
      	  `-> thread__find_map(thread, sample->cpumode, sample->ip, al);
      
      In this flow it needs to pass argument 'sample->cpumode' to tell what's
      the CPU mode, before it always passed PERF_RECORD_MISC_USER but without
      any failure until the commit edeb0c90 ("perf tools: Stop fallbacking
      to kallsyms for vdso symbols lookup") has been merged.  The reason is
      even with the wrong CPU mode the function thread__find_map() firstly
      fails to find map but it will rollback to find kernel map for vdso
      symbols lookup.  In the latest code it has removed the fallback code,
      thus if CPU mode is PERF_RECORD_MISC_USER then it cannot find map
      anymore with kernel address.
      
      This patch is to correct samples CPU mode setting, it creates a new
      helper function cs_etm__cpu_mode() to tell what's the CPU mode based on
      the address with the info from machine structure; this patch has a bit
      extension to check not only kernel and user mode, but also check for
      host/guest and hypervisor mode.  Finally this patch uses the function in
      instruction and branch samples and also apply in cs_etm__mem_access()
      for a minor polishing.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: coresight@lists.linaro.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: stable@kernel.org # v4.19
      Link: http://lkml.kernel.org/r/1540883908-17018-1-git-send-email-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29414ff3
    • D
      hwmon: (core) Fix double-free in __hwmon_device_register() · a63fffbd
      Dmitry Osipenko 提交于
      commit 74e3512731bd5c9673176425a76a7cc5efa8ddb6 upstream.
      
      Fix double-free that happens when thermal zone setup fails, see KASAN log
      below.
      
      ==================================================================
      BUG: KASAN: double-free or invalid-free in __hwmon_device_register+0x5dc/0xa7c
      
      CPU: 0 PID: 132 Comm: kworker/0:2 Tainted: G    B             4.19.0-rc8-next-20181016-00042-gb52cd80401e9-dirty #41
      Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
      Workqueue: events deferred_probe_work_func
      Backtrace:
      [<c0110540>] (dump_backtrace) from [<c0110944>] (show_stack+0x20/0x24)
      [<c0110924>] (show_stack) from [<c105cb08>] (dump_stack+0x9c/0xb0)
      [<c105ca6c>] (dump_stack) from [<c02fdaec>] (print_address_description+0x68/0x250)
      [<c02fda84>] (print_address_description) from [<c02fd4ac>] (kasan_report_invalid_free+0x68/0x88)
      [<c02fd444>] (kasan_report_invalid_free) from [<c02fc85c>] (__kasan_slab_free+0x1f4/0x200)
      [<c02fc668>] (__kasan_slab_free) from [<c02fd0c0>] (kasan_slab_free+0x14/0x18)
      [<c02fd0ac>] (kasan_slab_free) from [<c02f9c6c>] (kfree+0x90/0x294)
      [<c02f9bdc>] (kfree) from [<c0b41bbc>] (__hwmon_device_register+0x5dc/0xa7c)
      [<c0b415e0>] (__hwmon_device_register) from [<c0b421e8>] (hwmon_device_register_with_info+0xa0/0xa8)
      [<c0b42148>] (hwmon_device_register_with_info) from [<c0b42324>] (devm_hwmon_device_register_with_info+0x74/0xb4)
      [<c0b422b0>] (devm_hwmon_device_register_with_info) from [<c0b4481c>] (lm90_probe+0x414/0x578)
      [<c0b44408>] (lm90_probe) from [<c0aeeff4>] (i2c_device_probe+0x35c/0x384)
      [<c0aeec98>] (i2c_device_probe) from [<c08776cc>] (really_probe+0x290/0x3e4)
      [<c087743c>] (really_probe) from [<c0877a2c>] (driver_probe_device+0x80/0x1c4)
      [<c08779ac>] (driver_probe_device) from [<c0877da8>] (__device_attach_driver+0x104/0x11c)
      [<c0877ca4>] (__device_attach_driver) from [<c0874dd8>] (bus_for_each_drv+0xa4/0xc8)
      [<c0874d34>] (bus_for_each_drv) from [<c08773b0>] (__device_attach+0xf0/0x15c)
      [<c08772c0>] (__device_attach) from [<c0877e24>] (device_initial_probe+0x1c/0x20)
      [<c0877e08>] (device_initial_probe) from [<c08762f4>] (bus_probe_device+0xdc/0xec)
      [<c0876218>] (bus_probe_device) from [<c0876a08>] (deferred_probe_work_func+0xa8/0xd4)
      [<c0876960>] (deferred_probe_work_func) from [<c01527c4>] (process_one_work+0x3dc/0x96c)
      [<c01523e8>] (process_one_work) from [<c01541e0>] (worker_thread+0x4ec/0x8bc)
      [<c0153cf4>] (worker_thread) from [<c015b238>] (kthread+0x230/0x240)
      [<c015b008>] (kthread) from [<c01010bc>] (ret_from_fork+0x14/0x38)
      Exception stack(0xcf743fb0 to 0xcf743ff8)
      3fa0:                                     00000000 00000000 00000000 00000000
      3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
      
      Allocated by task 132:
       kasan_kmalloc.part.1+0x58/0xf4
       kasan_kmalloc+0x90/0xa4
       kmem_cache_alloc_trace+0x90/0x2a0
       __hwmon_device_register+0xbc/0xa7c
       hwmon_device_register_with_info+0xa0/0xa8
       devm_hwmon_device_register_with_info+0x74/0xb4
       lm90_probe+0x414/0x578
       i2c_device_probe+0x35c/0x384
       really_probe+0x290/0x3e4
       driver_probe_device+0x80/0x1c4
       __device_attach_driver+0x104/0x11c
       bus_for_each_drv+0xa4/0xc8
       __device_attach+0xf0/0x15c
       device_initial_probe+0x1c/0x20
       bus_probe_device+0xdc/0xec
       deferred_probe_work_func+0xa8/0xd4
       process_one_work+0x3dc/0x96c
       worker_thread+0x4ec/0x8bc
       kthread+0x230/0x240
       ret_from_fork+0x14/0x38
         (null)
      
      Freed by task 132:
       __kasan_slab_free+0x12c/0x200
       kasan_slab_free+0x14/0x18
       kfree+0x90/0x294
       hwmon_dev_release+0x1c/0x20
       device_release+0x4c/0xe8
       kobject_put+0xac/0x11c
       device_unregister+0x2c/0x30
       __hwmon_device_register+0xa58/0xa7c
       hwmon_device_register_with_info+0xa0/0xa8
       devm_hwmon_device_register_with_info+0x74/0xb4
       lm90_probe+0x414/0x578
       i2c_device_probe+0x35c/0x384
       really_probe+0x290/0x3e4
       driver_probe_device+0x80/0x1c4
       __device_attach_driver+0x104/0x11c
       bus_for_each_drv+0xa4/0xc8
       __device_attach+0xf0/0x15c
       device_initial_probe+0x1c/0x20
       bus_probe_device+0xdc/0xec
       deferred_probe_work_func+0xa8/0xd4
       process_one_work+0x3dc/0x96c
       worker_thread+0x4ec/0x8bc
       kthread+0x230/0x240
       ret_from_fork+0x14/0x38
         (null)
      
      Cc: <stable@vger.kernel.org> # v4.15+
      Fixes: 47c332de ("hwmon: Deal with errors from the thermal subsystem")
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a63fffbd
    • A
      mtd: docg3: don't set conflicting BCH_CONST_PARAMS option · 14e58f9d
      Arnd Bergmann 提交于
      commit be2e1c9dcf76886a83fb1c433a316e26d4ca2550 upstream.
      
      I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
      option that is set by DOCG3 breaks setting variable parameters for any
      other users of the BCH library code.
      
      The only other user we have today is the MTD_NAND software BCH
      implementation (most flash controllers use hardware BCH these days
      and are not affected). I considered removing BCH_CONST_PARAMS entirely
      because of the inherent conflict, but according to the description in
      lib/bch.c there is a significant performance benefit in keeping it.
      
      To avoid the immediate problem of the conflict between MTD_NAND_BCH
      and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
      is disabled, which should fix the problem for all cases that
      are affected. This should also work for all stable kernels.
      
      Note that there is only one machine that actually seems to use the
      DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
      the driver disabled, but it almost certainly shows up if we wanted
      to test random kernels on machines that use software BCH in MTD.
      
      Fixes: d13d19ec ("mtd: docg3: add ECC correction code")
      Cc: stable@vger.kernel.org
      Cc: Robert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14e58f9d
    • B
      mtd: nand: Fix nanddev_neraseblocks() · 9bec0c3d
      Boris Brezillon 提交于
      commit d098093ba06eb032057d1aca1c2e45889e099d00 upstream.
      
      nanddev_neraseblocks() currently returns the number pages per LUN
      instead of the total number of eraseblocks.
      
      Fixes: 9c3736a3 ("mtd: nand: Add core infrastructure to deal with NAND devices")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9bec0c3d
    • C
      mtd: spi-nor: cadence-quadspi: Return error code in cqspi_direct_read_execute() · 9e9dd0f1
      Christophe JAILLET 提交于
      commit 91d7b67000c6e9bd605624079fee5a084238ad92 upstream.
      
      We return 0 unconditionally in 'cqspi_direct_read_execute()'.
      However, 'ret' is set to some error codes in several error handling
      paths.
      
      Return 'ret' instead to propagate the error code.
      
      Fixes: ffa639e0 ("mtd: spi-nor: cadence-quadspi: Add DMA support for direct mode reads")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9e9dd0f1
    • J
      bonding/802.3ad: fix link_failure_count tracking · 218b6e82
      Jarod Wilson 提交于
      commit ea53abfab960909d622ca37bcfb8e1c5378d21cc upstream.
      
      Commit 4d2c0cda set slave->link to
      BOND_LINK_DOWN for 802.3ad bonds whenever invalid speed/duplex values
      were read, to fix a problem with slaves getting into weird states, but
      in the process, broke tracking of link failures, as going straight to
      BOND_LINK_DOWN when a link is indeed down (cable pulled, switch rebooted)
      means we broke out of bond_miimon_inspect()'s BOND_LINK_DOWN case because
      !link_state was already true, we never incremented commit, and never got
      a chance to call bond_miimon_commit(), where slave->link_failure_count
      would be incremented. I believe the simple fix here is to mark the slave
      as BOND_LINK_FAIL, and let bond_miimon_inspect() transition the link from
      _FAIL to either _UP or _DOWN, and in the latter case, we now get proper
      incrementing of link_failure_count again.
      
      Fixes: 4d2c0cda ("bonding: speed/duplex update at NETDEV_UP event")
      CC: Mahesh Bandewar <maheshb@google.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: netdev@vger.kernel.org
      CC: stable@vger.kernel.org
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      218b6e82
    • A
      ARM: 8809/1: proc-v7: fix Thumb annotation of cpu_v7_hvc_switch_mm · 9333523b
      Ard Biesheuvel 提交于
      commit 6282e916f774e37845c65d1eae9f8c649004f033 upstream.
      
      Due to what appears to be a copy/paste error, the opening ENTRY()
      of cpu_v7_hvc_switch_mm() lacks a matching ENDPROC(), and instead,
      the one for cpu_v7_smc_switch_mm() is duplicated.
      
      Given that it is ENDPROC() that emits the Thumb annotation, the
      cpu_v7_hvc_switch_mm() routine will be called in ARM mode on a
      Thumb2 kernel, resulting in the following splat:
      
        Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
        Modules linked in:
        CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc1-00030-g4d28ad89189d-dirty #488
        Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
        PC is at cpu_v7_hvc_switch_mm+0x12/0x18
        LR is at flush_old_exec+0x31b/0x570
        pc : [<c0316efe>]    lr : [<c04117c7>]    psr: 00000013
        sp : ee899e50  ip : 00000000  fp : 00000001
        r10: eda28f34  r9 : eda31800  r8 : c12470e0
        r7 : eda1fc00  r6 : eda53000  r5 : 00000000  r4 : ee88c000
        r3 : c0316eec  r2 : 00000001  r1 : eda53000  r0 : 6da6c000
        Flags: nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      
      Note the 'ISA ARM' in the last line.
      
      Fix this by using the correct name in ENDPROC().
      
      Cc: <stable@vger.kernel.org>
      Fixes: 10115105 ("ARM: spectre-v2: add firmware based hardening")
      Reviewed-by: NDave Martin <Dave.Martin@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9333523b
    • V
      netfilter: conntrack: fix calculation of next bucket number in early_drop · 1be1576a
      Vasily Khoruzhick 提交于
      commit f393808dc64149ccd0e5a8427505ba2974a59854 upstream.
      
      If there's no entry to drop in bucket that corresponds to the hash,
      early_drop() should look for it in other buckets. But since it increments
      hash instead of bucket number, it actually looks in the same bucket 8
      times: hsize is 16k by default (14 bits) and hash is 32-bit value, so
      reciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in
      most cases.
      
      Fix it by increasing bucket number instead of hash and rename _hash
      to bucket to avoid future confusion.
      
      Fixes: 3e86638e ("netfilter: conntrack: consider ct netns in early_drop logic")
      Cc: <stable@vger.kernel.org> # v4.7+
      Signed-off-by: NVasily Khoruzhick <vasilykh@arista.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1be1576a
    • M
      memory_hotplug: cond_resched in __remove_pages · ccd35ba5
      Michal Hocko 提交于
      commit dd33ad7b251f900481701b2a82d25de583867708 upstream.
      
      We have received a bug report that unbinding a large pmem (>1TB) can
      result in a soft lockup:
      
        NMI watchdog: BUG: soft lockup - CPU#9 stuck for 23s! [ndctl:4365]
        [...]
        Supported: Yes
        CPU: 9 PID: 4365 Comm: ndctl Not tainted 4.12.14-94.40-default #1 SLE12-SP4
        Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.01.00.0833.051120182255 05/11/2018
        task: ffff9cce7d4410c0 task.stack: ffffbe9eb1bc4000
        RIP: 0010:__put_page+0x62/0x80
        Call Trace:
         devm_memremap_pages_release+0x152/0x260
         release_nodes+0x18d/0x1d0
         device_release_driver_internal+0x160/0x210
         unbind_store+0xb3/0xe0
         kernfs_fop_write+0x102/0x180
         __vfs_write+0x26/0x150
         vfs_write+0xad/0x1a0
         SyS_write+0x42/0x90
         do_syscall_64+0x74/0x150
         entry_SYSCALL_64_after_hwframe+0x3d/0xa2
        RIP: 0033:0x7fd13166b3d0
      
      It has been reported on an older (4.12) kernel but the current upstream
      code doesn't cond_resched in the hot remove code at all and the given
      range to remove might be really large.  Fix the issue by calling
      cond_resched once per memory section.
      
      Link: http://lkml.kernel.org/r/20181031125840.23982-1-mhocko@kernel.orgSigned-off-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Cc: Dan Williams <dan.j.williams@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccd35ba5
    • A
      mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings · 67a19f87
      Andrea Arcangeli 提交于
      commit ac5b2c18911ffe95c08d69273917f90212cf5659 upstream.
      
      THP allocation might be really disruptive when allocated on NUMA system
      with the local node full or hard to reclaim.  Stefan has posted an
      allocation stall report on 4.12 based SLES kernel which suggests the
      same issue:
      
        kvm: page allocation stalls for 194572ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null)
        kvm cpuset=/ mems_allowed=0-1
        CPU: 10 PID: 84752 Comm: kvm Tainted: G        W 4.12.0+98-ph <a href="/view.php?id=1" title="[geschlossen] Integration Ramdisk" class="resolved">0000001</a> SLE15 (unreleased)
        Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 12/05/2017
        Call Trace:
         dump_stack+0x5c/0x84
         warn_alloc+0xe0/0x180
         __alloc_pages_slowpath+0x820/0xc90
         __alloc_pages_nodemask+0x1cc/0x210
         alloc_pages_vma+0x1e5/0x280
         do_huge_pmd_wp_page+0x83f/0xf00
         __handle_mm_fault+0x93d/0x1060
         handle_mm_fault+0xc6/0x1b0
         __do_page_fault+0x230/0x430
         do_page_fault+0x2a/0x70
         page_fault+0x7b/0x80
         [...]
        Mem-Info:
        active_anon:126315487 inactive_anon:1612476 isolated_anon:5
         active_file:60183 inactive_file:245285 isolated_file:0
         unevictable:15657 dirty:286 writeback:1 unstable:0
         slab_reclaimable:75543 slab_unreclaimable:2509111
         mapped:81814 shmem:31764 pagetables:370616 bounce:0
         free:32294031 free_pcp:6233 free_cma:0
        Node 0 active_anon:254680388kB inactive_anon:1112760kB active_file:240648kB inactive_file:981168kB unevictable:13368kB isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
        Node 1 active_anon:250583072kB inactive_anon:5337144kB active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
      
      The defrag mode is "madvise" and from the above report it is clear that
      the THP has been allocated for MADV_HUGEPAGA vma.
      
      Andrea has identified that the main source of the problem is
      __GFP_THISNODE usage:
      
      : The problem is that direct compaction combined with the NUMA
      : __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very
      : hard the local node, instead of failing the allocation if there's no
      : THP available in the local node.
      :
      : Such logic was ok until __GFP_THISNODE was added to the THP allocation
      : path even with MPOL_DEFAULT.
      :
      : The idea behind the __GFP_THISNODE addition, is that it is better to
      : provide local memory in PAGE_SIZE units than to use remote NUMA THP
      : backed memory. That largely depends on the remote latency though, on
      : threadrippers for example the overhead is relatively low in my
      : experience.
      :
      : The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in
      : extremely slow qemu startup with vfio, if the VM is larger than the
      : size of one host NUMA node. This is because it will try very hard to
      : unsuccessfully swapout get_user_pages pinned pages as result of the
      : __GFP_THISNODE being set, instead of falling back to PAGE_SIZE
      : allocations and instead of trying to allocate THP on other nodes (it
      : would be even worse without vfio type1 GUP pins of course, except it'd
      : be swapping heavily instead).
      
      Fix this by removing __GFP_THISNODE for THP requests which are
      requesting the direct reclaim.  This effectivelly reverts 5265047a
      on the grounds that the zone/node reclaim was known to be disruptive due
      to premature reclaim when there was memory free.  While it made sense at
      the time for HPC workloads without NUMA awareness on rare machines, it
      was ultimately harmful in the majority of cases.  The existing behaviour
      is similar, if not as widespare as it applies to a corner case but
      crucially, it cannot be tuned around like zone_reclaim_mode can.  The
      default behaviour should always be to cause the least harm for the
      common case.
      
      If there are specialised use cases out there that want zone_reclaim_mode
      in specific cases, then it can be built on top.  Longterm we should
      consider a memory policy which allows for the node reclaim like behavior
      for the specific memory ranges which would allow a
      
      [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
      
      Mel said:
      
      : Both patches look correct to me but I'm responding to this one because
      : it's the fix.  The change makes sense and moves further away from the
      : severe stalling behaviour we used to see with both THP and zone reclaim
      : mode.
      :
      : I put together a basic experiment with usemem configured to reference a
      : buffer multiple times that is 80% the size of main memory on a 2-socket
      : box with symmetric node sizes and defrag set to "always".  The defrag
      : setting is not the default but it would be functionally similar to
      : accessing a buffer with madvise(MADV_HUGEPAGE).  Usemem is configured to
      : reference the buffer multiple times and while it's not an interesting
      : workload, it would be expected to complete reasonably quickly as it fits
      : within memory.  The results were;
      :
      : usemem
      :                                   vanilla           noreclaim-v1
      : Amean     Elapsd-1       42.78 (   0.00%)       26.87 (  37.18%)
      : Amean     Elapsd-3       27.55 (   0.00%)        7.44 (  73.00%)
      : Amean     Elapsd-4        5.72 (   0.00%)        5.69 (   0.45%)
      :
      : This shows the elapsed time in seconds for 1 thread, 3 threads and 4
      : threads referencing buffers 80% the size of memory.  With the patches
      : applied, it's 37.18% faster for the single thread and 73% faster with two
      : threads.  Note that 4 threads showing little difference does not indicate
      : the problem is related to thread counts.  It's simply the case that 4
      : threads gets spread so their workload mostly fits in one node.
      :
      : The overall view from /proc/vmstats is more startling
      :
      :                          4.19.0-rc1  4.19.0-rc1
      :                             vanillanoreclaim-v1r1
      : Minor Faults               35593425      708164
      : Major Faults                 484088          36
      : Swap Ins                    3772837           0
      : Swap Outs                   3932295           0
      :
      : Massive amounts of swap in/out without the patch
      :
      : Direct pages scanned        6013214           0
      : Kswapd pages scanned              0           0
      : Kswapd pages reclaimed            0           0
      : Direct pages reclaimed      4033009           0
      :
      : Lots of reclaim activity without the patch
      :
      : Kswapd efficiency              100%        100%
      : Kswapd velocity               0.000       0.000
      : Direct efficiency               67%        100%
      : Direct velocity           11191.956       0.000
      :
      : Mostly from direct reclaim context as you'd expect without the patch.
      :
      : Page writes by reclaim  3932314.000       0.000
      : Page writes file                 19           0
      : Page writes anon            3932295           0
      : Page reclaim immediate        42336           0
      :
      : Writes from reclaim context is never good but the patch eliminates it.
      :
      : We should never have default behaviour to thrash the system for such a
      : basic workload.  If zone reclaim mode behaviour is ever desired but on a
      : single task instead of a global basis then the sensible option is to build
      : a mempolicy that enforces that behaviour.
      
      This was a severe regression compared to previous kernels that made
      important workloads unusable and it starts when __GFP_THISNODE was
      added to THP allocations under MADV_HUGEPAGE.  It is not a significant
      risk to go to the previous behavior before __GFP_THISNODE was added, it
      worked like that for years.
      
      This was simply an optimization to some lucky workloads that can fit in
      a single node, but it ended up breaking the VM for others that can't
      possibly fit in a single node, so going back is safe.
      
      [mhocko@suse.com: rewrote the changelog based on the one from Andrea]
      Link: http://lkml.kernel.org/r/20180925120326.24392-2-mhocko@kernel.org
      Fixes: 5265047a ("mm, thp: really limit transparent hugepage allocation to local node")
      Signed-off-by: NAndrea Arcangeli <aarcange@redhat.com>
      Signed-off-by: NMichal Hocko <mhocko@suse.com>
      Reported-by: NStefan Priebe <s.priebe@profihost.ag>
      Debugged-by: NAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: NAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: NMel Gorman <mgorman@techsingularity.net>
      Tested-by: NMel Gorman <mgorman@techsingularity.net>
      Cc: Zi Yan <zi.yan@cs.rutgers.edu>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: David Rientjes <rientjes@google.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: <stable@vger.kernel.org>	[4.1+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67a19f87
    • W
      ocfs2: free up write context when direct IO failed · 6bb462a4
      Wengang Wang 提交于
      commit 5040f8df56fb90c7919f1c9b0b6e54c843437456 upstream.
      
      The write context should also be freed even when direct IO failed.
      Otherwise a memory leak is introduced and entries remain in
      oi->ip_unwritten_list causing the following BUG later in unlink path:
      
        ERROR: bug expression: !list_empty(&oi->ip_unwritten_list)
        ERROR: Clear inode of 215043, inode has unwritten extents
        ...
        Call Trace:
        ? __set_current_blocked+0x42/0x68
        ocfs2_evict_inode+0x91/0x6a0 [ocfs2]
        ? bit_waitqueue+0x40/0x33
        evict+0xdb/0x1af
        iput+0x1a2/0x1f7
        do_unlinkat+0x194/0x28f
        SyS_unlinkat+0x1b/0x2f
        do_syscall_64+0x79/0x1ae
        entry_SYSCALL_64_after_hwframe+0x151/0x0
      
      This patch also logs, with frequency limit, direct IO failures.
      
      Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.comSigned-off-by: NWengang Wang <wen.gang.wang@oracle.com>
      Reviewed-by: NJunxiao Bi <junxiao.bi@oracle.com>
      Reviewed-by: NChangwei Ge <ge.changwei@h3c.com>
      Reviewed-by: NJoseph Qi <jiangqi903@gmail.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6bb462a4
    • C
      ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry · 148dc931
      Changwei Ge 提交于
      commit 29aa30167a0a2e6045a0d6d2e89d8168132333d5 upstream.
      
      Somehow, file system metadata was corrupted, which causes
      ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
      
      According to the original design intention, if above happens we should
      skip the problematic block and continue to retrieve dir entry.  But
      there is obviouse misuse of brelse around related code.
      
      After failure of ocfs2_check_dir_entry(), current code just moves to
      next position and uses the problematic buffer head again and again
      during which the problematic buffer head is released for multiple times.
      I suppose, this a serious issue which is long-lived in ocfs2.  This may
      cause other file systems which is also used in a the same host insane.
      
      So we should also consider about bakcporting this patch into linux
      -stable.
      
      Link: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.comSigned-off-by: NChangwei Ge <ge.changwei@h3c.com>
      Suggested-by: NChangkuo Shi <shi.changkuo@h3c.com>
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Joseph Qi <jiangqi903@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      148dc931
    • M
      soc: ti: QMSS: Fix usage of irq_set_affinity_hint · 176e8d6d
      Marc Zyngier 提交于
      commit 832ad0e3da4510fd17f98804abe512ea9a747035 upstream.
      
      The Keystone QMSS driver is pretty damaged, in the sense that it
      does things like this:
      
      	irq_set_affinity_hint(irq, to_cpumask(&cpu_map));
      
      where cpu_map is a local variable. As we leave the function, this
      will point to nowhere-land, and things will end-up badly.
      
      Instead, let's use a proper cpumask that gets allocated, giving
      the driver a chance to actually work with things like irqbalance
      as well as have a hypothetical 64bit future.
      
      Cc: stable@vger.kernel.org
      Acked-by: NSantosh Shilimkar <ssantosh@kernel.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      176e8d6d
    • C
      Revert "powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP" · ce65f0f6
      Christophe Leroy 提交于
      commit cc4ebf5c0a3440ed0a32d25c55ebdb6ce5f3c0bc upstream.
      
      This reverts commit 4f94b2c7.
      
      That commit was buggy, as it used rlwinm instead of rlwimi.
      Instead of fixing that bug, we revert the previous commit in order to
      reduce the dependency between L1 entries and L2 entries
      
      Fixes: 4f94b2c7 ("powerpc/8xx: Use L1 entry APG to handle _PAGE_ACCESSED for CONFIG_SWAP")
      Cc: stable@vger.kernel.org
      Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ce65f0f6
    • M
      SCSI: fix queue cleanup race before queue initialization is done · 410306a0
      Ming Lei 提交于
      commit 8dc765d438f1e42b3e8227b3b09fad7d73f4ec9a upstream.
      
      c2856ae2 ("blk-mq: quiesce queue before freeing queue") has
      already fixed this race, however the implied synchronize_rcu()
      in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
      performance regression.
      
      Then 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      tried to quiesce queue for avoiding unnecessary synchronize_rcu()
      only when queue initialization is done, because it is usual to see
      lots of inexistent LUNs which need to be probed.
      
      However, turns out it isn't safe to quiesce queue only when queue
      initialization is done. Because when one SCSI command is completed,
      the user of sending command can be waken up immediately, then the
      scsi device may be removed, meantime the run queue in scsi_end_request()
      is still in-progress, so kernel panic can be caused.
      
      In Red Hat QE lab, there are several reports about this kind of kernel
      panic triggered during kernel booting.
      
      This patch tries to address the issue by grabing one queue usage
      counter during freeing one request and the following run queue.
      
      Fixes: 1311326c ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
      Cc: Andrew Jones <drjones@redhat.com>
      Cc: Bart Van Assche <bart.vanassche@wdc.com>
      Cc: linux-scsi@vger.kernel.org
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
      Cc: stable <stable@vger.kernel.org>
      Cc: jianchao.wang <jianchao.w.wang@oracle.com>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      410306a0
    • Q
      scsi: qla2xxx: Initialize port speed to avoid setting lower speed · dd2fb8c6
      Quinn Tran 提交于
      commit f635e48e866ee1a47d2d42ce012fdcc07bf55853 upstream.
      
      This patch initializes port speed so that firmware does not set lower
      operating speed. Setting lower speed in firmware impacts WRITE perfomance.
      
      Fixes: 726b8548 ("qla2xxx: Add framework for async fabric discovery")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NQuinn Tran <quinn.tran@cavium.com>
      Signed-off-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
      Tested-by: NLaurence Oberman <loberman@redhat.com>
      Reviewed-by: NEwan D. Milne <emilne@redhat.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd2fb8c6
    • G
      vhost/scsi: truncate T10 PI iov_iter to prot_bytes · b1e99af9
      Greg Edwards 提交于
      commit 4542d623c7134bc1738f8a68ccb6dd546f1c264f upstream.
      
      Commands with protection information included were not truncating the
      protection iov_iter to the number of protection bytes in the command.
      This resulted in vhost_scsi mis-calculating the size of the protection
      SGL in vhost_scsi_calc_sgls(), and including both the protection and
      data SG entries in the protection SGL.
      
      Fixes: 09b13fa8 ("vhost/scsi: Add ANY_LAYOUT support in vhost_scsi_handle_vq")
      Signed-off-by: NGreg Edwards <gedwards@ddn.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Fixes: 09b13fa8
      Cc: stable@vger.kernel.org
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1e99af9
    • J
      crypto: hisilicon - Fix reference after free of memories on error path · 12555475
      John Garry 提交于
      commit 0b0cf6af3f3151c26c27e8e51def5527091c3e69 upstream.
      
      coccicheck currently warns of the following issues in the driver:
      drivers/crypto/hisilicon/sec/sec_algs.c:864:51-66: ERROR: reference preceded by free on line 812
      drivers/crypto/hisilicon/sec/sec_algs.c:864:40-49: ERROR: reference preceded by free on line 813
      drivers/crypto/hisilicon/sec/sec_algs.c:861:8-24: ERROR: reference preceded by free on line 814
      drivers/crypto/hisilicon/sec/sec_algs.c:860:41-51: ERROR: reference preceded by free on line 815
      drivers/crypto/hisilicon/sec/sec_algs.c:867:7-18: ERROR: reference preceded by free on line 816
      
      It would appear than on certain error paths that we may attempt reference-
      after-free some memories.
      
      This patch fixes those issues. The solution doesn't look perfect, but
      having same memories free'd possibly from separate functions makes it
      tricky.
      
      Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
      Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12555475
    • J
      crypto: hisilicon - Fix NULL dereference for same dst and src · 093d6ab5
      John Garry 提交于
      commit 68a031d22c57b94870ba13513c9d93b8a8119ab2 upstream.
      
      When the source and destination addresses for the cipher are the same, we
      will get a NULL dereference from accessing the split destination
      scatterlist memories, as shown:
      
      [   56.565719] tcrypt:
      [   56.565719] testing speed of async ecb(aes) (hisi_sec_aes_ecb) encryption
      [   56.574683] tcrypt: test 0 (128 bit key, 16 byte blocks):
      [   56.587585] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      [   56.596361] Mem abort info:
      [   56.599151]   ESR = 0x96000006
      [   56.602196]   Exception class = DABT (current EL), IL = 32 bits
      [   56.608105]   SET = 0, FnV = 0
      [   56.611149]   EA = 0, S1PTW = 0
      [   56.614280] Data abort info:
      [   56.617151]   ISV = 0, ISS = 0x00000006
      [   56.620976]   CM = 0, WnR = 0
      [   56.623930] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
      [   56.630533] [0000000000000000] pgd=0000041fc7e4d003, pud=0000041fcd9bf003, pmd=0000000000000000
      [   56.639224] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [   56.644782] Modules linked in: tcrypt(+)
      [   56.648695] CPU: 21 PID: 2326 Comm: insmod Tainted: G        W         4.19.0-rc6-00001-g3fabfb8-dirty #716
      [   56.658420] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT17 Nemo 2.0 RC0 10/05/2018
      [   56.667537] pstate: 20000005 (nzCv daif -PAN -UAO)
      [   56.672322] pc : sec_alg_skcipher_crypto+0x318/0x748
      [   56.677274] lr : sec_alg_skcipher_crypto+0x178/0x748
      [   56.682224] sp : ffff0000118e3840
      [   56.685525] x29: ffff0000118e3840 x28: ffff841fbb3f8118
      [   56.690825] x27: 0000000000000000 x26: 0000000000000000
      [   56.696125] x25: ffff841fbb3f8080 x24: ffff841fbadc0018
      [   56.701425] x23: ffff000009119000 x22: ffff841fbb24e280
      [   56.706724] x21: ffff841ff212e780 x20: ffff841ff212e700
      [   56.712023] x19: 0000000000000001 x18: ffffffffffffffff
      [   56.717322] x17: 0000000000000000 x16: 0000000000000000
      [   56.722621] x15: ffff0000091196c8 x14: 72635f7265687069
      [   56.727920] x13: 636b735f676c615f x12: ffff000009119940
      [   56.733219] x11: 0000000000000000 x10: 00000000006080c0
      [   56.738519] x9 : 0000000000000000 x8 : ffff841fbb24e480
      [   56.743818] x7 : ffff841fbb24e500 x6 : ffff841ff00cdcc0
      [   56.749117] x5 : 0000000000000010 x4 : 0000000000000000
      [   56.754416] x3 : ffff841fbb24e380 x2 : ffff841fbb24e480
      [   56.759715] x1 : 0000000000000000 x0 : ffff000008f682c8
      [   56.765016] Process insmod (pid: 2326, stack limit = 0x(____ptrval____))
      [   56.771702] Call trace:
      [   56.774136]  sec_alg_skcipher_crypto+0x318/0x748
      [   56.778740]  sec_alg_skcipher_encrypt+0x10/0x18
      [   56.783259]  test_skcipher_speed+0x2a0/0x700 [tcrypt]
      [   56.788298]  do_test+0x18f8/0x48c8 [tcrypt]
      [   56.792469]  tcrypt_mod_init+0x60/0x1000 [tcrypt]
      [   56.797161]  do_one_initcall+0x5c/0x178
      [   56.800985]  do_init_module+0x58/0x1b4
      [   56.804721]  load_module+0x1da4/0x2150
      [   56.808456]  __se_sys_init_module+0x14c/0x1e8
      [   56.812799]  __arm64_sys_init_module+0x18/0x20
      [   56.817231]  el0_svc_common+0x60/0xe8
      [   56.820880]  el0_svc_handler+0x2c/0x80
      [   56.824615]  el0_svc+0x8/0xc
      [   56.827483] Code: a94c87a3 910b2000 f87b7842 f9004ba2 (b87b7821)
      [   56.833564] ---[ end trace 0f63290590e93d94 ]---
      Segmentation fault
      
      Fix this by only accessing these memories when we have different src and
      dst.
      
      Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
      Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      093d6ab5
    • G
      reset: hisilicon: fix potential NULL pointer dereference · 459cfe0a
      Gustavo A. R. Silva 提交于
      commit e9a2310fb689151166df7fd9971093362d34bd79 upstream.
      
      There is a potential execution path in which function
      platform_get_resource() returns NULL. If this happens,
      we will end up having a NULL pointer dereference.
      
      Fix this by replacing devm_ioremap with devm_ioremap_resource,
      which has the NULL check and the memory region request.
      
      This code was detected with the help of Coccinelle.
      
      Cc: stable@vger.kernel.org
      Fixes: 97b7129c ("reset: hisilicon: change the definition of hisi_reset_init")
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      459cfe0a
    • D
      acpi, nfit: Fix ARS overflow continuation · b0a737bf
      Dan Williams 提交于
      commit 3fa58dcab50a0aa16817f16a8d38aee869eb3fb9 upstream.
      
      When the platform BIOS is unable to report all the media error records
      it requires the OS to restart the scrub at a prescribed location. The
      driver detects the overflow condition, but then fails to report it to
      the ARS state machine after reaping the records. Propagate -ENOSPC
      correctly to continue the ARS operation.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 1cf03c00 ("nfit: scrub and register regions in a workqueue")
      Reported-by: NJacek Zloch <jacek.zloch@intel.com>
      Reviewed-by: NDave Jiang <dave.jiang@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0a737bf
    • V
      acpi/nfit, x86/mce: Validate a MCE's address before using it · 8c547624
      Vishal Verma 提交于
      commit e8a308e5f47e545e0d41d0686c00f5f5217c5f61 upstream.
      
      The NFIT machine check handler uses the physical address from the mce
      structure, and compares it against information in the ACPI NFIT table
      to determine whether that location lies on an NVDIMM. The mce->addr
      field however may not always be valid, and this is indicated by the
      MCI_STATUS_ADDRV bit in the status field.
      
      Export mce_usable_address() which already performs validation for the
      address, and use it in the NFIT handler.
      
      Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error")
      Reported-by: NRobert Elliott <elliott@hpe.com>
      Signed-off-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      CC: Arnd Bergmann <arnd@arndb.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      CC: Dave Jiang <dave.jiang@intel.com>
      CC: elliott@hpe.com
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Len Brown <lenb@kernel.org>
      CC: linux-acpi@vger.kernel.org
      CC: linux-edac <linux-edac@vger.kernel.org>
      CC: linux-nvdimm@lists.01.org
      CC: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      CC: Ross Zwisler <zwisler@kernel.org>
      CC: stable <stable@vger.kernel.org>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tony Luck <tony.luck@intel.com>
      CC: x86-ml <x86@kernel.org>
      CC: Yazen Ghannam <yazen.ghannam@amd.com>
      Link: http://lkml.kernel.org/r/20181026003729.8420-2-vishal.l.verma@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c547624
    • V
      acpi/nfit, x86/mce: Handle only uncorrectable machine checks · 9013ac4d
      Vishal Verma 提交于
      commit 5d96c9342c23ee1d084802dcf064caa67ecaa45b upstream.
      
      The MCE handler for nfit devices is called for memory errors on a
      Non-Volatile DIMM and adds the error location to a 'badblocks' list.
      This list is used by the various NVDIMM drivers to avoid consuming known
      poison locations during IO.
      
      The MCE handler gets called for both corrected and uncorrectable errors.
      Until now, both kinds of errors have been added to the badblocks list.
      However, corrected memory errors indicate that the problem has already
      been fixed by hardware, and the resulting interrupt is merely a
      notification to Linux.
      
      As far as future accesses to that location are concerned, it is
      perfectly fine to use, and thus doesn't need to be included in the above
      badblocks list.
      
      Add a check in the nfit MCE handler to filter out corrected mce events,
      and only process uncorrectable errors.
      
      Fixes: 6839a6d9 ("nfit: do an ARS scrub on hitting a latent media error")
      Reported-by: NOmar Avelar <omar.avelar@intel.com>
      Signed-off-by: NVishal Verma <vishal.l.verma@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Dan Williams <dan.j.williams@intel.com>
      CC: Dave Jiang <dave.jiang@intel.com>
      CC: elliott@hpe.com
      CC: "H. Peter Anvin" <hpa@zytor.com>
      CC: Ingo Molnar <mingo@redhat.com>
      CC: Len Brown <lenb@kernel.org>
      CC: linux-acpi@vger.kernel.org
      CC: linux-edac <linux-edac@vger.kernel.org>
      CC: linux-nvdimm@lists.01.org
      CC: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      CC: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      CC: Ross Zwisler <zwisler@kernel.org>
      CC: stable <stable@vger.kernel.org>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: Tony Luck <tony.luck@intel.com>
      CC: x86-ml <x86@kernel.org>
      CC: Yazen Ghannam <yazen.ghannam@amd.com>
      Link: http://lkml.kernel.org/r/20181026003729.8420-1-vishal.l.verma@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9013ac4d
    • M
      mach64: fix image corruption due to reading accelerator registers · 3690f530
      Mikulas Patocka 提交于
      commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.
      
      Reading the registers without waiting for engine idle returns
      unpredictable values. These unpredictable values result in display
      corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
      bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
      never ever clear the bit, resulting in display corruption.
      
      We don't want to wait for idle because it would degrade performance, so
      this patch modifies the driver so that it never reads accelerator
      registers.
      
      HOST_CNTL doesn't have to be read, we can just write it with
      HOST_BYTE_ALIGN because no other part of the driver cares if
      HOST_BYTE_ALIGN is set.
      
      DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
      with the default value and in atyfb_imageblit with the value set according
      to the source image data.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: NVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3690f530
    • M
      mach64: fix display corruption on big endian machines · 215c5598
      Mikulas Patocka 提交于
      commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.
      
      The code for manual bit triple is not endian-clean. It builds the variable
      "hostdword" using byte accesses, therefore we must read the variable with
      "le32_to_cpu".
      
      The patch also enables (hardware or software) bit triple only if the image
      is monochrome (image->depth). If we want to blit full-color image, we
      shouldn't use the triple code.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Reviewed-by: NVille Syrjälä <syrjala@sci.fi>
      Cc: stable@vger.kernel.org
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      215c5598
    • D
      thermal: core: Fix use-after-free in thermal_cooling_device_destroy_sysfs · 2561c45b
      Dmitry Osipenko 提交于
      commit 3c587768271e9c20276522025729e4ebca51583b upstream.
      
      This patch fixes use-after-free that was detected by KASAN. The bug is
      triggered on a CPUFreq driver module unload by freeing 'cdev' on device
      unregister and then using the freed structure during of the cdev's sysfs
      data destruction. The solution is to unregister the sysfs at first, then
      destroy sysfs data and finally release the cooling device.
      
      Cc: <stable@vger.kernel.org> # v4.17+
      Fixes: 8ea22951 ("thermal: Add cooling device's statistics in sysfs")
      Signed-off-by: NDmitry Osipenko <digetx@gmail.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2561c45b
    • Y
      Revert "ceph: fix dentry leak in splice_dentry()" · e2496105
      Yan, Zheng 提交于
      commit efe328230dc01aa0b1269aad0b5fae73eea4677a upstream.
      
      This reverts commit 8b8f53af.
      
      splice_dentry() is used by three places. For two places, req->r_dentry
      is passed to splice_dentry(). In the case of error, req->r_dentry does
      not get updated. So splice_dentry() should not drop reference.
      
      Cc: stable@vger.kernel.org # 4.18+
      Signed-off-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2496105
    • I
      libceph: bump CEPH_MSG_MAX_DATA_LEN · 542705af
      Ilya Dryomov 提交于
      commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
      
      If the read is large enough, we end up spinning in the messenger:
      
        libceph: osd0 192.168.122.1:6801 io error
        libceph: osd0 192.168.122.1:6801 io error
        libceph: osd0 192.168.122.1:6801 io error
      
      This is a receive side limit, so only reads were affected.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      542705af
    • E
      clk: rockchip: Fix static checker warning in rockchip_ddrclk_get_parent call · 72872e36
      Enric Balletbo i Serra 提交于
      commit 665636b2940d0897c4130253467f5e8c42eea392 upstream.
      
      Fixes the signedness bug returning '(-22)' on the return type by removing the
      sanity checker in rockchip_ddrclk_get_parent(). The function should return
      and unsigned value only and it's safe to remove the sanity checker as the
      core functions that call get_parent like clk_core_get_parent_by_index already
      ensures the validity of the clk index returned (index >= core->num_parents).
      
      Fixes: a4f182bf ("clk: rockchip: add new clock-type for the ddrclk")
      Cc: stable@vger.kernel.org
      Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Reviewed-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72872e36
    • Z
      clk: rockchip: fix wrong mmc sample phase shift for rk3328 · a3eeeed1
      Ziyuan Xu 提交于
      commit 82f4b67f018c88a7cc9337f0067ed3d6ec352648 upstream.
      
      mmc sample shift is 0 for RK3328 referring to the TRM.
      So fix them.
      
      Fixes: fe3511ad ("clk: rockchip: add clock controller for rk3328")
      Cc: stable@vger.kernel.org
      Signed-off-by: NZiyuan Xu <xzy.xu@rock-chips.com>
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3eeeed1
    • I
      clk: sunxi-ng: h6: fix bus clocks' divider position · 1a2502d3
      Icenowy Zheng 提交于
      commit 2852bfbf4f168fec27049ad9ed20941fc9e84b95 upstream.
      
      The bus clocks (AHB/APB) on Allwinner H6 have their second divider start
      at bit 8, according to the user manual and the BSP code. However,
      currently the divider offset is incorrectly set to 16, thus the divider
      is not correctly read and the clock frequency is not correctly calculated.
      
      Fix this bit offset on all affected bus clocks in ccu-sun50i-h6.
      
      Cc: stable@vger.kernel.org # v4.17.y
      Signed-off-by: NIcenowy Zheng <icenowy@aosc.io>
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a2502d3
    • R
      clk: at91: Fix division by zero in PLL recalc_rate() · 11ace021
      Ronald Wahl 提交于
      commit 0f5cb0e6225cae2f029944cb8c74617aab6ddd49 upstream.
      
      Commit a982e45d ("clk: at91: PLL recalc_rate() now using cached MUL
      and DIV values") removed a check that prevents a division by zero. This
      now causes a stacktrace when booting the kernel on a at91 platform if
      the PLL DIV register contains zero. This commit reintroduces this check.
      
      Fixes: a982e45d ("clk: at91: PLL recalc_rate() now using cached...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRonald Wahl <rwahl@gmx.de>
      Acked-by: NLudovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11ace021
    • K
      clk: s2mps11: Fix matching when built as module and DT node contains compatible · 3d8c2945
      Krzysztof Kozlowski 提交于
      commit 8985167ecf57f97061599a155bb9652c84ea4913 upstream.
      
      When driver is built as module and DT node contains clocks compatible
      (e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
      module aliases won't match.
      
      The modalias from uevent: of:NclocksT<NULL>Csamsung,s2mps11-clk
      The modalias from driver: platform:s2mps11-clk
      
      The devices are instantiated by parent's MFD.  However both Device Tree
      bindings and parent define the compatible for clocks devices.  In case
      of module matching this DT compatible will be used.
      
      The issue will not happen if this is a built-in (no need for module
      matching) or when clocks DT node does not contain compatible (not
      correct from bindings perspective but working for driver).
      
      Note when backporting to stable kernels: adjust the list of device ID
      entries.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 53c31b34 ("mfd: sec-core: Add of_compatible strings for clock MFD cells")
      Signed-off-by: NKrzysztof Kozlowski <krzk@kernel.org>
      Acked-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NStephen Boyd <sboyd@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d8c2945
    • R
      um: Drop own definition of PTRACE_SYSEMU/_SINGLESTEP · 4a0344c5
      Richard Weinberger 提交于
      commit 0676b957c24bfb6e495449ba7b7e72c5b5d79233 upstream.
      
      32bit UML used to define PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
      own its own because many years ago not all libcs had these request codes
      in their UAPI.
      These days PTRACE_SYSEMU/_SINGLESTEP is well known and part of glibc
      and our own define becomes problematic.
      
      With change c48831d0eebf ("linux/x86: sync sys/ptrace.h with Linux 4.14
      [BZ #22433]") glibc turned PTRACE_SYSEMU/_SINGLESTEP into a enum and
      UML failed to build.
      
      Let's drop our define and rely on the fact that every libc has
      PTRACE_SYSEMU/_SINGLESTEP.
      
      Cc: <stable@vger.kernel.org>
      Cc: Ritesh Raj Sarraf <rrs@researchut.com>
      Reported-and-tested-by: NRitesh Raj Sarraf <rrs@researchut.com>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a0344c5
    • M
      xtensa: fix boot parameters address translation · 3ad5f233
      Max Filippov 提交于
      commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
      
      The bootloader may pass physical address of the boot parameters structure
      to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in
      the arch/xtensa/kernel/head.S is supposed to map that physical address to
      the virtual address in the configured virtual memory layout.
      
      This code haven't been updated when additional 256+256 and 512+512
      memory layouts were introduced and it may produce wrong addresses when
      used with these layouts.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ad5f233
    • M
      xtensa: make sure bFLT stack is 16 byte aligned · 591dd5df
      Max Filippov 提交于
      commit 0773495b1f5f1c5e23551843f87b5ff37e7af8f7 upstream.
      
      Xtensa ABI requires stack alignment to be at least 16. In noMMU
      configuration ARCH_SLAB_MINALIGN is used to align stack. Make it at
      least 16.
      
      This fixes the following runtime error in noMMU configuration, caused by
      interaction between insufficiently aligned stack and alloca function,
      that results in corruption of on-stack variable in the libc function
      glob:
      
       Caught unhandled exception in 'sh' (pid = 47, pc = 0x02d05d65)
        - should not happen
        EXCCAUSE is 15
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      591dd5df
    • M
      xtensa: add NOTES section to the linker script · 47af963b
      Max Filippov 提交于
      commit 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 upstream.
      
      This section collects all source .note.* sections together in the
      vmlinux image. Without it .note.Linux section may be placed at address
      0, while the rest of the kernel is at its normal address, resulting in a
      huge vmlinux.bin image that may not be linked into the xtensa Image.elf.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47af963b