summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-01-17Merge tag 'gpio-v5.5-4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO fixes from Linus Walleij: "This reverts the GPIOLIB_IRQCHIP in the ThunderX driver. ThunderX is a piece of Arm-based server chip. I converted the driver to hierarchical gpiochip without access to real silicon and failed miserably since I didn't take MSI's into account. Kevin Hao helpfully stepped in and fixed it properly, let's revert it for v5.5 and put the proper conversion into v5.6" * tag 'gpio-v5.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: Revert "gpio: thunderx: Switch to GPIOLIB_IRQCHIP"
2020-01-17Merge tag 'block-5.5-2020-01-16' of git://git.kernel.dk/linux-blockLinus Torvalds
Pull block fixes from Jens Axboe: "Three fixes that should go into this release: - The 32-bit segment size fix that I mentioned last week (Ming) - Use uint for the block size (Mikulas) - A null_blk zone write handling fix (Damien)" * tag 'block-5.5-2020-01-16' of git://git.kernel.dk/linux-block: block: fix an integer overflow in logical block size null_blk: Fix zone write handling block: fix get_max_segment_size() overflow on 32bit arch
2020-01-17x86/apic/uv: Avoid unused variable warningArnd Bergmann
When CONFIG_PROC_FS is disabled, the compiler warns about an unused variable: arch/x86/kernel/apic/x2apic_uv_x.c: In function 'uv_setup_proc_files': arch/x86/kernel/apic/x2apic_uv_x.c:1546:8: error: unused variable 'name' [-Werror=unused-variable] char *name = hubless ? "hubless" : "hubbed"; Simplify the code so this variable is no longer needed. Fixes: 8785968bce1c ("x86/platform/uv: Add UV Hubbed/Hubless Proc FS Files") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20191212140419.315264-1-arnd@arndb.de
2020-01-17arm64: entry: cleanup sp_el0 manipulationMark Rutland
The kernel stashes the current task struct in sp_el0 so that this can be acquired consistently/cheaply when required. When we take an exception from EL0 we have to: 1) stash the original sp_el0 value 2) find the current task 3) update sp_el0 with the current task pointer Currently steps #1 and #2 occur in one place, and step #3 a while later. As the value of sp_el0 is immaterial between these points, let's move them together to make the code clearer and minimize ifdeffery. This necessitates moving the comment for MDSCR_EL1.SS. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: entry: cleanup el0 svc handler namingMark Rutland
For most of the exception entry code, <foo>_handler() is the first C function called from the entry assembly in entry-common.c, and external functions handling the bulk of the logic are called do_<foo>(). For consistency, apply this scheme to el0_svc_handler and el0_svc_compat_handler, renaming them to do_el0_svc and do_el0_svc_compat respectively. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: entry: mark all entry code as notraceMark Rutland
Almost all functions in entry-common.c are marked notrace, with el1_undef and el1_inv being the only exceptions. We appear to have done this on the assumption that there were no exception registers that we needed to snapshot, and thus it was safe to run trace code that might result in further exceptions and clobber those registers. However, until we inherit the DAIF flags, our irq flag tracing is stale, and this discrepancy could set off warnings in some configurations. For example if CONFIG_DEBUG_LOCKDEP is selected and a trace function calls into any flag-checking locking routines. Given we don't expect to trigger el1_undef or el1_inv unless something is already wrong, any irqflag warnigns are liable to mask the information we'd actually care about. Let's keep things simple and mark el1_undef and el1_inv as notrace. Developers can trace do_undefinstr and bad_mode if they really want to monitor these cases. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: assembler: remove smp_dmb macroMark Rutland
These days arm64 kernels are always SMP, and thus smp_dmb is an overly-long way of writing dmb. Naturally, no-one uses it. Remove the unused macro. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: assembler: remove inherit_daif macroMark Rutland
We haven't needed the inherit_daif macro since commit: ed3768db588291dd ("arm64: entry: convert el1_sync to C") ... which converted all callers to C and the local_daif_inherit function. Remove the unused macro. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17ACPI/IORT: Fix 'Number of IDs' handling in iort_id_map()Hanjun Guo
The IORT specification [0] (Section 3, table 4, page 9) defines the 'Number of IDs' as 'The number of IDs in the range minus one'. However, the IORT ID mapping function iort_id_map() treats the 'Number of IDs' field as if it were the full IDs mapping count, with the following check in place to detect out of boundary input IDs: InputID >= Input base + Number of IDs This check is flawed in that it considers the 'Number of IDs' field as the full number of IDs mapping and disregards the 'minus one' from the IDs count. The correct check in iort_id_map() should be implemented as: InputID > Input base + Number of IDs this implements the specification correctly but unfortunately it breaks existing firmwares that erroneously set the 'Number of IDs' as the full IDs mapping count rather than IDs mapping count minus one. e.g. PCI hostbridge mapping entry 1: Input base: 0x1000 ID Count: 0x100 Output base: 0x1000 Output reference: 0xC4 //ITS reference PCI hostbridge mapping entry 2: Input base: 0x1100 ID Count: 0x100 Output base: 0x2000 Output reference: 0xD4 //ITS reference Two mapping entries which the second entry's Input base = the first entry's Input base + ID count, so for InputID 0x1100 and with the correct InputID check in place in iort_id_map() the kernel would map the InputID to ITS 0xC4 not 0xD4 as it would be expected. Therefore, to keep supporting existing flawed firmwares, introduce a workaround that instructs the kernel to use the old InputID range check logic in iort_id_map(), so that we can support both firmwares written with the flawed 'Number of IDs' logic and the correct one as defined in the specifications. [0]: http://infocenter.arm.com/help/topic/com.arm.doc.den0049d/DEN0049D_IO_Remapping_Table.pdf Reported-by: Pankaj Bansal <pankaj.bansal@nxp.com> Link: https://lore.kernel.org/linux-acpi/20191215203303.29811-1-pankaj.bansal@nxp.com/ Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Pankaj Bansal <pankaj.bansal@nxp.com> Cc: Will Deacon <will@kernel.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17mm: Reserve asm-generic prot flags 0x10 and 0x20 for arch useDave Martin
The asm-generic/mman.h definitions are used by a few architectures that also define arch-specific PROT flags with value 0x10 and 0x20. This currently applies to sparc and powerpc for 0x10, while arm64 will soon join with 0x10 and 0x20. To help future maintainers, document the use of this flag in the asm-generic header too. Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dave Martin <Dave.Martin@arm.com> [catalin.marinas@arm.com: reserve 0x20 as well] Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: Use macros instead of hard-coded constants for MAIR_EL1Catalin Marinas
Currently, the arm64 __cpu_setup has hard-coded constants for the memory attributes that go into the MAIR_EL1 register. Define proper macros in asm/sysreg.h and make use of them in proc.S. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17arm64: Add KRYO{3,4}XX CPU cores to spectre-v2 safe listSai Prakash Ranjan
The "silver" KRYO3XX and KRYO4XX CPU cores are not affected by Spectre variant 2. Add them to spectre_v2 safe list to correct the spurious ARM_SMCCC_ARCH_WORKAROUND_1 warning and vulnerability status reported under sysfs. Reviewed-by: Stephen Boyd <swboyd@chromium.org> Tested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> [will: tweaked commit message to remove stale mention of "gold" cores] Signed-off-by: Will Deacon <will@kernel.org>
2020-01-17net: systemport: Fixed queue mapping in internal ring mapFlorian Fainelli
We would not be transmitting using the correct SYSTEMPORT transmit queue during ndo_select_queue() which looks up the internal TX ring map because while establishing the mapping we would be off by 4, so for instance, when we populate switch port mappings we would be doing: switch port 0, queue 0 -> ring index #0 switch port 0, queue 1 -> ring index #1 ... switch port 0, queue 3 -> ring index #3 switch port 1, queue 0 -> ring index #8 (4 + 4 * 1) ... instead of using ring index #4. This would cause our ndo_select_queue() to use the fallback queue mechanism which would pick up an incorrect ring for that switch port. Fix this by using the correct switch queue number instead of SYSTEMPORT queue number. Fixes: 25c440704661 ("net: systemport: Simplify queue mapping logic") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: bcm_sf2: Configure IMP port for 2Gb/secFlorian Fainelli
With the implementation of the system reset controller we lost a setting that is currently applied by the bootloader and which configures the IMP port for 2Gb/sec, the default is 1Gb/sec. This is needed given the number of ports and applications we expect to run so bring back that setting. Fixes: 01b0ac07589e ("net: dsa: bcm_sf2: Add support for optional reset controller line") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17netns: Constify exported functionsGuillaume Nault
Mark function parameters as 'const' where possible. Signed-off-by: Guillaume Nault <gnault@redhat.com> Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: sja1105: Don't error out on disabled ports with no phy-modeVladimir Oltean
The sja1105_parse_ports_node function was tested only on device trees where all ports were enabled. Fix this check so that the driver continues to probe only with the ports where status is not "disabled", as expected. Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Don't error out on disabled ports with no phy-modeVladimir Oltean
The felix_parse_ports_node function was tested only on device trees where all ports were enabled. Fix this check so that the driver continues to probe only with the ports where status is not "disabled", as expected. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Don't restart PCS SGMII AN if not neededAlex Marginean
Some PHYs like VSC8234 don't like it when AN restarts on their system side and they restart line side AN too, going into an endless link up/down loop. Don't restart PCS AN if link is up already. Although in theory this feedback loop should be possible with the other in-band AN modes too, for some reason it was not seen with the VSC8514 QSGMII and AQR412 USXGMII PHYs. So keep this logic only for SGMII where the problem was found. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Suggested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: dsa: felix: Set USXGMII link based on BMSR, not LPAAlex Marginean
At least some PHYs (AQR412) don't advertise copper-side link status during system side AN. So remove this duplicate assignment to pcs->link and rely on the previous one for link state: the local indication from the MAC PCS. Fixes: bdeced75b13f ("net: dsa: felix: Add PCS operations for PHYLINK") Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17Documentation: Fix typo in devlink documentationIdo Schimmel
The driver is named "mlxsw", not "mlx5". Fixes: d4255d75856f ("devlink: document info versions for each driver") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17EDAC/amd64: Do not warn when removing instancesBorislav Petkov
On machines which do not populate all nodes with DIMMs, the driver doesn't initialize an instance there. However, the instance removal remove_one_instance() path will warn unconditionally, which is wrong. Remove the WARN_ON() even if the warning is innocent because it causes a splat in dmesg. Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200117115939.5524-1-bp@alien8.de
2020-01-17enetc: Don't print from enetc_sched_speed_set when link goes downVladimir Oltean
It is not an error to unplug a cable from the ENETC port even with TSN offloads, so don't spam the log with link-related messages from the tc-taprio offload subsystem, a single notification is sufficient: [10972.351859] fsl_enetc 0000:00:00.0 eno0: Qbv PSPEED set speed link down. [10972.360241] fsl_enetc 0000:00:00.0 eno0: Link is Down Fixes: 2e47cb415f0a ("enetc: update TSN Qbv PSPEED set according to adjust link speed") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17ALSA: hda/realtek - Add Headset Mic supported for HP cPCKailang Yang
HP ALC671 need to support Headset Mic. Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/r/06a9d2b176e14706976d6584cbe2d92a@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-17USB: serial: garmin_gps: Use flexible-array memberGustavo A. R. Silva
Old code in the kernel uses 1-byte and 0-byte arrays to indicate the presence of a "variable length array": struct something { int length; u8 data[1]; }; struct something *instance; instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); instance->length = size; memcpy(instance->data, source, size); There is also 0-byte arrays. Both cases pose confusion for things like sizeof(), CONFIG_FORTIFY_SOURCE, etc.[1] Instead, the preferred mechanism to declare variable-length types such as the one above is a flexible array member[2] which need to be the last member of a structure and empty-sized: struct something { int stuff; u8 data[]; }; Also, by making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being unadvertenly introduced[3] to the codebase from now on. [1] https://github.com/KSPP/linux/issues/21 [2] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17net: phy: adin: const-ify static dataAlexandru Ardelean
Some bits of static data should have been made const from the start. This change adds the const qualifier where appropriate. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: phy: dp83867: Set FORCE_LINK_GOOD to default after resetMichael Grzeschik
According to the Datasheet this bit should be 0 (Normal operation) in default. With the FORCE_LINK_GOOD bit set, it is not possible to get a link. This patch sets FORCE_LINK_GOOD to the default value after resetting the phy. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17perf/x86/intel/uncore: Remove PCIe3 unit for SNRKan Liang
The PCIe Root Port driver for CPU Complex PCIe Root Ports are not loaded on SNR. The device ID for SNR PCIe3 unit is used by both uncore driver and the PCIe Root Port driver. If uncore driver is loaded, the PCIe Root Port driver never be probed. Remove the PCIe3 unit for SNR for now. The support for PCIe3 unit will be added later separately. Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lkml.kernel.org/r/20200116200210.18937-2-kan.liang@linux.intel.com
2020-01-17perf/x86/intel/uncore: Fix missing marker for snr_uncore_imc_freerunning_eventsKan Liang
An Oops during the boot is found on some SNR machines. It turns out this is because the snr_uncore_imc_freerunning_events[] array was missing an end-marker. Fixes: ee49532b38dd ("perf/x86/intel/uncore: Add IMC uncore support for Snow Ridge") Reported-by: Like Xu <like.xu@linux.intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Like Xu <like.xu@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20200116200210.18937-1-kan.liang@linux.intel.com
2020-01-17perf/x86/intel/uncore: Add PCI ID of IMC for Xeon E3 V5 FamilyKan Liang
The IMC uncore support is missed for E3-1585 v5 CPU. Intel Xeon E3 V5 Family has Sky Lake CPU. Add the PCI ID of IMC for Intel Xeon E3 V5 Family. Reported-by: Rosales-fernandez, Carlos <carlos.rosales-fernandez@intel.com> Signed-off-by: Kan Liang <kan.liang@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Rosales-fernandez, Carlos <carlos.rosales-fernandez@intel.com> Link: https://lkml.kernel.org/r/1578687311-158748-1-git-send-email-kan.liang@linux.intel.com
2020-01-17perf: Correctly handle failed perf_get_aux_event()Mark Rutland
Vince reports a worrying issue: | so I was tracking down some odd behavior in the perf_fuzzer which turns | out to be because perf_even_open() sometimes returns 0 (indicating a file | descriptor of 0) even though as far as I can tell stdin is still open. ... and further the cause: | error is triggered if aux_sample_size has non-zero value. | | seems to be this line in kernel/events/core.c: | | if (perf_need_aux_event(event) && !perf_get_aux_event(event, group_leader)) | goto err_locked; | | (note, err is never set) This seems to be a thinko in commit: ab43762ef010967e ("perf: Allow normal events to output AUX data") ... and we should probably return -EINVAL here, as this should only happen when the new event is mis-configured or does not have a compatible aux_event group leader. Fixes: ab43762ef010967e ("perf: Allow normal events to output AUX data") Reported-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by: Vince Weaver <vincent.weaver@maine.edu>
2020-01-17USB: serial: opticon: stop all I/O on close()Johan Hovold
Make sure to stop any submitted write URBs on close(). Note that the tty layer will wait up to 30 seconds for the buffers to drain before close() is called. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17USB: serial: opticon: add chars_in_buffer() implementationJohan Hovold
Add a chars_in_buffer() implementation so that the tty layer will wait for outgoing buffered data to be drained when needed (e.g. on final close()). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17drivers/net: netdevsim depends on INETHongbo Yao
If CONFIG_INET is not set and CONFIG_NETDEVSIM=y. Building drivers/net/netdevsim/fib.o will get the following error: drivers/net/netdevsim/fib.o: In function `nsim_fib4_rt_hw_flags_set': fib.c:(.text+0x12b): undefined reference to `fib_alias_hw_flags_set' drivers/net/netdevsim/fib.o: In function `nsim_fib4_rt_destroy': fib.c:(.text+0xb11): undefined reference to `free_fib_info' Correct the Kconfig for netdevsim. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 48bb9eb47b270 ("netdevsim: fib: Add dummy implementation for FIB offload") Signed-off-by: Hongbo Yao <yaohongbo@huawei.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17Merge tag 'devfreq-next-for-5.6' of ↵Rafael J. Wysocki
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux Pull devfreq updates for v5.6 from Chanwoo Choi: "1. Update devfreq core - Add new 'name' attribute of sysfs to show the device name : /sys/class/devfreq/devfreqX/name - Make 'trans_stat' sysfs reset by entering zero(0) : echo 0 > /sys/class/devfreq/devfreqX/trans_stat - Add debugfs support with 'devfreq_summary' to show the summary : /sys/kernel/debug/devfreq/devfreq_summary - Change the type of time variable to 64bit to avoid overflows. - Make separate devfreq_stats including the statistics information. - Fix minor coding-style like indentation and kernel-doc warnings. 2. Update devfreq drivers - Add new imx8m-ddrc.c devfreq driver for dynamic scaling of DDR frequency. It changes the DDR frequency by using ARM SMCCC(SMC Calling Convention) interface to control TF-A firmware. - Add COMPILE_TEST dependency for rk3399_dmc.c. - Clean-up code for exynos-bus.c and rk3399_dmc.c without behavior changes 3. Update devfreq-event drivers - Fix excessive stack usage of exynos-ppmu.c and clean-up code of rockchip-dfi.c without behavior changes." * tag 'devfreq-next-for-5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux: (24 commits) PM / devfreq: Add debugfs support with devfreq_summary file PM / devfreq: exynos: Rename Exynos to lowercase PM / devfreq: imx8m-ddrc: Fix inconsistent IS_ERR and PTR_ERR PM / devfreq: exynos-bus: Add error log when fail to get devfreq-event PM / devfreq: exynos-bus: Disable devfreq-event device when fails PM / devfreq: rk3399_dmc: Disable devfreq-event device when fails PM / devfreq: imx8m-ddrc: Remove unused defines PM / devfreq: exynos-bus: Reduce goto statements and remove unused headers PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency PM / devfreq: rockchip-dfi: Convert to devm_platform_ioremap_resource PM / devfreq: rk3399_dmc: Add missing of_node_put() PM / devfreq: rockchip-dfi: Add missing of_node_put() PM / devfreq: Fix multiple kernel-doc warnings PM / devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() PM / devfreq: exynos-bus: Extract exynos_bus_profile_init() PM / devfreq: Move declaration of DEVICE_ATTR_RW(min_freq) PM / devfreq: Move statistics to separate struct devfreq_stats PM / devfreq: Add clearing transitions stats PM / devfreq: Change time stats to 64-bit PM / devfreq: Add new name attribute for sysfs ...
2020-01-17watchdog/softlockup: Enforce that timestamp is valid on bootThomas Gleixner
Robert reported that during boot the watchdog timestamp is set to 0 for one second which is the indicator for a watchdog reset. The reason for this is that the timestamp is in seconds and the time is taken from sched clock and divided by ~1e9. sched clock starts at 0 which means that for the first second during boot the watchdog timestamp is 0, i.e. reset. Use ULONG_MAX as the reset indicator value so the watchdog works correctly right from the start. ULONG_MAX would only conflict with a real timestamp if the system reaches an uptime of 136 years on 32bit and almost eternity on 64bit. Reported-by: Robert Richter <rrichter@marvell.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/87o8v3uuzl.fsf@nanos.tec.linutronix.de
2020-01-17net: hns: fix soft lockup when there is not enough memoryYonglong Liu
When there is not enough memory and napi_alloc_skb() return NULL, the HNS driver will print error message, and than try again, if the memory is not enough for a while, huge error message and the retry operation will cause soft lockup. When napi_alloc_skb() return NULL because of no memory, we can get a warn_alloc() call trace, so this patch deletes the error message. We already use polling mode to handle irq, but the retry operation will render the polling weight inactive, this patch just return budget when the rx is not completed to avoid dead loop. Fixes: 36eedfde1a36 ("net: hns: Optimize hns_nic_common_poll for better performance") Fixes: b5996f11ea54 ("net: add Hisilicon Network Subsystem basic ethernet support") Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: phy: Maintain MDIO device and bus statisticsFlorian Fainelli
We maintain global statistics for an entire MDIO bus, as well as broken down, per MDIO bus address statistics. Given that it is possible for MDIO devices such as switches to access MDIO bus addresses for which there is not a mdio_device instance created (therefore not a a corresponding device directory in sysfs either), we also maintain per-address statistics under the statistics folder. The layout looks like this: /sys/class/mdio_bus/../statistics/ transfers errrors writes reads transfers_<addr> errors_<addr> writes_<addr> reads_<addr> When a mdio_device instance is registered, a statistics/ folder is created with the tranfers, errors, writes and reads attributes which point to the appropriate MDIO bus statistics structure. Statistics are 64-bit unsigned quantities and maintained through the u64_stats_sync.h helper functions. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17livepatch: Handle allocation failure in the sample of shadow variable APIPetr Mladek
klp_shadow_alloc() is not handled in the sample of shadow variable API. It is not strictly necessary because livepatch_fix1_dummy_free() is able to handle the potential failure. But it is an example and it should use the API a clean way. Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-17livepatch/samples/selftest: Use klp_shadow_alloc() API correctlyPetr Mladek
The commit e91c2518a5d22a ("livepatch: Initialize shadow variables safely by a custom callback") leads to the following static checker warning: samples/livepatch/livepatch-shadow-fix1.c:86 livepatch_fix1_dummy_alloc() error: 'klp_shadow_alloc()' 'leak' too small (4 vs 8) It is because klp_shadow_alloc() is used a wrong way: int *leak; shadow_leak = klp_shadow_alloc(d, SV_LEAK, sizeof(leak), GFP_KERNEL, shadow_leak_ctor, leak); The code is supposed to store the "leak" pointer into the shadow variable. 3rd parameter correctly passes size of the data (size of pointer). But the 5th parameter is wrong. It should pass pointer to the data (pointer to the pointer) but it passes the pointer directly. It works because shadow_leak_ctor() handle "ctor_data" as the data instead of pointer to the data. But it is semantically wrong and confusing. The same problem is also in the module used by selftests. In this case, "pvX" variables are introduced. They represent the data stored in the shadow variables. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-17livepatch/selftest: Clean up shadow variable names and typePetr Mladek
The shadow variable selftest is quite tricky. Especially it is problematic to understand what values are stored, returned, and printed. Make it easier to understand by using "int *var, **sv" variables consistently everywhere instead of the generic "void *", "ret", and "ctor_data". Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-17livepatch/sample: Use the right type for the leaking data pointerPetr Mladek
The "leak" pointer, in the sample of shadow variable API, is allocated as sizeof(int). Let's help developers and static analyzers with understanding the code by using the appropriate pointer type. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Joe Lawrence <joe.lawrence@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2020-01-17USB: serial: suppress driver bind attributesJohan Hovold
USB-serial drivers must not be unbound from their ports before the corresponding USB driver is unbound from the parent interface so suppress the bind and unbind attributes. Unbinding a serial driver while it's port is open is a sure way to trigger a crash as any driver state is released on unbind while port hangup is handled on the parent USB interface level. Drivers for multiport devices where ports share a resource such as an interrupt endpoint also generally cannot handle individual ports going away. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2020-01-17net: avoid updating qdisc_xmit_lock_key in netdev_update_lockdep_key()Cong Wang
syzbot reported some bogus lockdep warnings, for example bad unlock balance in sch_direct_xmit(). They are due to a race condition between slow path and fast path, that is qdisc_xmit_lock_key gets re-registered in netdev_update_lockdep_key() on slow path, while we could still acquire the queue->_xmit_lock on fast path in this small window: CPU A CPU B __netif_tx_lock(); lockdep_unregister_key(qdisc_xmit_lock_key); __netif_tx_unlock(); lockdep_register_key(qdisc_xmit_lock_key); In fact, unlike the addr_list_lock which has to be reordered when the master/slave device relationship changes, queue->_xmit_lock is only acquired on fast path and only when NETIF_F_LLTX is not set, so there is likely no nested locking for it. Therefore, we can just get rid of re-registration of qdisc_xmit_lock_key. Reported-by: syzbot+4ec99438ed7450da6272@syzkaller.appspotmail.com Fixes: ab92d68fc22f ("net: core: add generic lockdep keys") Cc: Taehee Yoo <ap420073@gmail.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17netdevsim: fix nsim_fib6_rt_create() error pathEric Dumazet
It seems nsim_fib6_rt_create() intent was to return either a valid pointer or an embedded error code. BUG: unable to handle page fault for address: fffffffffffffff4 PGD 9870067 P4D 9870067 PUD 9872067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 22851 Comm: syz-executor.1 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:jhash2 include/linux/jhash.h:125 [inline] RIP: 0010:rhashtable_jhash2+0x76/0x2c0 lib/rhashtable.c:963 Code: b9 00 00 00 00 00 fc ff df 48 c1 e8 03 0f b6 14 08 4c 89 f0 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 30 02 00 00 49 8d 7e 04 <41> 8b 06 48 be 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 RSP: 0018:ffffc90016127190 EFLAGS: 00010246 RAX: 0000000000000007 RBX: 00000000dfb3ab49 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffffffff839ba7c8 RDI: fffffffffffffff8 RBP: ffffc900161271c0 R08: ffff8880951f8640 R09: ffffed1015d0703d R10: ffffed1015d0703c R11: ffff8880ae8381e3 R12: 00000000dfb3ab49 R13: 00000000dfb3ab49 R14: fffffffffffffff4 R15: 0000000000000007 FS: 00007f40bfbc6700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffff4 CR3: 0000000093660000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rht_key_get_hash include/linux/rhashtable.h:133 [inline] rht_key_hashfn include/linux/rhashtable.h:159 [inline] rht_head_hashfn include/linux/rhashtable.h:174 [inline] __rhashtable_insert_fast.constprop.0+0xe15/0x1180 include/linux/rhashtable.h:723 rhashtable_insert_fast include/linux/rhashtable.h:832 [inline] nsim_fib6_rt_add drivers/net/netdevsim/fib.c:603 [inline] nsim_fib6_rt_insert drivers/net/netdevsim/fib.c:658 [inline] nsim_fib6_event drivers/net/netdevsim/fib.c:719 [inline] nsim_fib_event drivers/net/netdevsim/fib.c:744 [inline] nsim_fib_event_nb+0x1b16/0x2600 drivers/net/netdevsim/fib.c:772 notifier_call_chain+0xc2/0x230 kernel/notifier.c:83 __atomic_notifier_call_chain+0xa6/0x1a0 kernel/notifier.c:173 atomic_notifier_call_chain+0x2e/0x40 kernel/notifier.c:183 call_fib_notifiers+0x173/0x2a0 net/core/fib_notifier.c:35 call_fib6_notifiers+0x4b/0x60 net/ipv6/fib6_notifier.c:22 call_fib6_entry_notifiers+0xfb/0x150 net/ipv6/ip6_fib.c:399 fib6_add_rt2node net/ipv6/ip6_fib.c:1216 [inline] fib6_add+0x20cd/0x3ec0 net/ipv6/ip6_fib.c:1471 __ip6_ins_rt+0x54/0x80 net/ipv6/route.c:1315 ip6_ins_rt+0x96/0xd0 net/ipv6/route.c:1325 __ipv6_dev_ac_inc+0x76f/0xb20 net/ipv6/anycast.c:324 ipv6_sock_ac_join+0x4c1/0x790 net/ipv6/anycast.c:139 do_ipv6_setsockopt.isra.0+0x3908/0x4290 net/ipv6/ipv6_sockglue.c:670 ipv6_setsockopt+0xff/0x180 net/ipv6/ipv6_sockglue.c:944 udpv6_setsockopt+0x68/0xb0 net/ipv6/udp.c:1564 sock_common_setsockopt+0x94/0xd0 net/core/sock.c:3149 __sys_setsockopt+0x261/0x4c0 net/socket.c:2130 __do_sys_setsockopt net/socket.c:2146 [inline] __se_sys_setsockopt net/socket.c:2143 [inline] __x64_sys_setsockopt+0xbe/0x150 net/socket.c:2143 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45aff9 Fixes: 48bb9eb47b27 ("netdevsim: fib: Add dummy implementation for FIB offload") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Cc: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net/sched: act_ife: initalize ife->metalist earlierEric Dumazet
It seems better to init ife->metalist earlier in tcf_ife_init() to avoid the following crash : kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 10483 Comm: syz-executor216 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:_tcf_ife_cleanup net/sched/act_ife.c:412 [inline] RIP: 0010:tcf_ife_cleanup+0x6e/0x400 net/sched/act_ife.c:431 Code: 48 c1 ea 03 80 3c 02 00 0f 85 94 03 00 00 49 8b bd f8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8d 67 e8 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 5c 03 00 00 48 bb 00 00 00 00 00 fc ff df 48 8b RSP: 0018:ffffc90001dc6d00 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff864619c0 RCX: ffffffff815bfa09 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 RBP: ffffc90001dc6d50 R08: 0000000000000004 R09: fffff520003b8d8e R10: fffff520003b8d8d R11: 0000000000000003 R12: ffffffffffffffe8 R13: ffff8880a79fc000 R14: ffff88809aba0e00 R15: 0000000000000000 FS: 0000000001b51880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000563f52cce140 CR3: 0000000093541000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: tcf_action_cleanup+0x62/0x1b0 net/sched/act_api.c:119 __tcf_action_put+0xfa/0x130 net/sched/act_api.c:135 __tcf_idr_release net/sched/act_api.c:165 [inline] __tcf_idr_release+0x59/0xf0 net/sched/act_api.c:145 tcf_idr_release include/net/act_api.h:171 [inline] tcf_ife_init+0x97c/0x1870 net/sched/act_ife.c:616 tcf_action_init_1+0x6b6/0xa40 net/sched/act_api.c:944 tcf_action_init+0x21a/0x330 net/sched/act_api.c:1000 tcf_action_add+0xf5/0x3b0 net/sched/act_api.c:1410 tc_ctl_action+0x390/0x488 net/sched/act_api.c:1465 rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5424 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 ____sys_sendmsg+0x753/0x880 net/socket.c:2330 ___sys_sendmsg+0x100/0x170 net/socket.c:2384 __sys_sendmsg+0x105/0x1d0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg net/socket.c:2424 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: 11a94d7fd80f ("net/sched: act_ife: validate the control action inside init()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Cc: Davide Caratti <dcaratti@redhat.com> Reviewed-by: Davide Caratti <dcaratti@redhat.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17net: xen-netback: hash.c: Use built-in RCU list checkingMadhuparna Bhowmik
list_for_each_entry_rcu has built-in RCU and lock checking. Pass cond argument to list_for_each_entry_rcu. Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com> Acked-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller
Pablo Neira Ayuso says: ==================== Netfilter updates for net The following patchset contains Netfilter fixes for net: 1) Fix use-after-free in ipset bitmap destroy path, from Cong Wang. 2) Missing init netns in entry cleanup path of arp_tables, from Florian Westphal. 3) Fix WARN_ON in set destroy path due to missing cleanup on transaction error. 4) Incorrect netlink sanity check in tunnel, from Florian Westphal. 5) Missing sanity check for erspan version netlink attribute, also from Florian. 6) Remove WARN in nft_request_module() that can be triggered from userspace, from Florian Westphal. 7) Memleak in NFTA_HOOK_DEVS netlink parser, from Dan Carpenter. 8) List poison from commit path for flowtables that are added and deleted in the same batch, from Florian Westphal. 9) Fix NAT ICMP packet corruption, from Eyal Birger. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-17locking/osq: Use optimized spinning loop for arm64Waiman Long
Arm64 has a more optimized spinning loop (atomic_cond_read_acquire) using wfe for spinlock that can boost performance of sibling threads by putting the current cpu to a wait state that is broken only when the monitored variable changes or an external event happens. OSQ has a more complicated spinning loop. Besides the lock value, it also checks for need_resched() and vcpu_is_preempted(). The check for need_resched() is not a problem as it is only set by the tick interrupt handler. That will be detected by the spinning cpu right after iret. The vcpu_is_preempted() check, however, is a problem as changes to the preempt state of of previous node will not affect the wait state. For ARM64, vcpu_is_preempted is not currently defined and so is a no-op. Will has indicated that he is planning to para-virtualize wfe instead of defining vcpu_is_preempted for PV support. So just add a comment in arch/arm64/include/asm/spinlock.h to indicate that vcpu_is_preempted() should not be defined as suggested. On a 2-socket 56-core 224-thread ARM64 system, a kernel mutex locking microbenchmark was run for 10s with and without the patch. The performance numbers before patch were: Running locktest with mutex [runtime = 10s, load = 1] Threads = 224, Min/Mean/Max = 316/123,143/2,121,269 Threads = 224, Total Rate = 2,757 kop/s; Percpu Rate = 12 kop/s After patch, the numbers were: Running locktest with mutex [runtime = 10s, load = 1] Threads = 224, Min/Mean/Max = 334/147,836/1,304,787 Threads = 224, Total Rate = 3,311 kop/s; Percpu Rate = 15 kop/s So there was about 20% performance improvement. Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/20200113150735.21956-1-longman@redhat.com
2020-01-17locking/qspinlock: Fix inaccessible URL of MCS lock paperWaiman Long
It turns out that the URL of the MCS lock paper listed in the source code is no longer accessible. I did got question about where the paper was. This patch updates the URL to BZ 206115 which contains a copy of the paper from https://www.cs.rochester.edu/u/scott/papers/1991_TOCS_synch.pdf Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/20200107174914.4187-1-longman@redhat.com
2020-01-17locking/lockdep: Fix lockdep_stats indentation problemWaiman Long
It was found that two lines in the output of /proc/lockdep_stats have indentation problem: # cat /proc/lockdep_stats : in-process chains: 25057 stack-trace entries: 137827 [max: 524288] number of stack traces: 7973 number of stack hash chains: 6355 combined max dependencies: 1356414598 hardirq-safe locks: 57 hardirq-unsafe locks: 1286 : All the numbers displayed in /proc/lockdep_stats except the two stack trace numbers are formatted with a field with of 11. To properly align all the numbers, a field width of 11 is now added to the two stack trace numbers. Fixes: 8c779229d0f4 ("locking/lockdep: Report more stack trace statistics") Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://lkml.kernel.org/r/20191211213139.29934-1-longman@redhat.com