aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-09bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and collidingJohn Fastabend3-10/+38
Strparser is reusing the qdisc_skb_cb struct to stash the skb message handling progress, e.g. offset and length of the skb. First this is poorly named and inherits a struct from qdisc that doesn't reflect the actual usage of cb[] at this layer. But, more importantly strparser is using the following to access its metadata. (struct _strp_msg *)((void *)skb->cb + offsetof(struct qdisc_skb_cb, data)) Where _strp_msg is defined as: struct _strp_msg { struct strp_msg strp; /* 0 8 */ int accum_len; /* 8 4 */ /* size: 12, cachelines: 1, members: 2 */ /* last cacheline: 12 bytes */ }; So we use 12 bytes of ->data[] in struct. However in BPF code running parser and verdict the user has read capabilities into the data[] array as well. Its not too problematic, but we should not be exposing internal state to BPF program. If its really needed then we can use the probe_read() APIs which allow reading kernel memory. And I don't believe cb[] layer poses any API breakage by moving this around because programs can't depend on cb[] across layers. In order to fix another issue with a ctx rewrite we need to stash a temp variable somewhere. To make this work cleanly this patch builds a cb struct for sk_skb types called sk_skb_cb struct. Then we can use this consistently in the strparser, sockmap space. Additionally we can start allowing ->cb[] write access after this. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Jussi Maki <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-11-09bpf, sockmap: Fix race in ingress receive verdict with redirect to selfJohn Fastabend1-0/+47
A socket in a sockmap may have different combinations of programs attached depending on configuration. There can be no programs in which case the socket acts as a sink only. There can be a TX program in this case a BPF program is attached to sending side, but no RX program is attached. There can be an RX program only where sends have no BPF program attached, but receives are hooked with BPF. And finally, both TX and RX programs may be attached. Giving us the permutations: None, Tx, Rx, and TxRx To date most of our use cases have been TX case being used as a fast datapath to directly copy between local application and a userspace proxy. Or Rx cases and TxRX applications that are operating an in kernel based proxy. The traffic in the first case where we hook applications into a userspace application looks like this: AppA redirect AppB Tx <-----------> Rx | | + + TCP <--> lo <--> TCP In this case all traffic from AppA (after 3whs) is copied into the AppB ingress queue and no traffic is ever on the TCP recieive_queue. In the second case the application never receives, except in some rare error cases, traffic on the actual user space socket. Instead the send happens in the kernel. AppProxy socket pool sk0 ------------->{sk1,sk2, skn} ^ | | | | v ingress lb egress TCP TCP Here because traffic is never read off the socket with userspace recv() APIs there is only ever one reader on the sk receive_queue. Namely the BPF programs. However, we've started to introduce a third configuration where the BPF program on receive should process the data, but then the normal case is to push the data into the receive queue of AppB. AppB recv() (userspace) ----------------------- tcp_bpf_recvmsg() (kernel) | | | | | | ingress_msgQ | | | RX_BPF | | | v v sk->receive_queue This is different from the App{A,B} redirect because traffic is first received on the sk->receive_queue. Now for the issue. The tcp_bpf_recvmsg() handler first checks the ingress_msg queue for any data handled by the BPF rx program and returned with PASS code so that it was enqueued on the ingress msg queue. Then if no data exists on that queue it checks the socket receive queue. Unfortunately, this is the same receive_queue the BPF program is reading data off of. So we get a race. Its possible for the recvmsg() hook to pull data off the receive_queue before the BPF hook has a chance to read it. It typically happens when an application is banging on recv() and getting EAGAINs. Until they manage to race with the RX BPF program. To fix this we note that before this patch at attach time when the socket is loaded into the map we check if it needs a TX program or just the base set of proto bpf hooks. Then it uses the above general RX hook regardless of if we have a BPF program attached at rx or not. This patch now extends this check to handle all cases enumerated above, TX, RX, TXRX, and none. And to fix above race when an RX program is attached we use a new hook that is nearly identical to the old one except now we do not let the recv() call skip the RX BPF program. Now only the BPF program pulls data from sk->receive_queue and recv() only pulls data from the ingress msgQ post BPF program handling. With this resolved our AppB from above has been up and running for many hours without detecting any errors. We do this by correlating counters in RX BPF events and the AppB to ensure data is never skipping the BPF program. Selftests, was not able to detect this because we only run them for a short period of time on well ordered send/recvs so we don't get any of the noise we see in real application environments. Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Jussi Maki <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-11-09bpf, sockmap: Remove unhash handler for BPF sockmap usageJohn Fastabend1-1/+0
We do not need to handle unhash from BPF side we can simply wait for the close to happen. The original concern was a socket could transition from ESTABLISHED state to a new state while the BPF hook was still attached. But, we convinced ourself this is no longer possible and we also improved BPF sockmap to handle listen sockets so this is no longer a problem. More importantly though there are cases where unhash is called when data is in the receive queue. The BPF unhash logic will flush this data which is wrong. To be correct it should keep the data in the receive queue and allow a receiving application to continue reading the data. This may happen when tcp_abort() is received for example. Instead of complicating the logic in unhash simply moving all this to tcp_close() hook solves this. Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Jussi Maki <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-11-09bpf, sockmap: Use stricter sk state checks in sk_lookup_assignJohn Fastabend3-8/+16
In order to fix an issue with sockets in TCP sockmap redirect cases we plan to allow CLOSE state sockets to exist in the sockmap. However, the check in bpf_sk_lookup_assign() currently only invalidates sockets in the TCP_ESTABLISHED case relying on the checks on sockmap insert to ensure we never SOCK_CLOSE state sockets in the map. To prepare for this change we flip the logic in bpf_sk_lookup_assign() to explicitly test for the accepted cases. Namely, a tcp socket in TCP_LISTEN or a udp socket in TCP_CLOSE state. This also makes the code more resilent to future changes. Suggested-by: Jakub Sitnicki <[email protected]> Signed-off-by: John Fastabend <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Jakub Sitnicki <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-11-08Merge tag 'backlight-next-5.16' of ↵Linus Torvalds4-15/+22
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "Fix-ups: - Standardise *_exit() and *_remove() return values in ili9320 and vgg2432a4 Bug Fixes: - Do not override maximum brightness - Propagate errors from get_brightness()" * tag 'backlight-next-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: video: backlight: ili9320: Make ili9320_remove() return void backlight: Propagate errors from get_brightness() video: backlight: Drop maximum brightness override for brightness zero
2021-11-08Merge tag 'mfd-next-5.16' of ↵Linus Torvalds77-2200/+2120
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Removed Drivers: - Remove support for TI TPS80031/TPS80032 PMICs New Device Support: - Add support for Magnetic Reader to TI AM335x - Add support for DA9063_EA to Dialog DA9063 - Add support for SC2730 PMIC to Spreadtrum SC27xx - Add support for MacBookPro16,2 ICL-N UART Intel LPSS PCI - Add support for lots of new PMICS in QCom SPMI PMIC - Add support for ADC to Diolan DLN2 New Functionality: - Add support for Power Off to Rockchip RK817 Fix-ups: - Simplify Regmap passing to child devices in hi6421-spmi-pmic - SPDX licensing updates in ti_am335x_tscadc - Improve error handling in ti_am335x_tscadc - Expedite clock search in ti_am335x_tscadc - Generic simplifications in ti_am335x_tscadc - Use generic macros/defines in ti_am335x_tscadc - Remove unused code in ti_am335x_tscadc, cros_ec_dev - Convert to GPIOD in wcd934x - Add namespacing in ti_am335x_tscadc - Restrict compilation to relevant arches in intel_pmt - Provide better description/documentation in exynos_lpass - Add SPI device ID table in altera-a10sr, motorola-cpcap, sprd-sc27xx-spi - Change IRQ handling in qcom-pm8xxx - Split out I2C and SPI code in arizona - Explicitly include used headers in altera-a10sr - Convert sysfs show() function to in sysfs_emit - Standardise *_exit() and *_remove() return values in mc13xxx, stmpe, tps65912 - Trivial (style/spelling/whitespace) fixups in ti_am335x_tscadc, qcom-spmi-pmic, max77686-private - Device Tree fix-ups in ti,am3359-tscadc, samsung,s2mps11, samsung,s2mpa01, samsung,s5m8767, brcm,misc, brcm,cru, syscon, qcom,tcsr, xylon,logicvc, max77686, x-powers,ac100, x-powers,axp152, x-powers,axp209-gpio, syscon, qcom,spmi-pmic Bug Fixes: - Balance refcounting (get/put) in ti_am335x_tscadc, mfd-core - Fix IRQ trigger type in sec-irq, max77693, max14577 - Repair off-by-one in altera-sysmgr - Add explicit 'select MFD_CORE' to MFD_SIMPLE_MFD_I2C" * tag 'mfd-next-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (95 commits) mfd: simple-mfd-i2c: Select MFD_CORE to fix build error mfd: tps80031: Remove driver mfd: max77686: Correct tab-based alignment of register addresses mfd: wcd934x: Replace legacy gpio interface for gpiod dt-bindings: mfd: qcom: pm8xxx: Add pm8018 compatible mfd: dln2: Add cell for initializing DLN2 ADC mfd: qcom-spmi-pmic: Add missing PMICs supported by socinfo mfd: qcom-spmi-pmic: Document ten more PMICs in the binding mfd: qcom-spmi-pmic: Sort compatibles in the driver mfd: qcom-spmi-pmic: Sort the compatibles in the binding mfd: janz-cmoio: Replace snprintf in show functions with sysfs_emit mfd: altera-a10sr: Include linux/module.h mfd: tps65912: Make tps65912_device_exit() return void mfd: stmpe: Make stmpe_remove() return void mfd: mc13xxx: Make mc13xxx_common_exit() return void dt-bindings: mfd: syscon: Add samsung,exynosautov9-sysreg compatible mfd: altera-sysmgr: Fix a mistake caused by resource_size conversion dt-bindings: gpio: Convert X-Powers AXP209 GPIO binding to a schema dt-bindings: mfd: syscon: Add rk3368 QoS register compatible mfd: arizona: Split of_match table into I2C and SPI versions ...
2021-11-08Merge tag 'gpio-updates-for-v5.16' of ↵Linus Torvalds26-351/+943
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio updates from Bartosz Golaszewski: "We have a single new driver, new features in others and some cleanups all over the place. Nothing really stands out and it is all relatively small. - new driver: gpio-modepin (plus relevant change in zynqmp firmware) - add interrupt support to gpio-virtio - enable the 'gpio-line-names' property in the DT bindings for gpio-rockchip - use the subsystem helpers where applicable in gpio-uniphier instead of accessing IRQ structures directly - code shrink in gpio-xilinx - add interrupt to gpio-mlxbf2 (and include the removal of custom interrupt code from the mellanox ethernet driver) - support multiple interrupts per bank in gpio-tegra186 (and force one interrupt per bank in older models) - fix GPIO line IRQ offset calculation in gpio-realtek-otto - drop unneeded MODULE_ALIAS expansions in multiple drivers - code cleanup in gpio-aggregator - minor improvements in gpio-max730x and gpio-mc33880 - Kconfig cleanups" * tag 'gpio-updates-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: virtio_gpio: drop packed attribute gpio: virtio: Add IRQ support gpio: realtek-otto: fix GPIO line IRQ offset gpio: clean up Kconfig file net: mellanox: mlxbf_gige: Replace non-standard interrupt handling gpio: mlxbf2: Introduce IRQ support gpio: mc33880: Drop if with an always false condition gpio: max730x: Make __max730x_remove() return void gpio: aggregator: Wrap access to gpiochip_fwd.tmp[] gpio: modepin: Add driver support for modepin GPIO controller dt-bindings: gpio: zynqmp: Add binding documentation for modepin firmware: zynqmp: Add MMIO read and write support for PS_MODE pin gpio: tps65218: drop unneeded MODULE_ALIAS gpio: max77620: drop unneeded MODULE_ALIAS gpio: xilinx: simplify getting .driver_data gpio: tegra186: Support multiple interrupts per bank gpio: tegra186: Force one interrupt per bank gpio: uniphier: Use helper functions to get private data from IRQ data gpio: uniphier: Use helper function to get IRQ hardware number dt-bindings: gpio: add gpio-line-names to rockchip,gpio-bank.yaml
2021-11-08Merge tag 'cxl-for-5.16' of ↵Linus Torvalds36-1490/+3269
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl Pull cxl updates from Dan Williams: "More preparation and plumbing work in the CXL subsystem. From an end user perspective the highlight here is lighting up the CXL Persistent Memory related commands (label read / write) with the generic ioctl() front-end in LIBNVDIMM. Otherwise, the ability to instantiate new persistent and volatile memory regions is still on track for v5.17. Summary: - Fix support for platforms that do not enumerate every ACPI0016 (CXL Host Bridge) in the CHBS (ACPI Host Bridge Structure). - Introduce a common pci_find_dvsec_capability() helper, clean up open coded implementations in various drivers. - Add 'cxl_test' for regression testing CXL subsystem ABIs. 'cxl_test' is a module built from tools/testing/cxl/ that mocks up a CXL topology to augment the nascent support for emulation of CXL devices in QEMU. - Convert libnvdimm to use the uuid API. - Complete the definition of CXL namespace labels in libnvdimm. - Tunnel libnvdimm label operations from nd_ioctl() back to the CXL mailbox driver. Enable 'ndctl {read,write}-labels' for CXL. - Continue to sort and refactor functionality into distinct driver and core-infrastructure buckets. For example, mailbox handling is now a generic core capability consumed by the PCI and cxl_test drivers" * tag 'cxl-for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: (34 commits) ocxl: Use pci core's DVSEC functionality cxl/pci: Use pci core's DVSEC functionality PCI: Add pci_find_dvsec_capability to find designated VSEC cxl/pci: Split cxl_pci_setup_regs() cxl/pci: Add @base to cxl_register_map cxl/pci: Make more use of cxl_register_map cxl/pci: Remove pci request/release regions cxl/pci: Fix NULL vs ERR_PTR confusion cxl/pci: Remove dev_dbg for unknown register blocks cxl/pci: Convert register block identifiers to an enum cxl/acpi: Do not fail cxl_acpi_probe() based on a missing CHBS cxl/pci: Disambiguate cxl_pci further from cxl_mem Documentation/cxl: Add bus internal docs cxl/core: Split decoder setup into alloc + add tools/testing/cxl: Introduce a mock memory device + driver cxl/mbox: Move command definitions to common location cxl/bus: Populate the target list at decoder create tools/testing/cxl: Introduce a mocked-up CXL port hierarchy cxl/pmem: Add support for multiple nvdimm-bridge objects cxl/pmem: Translate NVDIMM label commands to CXL label commands ...
2021-11-08Merge branch 'i2c/for-mergewindow' of ↵Linus Torvalds23-261/+558
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c updates from Wolfram Sang: - big refactoring of the PASEMI driver to support the Apple M1 - huge improvements to the XIIC in terms of locking and SMP safety - refactoring and clean ups for the i801 driver ... and the usual bunch of small driver updates * 'i2c/for-mergewindow' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (43 commits) i2c: amd-mp2-plat: ACPI: Use ACPI_COMPANION() directly i2c: i801: Add support for Intel Ice Lake PCH-N i2c: virtio: update the maintainer to Conghui i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()' i2c: qup: move to use request_irq by IRQF_NO_AUTOEN flag i2c: qup: fix a trivial typo i2c: tegra: Ensure that device is suspended before driver is removed i2c: i801: Fix incorrect and needless software PEC disabling i2c: mediatek: Dump i2c/dma register when a timeout occurs i2c: mediatek: Reset the handshake signal between i2c and dma i2c: mlxcpld: Allow flexible polling time setting for I2C transactions i2c: pasemi: Set enable bit for Apple variant i2c: pasemi: Add Apple platform driver i2c: pasemi: Refactor _probe to use devm_* i2c: pasemi: Allow to configure bus frequency i2c: pasemi: Move common reset code to own function i2c: pasemi: Split pci driver to its own file i2c: pasemi: Split off common probing code i2c: pasemi: Remove usage of pci_dev i2c: pasemi: Use dev_name instead of port number ...
2021-11-08Merge tag 'mtd/for-5.16' of ↵Linus Torvalds44-175/+204
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull mtd updates from Miquel Raynal: "Core: - Remove obsolete macros only used by the old nand_ecclayout struct - Don't remove debugfs directory if device is in use - MAINTAINERS: - Add entry for Qualcomm NAND controller driver - Update the devicetree documentation path of hyperbus MTD devices: - block2mtd: - Add support for an optional custom MTD label - Minor refactor to avoid hard coded constant - mtdswap: Remove redundant assignment of pointer eb CFI: - Fixup CFI on ixp4xx Raw NAND controller drivers: - Arasan: - Prevent an unsupported configuration - Xway, Socrates: plat_nand, Pasemi, Orion, mpc5121, GPIO, Au1550nd, AMS-Delta: - Keep the driver compatible with on-die ECC engines - cs553x, lpc32xx_slc, ndfc, sharpsl, tmio, txx9ndfmc: - Revert the commits: "Fix external use of SW Hamming ECC helper" - And let callers use the bare Hamming helpers - Fsmc: Fix use of SM ORDER - Intel: - Fix potential buffer overflow in probe - xway, vf610, txx9ndfm, tegra, stm32, plat_nand, oxnas, omap, mtk, hisi504, gpmi, gpio, denali, bcm6368, atmel: - Make use of the helper function devm_platform_ioremap_resource{,byname}() Onenand drivers: - Samsung: Drop Exynos4 and describe driver in KConfig Raw NAND chip drivers: - Hynix: Add support for H27UCG8T2ETR-BC MLC NAND SPI NOR core: - Add spi-nor device tree binding under SPI NOR maintainers SPI NOR manufacturer drivers: - Enable locking for n25q128a13 SPI NOR controller drivers: - Use devm_platform_ioremap_resource_byname()" * tag 'mtd/for-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: (50 commits) mtd: core: don't remove debugfs directory if device is in use MAINTAINERS: Update the devicetree documentation path of hyperbus mtd: block2mtd: add support for an optional custom MTD label mtd: block2mtd: minor refactor to avoid hard coded constant mtd: fixup CFI on ixp4xx mtd: rawnand: arasan: Prevent an unsupported configuration MAINTAINERS: Add entry for Qualcomm NAND controller driver mtd: rawnand: hynix: Add support for H27UCG8T2ETR-BC MLC NAND mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines Revert "mtd: rawnand: cs553x: Fix external use of SW Hamming ECC helper" Revert "mtd: rawnand: lpc32xx_slc: Fix external use of SW Hamming ECC helper" Revert "mtd: rawnand: ndfc: Fix external use of SW Hamming ECC helper" ...
2021-11-08Add 'tools/perf/libbpf/' to ignored filesLinus Torvalds1-0/+1
Commit 6b491a86b77c ("perf build: Install libbpf headers locally when building") installed copies of the libbpf headers into the build tree, causing unnecessary noise from 'git status' after a perf tools build. Add the 'libbpf/' subdirectory to the .gitignore file to silence it all again. Signed-off-by: Linus Torvalds <[email protected]>
2021-11-08xfs: use swap() to make dabtree code cleanerYang Guang1-4/+1
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid opencoding it. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Yang Guang <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>
2021-11-08cifs: send workstation name during ntlmssp session setupShyam Prasad N8-85/+170
During the ntlmssp session setup (authenticate phases) send the client workstation info. This can make debugging easier on servers. Signed-off-by: Shyam Prasad N <[email protected]> Reviewed-by: Paulo Alcantara (SUSE) <[email protected]> Reviewed-by: Enzo Matsumiya <[email protected]> Signed-off-by: Steve French <[email protected]>
2021-11-08KVM: arm64: Fix host stage-2 finalizationQuentin Perret1-2/+12
We currently walk the hypervisor stage-1 page-table towards the end of hyp init in nVHE protected mode and adjust the host page ownership attributes in its stage-2 in order to get a consistent state from both point of views. The walk is done on the entire hyp VA space, and expects to only ever find page-level mappings. While this expectation is reasonable in the half of hyp VA space that maps memory with a fixed offset (see the loop in pkvm_create_mappings_locked()), it can be incorrect in the other half where nothing prevents the usage of block mappings. For instance, on systems where memory is physically aligned at an address that happens to maps to a PMD aligned VA in the hyp_vmemmap, kvm_pgtable_hyp_map() will install block mappings when backing the hyp_vmemmap, which will later cause finalize_host_mappings() to fail. Furthermore, it should be noted that all pages backing the hyp_vmemmap are also mapped in the 'fixed offset range' of the hypervisor, which implies that finalize_host_mappings() will walk both aliases and update the host stage-2 attributes twice. The order in which this happens is unpredictable, though, since the hyp VA layout is highly dependent on the position of the idmap page, hence resulting in a fragile mess at best. In order to fix all of this, let's restrict the finalization walk to only cover memory regions in the 'fixed-offset range' of the hyp VA space and nothing else. This not only fixes a correctness issue, but will also result in a slighlty faster hyp initialization overall. Fixes: 2c50166c62ba ("KVM: arm64: Mark host bss and rodata section as shared") Signed-off-by: Quentin Perret <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-11-08Merge tag 'kgdb-5.16-rc1' of ↵Linus Torvalds4-122/+53
git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux Pull kgdb update from Daniel Thompson: "A single patch this cycle. We replace some open-coded routines to classify task states with the scheduler's own function to do this. Alongside the obvious benefits of removing funky code and aligning more exactly with the scheduler's task classification, this also fixes a long standing compiler warning by removing the open-coded routines that generated the warning" * tag 'kgdb-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux: kdb: Adopt scheduler's task classification
2021-11-08Merge tag 'for-linus' of git://github.com/openrisc/linuxLinus Torvalds4-7/+7
Pull OpenRISC updates from Stafford Horne: "This includes two minor cleanups, plus a bug fix for OpenRISC TLB flush code that allows the the SMP kernel to boot again" * tag 'for-linus' of git://github.com/openrisc/linux: openrisc: fix SMP tlb flush NULL pointer dereference openrisc: signal: remove unused DEBUG_SIG macro openrisc: time: don't mark comment as kernel-doc
2021-11-08Merge tag 'perf-tools-for-v5.16-2021-11-07-without-bpftool-fix' of ↵Linus Torvalds184-1705/+5083
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools updates from Arnaldo Carvalho de Melo: "perf annotate: - Add riscv64 support. - Add fusion logic for AMD microarchs. perf record: - Add an option to control the synthesizing behavior: --synth <no|all|task|mmap|cgroup> core: - Allow controlling synthesizing PERF_RECORD_ metadata events during record. - perf.data reader prep work for multithreaded processing. - Fix missing exclude_{host,guest} setting in PMUs that don't support it and that were causing the feature detection code to disable it for all events, even the ones in PMUs that support it. - Fix the default use of precise events on AMD, that were always falling back to non-precise because perf_event_attr.exclude_guest=1 was set and IBS does not have filtering capability, refusing precise + exclude_guest. - Add bitfield_swap() to handle branch_stack endian issue. perf script: - Show binary offsets for userspace addresses in callchains. - Support instruction latency via new "ins_lat" selectable field. - Add dlfilter-show-cycles perf inject: - Add vmlinux and ignore-vmlinux arguments, similar to other tools. perf list: - Display PMU prefix for partially supported hybrid cache events. - Display hybrid PMU events with cpu type. perf stat: - Improve metrics documentation of data structures. - Fix memory leaks in the metric code. - Use NAN for missing event IDs. - Don't compute unused events. - Fix memory leak on error path. - Encode and use metric-id as a metric qualifier. - Allow metrics with no events. - Avoid events for an 'if' constant result. - Only add a referenced metric once. - Simplify metric_refs calculation. - Allow modifiers on metrics. perf test: - Add workload test of metric and metric groups. - Workload test of all PMUs. - vmlinux-kallsyms: Ignore hidden symbols. - Add pmu-event test for event described as "config=". - Verify more event members in pmu-events test. - Add endian test for struct branch_flags on the sample-parsing test. - Improve temp file cleanup in several tests. perf daemon: - Address MSAN warnings on send_cmd(). perf kmem: - Improve man page for record options perf srcline: - Use long-running addr2line per DSO, greatly speeding up the 'srcline' sort order. perf symbols: - Ignore $a/$d symbols for ARM modules. - Fix /proc/kcore access on 32 bit systems. Kernel UAPI copies: - Update copy of linux/socket.h with the kernel sources, no change in tooling output. libbpf: - Pull in bpf_program__get_prog_info_linear() from libbpf, too much specific to perf. - Deprecate bpf_map__resize() in favor of bpf_map_set_max_entries() - Install libbpf headers locally when building. - Bump minimum LLVM C++ std to GNU++14. libperf: - Use binary search in perf_cpu_map__idx() as array are sorted. libtracefs: - Enable libtracefs dynamic linking. libtraceevent: - Increase logging when verbose. Arch specific: * PowerPC: - Add support to expose instruction and data address registers as part of extended regs. Vendor events: * JSON parser: - Support ConfigCode to set the config= in PMUs - Make the JSON parser more conformant when in strict mode. * All JSON files: - Fix all remaining invalid JSON files. * ARM: - Syntax corrections in Neoverse N1 json. - Categorise the Neoverse V1 counters. - Add new armv8 PMU events. - Revise hip08 uncore events. Hardware tracing: * auxtrace: - Add missing Z option to ITRACE_HELP. - Add itrace A option to approximate IPC. - Add itrace d+o option to direct debug log to stdout. * Intel PT: - Add support for PERF_RECORD_AUX_OUTPUT_HW_ID - Support itrace A option to approximate IPC - Support itrace d+o option to direct debug log to stdout" * tag 'perf-tools-for-v5.16-2021-11-07-without-bpftool-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (120 commits) perf build: Install libbpf headers locally when building perf MANIFEST: Add bpftool files to allow building with BUILD_BPF_SKEL=1 perf metric: Fix memory leaks perf parse-event: Add init and exit to parse_event_error perf parse-events: Rename parse_events_error functions perf stat: Fix memory leak on error path perf tools: Use __BYTE_ORDER__ perf inject: Add vmlinux and ignore-vmlinux arguments perf tools: Check vmlinux/kallsyms arguments in all tools perf tools: Refactor out kernel symbol argument sanity checking perf symbols: Ignore $a/$d symbols for ARM modules perf evsel: Don't set exclude_guest by default perf evsel: Fix missing exclude_{host,guest} setting perf bpf: Add missing free to bpf_event__print_bpf_prog_info() perf beauty: Update copy of linux/socket.h with the kernel sources perf clang: Fixes for more recent LLVM/clang tools: Bump minimum LLVM C++ std to GNU++14 perf bpf: Pull in bpf_program__get_prog_info_linear() Revert "perf bench futex: Add support for 32-bit systems with 64-bit time_t" perf test sample-parsing: Add endian test for struct branch_flags ...
2021-11-08Merge tag 'kbuild-v5.16' of ↵Linus Torvalds62-479/+453
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Remove the global -isystem compiler flag, which was made possible by the introduction of <linux/stdarg.h> - Improve the Kconfig help to print the location in the top menu level - Fix "FORCE prerequisite is missing" build warning for sparc - Add new build targets, tarzst-pkg and perf-tarzst-src-pkg, which generate a zstd-compressed tarball - Prevent gen_init_cpio tool from generating a corrupted cpio when KBUILD_BUILD_TIMESTAMP is set to 2106-02-07 or later - Misc cleanups * tag 'kbuild-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (28 commits) kbuild: use more subdir- for visiting subdirectories while cleaning sh: remove meaningless archclean line initramfs: Check timestamp to prevent broken cpio archive kbuild: split DEBUG_CFLAGS out to scripts/Makefile.debug gen_init_cpio: add static const qualifiers kbuild: Add make tarzst-pkg build option scripts: update the comments of kallsyms support sparc: Add missing "FORCE" target when using if_changed kconfig: refactor conf_touch_dep() kconfig: refactor conf_write_dep() kconfig: refactor conf_write_autoconf() kconfig: add conf_get_autoheader_name() kconfig: move sym_escape_string_value() to confdata.c kconfig: refactor listnewconfig code kconfig: refactor conf_write_symbol() kconfig: refactor conf_write_heading() kconfig: remove 'const' from the return type of sym_escape_string_value() kconfig: rename a variable in the lexer to a clearer name kconfig: narrow the scope of variables in the lexer kconfig: Create links to main menu items in search ...
2021-11-08Merge tag 'modules-5.16-rc1' of ↵Linus Torvalds1-21/+58
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux Pull module updates from Luis Chamberlain: "As requested by Jessica I'm stepping in to help with modules maintenance. This is my first pull request to you. I've collected only two patches for modules for the 5.16-rc1 merge window. These patches are from Shuah Khan as she debugged some corner case error with modules. The error messages are improved for elf_validity_check(). While doing this work a corner case fix was spotted on validate_section_offset() due to a possible overflow bug on 64-bit. The impact of this fix is low given this just limits module section headers placed within the 32-bit boundary, and we obviously don't have insane module sizes. Even if a specially crafted module is constructed later checks would invalidate the module right away. I've let this sit through 0-day testing since October 15th with no issues found" * tag 'modules-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux: module: change to print useful messages from elf_validity_check() module: fix validate_section_offset() overflow bug on 64-bit
2021-11-08soc: ti: fix wkup_m3_rproc_boot_thread return typeArnd Bergmann1-2/+3
The wkup_m3_rproc_boot_thread() function uses a nonstandard prototype, which broke after Eric's recent cleanup: drivers/soc/ti/wkup_m3_ipc.c: In function 'wkup_m3_rproc_boot_thread': drivers/soc/ti/wkup_m3_ipc.c:429:16: error: 'return' with a value, in function returning void [-Werror=return-type] 429 | return 0; | ^ drivers/soc/ti/wkup_m3_ipc.c:416:13: note: declared here 416 | static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc) | ^~~~~~~~~~~~~~~~~~~~~~~~~ Change it to the normal prototype as it should have been from the start. Fixes: 111e70490d2a ("exit/kthread: Have kernel threads return instead of calling do_exit") Fixes: cdd5de500b2c ("soc: ti: Add wkup_m3_ipc driver") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Acked-by: Santosh Shilimkar <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Eric W. Biederman <[email protected]>
2021-11-08xen/balloon: fix unused-variable warningArnd Bergmann1-2/+3
In configurations with CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=n and CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y, gcc warns about an unused variable: drivers/xen/balloon.c:83:12: error: 'xen_hotplug_unpopulated' defined but not used [-Werror=unused-variable] Since this is always zero when CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is disabled, turn it into a preprocessor constant in that case. Fixes: 121f2faca2c0 ("xen/balloon: rename alloc/free_xenballooned_pages") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
2021-11-08io_uring: honour zeroes as io-wq worker limitsPavel Begunkov1-1/+3
When we pass in zero as an io-wq worker number limit it shouldn't actually change the limits but return the old value, follow that behaviour with deferred limits setup as well. Cc: [email protected] # 5.15 Reported-by: Beld Zhang <[email protected]> Fixes: e139a1ec92f8d ("io_uring: apply max_workers limit to all future users") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/1b222a92f7a78a24b042763805e891a4cdd4b544.1636384034.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]>
2021-11-08ALSA: pci: rme: Fix unaligned buffer addressesTakashi Iwai2-36/+46
The recent fix for setting up the DMA buffer type on RME drivers tried to address the non-standard memory managements and changed the DMA buffer information to the standard snd_dma_buffer object that is allocated at the probe time. However, I overlooked that the RME drivers handle the buffer addresses based on 64k alignment, and the previous conversion broke that silently. This patch is an attempt to fix the regression. The snd_dma_buffer objects are copied to the original data with the correction to the aligned accesses, and those are passed to snd_pcm_set_runtime_buffer() helpers instead. The original snd_dma_buffer objects are managed by devres, hence they'll be released automagically. Fixes: 0899a7a23047 ("ALSA: pci: rme: Set up buffer type properly") Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-11-08blk-mq: don't free tags if the tag_set is used by other device in queue ↵Ye Bin1-1/+5
initialztion We got UAF report on v5.10 as follows: [ 1446.674930] ================================================================== [ 1446.675970] BUG: KASAN: use-after-free in blk_mq_get_driver_tag+0x9a4/0xa90 [ 1446.676902] Read of size 8 at addr ffff8880185afd10 by task kworker/1:2/12348 [ 1446.677851] [ 1446.678073] CPU: 1 PID: 12348 Comm: kworker/1:2 Not tainted 5.10.0-10177-gc9c81b1e346a #2 [ 1446.679168] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1446.680692] Workqueue: kthrotld blk_throtl_dispatch_work_fn [ 1446.681448] Call Trace: [ 1446.681800] dump_stack+0x9b/0xce [ 1446.682916] print_address_description.constprop.6+0x3e/0x60 [ 1446.685999] kasan_report.cold.9+0x22/0x3a [ 1446.687186] blk_mq_get_driver_tag+0x9a4/0xa90 [ 1446.687785] blk_mq_dispatch_rq_list+0x21a/0x1d40 [ 1446.692576] __blk_mq_do_dispatch_sched+0x394/0x830 [ 1446.695758] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [ 1446.698279] blk_mq_sched_dispatch_requests+0xdf/0x140 [ 1446.698967] __blk_mq_run_hw_queue+0xc0/0x270 [ 1446.699561] __blk_mq_delay_run_hw_queue+0x4cc/0x550 [ 1446.701407] blk_mq_run_hw_queue+0x13b/0x2b0 [ 1446.702593] blk_mq_sched_insert_requests+0x1de/0x390 [ 1446.703309] blk_mq_flush_plug_list+0x4b4/0x760 [ 1446.705408] blk_flush_plug_list+0x2c5/0x480 [ 1446.708471] blk_finish_plug+0x55/0xa0 [ 1446.708980] blk_throtl_dispatch_work_fn+0x23b/0x2e0 [ 1446.711236] process_one_work+0x6d4/0xfe0 [ 1446.711778] worker_thread+0x91/0xc80 [ 1446.713400] kthread+0x32d/0x3f0 [ 1446.714362] ret_from_fork+0x1f/0x30 [ 1446.714846] [ 1446.715062] Allocated by task 1: [ 1446.715509] kasan_save_stack+0x19/0x40 [ 1446.716026] __kasan_kmalloc.constprop.1+0xc1/0xd0 [ 1446.716673] blk_mq_init_tags+0x6d/0x330 [ 1446.717207] blk_mq_alloc_rq_map+0x50/0x1c0 [ 1446.717769] __blk_mq_alloc_map_and_request+0xe5/0x320 [ 1446.718459] blk_mq_alloc_tag_set+0x679/0xdc0 [ 1446.719050] scsi_add_host_with_dma.cold.3+0xa0/0x5db [ 1446.719736] virtscsi_probe+0x7bf/0xbd0 [ 1446.720265] virtio_dev_probe+0x402/0x6c0 [ 1446.720808] really_probe+0x276/0xde0 [ 1446.721320] driver_probe_device+0x267/0x3d0 [ 1446.721892] device_driver_attach+0xfe/0x140 [ 1446.722491] __driver_attach+0x13a/0x2c0 [ 1446.723037] bus_for_each_dev+0x146/0x1c0 [ 1446.723603] bus_add_driver+0x3fc/0x680 [ 1446.724145] driver_register+0x1c0/0x400 [ 1446.724693] init+0xa2/0xe8 [ 1446.725091] do_one_initcall+0x9e/0x310 [ 1446.725626] kernel_init_freeable+0xc56/0xcb9 [ 1446.726231] kernel_init+0x11/0x198 [ 1446.726714] ret_from_fork+0x1f/0x30 [ 1446.727212] [ 1446.727433] Freed by task 26992: [ 1446.727882] kasan_save_stack+0x19/0x40 [ 1446.728420] kasan_set_track+0x1c/0x30 [ 1446.728943] kasan_set_free_info+0x1b/0x30 [ 1446.729517] __kasan_slab_free+0x111/0x160 [ 1446.730084] kfree+0xb8/0x520 [ 1446.730507] blk_mq_free_map_and_requests+0x10b/0x1b0 [ 1446.731206] blk_mq_realloc_hw_ctxs+0x8cb/0x15b0 [ 1446.731844] blk_mq_init_allocated_queue+0x374/0x1380 [ 1446.732540] blk_mq_init_queue_data+0x7f/0xd0 [ 1446.733155] scsi_mq_alloc_queue+0x45/0x170 [ 1446.733730] scsi_alloc_sdev+0x73c/0xb20 [ 1446.734281] scsi_probe_and_add_lun+0x9a6/0x2d90 [ 1446.734916] __scsi_scan_target+0x208/0xc50 [ 1446.735500] scsi_scan_channel.part.3+0x113/0x170 [ 1446.736149] scsi_scan_host_selected+0x25a/0x360 [ 1446.736783] store_scan+0x290/0x2d0 [ 1446.737275] dev_attr_store+0x55/0x80 [ 1446.737782] sysfs_kf_write+0x132/0x190 [ 1446.738313] kernfs_fop_write_iter+0x319/0x4b0 [ 1446.738921] new_sync_write+0x40e/0x5c0 [ 1446.739429] vfs_write+0x519/0x720 [ 1446.739877] ksys_write+0xf8/0x1f0 [ 1446.740332] do_syscall_64+0x2d/0x40 [ 1446.740802] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1446.741462] [ 1446.741670] The buggy address belongs to the object at ffff8880185afd00 [ 1446.741670] which belongs to the cache kmalloc-256 of size 256 [ 1446.743276] The buggy address is located 16 bytes inside of [ 1446.743276] 256-byte region [ffff8880185afd00, ffff8880185afe00) [ 1446.744765] The buggy address belongs to the page: [ 1446.745416] page:ffffea0000616b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x185ac [ 1446.746694] head:ffffea0000616b00 order:2 compound_mapcount:0 compound_pincount:0 [ 1446.747719] flags: 0x1fffff80010200(slab|head) [ 1446.748337] raw: 001fffff80010200 ffffea00006a3208 ffffea000061bf08 ffff88801004f240 [ 1446.749404] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 [ 1446.750455] page dumped because: kasan: bad access detected [ 1446.751227] [ 1446.751445] Memory state around the buggy address: [ 1446.752102] ffff8880185afc00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1446.753090] ffff8880185afc80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1446.754079] >ffff8880185afd00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1446.755065] ^ [ 1446.755589] ffff8880185afd80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1446.756574] ffff8880185afe00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 1446.757566] ================================================================== Flag 'BLK_MQ_F_TAG_QUEUE_SHARED' will be set if the second device on the same host initializes it's queue successfully. However, if the second device failed to allocate memory in blk_mq_alloc_and_init_hctx() from blk_mq_realloc_hw_ctxs() from blk_mq_init_allocated_queue(), __blk_mq_free_map_and_rqs() will be called on error path, and if 'BLK_MQ_TAG_HCTX_SHARED' is not set, 'tag_set->tags' will be freed while it's still used by the first device. To fix this issue we move release newly allocated hardware context from blk_mq_realloc_hw_ctxs to __blk_mq_update_nr_hw_queues. As there is needn't to release hardware context in blk_mq_init_allocated_queue. Fixes: 868f2f0b7206 ("blk-mq: dynamic h/w context count") Signed-off-by: Ye Bin <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Ming Lei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-11-08bcache: Revert "bcache: use bvec_virt"Coly Li1-1/+1
This reverts commit 2fd3e5efe791946be0957c8e1eed9560b541fe46. The above commit replaces page_address(bv->bv_page) by bvec_virt(bv) to avoid directly access to bv->bv_page, but in situation bv->bv_offset is not zero and page_address(bv->bv_page) is not equal to bvec_virt(bv). In such case a memory corruption may happen because memory in next page is tainted by following line in do_btree_node_write(), memcpy(bvec_virt(bv), addr, PAGE_SIZE); This patch reverts the mentioned commit to avoid the memory corruption. Fixes: 2fd3e5efe791 ("bcache: use bvec_virt") Signed-off-by: Coly Li <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: [email protected] # 5.15 Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-11-08s390/cio: check the subchannel validity for dev_busidVineeth Vijayan1-2/+2
Check the validity of subchanel before reading other fields in the schib. Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel") CC: <[email protected]> Reported-by: Cornelia Huck <[email protected]> Signed-off-by: Vineeth Vijayan <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08s390/cpumf: cpum_cf PMU displays invalid value after hotplug removeThomas Richter1-1/+3
When a CPU is hotplugged while the perf stat -e cycles command is running, a wrong (very large) value is displayed immediately after the CPU removal: Check the values, shouldn't be too high as in time counts unit events 1.001101919 29261846 cycles 2.002454499 17523405 cycles 3.003659292 24361161 cycles 4.004816983 18446744073638406144 cycles 5.005671647 <not counted> cycles ... The CPU hotplug off took place after 3 seconds. The issue is the read of the event count value after 4 seconds when the CPU is not available and the read of the counter returns an error. This is treated as a counter value of zero. This results in a very large value (0 - previous_value). Fix this by detecting the hotplugged off CPU and report 0 instead of a very large number. Cc: [email protected] Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Reported-by: Sumanth Korikkar <[email protected]> Signed-off-by: Thomas Richter <[email protected]> Reviewed-by: Sumanth Korikkar <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08s390/tape: fix timer initialization in tape_std_assign()Sven Schnelle1-2/+1
commit 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()") changed the timer setup from init_timer_on_stack(() to timer_setup(), but missed to change the mod_timer() call. And while at it, use msecs_to_jiffies() instead of the open coded timeout calculation. Cc: [email protected] Fixes: 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()") Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Vasily Gorbik <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08s390/pci: implement minimal PCI error recoveryNiklas Schnelle3-4/+277
When the platform detects an error on a PCI function or a service action has been performed it is put in the error state and an error event notification is provided to the OS. Currently we treat all error event notifications the same and simply set pdev->error_state = pci_channel_io_perm_failure requiring user intervention such as use of the recover attribute to get the device usable again. Despite requiring a manual step this also has the disadvantage that the device is completely torn down and recreated resulting in higher level devices such as a block or network device being recreated. In case of a block device this also means that it may need to be removed and added to a software raid even if that could otherwise survive with a temporary degradation. This is of course not ideal more so since an error notification with PEC 0x3A indicates that the platform already performed error recovery successfully or that the error state was caused by a service action that is now finished. At least in this case we can assume that the error state can be reset and the function made usable again. So as not to have the disadvantage of a full tear down and recreation we need to coordinate this recovery with the driver. Thankfully there is already a well defined recovery flow for this described in Documentation/PCI/pci-error-recovery.rst. The implementation of this is somewhat straight forward and simplified by the fact that our recovery flow is defined per PCI function. As a reset we use the newly introduced zpci_hot_reset_device() which also takes the PCI function out of the error state. Reviewed-by: Pierre Morel <[email protected]> Acked-by: Matthew Rosato <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08PCI: Export pci_dev_lock()Niklas Schnelle2-1/+3
Commit e3a9b1212b9d ("PCI: Export pci_dev_trylock() and pci_dev_unlock()") already exported pci_dev_trylock()/pci_dev_unlock() however in some circumstances such as during error recovery it makes sense to block waiting to get full access to the device so also export pci_dev_lock(). Link: https://lore.kernel.org/all/20210928181014.GA713179@bhelgaas/ Acked-by: Pierre Morel <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08s390/pci: implement reset_slot for hotplug slotNiklas Schnelle4-0/+93
This is done by adding a zpci_hot_reset_device() call which does a low level reset of the PCI function without changing its higher level function state. This way it can be used while the zPCI function is bound to a driver and with DMA tables being controlled either through the IOMMU or DMA APIs which is prohibited when using zpci_disable_device() as that drop existing DMA translations. As this reset, unlike a normal FLR, also calls zpci_clear_irq() we need to implement arch_restore_msi_irqs() and make sure we re-enable IRQs for the PCI function if they were previously disabled. Reviewed-by: Pierre Morel <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08s390/pci: refresh function handle in iomapNiklas Schnelle4-9/+38
The function handle of a PCI function is updated when disabling or enabling it as well as when the function's availability changes or it enters the error state. Until now this only occurred either while there is no struct pci_dev associated with the function yet or the function became unavailable. This meant that leaving a stale function handle in the iomap either didn't happen because there was no iomap yet or it lead to errors on PCI access but so would the correct disabled function handle. In the future a CLP Set PCI Function Disable/Enable cycle during PCI device recovery may be done while the device is bound to a driver. In this case we must update the iomap associated with the now-stale function handle to ensure that the resulting zPCI instruction references an accurate function handle. Since the function handle is accessed by the PCI accessor helpers without locking use READ_ONCE()/WRITE_ONCE() to mark this access and prevent compiler optimizations that would move the load/store. With that infrastructure in place let's also properly update the function handle in the existing cases. This makes sure that in the future debugging of a zPCI function access through the handle will show an up to date handle reducing the chance of confusion. Also it makes sure we have one single place where a zPCI function handle is updated after initialization. Reviewed-by: Pierre Morel <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Signed-off-by: Niklas Schnelle <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-11-08drm/virtio: Fix NULL dereference error in virtio_gpu_pollVivek Kasireddy1-1/+2
When virgl is not enabled, vfpriv pointer would not be allocated. Therefore, check for a valid value before dereferencing. Reported-by: Christian Zigotzky <[email protected]> Cc: Gurchetan Singh <[email protected]> Cc: Gerd Hoffmann <[email protected]> Signed-off-by: Vivek Kasireddy <[email protected]> Tested-by: Christian Zigotzky <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2021-11-08ALSA: firewire-motu: add support for MOTU Track 16Takashi Sakamoto4-3/+19
Mark of the Unicorn designed Track 16 2011 as one of models in third generation of its FireWire series. The model is already discontinued. It consists of below ICs: * Texas Instruments TSB41AB1 * Microchip (SMSC) USB3300 * Xilinx Spartan-3A FPGA, XC3S700A * Texas Instruments TMS320C6722 * Microchip (Atmel) AT91SAM SAM7S512 It supports sampling transfer frequency up to 192.0 kHz. The packet format differs depending on both of current sampling transfer frequency and the type of signal in optical interfaces. The model supports transmission of PCM frames as well as MIDI messages. The model supports command mechanism to configure internal DSP. Hardware meter information is available in the first 2 chunks of each data block of tx packet. This commit adds support for it. $ cd linux-firewire-tools/src $ python crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 400 04107d95 bus_info_length 4, crc_length 16, crc 32149 404 31333934 bus_name "1394" 408 20ff7000 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 7 (256) 40c 0001f200 company_id 0001f2 | 410 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4 root directory ----------------------------------------------------------------- 414 0004ef04 directory_length 4, crc 61188 418 030001f2 vendor 41c 0c0083c0 node capabilities per IEEE 1394 420 d1000002 --> unit directory at 428 424 8d000005 --> eui-64 leaf at 438 unit directory at 428 ----------------------------------------------------------------- 428 00035b04 directory_length 3, crc 23300 42c 120001f2 specifier id 430 13000039 version 434 17102800 model eui-64 leaf at 438 ----------------------------------------------------------------- 438 0002b25f leaf_length 2, crc 45663 43c 0001f200 company_id 0001f2 | 440 000a83c4 device_id 00000a83c4 | EUI-64 0001f200000a83c4 Signed-off-by: Takashi Sakamoto <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-11-08KVM: arm64: Change the return type of kvm_vcpu_preferred_target()YueHaibing3-11/+3
kvm_vcpu_preferred_target() always return 0 because kvm_target_cpu() never returns a negative error code. Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Alexandru Elisei <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-11-08KVM: arm64: nvhe: Fix a non-kernel-doc commentRandy Dunlap1-1/+1
Do not use kernel-doc "/**" notation when the comment is not in kernel-doc format. Fixes this docs build warning: arch/arm64/kvm/hyp/nvhe/sys_regs.c:478: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Handler for protected VM restricted exceptions. Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Fuad Tabba <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-11-08KVM: arm64: Extract ESR_ELx.EC onlyMark Rutland3-2/+3
Since ARMv8.0 the upper 32 bits of ESR_ELx have been RES0, and recently some of the upper bits gained a meaning and can be non-zero. For example, when FEAT_LS64 is implemented, ESR_ELx[36:32] contain ISS2, which for an ST64BV or ST64BV0 can be non-zero. This can be seen in ARM DDI 0487G.b, page D13-3145, section D13.2.37. Generally, we must not rely on RES0 bit remaining zero in future, and when extracting ESR_ELx.EC we must mask out all other bits. All C code uses the ESR_ELx_EC() macro, which masks out the irrelevant bits, and therefore no alterations are required to C code to avoid consuming irrelevant bits. In a couple of places the KVM assembly extracts ESR_ELx.EC using LSR on an X register, and so could in theory consume previously RES0 bits. In both cases this is for comparison with EC values ESR_ELx_EC_HVC32 and ESR_ELx_EC_HVC64, for which the upper bits of ESR_ELx must currently be zero, but this could change in future. This patch adjusts the KVM vectors to use UBFX rather than LSR to extract ESR_ELx.EC, ensuring these are robust to future additions to ESR_ELx. Cc: [email protected] Signed-off-by: Mark Rutland <[email protected]> Cc: Alexandru Elisei <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: James Morse <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Suzuki K Poulose <[email protected]> Cc: Will Deacon <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-11-08arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functionsArnd Bergmann1-3/+9
gcc warns about undefined behavior the vmalloc code when building with CONFIG_ARM64_PA_BITS_52, when the 'idx++' in the argument to __phys_to_pte_val() is evaluated twice: mm/vmalloc.c: In function 'vmap_pfn_apply': mm/vmalloc.c:2800:58: error: operation on 'data->idx' may be undefined [-Werror=sequence-point] 2800 | *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); | ~~~~~~~~~^~ arch/arm64/include/asm/pgtable-types.h:25:37: note: in definition of macro '__pte' 25 | #define __pte(x) ((pte_t) { (x) } ) | ^ arch/arm64/include/asm/pgtable.h:80:15: note: in expansion of macro '__phys_to_pte_val' 80 | __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)) | ^~~~~~~~~~~~~~~~~ mm/vmalloc.c:2800:30: note: in expansion of macro 'pfn_pte' 2800 | *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); | ^~~~~~~ I have no idea why this never showed up earlier, but the safest workaround appears to be changing those macros into inline functions so the arguments get evaluated only once. Cc: Matthew Wilcox <[email protected]> Fixes: 75387b92635e ("arm64: handle 52-bit physical addresses in page table entries") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2021-11-08arm64: Track no early_pgtable_alloc() for kmemleakQian Cai5-8/+13
After switched page size from 64KB to 4KB on several arm64 servers here, kmemleak starts to run out of early memory pool due to a huge number of those early_pgtable_alloc() calls: kmemleak_alloc_phys() memblock_alloc_range_nid() memblock_phys_alloc_range() early_pgtable_alloc() init_pmd() alloc_init_pud() __create_pgd_mapping() __map_memblock() paging_init() setup_arch() start_kernel() Increased the default value of DEBUG_KMEMLEAK_MEM_POOL_SIZE by 4 times won't be enough for a server with 200GB+ memory. There isn't much interesting to check memory leaks for those early page tables and those early memory mappings should not reference to other memory. Hence, no kmemleak false positives, and we can safely skip tracking those early allocations from kmemleak like we did in the commit fed84c785270 ("mm/memblock.c: skip kmemleak for kasan_init()") without needing to introduce complications to automatically scale the value depends on the runtime memory size etc. After the patch, the default value of DEBUG_KMEMLEAK_MEM_POOL_SIZE becomes sufficient again. Signed-off-by: Qian Cai <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Reviewed-by: Mike Rapoport <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2021-11-08arm64: mte: change PR_MTE_TCF_NONE back into an unsigned longPeter Collingbourne2-2/+2
This constant was previously an unsigned long, but was changed into an int in commit 433c38f40f6a ("arm64: mte: change ASYNC and SYNC TCF settings into bitfields"). This ended up causing spurious unsigned-signed comparison warnings in expressions such as: (x & PR_MTE_TCF_MASK) != PR_MTE_TCF_NONE Therefore, change it back into an unsigned long to silence these warnings. Link: https://linux-review.googlesource.com/id/I07a72310db30227a5b7d789d0b817d78b657c639 Signed-off-by: Peter Collingbourne <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2021-11-08arm64: vdso: remove -nostdlib compiler flagMasahiro Yamada2-2/+2
The -nostdlib option requests the compiler to not use the standard system startup files or libraries when linking. It is effective only when $(CC) is used as a linker driver. Since commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO"), $(LD) is directly used, hence -nostdlib is unneeded. Signed-off-by: Masahiro Yamada <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2021-11-08arm64: arm64_ftr_reg->name may not be a human-readable stringReiji Watanabe1-3/+7
The id argument of ARM64_FTR_REG_OVERRIDE() is used for two purposes: one as the system register encoding (used for the sys_id field of __ftr_reg_entry), and the other as the register name (stringified and used for the name field of arm64_ftr_reg), which is debug information. The id argument is supposed to be a macro that indicates an encoding of the register (eg. SYS_ID_AA64PFR0_EL1, etc). ARM64_FTR_REG(), which also has the same id argument, uses ARM64_FTR_REG_OVERRIDE() and passes the id to the macro. Since the id argument is completely macro-expanded before it is substituted into a macro body of ARM64_FTR_REG_OVERRIDE(), the stringified id in the body of ARM64_FTR_REG_OVERRIDE is not a human-readable register name, but a string of numeric bitwise operations. Fix this so that human-readable register names are available as debug information. Fixes: 8f266a5d878a ("arm64: cpufeature: Add global feature override facility") Signed-off-by: Reiji Watanabe <[email protected]> Reviewed-by: Oliver Upton <[email protected]> Acked-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2021-11-08ceph: add a new metric to keep track of remote object copiesLuís Henriques3-1/+14
This patch adds latency and size metrics for remote object copies operations ("copyfrom"). For now, these metrics will be available on the client only, they won't be sent to the MDS. Signed-off-by: Luís Henriques <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08libceph, ceph: move ceph_osdc_copy_from() into cephfs codeLuís Henriques3-73/+80
This patch moves ceph_osdc_copy_from() function out of libceph code into cephfs. There are no other users for this function, and there is the need (in another patch) to access internal ceph_osd_request struct members. Signed-off-by: Luís Henriques <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: clean-up metrics data structures to reduce code duplicationLuís Henriques3-180/+115
This patch modifies struct ceph_client_metric so that each metric block (read, write and metadata) becomes an element in a array. This allows to also re-write the helper functions that handle these blocks, making them simpler and, above all, reduce the amount of copy&paste every time a new metric is added. Thus, for each of these metrics there will be a new struct ceph_metric entry that'll will contain all the sizes and latencies fields (and a lock). Note however that the metadata metric doesn't really use the size_fields, and thus this metric won't be shown in the debugfs '../metrics/size' file. Signed-off-by: Luís Henriques <[email protected]> Reviewed-by: Xiubo Li <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: split 'metric' debugfs file into several filesLuís Henriques2-26/+57
Currently, all the metrics are grouped together in a single file, making it difficult to process this file from scripts. Furthermore, as new metrics are added, processing this file will become even more challenging. This patch turns the 'metric' file into a directory that will contain several files, one for each metric. Signed-off-by: Luís Henriques <[email protected]> Reviewed-by: Xiubo Li <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: return the real size read when it hits EOFXiubo Li1-5/+8
Currently, if the sync read handler ends up reading more from the last object in the file than the i_size indicates, then it'll end up returning the wrong length. Ensure that we cap the returned length and pos at the EOF. Signed-off-by: Xiubo Li <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: properly handle statfs on multifs setupsJeff Layton1-5/+6
ceph_statfs currently stuffs the cluster fsid into the f_fsid field. This was fine when we only had a single filesystem per cluster, but now that we have multiples we need to use something that will vary between them. Change ceph_statfs to xor each 32-bit chunk of the fsid (aka cluster id) into the lower bits of the statfs->f_fsid. Change the lower bits to hold the fscid (filesystem ID within the cluster). That should give us a value that is guaranteed to be unique between filesystems within a cluster, and should minimize the chance of collisions between mounts of different clusters. URL: https://tracker.ceph.com/issues/52812 Reported-by: Sachin Prabhu <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Xiubo Li <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: shut down mount on bad mdsmap or fsmap decodeJeff Layton3-3/+6
As Greg pointed out, if we get a mangled mdsmap or fsmap, then something has gone very wrong, and we should avoid doing any activity on the filesystem. When this occurs, shut down the mount the same way we would with a forced umount by calling ceph_umount_begin when decoding fails on either map. This causes most operations done against the filesystem to return an error. Any dirty data or caps in the cache will be dropped as well. The effect is not reversible, so the only remedy is to umount. [ idryomov: print fsmap decoding error ] URL: https://tracker.ceph.com/issues/52303 Signed-off-by: Jeff Layton <[email protected]> Acked-by: Greg Farnum <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
2021-11-08ceph: fix mdsmap decode when there are MDS's beyond max_mdsXiubo Li1-4/+0
If the max_mds is decreased in a cephfs cluster, there is a window of time before the MDSs are removed. If a map goes out during this period, the mdsmap may show the decreased max_mds but still shows those MDSes as in or in the export target list. Ensure that we don't fail the map decode in that case. Cc: [email protected] URL: https://tracker.ceph.com/issues/52436 Fixes: d517b3983dd3 ("ceph: reconnect to the export targets on new mdsmaps") Signed-off-by: Xiubo Li <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Ilya Dryomov <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.