September 2018 - Linux-stable-mirror

[PATCH] perf/x86/intel/uncore: Fix PCI BDF address of M3UPI on SKX

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> The counters on M3UPI Link 0 and Link 3 don't count. Writing 0 to these counters may causes system crash on some machines. The PCI BDF addresses of M3UPI in current code are incorrect. The correct addresses should be D18:F1 0x204D D18:F2 0x204E D18:F5 0x204D Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> --- arch/x86/events/intel/uncore_snbep.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/events/intel/uncore_snbep.c b/arch/x86/events/intel/uncore_snbep.c index 51d7c11..3b3fc92 100644 --- a/arch/x86/events/intel/uncore_snbep.c +++ b/arch/x86/events/intel/uncore_snbep.c @@ -3931,16 +3931,16 @@ static const struct pci_device_id skx_uncore_pci_ids[] = { .driver_data = UNCORE_PCI_DEV_FULL_DATA(21, 5, SKX_PCI_UNCORE_M2PCIE, 3), }, { /* M3UPI0 Link 0 */ - PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204C), - .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 0, SKX_PCI_UNCORE_M3UPI, 0), + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204D), + .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 1, SKX_PCI_UNCORE_M3UPI, 0), }, { /* M3UPI0 Link 1 */ - PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204D), - .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 1, SKX_PCI_UNCORE_M3UPI, 1), + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204E), + .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 2, SKX_PCI_UNCORE_M3UPI, 1), }, { /* M3UPI1 Link 2 */ - PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204C), - .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 4, SKX_PCI_UNCORE_M3UPI, 2), + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x204D), + .driver_data = UNCORE_PCI_DEV_FULL_DATA(18, 5, SKX_PCI_UNCORE_M3UPI, 2), }, { /* end: all zeroes */ } }; -- 2.7.4

6 years, 7 months

3
2
0 0

[GIT PULL] commits for Linux 4.18

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Greg, Pleae pull commits for Linux 4.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit dfba61ec760efc578a3f3702e752b51ca1dfed52: Linux 4.18.8 (2018-09-15 09:47:02 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.18-17092018 for you to fetch changes up to 77d141736c922f90410b6acf877fe335335d9571: xen-netfront: fix warn message as irq device name has '/' (2018-09-15 10:22:00 -0400) - ---------------------------------------------------------------- for-greg-4.18-17092018 - ---------------------------------------------------------------- Alexandru Gagniuc (1): PCI/AER: Honor "pcie_ports=native" even if HEST sets FIRMWARE_FIRST Andreas Gruenbacher (1): gfs2: Special-case rindex for gfs2_grow Anton Vasilyev (1): video: goldfishfb: fix memory leak on driver remove Ard Biesheuvel (1): efi/arm: preserve early mapping of UEFI memory map longer for BGRT Arnd Bergmann (1): omapfb: rename omap2 module to omap2fb.ko Bhushan Shah (1): ARM: dts: qcom: msm8974-hammerhead: increase load on l20 for sdhci Bjorn Andersson (1): soc: qcom: smem: Correct check for global partition Bob Peterson (1): gfs2: Don't reject a supposedly full bitmap if we have blocks reserved Christoffer Dall (1): KVM: arm/arm64: Fix vgic init race Dan Carpenter (1): fbdev: omapfb: off by one in omapfb_register_client() Daniel Mack (1): video: fbdev: pxafb: clear allocated memory for video modes Dmitry Torokhov (1): Input: pxrc - fix freeing URB on device teardown Erich E. Hoover (1): usb: dwc3: change stream event enable bit back to 13 Felix Fietkau (1): MIPS: ath79: fix system restart Fredrik Noring (1): fbdev: Distinguish between interlaced and progressive modes Golan Ben Ami (1): iwlwifi: cancel the injective function between hw pointers to tfd entry index Gregory CLEMENT (1): clk: mvebu: armada-37xx-periph: Fix wrong return value in get_parent Hanna Hawa (1): dmaengine: mv_xor_v2: kill the tasklets upon exit Hans Verkuil (1): media: videobuf2-core: check for q->error in vb2_core_qbuf() Jae Hyun Yoo (1): i2c: aspeed: Fix initial values of master and slave state Jakub Kicinski (2): nfp: don't fail probe on pci_sriov_set_totalvfs() errors nfp: avoid buffer leak when FW communication fails Jean-Philippe Brucker (2): iommu/io-pgtable-arm-v7s: Abort allocation when table address overflows the PTE iommu/io-pgtable-arm: Fix pgtable allocation in selftest Jeff Crukley (1): ALSA: usb-audio: Add support for Encore mDSD USB DAC Jiang Biao (2): x86/pti: Check the return value of pti_user_pagetable_walk_p4d() x86/pti: Check the return value of pti_user_pagetable_walk_pmd() Jiri Olsa (2): perf tools: Synthesize GROUP_DESC feature in pipe mode perf tools: Fix struct comm_str removal crash Joerg Roedel (1): x86/mm/pti: Add an overflow check to pti_clone_pmds() John Keeping (1): dmaengine: pl330: fix irq race with terminate_all Julian Wiedmann (2): s390/qeth: fix race in used-buffer accounting s390/qeth: reset layer2 attribute on layer switch Krzysztof Ha?asa (1): media: tw686x: Fix oops on buffer alloc failure Krzysztof Kozlowski (1): ARM: exynos: Clear global variable on init error path Leonard Crestez (1): reset: imx7: Fix always writing bits as 0 Loic Poulain (1): arm64: dts: qcom: db410c: Fix Bluetooth LED trigger Manikanta Pubbisetty (1): mac80211: restrict delayed tailroom needed decrement Mark Rutland (2): KVM: arm/arm64: vgic: Fix possible spectre-v1 write in vgic_mmio_write_apr() arm64: fix possible spectre-v1 write in ptrace_hbp_set_event() Masahiro Yamada (2): kbuild: add .DELETE_ON_ERROR special target kbuild: do not update config when running install targets Miao Zhong (1): iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register Michael MÃ¼ller (1): crypto: sharah - Unregister correct algorithms for SAHARA 3 Mike Snitzer (1): block: allow max_discard_segments to be stacked Mikko Perttunen (1): clk: core: Potentially free connection id Nicholas Mc Guire (4): clk: imx6ul: fix missing of_node_put() clk: imx6sll: fix missing of_node_put() staging: bcm2835-camera: fix timeout handling in wait_for_completion_timeout staging: bcm2835-camera: handle wait_for_completion_timeout return properly Nicholas Piggin (1): powerpc/powernv: opal_put_chars partial write fix Niklas Cassel (2): regulator: qcom_spmi: Use correct regmap when checking for error regulator: qcom_spmi: Fix warning Bad of_node_put() Oder Chiou (1): ASoC: rt5514: Fix the issue of the delay volume applied Paul Cercueil (1): MIPS: jz4740: Bump zload address Pingfan Liu (1): drivers/base: stop new probing during shutdown Piotr Sawicki (1): Smack: Fix handling of IPv4 traffic received by PF_INET6 sockets Rajan Vaja (1): clk: clk-fixed-factor: Clear OF_POPULATED flag in case of failure Randy Dunlap (3): mtd/maps: fix solutionengine.c printk format warnings fbdev/via: fix defined but not used warning platform/x86: toshiba_acpi: Fix defined but not used build warnings Rex Zhu (1): drm/amd/pp: Set Max clock level to display by default Sagi Grimberg (2): nvmet: fix file discard return status nvme-rdma: unquiesce queues when deleting the controller Sandipan Das (6): perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 perf tests: Fix record+probe_libc_inet_pton.sh when event exists perf tests: Fix record+probe_libc_inet_pton.sh to ensure cleanups perf powerpc: Fix callchain ip filtering when return address is in a register perf powerpc: Fix callchain ip filtering perf script: Show correct offsets for DWARF-based unwinding Takashi Iwai (3): ALSA: pcm: Add __force to cast in snd_pcm_lib_read/write() ALSA: msnd: Fix the default sample sizes ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro Thomas Richter (1): perf test: Fix subtest number when showing results Todor Tomov (1): media: ov5645: Supported external clock is 24MHz Vitaly Kuznetsov (1): xen-netfront: fix queue name setting Wei Yongjun (1): IB/ipoib: Fix error return code in ipoib_dev_init() Xiao Liang (1): xen-netfront: fix warn message as irq device name has '/' Yoshihiro Shimoda (1): iommu/ipmmu-vmsa: IMUCTRn.TTSEL needs a special usage on R-Car Gen3 Yue Wang (1): ALSA: usb-audio: Generic DSD detection for Thesycon-based implementations YueHaibing (3): xfrm: fix 'passing zero to ERR_PTR()' warning amd-xgbe: use dma_mapping_error to check map errors wan/fsl_ucc_hdlc: use IS_ERR_VALUE() to check return value of qe_muram_alloc Zhu Yanjun (1): IB/rxe: Drop QP0 silently Makefile | 27 ++++++--- .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 + arch/arm/mach-exynos/suspend.c | 1 + arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 2 +- arch/arm64/kernel/ptrace.c | 19 ++++--- arch/mips/ath79/setup.c | 1 + arch/mips/include/asm/mach-ath79/ath79.h | 1 + arch/mips/jz4740/Platform | 2 +- arch/powerpc/platforms/powernv/opal.c | 2 +- arch/x86/mm/pti.c | 25 ++++++-- block/blk-settings.c | 2 +- drivers/base/core.c | 3 + drivers/clk/clk-fixed-factor.c | 9 ++- drivers/clk/clk.c | 3 + drivers/clk/imx/clk-imx6sll.c | 1 + drivers/clk/imx/clk-imx6ul.c | 1 + drivers/clk/mvebu/armada-37xx-periph.c | 3 - drivers/crypto/sahara.c | 4 +- drivers/dma/mv_xor_v2.c | 2 + drivers/dma/pl330.c | 5 +- drivers/firmware/efi/arm-init.c | 1 - drivers/firmware/efi/arm-runtime.c | 4 +- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 9 ++- drivers/i2c/busses/i2c-aspeed.c | 4 +- drivers/infiniband/sw/rxe/rxe_recv.c | 9 ++- drivers/infiniband/ulp/ipoib/ipoib_main.c | 3 +- drivers/input/joystick/pxrc.c | 66 ++++++++++------------ drivers/iommu/arm-smmu-v3.c | 1 + drivers/iommu/io-pgtable-arm-v7s.c | 7 ++- drivers/iommu/io-pgtable-arm.c | 3 +- drivers/iommu/ipmmu-vmsa.c | 8 +++ drivers/media/common/videobuf2/videobuf2-core.c | 5 ++ drivers/media/i2c/ov5645.c | 13 +++-- drivers/media/pci/tw686x/tw686x-video.c | 11 +++- drivers/mtd/maps/solutionengine.c | 6 +- drivers/net/ethernet/amd/xgbe/xgbe-desc.c | 7 +-- drivers/net/ethernet/netronome/nfp/nfp_main.c | 20 ++++--- .../net/ethernet/netronome/nfp/nfp_net_common.c | 13 ++++- drivers/net/wan/fsl_ucc_hdlc.c | 6 +- drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 12 ++-- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 11 +++- drivers/net/xen-netfront.c | 6 +- drivers/nvme/host/rdma.c | 2 + drivers/nvme/target/io-cmd-file.c | 18 +++--- drivers/pci/pcie/aer.c | 6 ++ drivers/platform/x86/toshiba_acpi.c | 3 +- drivers/regulator/qcom_spmi-regulator.c | 34 ++++++----- drivers/reset/reset-imx7.c | 2 +- drivers/s390/net/qeth_core_main.c | 3 +- drivers/s390/net/qeth_core_sys.c | 1 + drivers/soc/qcom/smem.c | 10 ++-- .../vc04_services/bcm2835-camera/bcm2835-camera.c | 7 ++- .../vc04_services/bcm2835-camera/mmal-vchiq.c | 11 ++-- drivers/usb/dwc3/gadget.h | 2 +- drivers/video/fbdev/core/modedb.c | 41 ++++++++++---- drivers/video/fbdev/goldfishfb.c | 1 + drivers/video/fbdev/omap/omapfb_main.c | 2 +- drivers/video/fbdev/omap2/omapfb/Makefile | 4 +- drivers/video/fbdev/pxafb.c | 4 +- drivers/video/fbdev/via/viafbdev.c | 3 +- fs/gfs2/bmap.c | 2 +- fs/gfs2/rgrp.c | 3 +- include/sound/pcm.h | 4 +- net/mac80211/cfg.c | 2 +- net/mac80211/key.c | 24 +++++--- net/xfrm/xfrm_policy.c | 5 +- scripts/Kbuild.include | 3 + security/smack/smack_lsm.c | 14 +++-- sound/isa/msnd/msnd_pinnacle.c | 4 +- sound/soc/codecs/rt5514.c | 8 +-- sound/usb/quirks-table.h | 3 +- sound/usb/quirks.c | 2 + tools/perf/arch/powerpc/util/skip-callchain-idx.c | 10 +++- tools/perf/tests/builtin-test.c | 2 +- .../tests/shell/record+probe_libc_inet_pton.sh | 36 ++++++++++-- tools/perf/util/comm.c | 16 ++++-- tools/perf/util/header.c | 2 +- tools/perf/util/machine.c | 9 ++- tools/perf/util/unwind-libdw.c | 2 +- tools/perf/util/unwind-libunwind-local.c | 2 +- virt/kvm/arm/vgic/vgic-init.c | 4 ++ virt/kvm/arm/vgic/vgic-mmio-v2.c | 3 + 82 files changed, 436 insertions(+), 218 deletions(-) -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlugPMwACgkQ3qZv95d3 LNyyIw//fOsB+VO3qSfxAB+nCIH6xaO7jWW8EIAaFYGIFjhgm8dDvXmTR2zv4OsW MoDPTfQXCmsWnwnymTEvlopu3tEMKK0R8uHXMpkSByCP6ie5WE6DJ2zjex+yqEDM W5gUBQVK9Qj3OzQxA4YbHtUKRXNVE/EtMqOrgjuRw08brdCXxbqt48iOm3EC+lFq nrKquXCvRggBguPV1xKoFP9bwTafClQ0owuPS6OWdTBWNu2B7X2dua3jBW64yX1V wru3/MznYgcC/yKsauimLeS99x2Y3I+He0udEyCII4ylsgWzZJg6O9uvNi9HnuP+ qFg+ew4ecb+MFH31RjEkipHg3thAFdMdMC1pNzZLdaof03wMWV2DsioA4newv+Px jzW8vikqQC51MeVIbEIiCAkoFf4yZjIOehvi70s4TsaCOwxKusntP0jvUGDxWS6A GmU6wpoeqBAUZoWFspLbhrkOZanOCncdBUFSBgS0xX4som9j+jnHYAf3cyz7Iuj0 jeenjgM5vqL2jyOh18gz2BYTQT+kHsuJ/bD6OS5AEcgNlnTLC5SRlVYrFHopzt8Z 8yp1kko8LhTAXDaTwXuhi30DrStJzM1Cnm0pbi/XnRSLEpXRLWx3f5ODTQvID4d9 IksJxN7G+Mm7Bc/obEVytvnslSVvFFWzmJKhYRYbpAmfHT4Byo8= =A0j/ -----END PGP SIGNATURE-----

6 years, 7 months

2
1
0 0

[PATCH] powerpc: fix csum_ipv6_magic() on little endian platforms

by Christophe Leroy

On little endian platforms, csum_ipv6_magic() keeps len and proto in CPU byte order. This generates a bad results leading to ICMPv6 packets from other hosts being dropped by powerpc64le platforms. In order to fix this, len and proto should be converted to network byte order ie bigendian byte order. However checksumming 0x12345678 and 0x56341278 provide the exact same result so it is enough to rotate the sum of len and proto by 1 byte. PPC32 only support bigendian so the fix is needed for PPC64 only Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly") Reported-by: Jianlin Shi <jishi(a)redhat.com> Reported-by: Xin Long <lucien.xin(a)gmail.com> Cc: <stable(a)vger.kernel.org> # 4.18+ Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> --- arch/powerpc/lib/checksum_64.S | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S index 886ed94b9c13..2a68c43e13f5 100644 --- a/arch/powerpc/lib/checksum_64.S +++ b/arch/powerpc/lib/checksum_64.S @@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic) addc r0, r8, r9 ld r10, 0(r4) ld r11, 8(r4) +#ifndef CONFIG_CPU_BIG_ENDIAN + rotldi r5, r5, 8 +#endif adde r0, r0, r10 add r5, r5, r7 adde r0, r0, r11 -- 2.13.3

6 years, 7 months

4
3
0 0

[PATCH] spi: spi-mem: Adjust op len based on message/transfer size limitations

by Chuanhua Han

We need that to adjust the len of the 2nd transfer (called data in spi-mem) if it's too long to fit in a SPI message or SPI transfer. Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers") Cc: <stable(a)vger.kernel.org> Signed-off-by: Chuanhua Han <chuanhua.han(a)nxp.com> Reviewed-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- drivers/spi/spi-mem.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index 990770dfa5cf..ec0c24e873cd 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -328,10 +328,25 @@ EXPORT_SYMBOL_GPL(spi_mem_exec_op); int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op) { struct spi_controller *ctlr = mem->spi->controller; + size_t len; + + len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes; if (ctlr->mem_ops && ctlr->mem_ops->adjust_op_size) return ctlr->mem_ops->adjust_op_size(mem, op); + if (!ctlr->mem_ops || !ctlr->mem_ops->exec_op) { + if (len > spi_max_transfer_size(mem->spi)) + return -EINVAL; + + op->data.nbytes = min3((size_t)op->data.nbytes, + spi_max_transfer_size(mem->spi), + spi_max_message_size(mem->spi) - + len); + if (!op->data.nbytes) + return -EINVAL; + } + return 0; } EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size); -- 2.17.1

6 years, 7 months

1
1
0 0

[PATCH] apparmor: fix SECURITY_APPARMOR_HASH_DEFAULT parameter handling

by Loic

Hello, Tested without any problem so please picked up this for 4.4 to fix the problem. The patch below is slightly modified to adapt to this version. [ Upstream commit 7616ac70d1bb4f2e9d25c1a82d283f3368a7b632 ] The newly added Kconfig option could never work and just causes a build error when disabled: security/apparmor/lsm.c:675:25: error: 'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a function) bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT; The problem is that the macro undefined in this case, and we need to use the IS_ENABLED() helper to turn it into a boolean constant. Another minor problem with the original patch is that the option is even offered in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides the option in that case. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Fixes: 6059f71f1e94 ("apparmor: add parameter to control whether policy hashing is used") Signed-off-by: John Johansen <john.johansen(a)canonical.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> --- diff -Nurp a/security/apparmor/crypto.c b/security/apparmor/crypto.c --- a/security/apparmor/crypto.c +++ b/security/apparmor/crypto.c @@ -39,6 +39,9 @@ int aa_calc_profile_hash(struct aa_profi int error = -ENOMEM; u32 le32_version = cpu_to_le32(version); + if (!aa_g_hash_policy) + return 0; + if (!apparmor_tfm) return 0; diff -Nurp a/security/apparmor/lsm.c b/security/apparmor/lsm.c --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -692,6 +692,12 @@ enum profile_mode aa_g_profile_mode = AP module_param_call(mode, param_set_mode, param_get_mode, &aa_g_profile_mode, S_IRUSR | S_IWUSR); +#ifdef CONFIG_SECURITY_APPARMOR_HASH +/* whether policy verification hashing is enabled */ +bool aa_g_hash_policy = IS_ENABLED(CONFIG_SECURITY_APPARMOR_HASH_DEFAULT); +module_param_named(hash_policy, aa_g_hash_policy, aabool, S_IRUSR | S_IWUSR); +#endif + /* Debug mode */ bool aa_g_debug; module_param_named(debug, aa_g_debug, aabool, S_IRUSR | S_IWUSR); ---

6 years, 7 months

4
10
0 0

[PATCH for-rc 0/4] IB/hfi1: Couple more for the RC cycle

by Dennis Dalessandro

Hi Doug and Jason, Mike and Ira have identified some fixes that they would like to see land in the RC, these are serious problems and are marked as stable. Changes since v1: Update Lukasz' email address and fix subject tag. --- Ira Weiny (1): IB/hfi1: Fix SL array bounds check Michael J. Ruhl (3): IB/hfi1: Invalid user input can result in crash IB/hfi1: Fix context recovery when PBC has an UnsupportedVL IB/hfi1: Fix destroy_qp hang after a link down drivers/infiniband/hw/hfi1/chip.c | 6 +++- drivers/infiniband/hw/hfi1/pio.c | 51 ++++++++++++++++++++++++++------ drivers/infiniband/hw/hfi1/pio.h | 2 + drivers/infiniband/hw/hfi1/user_sdma.c | 2 + drivers/infiniband/hw/hfi1/verbs.c | 8 ++++- 5 files changed, 56 insertions(+), 13 deletions(-) -- -Denny

6 years, 7 months

2
5
0 0

[PATCH v2 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

by Lyude Paul

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic commit to fail. However, this is wrong in a rather subtle way. If ->best_encoder() returns NULL, this makes ALL modesets involving the connector fail. This includes modesets from userspace that would shut off the CRTCs being used by the connector. Since this results in blocking any changes to a connector's DPMS prop, it has the sideaffect of preventing legacy modesetting users from ever disabling a CRTC that was previously enabled for use in an MST topology. An example of this, where X tries to change the DPMS property of an MST connector that was just detached from the system: [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] status updated from connected to disconnected [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] disconnected [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1) [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event ... [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETPROPERTY [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 000000007155ba49 [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1) [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1) [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 0000000097a6396e state to 000000007155ba49 [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:41:head-0] to 000000007155ba49 [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3) [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4) [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:82:DP-6] 0000000087427144 state to 000000007155ba49 [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 000000007155ba49 [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:41:head-0] active changed [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:82:DP-6] [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No suitable encoder found for [CONNECTOR:82:DP-6] [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000007155ba49 failed: -22 [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000007155ba49 [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4) [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3) [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2) [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2) [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 000000007155ba49 [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2) [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22 While this doesn't usually result in any errors that would be obvious to the user, it does result in us leaving display resources on. This in turn leads to unwanted sideaffects like inactive GPUs being left on (usually from the resulting leaked runtime PM ref). So, provide an easier way of doing this that doesn't require breaking ->best_encoder(): add a common drm_dp_mst_connector_atomic_check() function that DRM drivers can call in order to have CRTC enabling commits fail automatically if the MST port driving the connector no longer exists. We'll also be able to expand upon this later as well once we add MST fallback retraining support. Changes since v1: - Use list_for_each_entry_safe in drm_dp_mst_connector_still_exists() - Julia Lawall Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Julia Lawall <julia.lawall(a)lip6.fr> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++++++++++++++++++++++++++ include/drm/drm_dp_mst_helper.h | 3 ++ 2 files changed, 79 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 7780567aa669..58b9554711c7 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs mst_state_funcs = { .atomic_destroy_state = drm_dp_mst_destroy_state, }; +static bool +drm_dp_mst_connector_still_exists(struct drm_connector *connector, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_branch *mstb) +{ + struct drm_dp_mst_port *port, *tmp; + bool exists = false; + + mstb = drm_dp_get_validated_mstb_ref(mgr, mstb); + if (!mstb) + return false; + + list_for_each_entry_safe(port, tmp, &mstb->ports, next) { + port = drm_dp_get_validated_port_ref(mgr, port); + if (!port) + continue; + + exists = (port->connector == connector || + (port->mstb && + drm_dp_mst_connector_still_exists(connector, mgr, + port->mstb))); + + drm_dp_put_port(port); + if (exists) + break; + } + + drm_dp_put_mst_branch_device(mstb); + return exists; +} + +/** + * drm_dp_mst_connector_atomic_check - Helper for validating a new atomic + * state on an MST connector + * @connector: drm connector + * @connector_state: the new atomic state of @connector + * @mgr: the MST topology mgr for @connector + * + * This function performs various atomic checks that apply to all drivers + * using the DRM DP MST helpers. This should be called by all drivers at the + * start of the atomic_check function for their MST connectors. + * + * Return 0 for success, or negative error code on failure. + */ +int +drm_dp_mst_connector_atomic_check(struct drm_connector *connector, + struct drm_connector_state *connector_state, + struct drm_dp_mst_topology_mgr *mgr) +{ + struct drm_atomic_state *state = connector_state->state; + struct drm_crtc *crtc = connector_state->crtc; + struct drm_crtc_state *new_crtc_state; + + if (!crtc) + return 0; + + new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc); + if (!new_crtc_state) + return 0; + + if (!drm_atomic_crtc_needs_modeset(new_crtc_state) || + !new_crtc_state->active) + return 0; + + /* Make sure that the port for this MST connector still exists */ + if (!drm_dp_mst_connector_still_exists(connector, mgr, + mgr->mst_primary)) { + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] has disappeared from the MST topology\n", + connector->base.id, connector->name); + return -EINVAL; + } + + return 0; +} +EXPORT_SYMBOL(drm_dp_mst_connector_atomic_check); + /** * drm_atomic_get_mst_topology_state: get MST topology state * diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 7f78d26a0766..8e33c2c85d1e 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -625,6 +625,9 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr); int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr); struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr); +int drm_dp_mst_connector_atomic_check(struct drm_connector *connector, + struct drm_connector_state *connector_state, + struct drm_dp_mst_topology_mgr *mgr); int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port, int pbn); -- 2.17.1

6 years, 7 months

2
1
0 0

[PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()

by Lyude Paul

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic commit to fail. However, this is wrong in a rather subtle way. If ->best_encoder() returns NULL, this makes ALL modesets involving the connector fail. This includes modesets from userspace that would shut off the CRTCs being used by the connector. Since this results in blocking any changes to a connector's DPMS prop, it has the sideaffect of preventing legacy modesetting users from ever disabling a CRTC that was previously enabled for use in an MST topology. An example of this, where X tries to change the DPMS property of an MST connector that was just detached from the system: [ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] [ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] status updated from connected to disconnected [ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] disconnected [ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1) [ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event ... [ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETPROPERTY [ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 000000007155ba49 [ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1) [ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1) [ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 0000000097a6396e state to 000000007155ba49 [ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:41:head-0] to 000000007155ba49 [ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3) [ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4) [ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:82:DP-6] 0000000087427144 state to 000000007155ba49 [ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 000000007155ba49 [ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:41:head-0] active changed [ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:82:DP-6] [ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No suitable encoder found for [CONNECTOR:82:DP-6] [ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000007155ba49 failed: -22 [ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000007155ba49 [ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4) [ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3) [ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2) [ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2) [ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 000000007155ba49 [ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2) [ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22 While this doesn't usually result in any errors that would be obvious to the user, it does result in us leaving display resources on. This in turn leads to unwanted sideaffects like inactive GPUs being left on (usually from the resulting leaked runtime PM ref). So, provide an easier way of doing this that doesn't require breaking ->best_encoder(): add a common drm_dp_mst_connector_atomic_check() function that DRM drivers can call in order to have CRTC enabling commits fail automatically if the MST port driving the connector no longer exists. We'll also be able to expand upon this later as well once we add MST fallback retraining support. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++++++++++++++++++++++++++ include/drm/drm_dp_mst_helper.h | 3 ++ 2 files changed, 79 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 7780567aa669..0162d4bf2549 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs mst_state_funcs = { .atomic_destroy_state = drm_dp_mst_destroy_state, }; +static bool +drm_dp_mst_connector_still_exists(struct drm_connector *connector, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_branch *mstb) +{ + struct drm_dp_mst_port *port; + bool exists = false; + + mstb = drm_dp_get_validated_mstb_ref(mgr, mstb); + if (!mstb) + return false; + + list_for_each_entry(port, &mstb->ports, next) { + port = drm_dp_get_validated_port_ref(mgr, port); + if (!port) + continue; + + exists = (port->connector == connector || + (port->mstb && + drm_dp_mst_connector_still_exists(connector, mgr, + port->mstb))); + + drm_dp_put_port(port); + if (exists) + break; + } + + drm_dp_put_mst_branch_device(mstb); + return exists; +} + +/** + * drm_dp_mst_connector_atomic_check - Helper for validating a new atomic + * state on an MST connector + * @connector: drm connector + * @connector_state: the new atomic state of @connector + * @mgr: the MST topology mgr for @connector + * + * This function performs various atomic checks that apply to all drivers + * using the DRM DP MST helpers. This should be called by all drivers at the + * start of the atomic_check function for their MST connectors. + * + * Return 0 for success, or negative error code on failure. + */ +int +drm_dp_mst_connector_atomic_check(struct drm_connector *connector, + struct drm_connector_state *connector_state, + struct drm_dp_mst_topology_mgr *mgr) +{ + struct drm_atomic_state *state = connector_state->state; + struct drm_crtc *crtc = connector_state->crtc; + struct drm_crtc_state *new_crtc_state; + + if (!crtc) + return 0; + + new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc); + if (!new_crtc_state) + return 0; + + if (!drm_atomic_crtc_needs_modeset(new_crtc_state) || + !new_crtc_state->active) + return 0; + + /* Make sure that the port for this MST connector still exists */ + if (!drm_dp_mst_connector_still_exists(connector, mgr, + mgr->mst_primary)) { + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] has disappeared from the MST topology\n", + connector->base.id, connector->name); + return -EINVAL; + } + + return 0; +} +EXPORT_SYMBOL(drm_dp_mst_connector_atomic_check); + /** * drm_atomic_get_mst_topology_state: get MST topology state * diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 7f78d26a0766..8e33c2c85d1e 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -625,6 +625,9 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr); int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr); struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr); +int drm_dp_mst_connector_atomic_check(struct drm_connector *connector, + struct drm_connector_state *connector_state, + struct drm_dp_mst_topology_mgr *mgr); int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port, int pbn); -- 2.17.1

6 years, 7 months

4
4
0 0

Re: [PATCH] nohz: Fix missing tick reprog while interrupting inline timer softirq

by Thomas Gleixner

On Thu, 20 Sep 2018, Evan Green wrote: > On Thu, Aug 30, 2018 at 7:29 AM Thomas Gleixner <tglx(a)linutronix.de> wrote: > > > > On Thu, 30 Aug 2018, John Crispin wrote: > > > > > > Sry, that disturbing you all, but what are the conclusion here for 4.14.y? > > > > - take Thomas's patch https://lore.kernel.org/patchwork/patch/969521/#1162900 > > > > - revert commit 2d898915ccf4838c04531c51a598469e921a5eb5 > > > > > > Hi Frederic, > > > > > > I reported this very issue to tglx last night and he asked me to verify his > > > proposed patch which i just did. I can confirm the the patch fixes the issue > > > on 4.14.67 and Greg should add it to the stable queue please. > > > > > > Tested-by: John Crispin <john(a)phrozen.org> > > > > Let me whip up a proper patch with changelog. > > > Hi Thomas, > Did this patch ever go anywhere? I believe it fixes the prints I'm > seeing in our kernel, and I wondered if the official patch was > somewhere. It's out there: https://lore.kernel.org/patchwork/patch/979451/ I assume that it has fallen through the stable cracks. Thanks, tglx

6 years, 7 months

2
1
0 0

[PATCH for-next 0/4] IB/hfi1: Couple more for the RC cycle

by Dennis Dalessandro

Hi Doug and Jason, Mike and Ira have identified some fixes that they would like to see land in the RC, these are serious problems and are marked as stable. --- Ira Weiny (1): IB/hfi1: Fix SL array bounds check Michael J. Ruhl (3): IB/hfi1: Invalid user input can result in crash IB/hfi1: Fix context recovery when PBC has an UnsupportedVL IB/hfi1: Fix destroy_qp hang after a link down drivers/infiniband/hw/hfi1/chip.c | 6 +++- drivers/infiniband/hw/hfi1/pio.c | 51 ++++++++++++++++++++++++++------ drivers/infiniband/hw/hfi1/pio.h | 2 + drivers/infiniband/hw/hfi1/user_sdma.c | 2 + drivers/infiniband/hw/hfi1/verbs.c | 8 ++++- 5 files changed, 56 insertions(+), 13 deletions(-) -- -Denny

6 years, 7 months

1
5
0 0

[patch 7/7] ocfs2: fix ocfs2 read block panic

by akpm＠linux-foundation.org

From: Junxiao Bi <junxiao.bi(a)oracle.com> Subject: ocfs2: fix ocfs2 read block panic While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic. [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342! [203748.702533] invalid opcode: 0000 [#1] SMP [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2 [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015 [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000 [203748.703088] RIP: 0010:[<ffffffffa05e9f09>] [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.703130] RSP: 0018:ffff88006ff4b818 EFLAGS: 00010206 [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000 [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0 [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000 [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000 [203748.705871] FS: 00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000 [203748.706370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670 [203748.707124] Stack: [203748.707371] ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001 [203748.707885] 0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00 [203748.708399] 00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000 [203748.708915] Call Trace: [203748.709175] [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2] [203748.709680] [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2] [203748.710185] [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2] [203748.710691] [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2] [203748.711204] [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2] [203748.711716] [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2] [203748.712227] [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2] [203748.712737] [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2] [203748.713003] [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2] [203748.713263] [<ffffffff8121714b>] vfs_create+0xdb/0x150 [203748.713518] [<ffffffff8121b225>] do_last+0x815/0x1210 [203748.713772] [<ffffffff812192e9>] ? path_init+0xb9/0x450 [203748.714123] [<ffffffff8121bca0>] path_openat+0x80/0x600 [203748.714378] [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620 [203748.714634] [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0 [203748.714888] [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130 [203748.715143] [<ffffffff81209ffc>] do_sys_open+0x12c/0x220 [203748.715403] [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180 [203748.715668] [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190 [203748.715928] [<ffffffff8120a10e>] SyS_open+0x1e/0x20 [203748.716184] [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7 [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10 [203748.717505] RIP [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.717775] RSP <ffff88006ff4b818> Joesph ever reported a similar panic. Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Joseph Qi <jiangqi903(a)gmail.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN fs/ocfs2/buffer_head_io.c~ocfs2-fix-ocfs2-read-block-panic fs/ocfs2/buffer_head_io.c --- a/fs/ocfs2/buffer_head_io.c~ocfs2-fix-ocfs2-read-block-panic +++ a/fs/ocfs2/buffer_head_io.c @@ -342,6 +342,7 @@ int ocfs2_read_blocks(struct ocfs2_cachi * for this bh as it's not marked locally * uptodate. */ status = -EIO; + clear_buffer_needs_validate(bh); put_bh(bh); bhs[i] = NULL; continue; _

6 years, 7 months

1
0
0 0

[patch 4/7] mm: shmem.c: Correctly annotate new inodes for lockdep

by akpm＠linux-foundation.org

From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org> Subject: mm: shmem.c: Correctly annotate new inodes for lockdep Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class. This should fix a lockdep splat reported by syzbot: > ====================================================== > WARNING: possible circular locking dependency detected > 4.18.0-rc8-next-20180810+ #36 Not tainted > ------------------------------------------------------ > syz-executor900/4483 is trying to acquire lock: > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock > include/linux/fs.h:765 [inline] > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > > but task is already holding lock: > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 > drivers/staging/android/ashmem.c:448 > > which lock already depends on the new lock. > > -> #2 (ashmem_mutex){+.+.}: > __mutex_lock_common kernel/locking/mutex.c:925 [inline] > __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088 > ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361 > call_mmap include/linux/fs.h:1844 [inline] > mmap_region+0xf27/0x1c50 mm/mmap.c:1762 > do_mmap+0xa10/0x1220 mm/mmap.c:1535 > do_mmap_pgoff include/linux/mm.h:2298 [inline] > vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357 > ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585 > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #1 (&mm->mmap_sem){++++}: > __might_fault+0x155/0x1e0 mm/memory.c:4568 > _copy_to_user+0x30/0x110 lib/usercopy.c:25 > copy_to_user include/linux/uaccess.h:155 [inline] > filldir+0x1ea/0x3a0 fs/readdir.c:196 > dir_emit_dot include/linux/fs.h:3464 [inline] > dir_emit_dots include/linux/fs.h:3475 [inline] > dcache_readdir+0x13a/0x620 fs/libfs.c:193 > iterate_dir+0x48b/0x5d0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #0 (&sb->s_type->i_mutex_key#9){++++}: > lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 > down_write+0x8f/0x130 kernel/locking/rwsem.c:70 > inode_lock include/linux/fs.h:765 [inline] > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455 > ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > other info that might help us debug this: > > Chain exists of: > &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(ashmem_mutex); > lock(&mm->mmap_sem); > lock(ashmem_mutex); > lock(&sb->s_type->i_mutex_key#9); > > *** DEADLOCK *** > > 1 lock held by syz-executor900/4483: > #0: 0000000025208078 (ashmem_mutex){+.+.}, at: > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448 Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: NeilBrown <neilb(a)suse.com> Suggested-by: NeilBrown <neilb(a)suse.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/shmem.c~mm-shmem-correctly-annotate-new-inodes-for-lockdep mm/shmem.c --- a/mm/shmem.c~mm-shmem-correctly-annotate-new-inodes-for-lockdep +++ a/mm/shmem.c @@ -2227,6 +2227,8 @@ static struct inode *shmem_get_inode(str mpol_shared_policy_init(&info->policy, NULL); break; } + + lockdep_annotate_inode_mutex_key(inode); } else shmem_free_inode(sb); return inode; _

6 years, 7 months

1
0
0 0

[patch 2/7] mm: disable deferred struct page for 32-bit arches

by akpm＠linux-foundation.org

From: Pasha Tatashin <Pavel.Tatashin(a)microsoft.com> Subject: mm: disable deferred struct page for 32-bit arches Deferred struct page init is needed only on systems with large amount of physical memory to improve boot performance. 32-bit systems do not benefit from this feature. Jiri reported a problem where deferred struct pages do not work well with x86-32: [ 0.035162] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.035725] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.036269] Initializing CPU#0 [ 0.036513] Initializing HighMem for node 0 (00036ffe:0007ffe0) [ 0.038459] page:f6780000 is uninitialized and poisoned [ 0.038460] raw: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff [ 0.039509] page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)) [ 0.040038] ------------[ cut here ]------------ [ 0.040399] kernel BUG at include/linux/page-flags.h:293! [ 0.040823] invalid opcode: 0000 [#1] SMP PTI [ 0.041166] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1_pt_jiri #9 [ 0.041694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 [ 0.042496] EIP: free_highmem_page+0x64/0x80 [ 0.042839] Code: 13 46 d8 c1 e8 18 5d 83 e0 03 8d 04 c0 c1 e0 06 ff 80 ec 5f 44 d8 c3 8d b4 26 00 00 00 00 ba 08 65 28 d8 89 d8 e8 fc 71 02 00 <0f> 0b 8d 76 00 8d bc 27 00 00 00 00 ba d0 b1 26 d8 89 d8 e8 e4 71 [ 0.044338] EAX: 0000003c EBX: f6780000 ECX: 00000000 EDX: d856cbe8 [ 0.044868] ESI: 0007ffe0 EDI: d838df20 EBP: d838df00 ESP: d838defc [ 0.045372] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210086 [ 0.045913] CR0: 80050033 CR2: 00000000 CR3: 18556000 CR4: 00040690 [ 0.046413] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 0.046913] DR6: fffe0ff0 DR7: 00000400 [ 0.047220] Call Trace: [ 0.047419] add_highpages_with_active_regions+0xbd/0x10d [ 0.047854] set_highmem_pages_init+0x5b/0x71 [ 0.048202] mem_init+0x2b/0x1e8 [ 0.048460] start_kernel+0x1d2/0x425 [ 0.048757] i386_start_kernel+0x93/0x97 [ 0.049073] startup_32_smp+0x164/0x168 [ 0.049379] Modules linked in: [ 0.049626] ---[ end trace 337949378db0abbb ]--- We free highmem pages before their struct pages are initialized: mem_init() set_highmem_pages_init() add_highpages_with_active_regions() free_highmem_page() .. Access uninitialized struct page here.. Because there is no reason to have this feature on 32-bit systems, just disable it. Link: http://lkml.kernel.org/r/20180831150506.31246-1-pavel.tatashin@microsoft.com Fixes: 2e3ca40f03bb ("mm: relax deferred struct page requirements") Signed-off-by: Pavel Tatashin <pavel.tatashin(a)microsoft.com> Reported-by: Jiri Slaby <jslaby(a)suse.cz> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/Kconfig~mm-disable-deferred-struct-page-for-32-bit-arches mm/Kconfig --- a/mm/Kconfig~mm-disable-deferred-struct-page-for-32-bit-arches +++ a/mm/Kconfig @@ -637,6 +637,7 @@ config DEFERRED_STRUCT_PAGE_INIT depends on NO_BOOTMEM depends on SPARSEMEM depends on !NEED_PER_CPU_KM + depends on 64BIT help Ordinarily all struct pages are initialised during early boot in a single thread. On very large machines this can take a considerable _

6 years, 7 months

1
0
0 0

[patch 1/7] fork: report pid exhaustion correctly

by akpm＠linux-foundation.org

From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Subject: fork: report pid exhaustion correctly Make the clone and fork syscalls return EAGAIN when the limit on the number of pids /proc/sys/kernel/pid_max is exceeded. Currently, when the pid_max limit is exceeded, the kernel will return ENOSPC from the fork and clone syscalls. This is contrary to the documented behaviour, which explicitly calls out the pid_max case as one where EAGAIN should be returned. It also leads to really confusing error messages in userspace programs which will complain about a lack of disk space when they fail to create processes/threads for this reason. This error is being returned because alloc_pid() uses the idr api to find a new pid; when there are none available, idr_alloc_cyclic() returns -ENOSPC, and this is being propagated back to userspace. This behaviour has been broken before, and was explicitly fixed in commit 35f71bc0a09a ("fork: report pid reservation failure properly"), so I think -EAGAIN is definitely the right thing to return in this case. The current behaviour change dates from commit 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") and was I believe unintentional. This patch has no impact on the case where allocating a pid fails because the child reaper for the namespace is dead; that case will still return -ENOMEM. Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Gargi Sharma <gs051095(a)gmail.com> Cc: Rik van Riel <riel(a)redhat.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c --- a/kernel/pid.c~fork-report-pid-exhaustion-correctly +++ a/kernel/pid.c @@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa idr_preload_end(); if (nr < 0) { - retval = nr; + retval = (nr == -ENOSPC) ? -EAGAIN : nr; goto out_free; } _

6 years, 7 months

1
0
0 0

[patch 1/7] fork: report pid exhaustion correctly

by akpm＠linux-foundation.org

From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Subject: fork: report pid exhaustion correctly Make the clone and fork syscalls return EAGAIN when the limit on the number of pids /proc/sys/kernel/pid_max is exceeded. Currently, when the pid_max limit is exceeded, the kernel will return ENOSPC from the fork and clone syscalls. This is contrary to the documented behaviour, which explicitly calls out the pid_max case as one where EAGAIN should be returned. It also leads to really confusing error messages in userspace programs which will complain about a lack of disk space when they fail to create processes/threads for this reason. This error is being returned because alloc_pid() uses the idr api to find a new pid; when there are none available, idr_alloc_cyclic() returns -ENOSPC, and this is being propagated back to userspace. This behaviour has been broken before, and was explicitly fixed in commit 35f71bc0a09a ("fork: report pid reservation failure properly"), so I think -EAGAIN is definitely the right thing to return in this case. The current behaviour change dates from commit 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") and was I believe unintentional. This patch has no impact on the case where allocating a pid fails because the child reaper for the namespace is dead; that case will still return -ENOMEM. Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Gargi Sharma <gs051095(a)gmail.com> Cc: Rik van Riel <riel(a)redhat.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c --- a/kernel/pid.c~fork-report-pid-exhaustion-correctly +++ a/kernel/pid.c @@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa idr_preload_end(); if (nr < 0) { - retval = nr; + retval = (nr == -ENOSPC) ? -EAGAIN : nr; goto out_free; } _

6 years, 7 months

1
0
0 0

[patch 7/7] ocfs2: fix ocfs2 read block panic

by akpm＠linux-foundation.org

From: Junxiao Bi <junxiao.bi(a)oracle.com> Subject: ocfs2: fix ocfs2 read block panic While reading block, it is possible that io error return due to underlying storage issue, in this case, BH_NeedsValidate was left in the buffer head. Then when reading the very block next time, if it was already linked into journal, that will trigger the following panic. [203748.702517] kernel BUG at fs/ocfs2/buffer_head_io.c:342! [203748.702533] invalid opcode: 0000 [#1] SMP [203748.702561] Modules linked in: ocfs2 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc dm_switch dm_queue_length dm_multipath bonding be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i iw_cxgb4 cxgb4 cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_devintf iTCO_wdt iTCO_vendor_support dcdbas ipmi_ssif i2c_core ipmi_si ipmi_msghandler acpi_pad pcspkr sb_edac edac_core lpc_ich mfd_core shpchp sg tg3 ptp pps_core ext4 jbd2 mbcache2 sr_mod cdrom sd_mod ahci libahci megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [203748.703024] CPU: 7 PID: 38369 Comm: touch Not tainted 4.1.12-124.18.6.el6uek.x86_64 #2 [203748.703045] Hardware name: Dell Inc. PowerEdge R620/0PXXHP, BIOS 2.5.2 01/28/2015 [203748.703067] task: ffff880768139c00 ti: ffff88006ff48000 task.ti: ffff88006ff48000 [203748.703088] RIP: 0010:[<ffffffffa05e9f09>] [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.703130] RSP: 0018:ffff88006ff4b818 EFLAGS: 00010206 [203748.703389] RAX: 0000000008620029 RBX: ffff88006ff4b910 RCX: 0000000000000000 [203748.703885] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000023079fe [203748.704382] RBP: ffff88006ff4b8d8 R08: 0000000000000000 R09: ffff8807578c25b0 [203748.704877] R10: 000000000f637376 R11: 000000003030322e R12: 0000000000000000 [203748.705373] R13: ffff88006ff4b910 R14: ffff880732fe38f0 R15: 0000000000000000 [203748.705871] FS: 00007f401992c700(0000) GS:ffff880bfebc0000(0000) knlGS:0000000000000000 [203748.706370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [203748.706627] CR2: 00007f4019252440 CR3: 00000000a621e000 CR4: 0000000000060670 [203748.707124] Stack: [203748.707371] ffff88006ff4b828 ffffffffa0609f52 ffff88006ff4b838 0000000000000001 [203748.707885] 0000000000000000 0000000000000000 ffff880bf67c3800 ffffffffa05eca00 [203748.708399] 00000000023079ff ffffffff81c58b80 0000000000000000 0000000000000000 [203748.708915] Call Trace: [203748.709175] [<ffffffffa0609f52>] ? ocfs2_inode_cache_io_unlock+0x12/0x20 [ocfs2] [203748.709680] [<ffffffffa05eca00>] ? ocfs2_empty_dir_filldir+0x80/0x80 [ocfs2] [203748.710185] [<ffffffffa05ec0cb>] ocfs2_read_dir_block_direct+0x3b/0x200 [ocfs2] [203748.710691] [<ffffffffa05f0fbf>] ocfs2_prepare_dx_dir_for_insert.isra.57+0x19f/0xf60 [ocfs2] [203748.711204] [<ffffffffa065660f>] ? ocfs2_metadata_cache_io_unlock+0x1f/0x30 [ocfs2] [203748.711716] [<ffffffffa05f4f3a>] ocfs2_prepare_dir_for_insert+0x13a/0x890 [ocfs2] [203748.712227] [<ffffffffa05f442e>] ? ocfs2_check_dir_for_entry+0x8e/0x140 [ocfs2] [203748.712737] [<ffffffffa061b2f2>] ocfs2_mknod+0x4b2/0x1370 [ocfs2] [203748.713003] [<ffffffffa061c385>] ocfs2_create+0x65/0x170 [ocfs2] [203748.713263] [<ffffffff8121714b>] vfs_create+0xdb/0x150 [203748.713518] [<ffffffff8121b225>] do_last+0x815/0x1210 [203748.713772] [<ffffffff812192e9>] ? path_init+0xb9/0x450 [203748.714123] [<ffffffff8121bca0>] path_openat+0x80/0x600 [203748.714378] [<ffffffff811bcd45>] ? handle_pte_fault+0xd15/0x1620 [203748.714634] [<ffffffff8121d7ba>] do_filp_open+0x3a/0xb0 [203748.714888] [<ffffffff8122a767>] ? __alloc_fd+0xa7/0x130 [203748.715143] [<ffffffff81209ffc>] do_sys_open+0x12c/0x220 [203748.715403] [<ffffffff81026ddb>] ? syscall_trace_enter_phase1+0x11b/0x180 [203748.715668] [<ffffffff816f0c9f>] ? system_call_after_swapgs+0xe9/0x190 [203748.715928] [<ffffffff8120a10e>] SyS_open+0x1e/0x20 [203748.716184] [<ffffffff816f0d5e>] system_call_fastpath+0x18/0xd7 [203748.716440] Code: 00 00 48 8b 7b 08 48 83 c3 10 45 89 f8 44 89 e1 44 89 f2 4c 89 ee e8 07 06 11 e1 48 8b 03 48 85 c0 75 df 8b 5d c8 e9 4d fa ff ff <0f> 0b 48 8b 7d a0 e8 dc c6 06 00 48 b8 00 00 00 00 00 00 00 10 [203748.717505] RIP [<ffffffffa05e9f09>] ocfs2_read_blocks+0x669/0x7f0 [ocfs2] [203748.717775] RSP <ffff88006ff4b818> Joesph ever reported a similar panic. Link: https://oss.oracle.com/pipermail/ocfs2-devel/2013-May/008931.html Link: http://lkml.kernel.org/r/20180912063207.29484-1-junxiao.bi@oracle.com Signed-off-by: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Joseph Qi <jiangqi903(a)gmail.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Changwei Ge <ge.changwei(a)h3c.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN fs/ocfs2/buffer_head_io.c~ocfs2-fix-ocfs2-read-block-panic fs/ocfs2/buffer_head_io.c --- a/fs/ocfs2/buffer_head_io.c~ocfs2-fix-ocfs2-read-block-panic +++ a/fs/ocfs2/buffer_head_io.c @@ -342,6 +342,7 @@ int ocfs2_read_blocks(struct ocfs2_cachi * for this bh as it's not marked locally * uptodate. */ status = -EIO; + clear_buffer_needs_validate(bh); put_bh(bh); bhs[i] = NULL; continue; _

6 years, 7 months

1
0
0 0

[patch 4/7] mm: shmem.c: Correctly annotate new inodes for lockdep

by akpm＠linux-foundation.org

From: "Joel Fernandes (Google)" <joel(a)joelfernandes.org> Subject: mm: shmem.c: Correctly annotate new inodes for lockdep Directories and inodes don't necessarily need to be in the same lockdep class. For ex, hugetlbfs splits them out too to prevent false positives in lockdep. Annotate correctly after new inode creation. If its a directory inode, it will be put into a different class. This should fix a lockdep splat reported by syzbot: > ====================================================== > WARNING: possible circular locking dependency detected > 4.18.0-rc8-next-20180810+ #36 Not tainted > ------------------------------------------------------ > syz-executor900/4483 is trying to acquire lock: > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: inode_lock > include/linux/fs.h:765 [inline] > 00000000d2bfc8fe (&sb->s_type->i_mutex_key#9){++++}, at: > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > > but task is already holding lock: > 0000000025208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630 > drivers/staging/android/ashmem.c:448 > > which lock already depends on the new lock. > > -> #2 (ashmem_mutex){+.+.}: > __mutex_lock_common kernel/locking/mutex.c:925 [inline] > __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073 > mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088 > ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361 > call_mmap include/linux/fs.h:1844 [inline] > mmap_region+0xf27/0x1c50 mm/mmap.c:1762 > do_mmap+0xa10/0x1220 mm/mmap.c:1535 > do_mmap_pgoff include/linux/mm.h:2298 [inline] > vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357 > ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585 > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #1 (&mm->mmap_sem){++++}: > __might_fault+0x155/0x1e0 mm/memory.c:4568 > _copy_to_user+0x30/0x110 lib/usercopy.c:25 > copy_to_user include/linux/uaccess.h:155 [inline] > filldir+0x1ea/0x3a0 fs/readdir.c:196 > dir_emit_dot include/linux/fs.h:3464 [inline] > dir_emit_dots include/linux/fs.h:3475 [inline] > dcache_readdir+0x13a/0x620 fs/libfs.c:193 > iterate_dir+0x48b/0x5d0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > -> #0 (&sb->s_type->i_mutex_key#9){++++}: > lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924 > down_write+0x8f/0x130 kernel/locking/rwsem.c:70 > inode_lock include/linux/fs.h:765 [inline] > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602 > ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455 > ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:501 [inline] > do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685 > ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702 > __do_sys_ioctl fs/ioctl.c:709 [inline] > __se_sys_ioctl fs/ioctl.c:707 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707 > do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > other info that might help us debug this: > > Chain exists of: > &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex > > Possible unsafe locking scenario: > > CPU0 CPU1 > ---- ---- > lock(ashmem_mutex); > lock(&mm->mmap_sem); > lock(ashmem_mutex); > lock(&sb->s_type->i_mutex_key#9); > > *** DEADLOCK *** > > 1 lock held by syz-executor900/4483: > #0: 0000000025208078 (ashmem_mutex){+.+.}, at: > ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448 Link: http://lkml.kernel.org/r/20180821231835.166639-1-joel@joelfernandes.org Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> Reported-by: syzbot <syzkaller(a)googlegroups.com> Reviewed-by: NeilBrown <neilb(a)suse.com> Suggested-by: NeilBrown <neilb(a)suse.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Hugh Dickins <hughd(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/shmem.c~mm-shmem-correctly-annotate-new-inodes-for-lockdep mm/shmem.c --- a/mm/shmem.c~mm-shmem-correctly-annotate-new-inodes-for-lockdep +++ a/mm/shmem.c @@ -2227,6 +2227,8 @@ static struct inode *shmem_get_inode(str mpol_shared_policy_init(&info->policy, NULL); break; } + + lockdep_annotate_inode_mutex_key(inode); } else shmem_free_inode(sb); return inode; _

6 years, 7 months

1
0
0 0

[patch 2/7] mm: disable deferred struct page for 32-bit arches

by akpm＠linux-foundation.org

From: Pasha Tatashin <Pavel.Tatashin(a)microsoft.com> Subject: mm: disable deferred struct page for 32-bit arches Deferred struct page init is needed only on systems with large amount of physical memory to improve boot performance. 32-bit systems do not benefit from this feature. Jiri reported a problem where deferred struct pages do not work well with x86-32: [ 0.035162] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.035725] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.036269] Initializing CPU#0 [ 0.036513] Initializing HighMem for node 0 (00036ffe:0007ffe0) [ 0.038459] page:f6780000 is uninitialized and poisoned [ 0.038460] raw: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff [ 0.039509] page dumped because: VM_BUG_ON_PAGE(1 && PageCompound(page)) [ 0.040038] ------------[ cut here ]------------ [ 0.040399] kernel BUG at include/linux/page-flags.h:293! [ 0.040823] invalid opcode: 0000 [#1] SMP PTI [ 0.041166] CPU: 0 PID: 0 Comm: swapper Not tainted 4.19.0-rc1_pt_jiri #9 [ 0.041694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 [ 0.042496] EIP: free_highmem_page+0x64/0x80 [ 0.042839] Code: 13 46 d8 c1 e8 18 5d 83 e0 03 8d 04 c0 c1 e0 06 ff 80 ec 5f 44 d8 c3 8d b4 26 00 00 00 00 ba 08 65 28 d8 89 d8 e8 fc 71 02 00 <0f> 0b 8d 76 00 8d bc 27 00 00 00 00 ba d0 b1 26 d8 89 d8 e8 e4 71 [ 0.044338] EAX: 0000003c EBX: f6780000 ECX: 00000000 EDX: d856cbe8 [ 0.044868] ESI: 0007ffe0 EDI: d838df20 EBP: d838df00 ESP: d838defc [ 0.045372] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210086 [ 0.045913] CR0: 80050033 CR2: 00000000 CR3: 18556000 CR4: 00040690 [ 0.046413] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 0.046913] DR6: fffe0ff0 DR7: 00000400 [ 0.047220] Call Trace: [ 0.047419] add_highpages_with_active_regions+0xbd/0x10d [ 0.047854] set_highmem_pages_init+0x5b/0x71 [ 0.048202] mem_init+0x2b/0x1e8 [ 0.048460] start_kernel+0x1d2/0x425 [ 0.048757] i386_start_kernel+0x93/0x97 [ 0.049073] startup_32_smp+0x164/0x168 [ 0.049379] Modules linked in: [ 0.049626] ---[ end trace 337949378db0abbb ]--- We free highmem pages before their struct pages are initialized: mem_init() set_highmem_pages_init() add_highpages_with_active_regions() free_highmem_page() .. Access uninitialized struct page here.. Because there is no reason to have this feature on 32-bit systems, just disable it. Link: http://lkml.kernel.org/r/20180831150506.31246-1-pavel.tatashin@microsoft.com Fixes: 2e3ca40f03bb ("mm: relax deferred struct page requirements") Signed-off-by: Pavel Tatashin <pavel.tatashin(a)microsoft.com> Reported-by: Jiri Slaby <jslaby(a)suse.cz> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/Kconfig~mm-disable-deferred-struct-page-for-32-bit-arches mm/Kconfig --- a/mm/Kconfig~mm-disable-deferred-struct-page-for-32-bit-arches +++ a/mm/Kconfig @@ -637,6 +637,7 @@ config DEFERRED_STRUCT_PAGE_INIT depends on NO_BOOTMEM depends on SPARSEMEM depends on !NEED_PER_CPU_KM + depends on 64BIT help Ordinarily all struct pages are initialised during early boot in a single thread. On very large machines this can take a considerable _

6 years, 7 months

1
0
0 0

[patch 1/7] fork: report pid exhaustion correctly

by akpm＠linux-foundation.org

From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Subject: fork: report pid exhaustion correctly Make the clone and fork syscalls return EAGAIN when the limit on the number of pids /proc/sys/kernel/pid_max is exceeded. Currently, when the pid_max limit is exceeded, the kernel will return ENOSPC from the fork and clone syscalls. This is contrary to the documented behaviour, which explicitly calls out the pid_max case as one where EAGAIN should be returned. It also leads to really confusing error messages in userspace programs which will complain about a lack of disk space when they fail to create processes/threads for this reason. This error is being returned because alloc_pid() uses the idr api to find a new pid; when there are none available, idr_alloc_cyclic() returns -ENOSPC, and this is being propagated back to userspace. This behaviour has been broken before, and was explicitly fixed in commit 35f71bc0a09a ("fork: report pid reservation failure properly"), so I think -EAGAIN is definitely the right thing to return in this case. The current behaviour change dates from commit 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") and was I believe unintentional. This patch has no impact on the case where allocating a pid fails because the child reaper for the namespace is dead; that case will still return -ENOMEM. Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP") Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Gargi Sharma <gs051095(a)gmail.com> Cc: Rik van Riel <riel(a)redhat.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c --- a/kernel/pid.c~fork-report-pid-exhaustion-correctly +++ a/kernel/pid.c @@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa idr_preload_end(); if (nr < 0) { - retval = nr; + retval = (nr == -ENOSPC) ? -EAGAIN : nr; goto out_free; } _

6 years, 7 months

1
0
0 0

Applied "regulator: fix crash caused by null driver data" to the regulator tree

by Mark Brown

The patch regulator: fix crash caused by null driver data has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From fb6de923ca3358a91525552b4907d4cb38730bdd Mon Sep 17 00:00:00 2001 From: Yu Zhao <yuzhao(a)google.com> Date: Wed, 19 Sep 2018 15:30:51 -0600 Subject: [PATCH] regulator: fix crash caused by null driver data dev_set_drvdata() needs to be called before device_register() exposes device to userspace. Otherwise kernel crashes after it gets null pointer from dev_get_drvdata() when userspace tries to access sysfs entries. [Removed backtrace for length -- broonie] Signed-off-by: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/regulator/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 90215f57270f..9577d8941846 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -4395,13 +4395,13 @@ regulator_register(const struct regulator_desc *regulator_desc, !rdev->desc->fixed_uV) rdev->is_switch = true; + dev_set_drvdata(&rdev->dev, rdev); ret = device_register(&rdev->dev); if (ret != 0) { put_device(&rdev->dev); goto unset_supplies; } - dev_set_drvdata(&rdev->dev, rdev); rdev_init_debugfs(rdev); /* try to resolve regulators supply since a new one was registered */ -- 2.19.0

6 years, 7 months

1
0
0 0

[PATCH] xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

by Boris Ostrovsky

Otherwise we may leak kernel stack for events that sample user registers. Reported-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: stable(a)vger.kernel.org --- arch/x86/xen/pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c index 7d00d4a..95997e6 100644 --- a/arch/x86/xen/pmu.c +++ b/arch/x86/xen/pmu.c @@ -478,7 +478,7 @@ static void xen_convert_regs(const struct xen_pmu_regs *xen_regs, irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id) { int err, ret = IRQ_NONE; - struct pt_regs regs; + struct pt_regs regs = {0}; const struct xen_pmu_data *xenpmu_data = get_xenpmu_data(); uint8_t xenpmu_flags = get_xenpmu_flags(); -- 1.8.3.1

6 years, 7 months

2
2
0 0

[PATCH v2 3/3] usb: typec: pci: Enable Intel USB role mux on Apollo Lake platforms

by Mathias Nyman

From: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Intel Apollo Lake has the same internal USB role mux as Intel Cherry Trail. Cc: <stable(a)vger.kernel.org> Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 722860e..51dd8e0 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -179,10 +179,12 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_PME_STUCK_QUIRK; } if (pdev->vendor == PCI_VENDOR_ID_INTEL && - pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) { + pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) xhci->quirks |= XHCI_SSIC_PORT_UNUSED; + if (pdev->vendor == PCI_VENDOR_ID_INTEL && + (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI)) xhci->quirks |= XHCI_INTEL_USB_ROLE_SW; - } if (pdev->vendor == PCI_VENDOR_ID_INTEL && (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI || -- 2.7.4

6 years, 7 months

1
0
0 0

[PATCH v2 2/3] usb: xhci-mtk: resume USB3 roothub first

by Mathias Nyman

From: Chunfeng Yun <chunfeng.yun(a)mediatek.com> Give USB3 devices a better chance to enumerate at USB3 speeds if they are connected to a suspended host. Porting from "671ffdff5b13 xhci: resume USB 3 roothub first" Cc: <stable(a)vger.kernel.org> Signed-off-by: Chunfeng Yun <chunfeng.yun(a)mediatek.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-mtk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c index 7334da9..71d0d33 100644 --- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -642,10 +642,10 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev) xhci_mtk_host_enable(mtk); xhci_dbg(xhci, "%s: restart port polling\n", __func__); - set_bit(HCD_FLAG_POLL_RH, &hcd->flags); - usb_hcd_poll_rh_status(hcd); set_bit(HCD_FLAG_POLL_RH, &xhci->shared_hcd->flags); usb_hcd_poll_rh_status(xhci->shared_hcd); + set_bit(HCD_FLAG_POLL_RH, &hcd->flags); + usb_hcd_poll_rh_status(hcd); return 0; } -- 2.7.4

6 years, 7 months

1
0
0 0

[PATCH v2 1/3] xhci: Add missing CAS workaround for Intel Sunrise Point xHCI

by Mathias Nyman

The workaround for missing CAS bit is also needed for xHC on Intel sunrisepoint PCH. For more details see: Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Cc: <stable(a)vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 6372edf..722860e 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -185,6 +185,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) } if (pdev->vendor == PCI_VENDOR_ID_INTEL && (pdev->device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI || + pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_H_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_APL_XHCI || pdev->device == PCI_DEVICE_ID_INTEL_DNV_XHCI)) xhci->quirks |= XHCI_MISSING_CAS; -- 2.7.4

6 years, 7 months

1
0
0 0

v4.4.157 build: 0 failures 31 warnings (v4.4.157)

by Build bot for Mark Brown

Tree/Branch: v4.4.157 Git describe: v4.4.157 Commit: d956091968 Linux 4.4.157 Build Time: 68 min 54 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 31 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 19 warnings 0 mismatches : arm64-allmodconfig 17 warnings 0 mismatches : x86_64-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 31 3 warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) 2 ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] 2 ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 2 ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 19 warnings, 0 section mismatches Warnings: warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI) ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 17 warnings, 0 section mismatches Warnings: ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=] ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig

6 years, 7 months

1
0
0 0

patch "serial: imx: restore handshaking irq for imx1" added to tty-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: imx: restore handshaking irq for imx1 to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7e620984b62532783912312e334f3c48cdacbd5d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de> Date: Thu, 20 Sep 2018 14:11:17 +0200 Subject: serial: imx: restore handshaking irq for imx1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Back in 2015 when irda was dropped from the driver imx1 was broken. This change reintroduces the support for the third interrupt of the UART. Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Reviewed-by: Leonard Crestez <leonard.crestez(a)nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/imx.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 239c0fa2e981..0f67197a3783 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2351,6 +2351,14 @@ static int imx_uart_probe(struct platform_device *pdev) ret); return ret; } + + ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0, + dev_name(&pdev->dev), sport); + if (ret) { + dev_err(&pdev->dev, "failed to request rts irq: %d\n", + ret); + return ret; + } } else { ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0, dev_name(&pdev->dev), sport); -- 2.19.0

6 years, 7 months

1
0
0 0

[PATCH] b43: Fix regression in kernel 4.18

by Larry Finger

In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"), a condition is noted where the network controller needs to be reset. Note that this situation happens when running the open-source firmware (http://netweb.ing.unibs.it/~openfwwf/), plus a number of other special conditions. for a different card model, it is reported that this change breaks operation running the proprietary firmware (https://marc.info/?l=linux-wireless&m=153504546924558&w=2). Rather than reverting the previous patch, the code is tweaked to avoid the reset unless the open-source firmware is being used. Fixes: 66cffd6daab7 ("b43: fix transmit failure when VT is switched") Cc: Stable <stable(a)vger.kernel.org> # 4.18+ Cc: Taketo Kabe <kabe(a)sra-tohoku.co.jp> Reported-and-tested-by: D. Prabhu <d.praabhu(a)gmail.com> Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net> --- drivers/net/wireless/broadcom/b43/dma.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/dma.c b/drivers/net/wireless/broadcom/b43/dma.c index 6b0e1ec346cb..d46d57b989ae 100644 --- a/drivers/net/wireless/broadcom/b43/dma.c +++ b/drivers/net/wireless/broadcom/b43/dma.c @@ -1518,13 +1518,15 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev, } } else { /* More than a single header/data pair were missed. - * Report this error, and reset the controller to + * Report this error. If running with open-source + * firmware, then reset the controller to * revive operation. */ b43dbg(dev->wl, "Out of order TX status report on DMA ring %d. Expected %d, but got %d\n", ring->index, firstused, slot); - b43_controller_restart(dev, "Out of order TX"); + if (dev->fw.opensource) + b43_controller_restart(dev, "Out of order TX"); return; } } -- 2.18.0

6 years, 7 months

2
2
0 0

[PATCH 1/2] usb: typec: mux: Take care of driver module reference counting

by Heikki Krogerus

Functions typec_mux_get() and typec_switch_get() already make sure that the mux device reference count is incremented, but the same must be done to the driver module as well to prevent the drivers from being unloaded in the middle of operation. This fixes a potential "BUG: unable to handle kernel paging request at ..." from happening. Fixes: 93dd2112c7b2 ("usb: typec: mux: Get the mux identifier from function parameter") Cc: <stable(a)vger.kernel.org> Acked-by: Hans de Goede <hdegoede(a)redhat.com> Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> --- drivers/usb/typec/mux.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c index ddaac63ecf12..d990aa510fab 100644 --- a/drivers/usb/typec/mux.c +++ b/drivers/usb/typec/mux.c @@ -9,6 +9,7 @@ #include <linux/device.h> #include <linux/list.h> +#include <linux/module.h> #include <linux/mutex.h> #include <linux/usb/typec_mux.h> @@ -49,8 +50,10 @@ struct typec_switch *typec_switch_get(struct device *dev) mutex_lock(&switch_lock); sw = device_connection_find_match(dev, "typec-switch", NULL, typec_switch_match); - if (!IS_ERR_OR_NULL(sw)) + if (!IS_ERR_OR_NULL(sw)) { + WARN_ON(!try_module_get(sw->dev->driver->owner)); get_device(sw->dev); + } mutex_unlock(&switch_lock); return sw; @@ -65,8 +68,10 @@ EXPORT_SYMBOL_GPL(typec_switch_get); */ void typec_switch_put(struct typec_switch *sw) { - if (!IS_ERR_OR_NULL(sw)) + if (!IS_ERR_OR_NULL(sw)) { + module_put(sw->dev->driver->owner); put_device(sw->dev); + } } EXPORT_SYMBOL_GPL(typec_switch_put); @@ -136,8 +141,10 @@ struct typec_mux *typec_mux_get(struct device *dev, const char *name) mutex_lock(&mux_lock); mux = device_connection_find_match(dev, name, NULL, typec_mux_match); - if (!IS_ERR_OR_NULL(mux)) + if (!IS_ERR_OR_NULL(mux)) { + WARN_ON(!try_module_get(mux->dev->driver->owner)); get_device(mux->dev); + } mutex_unlock(&mux_lock); return mux; @@ -152,8 +159,10 @@ EXPORT_SYMBOL_GPL(typec_mux_get); */ void typec_mux_put(struct typec_mux *mux) { - if (!IS_ERR_OR_NULL(mux)) + if (!IS_ERR_OR_NULL(mux)) { + module_put(mux->dev->driver->owner); put_device(mux->dev); + } } EXPORT_SYMBOL_GPL(typec_mux_put); -- 2.18.0

6 years, 7 months

3
4
0 0

patch "usb: core: safely deal with the dynamic quirk lists" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: core: safely deal with the dynamic quirk lists to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 16c4cb19fa85c648a803752eb63cac0ef69231c2 Mon Sep 17 00:00:00 2001 From: Harry Pan <harry.pan(a)intel.com> Date: Fri, 14 Sep 2018 16:58:16 +0800 Subject: usb: core: safely deal with the dynamic quirk lists Applying dynamic usbcore quirks in early booting when the slab is not yet ready would cause kernel panic of null pointer dereference because the quirk_count has been counted as 1 while the quirk_list was failed to allocate. i.e., [ 1.044970] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1.044995] IP: [<ffffffffb0953ec7>] usb_detect_quirks+0x88/0xd1 [ 1.045016] PGD 0 [ 1.045026] Oops: 0000 [#1] PREEMPT SMP [ 1.046986] gsmi: Log Shutdown Reason 0x03 [ 1.046995] Modules linked in: [ 1.047008] CPU: 0 PID: 81 Comm: kworker/0:3 Not tainted 4.4.154 #28 [ 1.047016] Hardware name: Google Coral/Coral, BIOS Google_Coral.10068.27.0 12/04/2017 [ 1.047028] Workqueue: usb_hub_wq hub_event [ 1.047037] task: ffff88017a321c80 task.stack: ffff88017a384000 [ 1.047044] RIP: 0010:[<ffffffffb0953ec7>] [<ffffffffb0953ec7>] usb_detect_quirks+0x88/0xd1 To tackle this odd, let's balance the quirk_count to 0 when the kcalloc call fails, and defer the quirk setting into a lower level callback which ensures that the kernel memory management has been initialized. Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore") Signed-off-by: Harry Pan <harry.pan(a)intel.com> Acked-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/quirks.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c index e77dfe5ed5ec..178d6c6063c0 100644 --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -58,6 +58,7 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp) quirk_list = kcalloc(quirk_count, sizeof(struct quirk_entry), GFP_KERNEL); if (!quirk_list) { + quirk_count = 0; mutex_unlock(&quirk_mutex); return -ENOMEM; } @@ -154,7 +155,7 @@ static struct kparam_string quirks_param_string = { .string = quirks_param, }; -module_param_cb(quirks, &quirks_param_ops, &quirks_param_string, 0644); +device_param_cb(quirks, &quirks_param_ops, &quirks_param_string, 0644); MODULE_PARM_DESC(quirks, "Add/modify USB quirks by specifying quirks=vendorID:productID:quirks"); /* Lists of quirky USB devices, split in device quirks and interface quirks. -- 2.19.0

6 years, 7 months

1
0
0 0

patch "usb: roles: Take care of driver module reference counting" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: roles: Take care of driver module reference counting to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 5c54fcac9a9de559b444ac63ec3cd82f1d157a0b Mon Sep 17 00:00:00 2001 From: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Date: Wed, 19 Sep 2018 10:58:05 +0300 Subject: usb: roles: Take care of driver module reference counting This fixes potential "BUG: unable to handle kernel paging request at ..." from happening. Fixes: fde0aa6c175a ("usb: common: Small class for USB role switches") Cc: <stable(a)vger.kernel.org> Acked-by: Hans de Goede <hdegoede(a)redhat.com> Tested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/common/roles.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c index 15cc76e22123..99116af07f1d 100644 --- a/drivers/usb/common/roles.c +++ b/drivers/usb/common/roles.c @@ -109,8 +109,15 @@ static void *usb_role_switch_match(struct device_connection *con, int ep, */ struct usb_role_switch *usb_role_switch_get(struct device *dev) { - return device_connection_find_match(dev, "usb-role-switch", NULL, - usb_role_switch_match); + struct usb_role_switch *sw; + + sw = device_connection_find_match(dev, "usb-role-switch", NULL, + usb_role_switch_match); + + if (!IS_ERR_OR_NULL(sw)) + WARN_ON(!try_module_get(sw->dev.parent->driver->owner)); + + return sw; } EXPORT_SYMBOL_GPL(usb_role_switch_get); @@ -122,8 +129,10 @@ EXPORT_SYMBOL_GPL(usb_role_switch_get); */ void usb_role_switch_put(struct usb_role_switch *sw) { - if (!IS_ERR_OR_NULL(sw)) + if (!IS_ERR_OR_NULL(sw)) { put_device(&sw->dev); + module_put(sw->dev.parent->driver->owner); + } } EXPORT_SYMBOL_GPL(usb_role_switch_put); -- 2.19.0

6 years, 7 months

1
0
0 0

patch "USB: fix error handling in usb_driver_claim_interface()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: fix error handling in usb_driver_claim_interface() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From bd729f9d67aa9a303d8925bb8c4f06af25f407d1 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Mon, 10 Sep 2018 13:59:59 -0400 Subject: USB: fix error handling in usb_driver_claim_interface() The syzbot fuzzing project found a use-after-free bug in the USB core. The bug was caused by usbfs not unbinding from an interface when the USB device file was closed, which led another process to attempt the unbind later on, after the private data structure had been deallocated. The reason usbfs did not unbind the interface at the appropriate time was because it thought the interface had never been claimed in the first place. This was caused by the fact that usb_driver_claim_interface() does not clean up properly when device_bind_driver() returns an error. Although the error code gets passed back to the caller, the iface->dev.driver pointer remains set and iface->condition remains equal to USB_INTERFACE_BOUND. This patch adds proper error handling to usb_driver_claim_interface(). Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: syzbot+f84aa7209ccec829536f(a)syzkaller.appspotmail.com CC: <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/driver.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index 7652dcb57998..a1f225f077cd 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/usb/core/driver.c @@ -550,6 +550,21 @@ int usb_driver_claim_interface(struct usb_driver *driver, if (device_is_registered(dev)) retval = device_bind_driver(dev); + if (retval) { + dev->driver = NULL; + usb_set_intfdata(iface, NULL); + iface->needs_remote_wakeup = 0; + iface->condition = USB_INTERFACE_UNBOUND; + + /* + * Unbound interfaces are always runtime-PM-disabled + * and runtime-PM-suspended + */ + if (driver->supports_autosuspend) + pm_runtime_disable(dev); + pm_runtime_set_suspended(dev); + } + return retval; } EXPORT_SYMBOL_GPL(usb_driver_claim_interface); -- 2.19.0

6 years, 7 months

1
0
0 0

patch "USB: handle NULL config in usb_find_alt_setting()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: handle NULL config in usb_find_alt_setting() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Mon, 10 Sep 2018 14:00:53 -0400 Subject: USB: handle NULL config in usb_find_alt_setting() usb_find_alt_setting() takes a pointer to a struct usb_host_config as an argument; it searches for an interface with specified interface and alternate setting numbers in that config. However, it crashes if the usb_host_config pointer argument is NULL. Since this is a general-purpose routine, available for use in many places, we want to to be more robust. This patch makes it return NULL whenever the config argument is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Reported-by: syzbot+19c3aaef85a89d451eac(a)syzkaller.appspotmail.com CC: <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/usb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index 623be3174fb3..79d8bd7a612e 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -228,6 +228,8 @@ struct usb_host_interface *usb_find_alt_setting( struct usb_interface_cache *intf_cache = NULL; int i; + if (!config) + return NULL; for (i = 0; i < config->desc.bNumInterfaces; i++) { if (config->intf_cache[i]->altsetting[0].desc.bInterfaceNumber == iface_num) { -- 2.19.0

6 years, 7 months

1
0
0 0

patch "USB: remove LPM management from usb_driver_claim_interface()" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: remove LPM management from usb_driver_claim_interface() to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c183813fcee44a249339b7c46e1ad271ca1870aa Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Mon, 10 Sep 2018 13:58:51 -0400 Subject: USB: remove LPM management from usb_driver_claim_interface() usb_driver_claim_interface() disables and re-enables Link Power Management, but it shouldn't do either one, for the reasons listed below. This patch removes the two LPM-related function calls from the routine. The reason for disabling LPM in the analogous function usb_probe_interface() is so that drivers won't have to deal with unwanted LPM transitions in their probe routine. But usb_driver_claim_interface() doesn't call the driver's probe routine (or any other callbacks), so that reason doesn't apply here. Furthermore, no driver other than usbfs will ever call usb_driver_claim_interface() unless it is already bound to another interface in the same device, which means disabling LPM here would be redundant. usbfs doesn't interact with LPM at all. Lastly, the error return from usb_unlocked_disable_lpm() isn't handled properly; the code doesn't clean up its earlier actions before returning. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.") CC: <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/driver.c | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c index e76e95f62f76..7652dcb57998 100644 --- a/drivers/usb/core/driver.c +++ b/drivers/usb/core/driver.c @@ -512,7 +512,6 @@ int usb_driver_claim_interface(struct usb_driver *driver, struct device *dev; struct usb_device *udev; int retval = 0; - int lpm_disable_error = -ENODEV; if (!iface) return -ENODEV; @@ -533,16 +532,6 @@ int usb_driver_claim_interface(struct usb_driver *driver, iface->condition = USB_INTERFACE_BOUND; - /* See the comment about disabling LPM in usb_probe_interface(). */ - if (driver->disable_hub_initiated_lpm) { - lpm_disable_error = usb_unlocked_disable_lpm(udev); - if (lpm_disable_error) { - dev_err(&iface->dev, "%s Failed to disable LPM for driver %s\n", - __func__, driver->name); - return -ENOMEM; - } - } - /* Claimed interfaces are initially inactive (suspended) and * runtime-PM-enabled, but only if the driver has autosuspend * support. Otherwise they are marked active, to prevent the @@ -561,10 +550,6 @@ int usb_driver_claim_interface(struct usb_driver *driver, if (device_is_registered(dev)) retval = device_bind_driver(dev); - /* Attempt to re-enable USB3 LPM, if the disable was successful. */ - if (!lpm_disable_error) - usb_unlocked_enable_lpm(udev); - return retval; } EXPORT_SYMBOL_GPL(usb_driver_claim_interface); -- 2.19.0

6 years, 7 months

1
0
0 0

patch "USB: usbdevfs: restore warning for nonsensical flags" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: usbdevfs: restore warning for nonsensical flags to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 81e0403b26d94360abd1f6a57311337973bc82cd Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Wed, 5 Sep 2018 12:07:03 +0200 Subject: USB: usbdevfs: restore warning for nonsensical flags If we filter flags before they reach the core we need to generate our own warnings. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/devio.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 263dd2f309fb..244417d0dfd1 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1697,6 +1697,11 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u |= URB_NO_INTERRUPT; as->urb->transfer_flags = u; + if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK) + dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_SHORT_NOT_OK.\n"); + if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET) + dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_ZERO_PACKET.\n"); + as->urb->transfer_buffer_length = uurb->buffer_length; as->urb->setup_packet = (unsigned char *)dr; dr = NULL; -- 2.19.0

6 years, 7 months

1
0
0 0

patch "USB: usbdevfs: sanitize flags more" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: usbdevfs: sanitize flags more to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7a68d9fb851012829c29e770621905529bd9490b Mon Sep 17 00:00:00 2001 From: Oliver Neukum <oneukum(a)suse.com> Date: Wed, 5 Sep 2018 12:07:02 +0200 Subject: USB: usbdevfs: sanitize flags more Requesting a ZERO_PACKET or not is sensible only for output. In the input direction the device decides. Likewise accepting short packets makes sense only for input. This allows operation with panic_on_warn without opening up a local DOS. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Reported-by: syzbot+843efa30c8821bd69f53(a)syzkaller.appspotmail.com Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/devio.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c index 6ce77b33da61..263dd2f309fb 100644 --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1434,10 +1434,13 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb struct async *as = NULL; struct usb_ctrlrequest *dr = NULL; unsigned int u, totlen, isofrmlen; - int i, ret, is_in, num_sgs = 0, ifnum = -1; + int i, ret, num_sgs = 0, ifnum = -1; int number_of_packets = 0; unsigned int stream_id = 0; void *buf; + bool is_in; + bool allow_short = false; + bool allow_zero = false; unsigned long mask = USBDEVFS_URB_SHORT_NOT_OK | USBDEVFS_URB_BULK_CONTINUATION | USBDEVFS_URB_NO_FSBR | @@ -1471,6 +1474,8 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u = 0; switch (uurb->type) { case USBDEVFS_URB_TYPE_CONTROL: + if (is_in) + allow_short = true; if (!usb_endpoint_xfer_control(&ep->desc)) return -EINVAL; /* min 8 byte setup packet */ @@ -1511,6 +1516,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb break; case USBDEVFS_URB_TYPE_BULK: + if (!is_in) + allow_zero = true; + else + allow_short = true; switch (usb_endpoint_type(&ep->desc)) { case USB_ENDPOINT_XFER_CONTROL: case USB_ENDPOINT_XFER_ISOC: @@ -1531,6 +1540,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb if (!usb_endpoint_xfer_int(&ep->desc)) return -EINVAL; interrupt_urb: + if (!is_in) + allow_zero = true; + else + allow_short = true; break; case USBDEVFS_URB_TYPE_ISO: @@ -1676,9 +1689,9 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb u = (is_in ? URB_DIR_IN : URB_DIR_OUT); if (uurb->flags & USBDEVFS_URB_ISO_ASAP) u |= URB_ISO_ASAP; - if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in) + if (allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK) u |= URB_SHORT_NOT_OK; - if (uurb->flags & USBDEVFS_URB_ZERO_PACKET) + if (allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET) u |= URB_ZERO_PACKET; if (uurb->flags & USBDEVFS_URB_NO_INTERRUPT) u |= URB_NO_INTERRUPT; -- 2.19.0

6 years, 7 months

1
0
0 0

patch "Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From e871db8d78df1c411032cbb3acfdf8930509360e Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Date: Tue, 11 Sep 2018 10:00:44 +0200 Subject: Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()" This reverts commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427. The bug the patch describes to, has been already fixed in commit 2df6948428542 ("USB: cdc-wdm: don't enable interrupts in USB-giveback") so need to this, revert it. Fixes: 6e22e3af7bb3 ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/cdc-wdm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c index 656d247819c9..bec581fb7c63 100644 --- a/drivers/usb/class/cdc-wdm.c +++ b/drivers/usb/class/cdc-wdm.c @@ -460,7 +460,7 @@ static int service_outstanding_interrupt(struct wdm_device *desc) set_bit(WDM_RESPONDING, &desc->flags); spin_unlock_irq(&desc->iuspin); - rv = usb_submit_urb(desc->response, GFP_ATOMIC); + rv = usb_submit_urb(desc->response, GFP_KERNEL); spin_lock_irq(&desc->iuspin); if (rv) { dev_err(&desc->intf->dev, -- 2.19.0

6 years, 7 months

1
0
0 0

v4.18.9 build: 0 failures 3 warnings (v4.18.9)

by Build bot for Mark Brown

Tree/Branch: v4.18.9 Git describe: v4.18.9 Commit: 86e014f514 Linux 4.18.9 Build Time: 123 min 24 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 3 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allnoconfig 3 warnings 0 mismatches : arm64-allmodconfig 2 warnings 0 mismatches : arm-multi_v5_defconfig 2 warnings 0 mismatches : arm-multi_v7_defconfig 2 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 1 warnings 0 mismatches : arm-multi_v4t_defconfig 2 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 3 8 <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] 5 <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] 1 ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches Warnings: <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] ../drivers/isdn/hardware/eicon/message.c:5985:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] ------------------------------------------------------------------------------- arm-multi_v4t_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: <stdin>:1332:2: warning: #warning syscall io_pgetevents not implemented [-Wcpp] ------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] <stdin>:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: x86_64-allnoconfig x86_64-allmodconfig x86_64-defconfig

6 years, 7 months

1
0
0 0

[PATCHES] Networking

by David Miller

Please queue up the following networking bug fixes for v4.14.x and v4.18.x -stable, respectively. Thank you!

6 years, 7 months

2
1
0 0

Request for inclusion on linux-4.14.y

by Alakesh Haloi

Hello Greg, Can you please consider including the following patch in the stable linux-4.14.y branch? This is to fix a defect in the Hyper-V network driver (hv_netsvc) that triggers kernel null pointer dereference bug, while loading the driver. b19b46346f48("hv/netvsc: Fix NULL dereference at single queue mode fallback") Thanks Alakesh Haloi

6 years, 7 months

2
1
0 0

[PATCH] drm/amdgpu: add new polaris pci id

by Alex Deucher

Add new pci id. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 14 ++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c index 693ec5ea4950..8816c697b205 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c @@ -367,12 +367,14 @@ static int amdgpu_cgs_get_firmware_info(struct cgs_device *cgs_device, break; case CHIP_POLARIS10: if (type == CGS_UCODE_ID_SMU) { - if ((adev->pdev->device == 0x67df) && - ((adev->pdev->revision == 0xe0) || - (adev->pdev->revision == 0xe3) || - (adev->pdev->revision == 0xe4) || - (adev->pdev->revision == 0xe5) || - (adev->pdev->revision == 0xe7) || + if (((adev->pdev->device == 0x67df) && + ((adev->pdev->revision == 0xe0) || + (adev->pdev->revision == 0xe3) || + (adev->pdev->revision == 0xe4) || + (adev->pdev->revision == 0xe5) || + (adev->pdev->revision == 0xe7) || + (adev->pdev->revision == 0xef))) || + ((adev->pdev->device == 0x6fdf) && (adev->pdev->revision == 0xef))) { info->is_kicker = true; strcpy(fw_name, "amdgpu/polaris10_k_smc.bin"); diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index ff10df4f50d3..b536808f62ec 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -837,6 +837,7 @@ static const struct pci_device_id pciidlist[] = { {0x1002, 0x67CA, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10}, {0x1002, 0x67CC, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10}, {0x1002, 0x67CF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10}, + {0x1002, 0x6FDF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS10}, /* Polaris12 */ {0x1002, 0x6980, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12}, {0x1002, 0x6981, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_POLARIS12}, -- 2.13.6

6 years, 7 months

1
0
0 0

[PATCH AUTOSEL 3.18 1/4] thermal: of-thermal: disable passive polling when thermal zone is disabled

by Sasha Levin

From: Anson Huang <Anson.Huang(a)nxp.com> [ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ] When thermal zone is in passive mode, disabling its mode from sysfs is NOT taking effect at all, it is still polling the temperature of the disabled thermal zone and handling all thermal trips, it makes user confused. The disabling operation should disable the thermal zone behavior completely, for both active and passive mode, this patch clears the passive_delay when thermal zone is disabled and restores it when it is enabled. Signed-off-by: Anson Huang <Anson.Huang(a)nxp.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/thermal/of-thermal.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index 62143ba31001..3aeb476c2894 100644 --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -209,10 +209,13 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz, mutex_lock(&tz->lock); - if (mode == THERMAL_DEVICE_ENABLED) + if (mode == THERMAL_DEVICE_ENABLED) { tz->polling_delay = data->polling_delay; - else + tz->passive_delay = data->passive_delay; + } else { tz->polling_delay = 0; + tz->passive_delay = 0; + } mutex_unlock(&tz->lock); -- 2.17.1

6 years, 7 months

1
3
0 0

[PATCH AUTOSEL 4.4 1/7] thermal: of-thermal: disable passive polling when thermal zone is disabled

by Sasha Levin

From: Anson Huang <Anson.Huang(a)nxp.com> [ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ] When thermal zone is in passive mode, disabling its mode from sysfs is NOT taking effect at all, it is still polling the temperature of the disabled thermal zone and handling all thermal trips, it makes user confused. The disabling operation should disable the thermal zone behavior completely, for both active and passive mode, this patch clears the passive_delay when thermal zone is disabled and restores it when it is enabled. Signed-off-by: Anson Huang <Anson.Huang(a)nxp.com> Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/thermal/of-thermal.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c index be4eedcb839a..236c4eb5cf78 100644 --- a/drivers/thermal/of-thermal.c +++ b/drivers/thermal/of-thermal.c @@ -284,10 +284,13 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz, mutex_lock(&tz->lock); - if (mode == THERMAL_DEVICE_ENABLED) + if (mode == THERMAL_DEVICE_ENABLED) { tz->polling_delay = data->polling_delay; - else + tz->passive_delay = data->passive_delay; + } else { tz->polling_delay = 0; + tz->passive_delay = 0; + } mutex_unlock(&tz->lock); -- 2.17.1

6 years, 7 months

1
6
0 0

[PATCH AUTOSEL 4.9 01/14] qed: Wait for ready indication before rereading the shmem

by Sasha Levin

From: Tomer Tayar <Tomer.Tayar(a)cavium.com> [ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ] The MFW might be reset and re-update its shared memory. Upon the detection of such a reset the driver rereads this memory, but it has to wait till the data is valid. This patch adds the missing wait for a data ready indication. Signed-off-by: Tomer Tayar <Tomer.Tayar(a)cavium.com> Signed-off-by: Ariel Elior <Ariel.Elior(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/net/ethernet/qlogic/qed/qed_mcp.c | 50 +++++++++++++++++++---- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c index eaa242df4131..a89385ba6b63 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c +++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c @@ -97,18 +97,57 @@ int qed_mcp_free(struct qed_hwfn *p_hwfn) return 0; } +/* Maximum of 1 sec to wait for the SHMEM ready indication */ +#define QED_MCP_SHMEM_RDY_MAX_RETRIES 20 +#define QED_MCP_SHMEM_RDY_ITER_MS 50 + static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) { struct qed_mcp_info *p_info = p_hwfn->mcp_info; + u8 cnt = QED_MCP_SHMEM_RDY_MAX_RETRIES; + u8 msec = QED_MCP_SHMEM_RDY_ITER_MS; u32 drv_mb_offsize, mfw_mb_offsize; u32 mcp_pf_id = MCP_PF_ID(p_hwfn); p_info->public_base = qed_rd(p_hwfn, p_ptt, MISC_REG_SHARED_MEM_ADDR); - if (!p_info->public_base) - return 0; + if (!p_info->public_base) { + DP_NOTICE(p_hwfn, + "The address of the MCP scratch-pad is not configured\n"); + return -EINVAL; + } p_info->public_base |= GRCBASE_MCP; + /* Get the MFW MB address and number of supported messages */ + mfw_mb_offsize = qed_rd(p_hwfn, p_ptt, + SECTION_OFFSIZE_ADDR(p_info->public_base, + PUBLIC_MFW_MB)); + p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); + p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr + + offsetof(struct public_mfw_mb, + sup_msgs)); + + /* The driver can notify that there was an MCP reset, and might read the + * SHMEM values before the MFW has completed initializing them. + * To avoid this, the "sup_msgs" field in the MFW mailbox is used as a + * data ready indication. + */ + while (!p_info->mfw_mb_length && --cnt) { + msleep(msec); + p_info->mfw_mb_length = + (u16)qed_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr + + offsetof(struct public_mfw_mb, sup_msgs)); + } + + if (!cnt) { + DP_NOTICE(p_hwfn, + "Failed to get the SHMEM ready notification after %d msec\n", + QED_MCP_SHMEM_RDY_MAX_RETRIES * msec); + return -EBUSY; + } + /* Calculate the driver and MFW mailbox address */ drv_mb_offsize = qed_rd(p_hwfn, p_ptt, SECTION_OFFSIZE_ADDR(p_info->public_base, @@ -118,13 +157,6 @@ static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) "drv_mb_offsiz = 0x%x, drv_mb_addr = 0x%x mcp_pf_id = 0x%x\n", drv_mb_offsize, p_info->drv_mb_addr, mcp_pf_id); - /* Set the MFW MB address */ - mfw_mb_offsize = qed_rd(p_hwfn, p_ptt, - SECTION_OFFSIZE_ADDR(p_info->public_base, - PUBLIC_MFW_MB)); - p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); - p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, p_info->mfw_mb_addr); - /* Get the current driver mailbox sequence before sending * the first command */ -- 2.17.1

6 years, 7 months

1
13
0 0

[PATCH AUTOSEL 4.14 01/25] qed: Wait for ready indication before rereading the shmem

by Sasha Levin

From: Tomer Tayar <Tomer.Tayar(a)cavium.com> [ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ] The MFW might be reset and re-update its shared memory. Upon the detection of such a reset the driver rereads this memory, but it has to wait till the data is valid. This patch adds the missing wait for a data ready indication. Signed-off-by: Tomer Tayar <Tomer.Tayar(a)cavium.com> Signed-off-by: Ariel Elior <Ariel.Elior(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/net/ethernet/qlogic/qed/qed_mcp.c | 50 +++++++++++++++++++---- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c index 3c469355f5a4..9348d367cfdf 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c +++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c @@ -182,18 +182,57 @@ int qed_mcp_free(struct qed_hwfn *p_hwfn) return 0; } +/* Maximum of 1 sec to wait for the SHMEM ready indication */ +#define QED_MCP_SHMEM_RDY_MAX_RETRIES 20 +#define QED_MCP_SHMEM_RDY_ITER_MS 50 + static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) { struct qed_mcp_info *p_info = p_hwfn->mcp_info; + u8 cnt = QED_MCP_SHMEM_RDY_MAX_RETRIES; + u8 msec = QED_MCP_SHMEM_RDY_ITER_MS; u32 drv_mb_offsize, mfw_mb_offsize; u32 mcp_pf_id = MCP_PF_ID(p_hwfn); p_info->public_base = qed_rd(p_hwfn, p_ptt, MISC_REG_SHARED_MEM_ADDR); - if (!p_info->public_base) - return 0; + if (!p_info->public_base) { + DP_NOTICE(p_hwfn, + "The address of the MCP scratch-pad is not configured\n"); + return -EINVAL; + } p_info->public_base |= GRCBASE_MCP; + /* Get the MFW MB address and number of supported messages */ + mfw_mb_offsize = qed_rd(p_hwfn, p_ptt, + SECTION_OFFSIZE_ADDR(p_info->public_base, + PUBLIC_MFW_MB)); + p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); + p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr + + offsetof(struct public_mfw_mb, + sup_msgs)); + + /* The driver can notify that there was an MCP reset, and might read the + * SHMEM values before the MFW has completed initializing them. + * To avoid this, the "sup_msgs" field in the MFW mailbox is used as a + * data ready indication. + */ + while (!p_info->mfw_mb_length && --cnt) { + msleep(msec); + p_info->mfw_mb_length = + (u16)qed_rd(p_hwfn, p_ptt, + p_info->mfw_mb_addr + + offsetof(struct public_mfw_mb, sup_msgs)); + } + + if (!cnt) { + DP_NOTICE(p_hwfn, + "Failed to get the SHMEM ready notification after %d msec\n", + QED_MCP_SHMEM_RDY_MAX_RETRIES * msec); + return -EBUSY; + } + /* Calculate the driver and MFW mailbox address */ drv_mb_offsize = qed_rd(p_hwfn, p_ptt, SECTION_OFFSIZE_ADDR(p_info->public_base, @@ -203,13 +242,6 @@ static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) "drv_mb_offsiz = 0x%x, drv_mb_addr = 0x%x mcp_pf_id = 0x%x\n", drv_mb_offsize, p_info->drv_mb_addr, mcp_pf_id); - /* Set the MFW MB address */ - mfw_mb_offsize = qed_rd(p_hwfn, p_ptt, - SECTION_OFFSIZE_ADDR(p_info->public_base, - PUBLIC_MFW_MB)); - p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id); - p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, p_info->mfw_mb_addr); - /* Get the current driver mailbox sequence before sending * the first command */ -- 2.17.1

6 years, 7 months

1
24
0 0

[PATCH AUTOSEL 4.18 01/56] ARM: OMAP2+: Fix null hwmod for ti-sysc debug

by Sasha Levin

From: Tony Lindgren <tony(a)atomide.com> [ Upstream commit 4769c003e0fcff0ee001a9102e2605bdaa5880f0 ] We may call omap_hwmod_parse_module_range() with no hwmod allocated yet and may have debug enabled. Let's fix this by checking for hwmod before trying to use it's name. Fixes: 6c72b3550672 ("ARM: OMAP2+: Parse module IO range from dts for legacy Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- arch/arm/mach-omap2/omap_hwmod.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index 2ceffd85dd3d..7f759abcf49c 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -2220,7 +2220,7 @@ int omap_hwmod_parse_module_range(struct omap_hwmod *oh, size = be32_to_cpup(ranges); pr_debug("omap_hwmod: %s %s at 0x%llx size 0x%llx\n", - oh->name, np->name, base, size); + oh ? oh->name : "", np->name, base, size); res->start = base; res->end = base + size - 1; -- 2.17.1

6 years, 7 months

1
55
0 0

[PATCH AUTOSEL 4.18 01/92] binfmt_elf: Respect error return from `regset->active'

by Sasha Levin

From: "Maciej W. Rozycki" <macro(a)mips.com> [ Upstream commit 2f819db565e82e5f73cd42b39925098986693378 ] The regset API documented in <linux/regset.h> defines -ENODEV as the result of the `->active' handler to be used where the feature requested is not available on the hardware found. However code handling core file note generation in `fill_thread_core_info' interpretes any non-zero result from the `->active' handler as the regset requested being active. Consequently processing continues (and hopefully gracefully fails later on) rather than being abandoned right away for the regset requested. Fix the problem then by making the code proceed only if a positive result is returned from the `->active' handler. Signed-off-by: Maciej W. Rozycki <macro(a)mips.com> Signed-off-by: Paul Burton <paul.burton(a)mips.com> Fixes: 4206d3aa1978 ("elf core dump: notes user_regset") Patchwork: https://patchwork.linux-mips.org/patch/19332/ Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: James Hogan <jhogan(a)kernel.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-fsdevel(a)vger.kernel.org Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- fs/binfmt_elf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 816cc921cf36..efae2fb0930a 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -1751,7 +1751,7 @@ static int fill_thread_core_info(struct elf_thread_core_info *t, const struct user_regset *regset = &view->regsets[i]; do_thread_regset_writeback(t->task, regset); if (regset->core_note_type && regset->get && - (!regset->active || regset->active(t->task, regset))) { + (!regset->active || regset->active(t->task, regset) > 0)) { int ret; size_t size = regset_size(t->task, regset); void *data = kmalloc(size, GFP_KERNEL); -- 2.17.1

6 years, 7 months

3
95
0 0

[PATCH v2 5/6] drm/i915: Fix intel_dp_mst_best_encoder()

by Lyude Paul

Currently, i915 appears to rely on blocking modesets on no-longer-present MSTB ports by simply returning NULL for ->best_encoder(), which in turn causes any new atomic commits that don't disable the CRTC to fail. This is wrong however, since we still want to allow userspace to disable CRTCs on no-longer-present MSTB ports by changing the DPMS state to off and this still requires that we retrieve an encoder. So, fix this by always returning a valid encoder regardless of the state of the MST port. Additionally, make intel_dp_mst_atomic_check() simply rely on drm_dp_mst_connector_atomic_check() to prevent new modesets on no-longer-present MSTB ports. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index a366f32b048a..2b798d4592f0 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -106,14 +106,21 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, } static int intel_dp_mst_atomic_check(struct drm_connector *connector, - struct drm_connector_state *new_conn_state) + struct drm_connector_state *new_conn_state) { struct drm_atomic_state *state = new_conn_state->state; struct drm_connector_state *old_conn_state; struct drm_crtc *old_crtc; struct drm_crtc_state *crtc_state; + struct drm_dp_mst_topology_mgr *mgr = + &to_intel_connector(connector)->mst_port->mst_mgr; int slots, ret = 0; + ret = drm_dp_mst_connector_atomic_check(connector, new_conn_state, + mgr); + if (ret) + return ret; + old_conn_state = drm_atomic_get_old_connector_state(state, connector); old_crtc = old_conn_state->crtc; if (!old_crtc) @@ -122,12 +129,6 @@ static int intel_dp_mst_atomic_check(struct drm_connector *connector, crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc); slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu; if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) { - struct drm_dp_mst_topology_mgr *mgr; - struct drm_encoder *old_encoder; - - old_encoder = old_conn_state->best_encoder; - mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr; - ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots); if (ret) DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", slots, ret); @@ -407,8 +408,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c struct intel_dp *intel_dp = intel_connector->mst_port; struct intel_crtc *crtc = to_intel_crtc(state->crtc); - if (intel_connector->mst_port_gone) - return NULL; return &intel_dp->mst_encoders[crtc->pipe]->base.base; } -- 2.17.1

6 years, 7 months

1
0
0 0

[PATCH v2 4/6] drm/i915: Skip vcpi allocation for MSTB ports that are gone

by Lyude Paul

Since we need to be able to allow DPMS on->off prop changes after an MST port has disappeared from the system, we need to be able to make sure we can compute a config for the resulting atomic commit. Currently this is impossible when the port has disappeared, since the VCPI slot searching we try to do in intel_dp_mst_compute_config() will fail with -EINVAL. Since the only commits we want to allow on no-longer-present MST ports are ones that shut off display hardware, we already know that no VCPI allocations are needed. So, hardcode the VCPI slot count to 0 when intel_dp_mst_compute_config() is called on an MST port that's gone. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index fcb9b87b9339..a366f32b048a 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, to_intel_connector(conn_state->connector); struct drm_atomic_state *state = pipe_config->base.state; int bpp; - int lane_count, slots; + int lane_count, slots = 0; const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode; int mst_pbn; bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc, @@ -76,11 +76,16 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); pipe_config->pbn = mst_pbn; - slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr, - connector->port, mst_pbn); - if (slots < 0) { - DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots); - return false; + if (!connector->mst_port_gone) { + slots = drm_dp_atomic_find_vcpi_slots(state, + &intel_dp->mst_mgr, + connector->port, + mst_pbn); + if (slots < 0) { + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", + slots); + return false; + } } intel_link_compute_m_n(bpp, lane_count, -- 2.17.1

6 years, 7 months

1
0
0 0

[PATCH v2 2/6] drm/nouveau: Unbreak nv50_mstc->best_encoder()

by Lyude Paul

As mentioned in the previous commit, we currently prevent new modesets on recently-removed MST connectors by returning no encoder from our ->best_encoder() callback once the MST port has disappeared. This is wrong however, because it prevents legacy modesetting users from being able to disable CRTCs on MST connectors after the connector's respective topology has disappeared. So, fix this by instead using the new drm_dp_mst_connector_atomic_check() helper instead while always returning a valid encoder from ->best_encoder(). Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 9da0bdfe1e1c..8d6f6ee9bc75 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -881,22 +881,16 @@ nv50_mstc_atomic_best_encoder(struct drm_connector *connector, { struct nv50_head *head = nv50_head(connector_state->crtc); struct nv50_mstc *mstc = nv50_mstc(connector); - if (mstc->port) { - struct nv50_mstm *mstm = mstc->mstm; - return &mstm->msto[head->base.index]->encoder; - } - return NULL; + + return &mstc->mstm->msto[head->base.index]->encoder; } static struct drm_encoder * nv50_mstc_best_encoder(struct drm_connector *connector) { struct nv50_mstc *mstc = nv50_mstc(connector); - if (mstc->port) { - struct nv50_mstm *mstm = mstc->mstm; - return &mstm->msto[0]->encoder; - } - return NULL; + + return &mstc->mstm->msto[0]->encoder; } static enum drm_mode_status @@ -926,10 +920,21 @@ nv50_mstc_get_modes(struct drm_connector *connector) return ret; } +static int +nv50_mstc_atomic_check(struct drm_connector *connector, + struct drm_connector_state *state) +{ + struct nv50_mstc *mstc = nv50_mstc(connector); + + return drm_dp_mst_connector_atomic_check(connector, state, + &mstc->mstm->mgr); +} + static const struct drm_connector_helper_funcs nv50_mstc_help = { .get_modes = nv50_mstc_get_modes, .mode_valid = nv50_mstc_mode_valid, + .atomic_check = nv50_mstc_atomic_check, .best_encoder = nv50_mstc_best_encoder, .atomic_best_encoder = nv50_mstc_atomic_best_encoder, }; -- 2.17.1

6 years, 7 months

1
0
0 0

[PATCH V2 00/12] OPP: Don't create multiple OPP tables for devices sharing OPP table

by Viresh Kumar

Hello, Niklas Cassle recently reported some regressions with his Qcom cpufreq driver where he was getting some errors while creating the OPPs tables. After looking into it I realized that the OPP core incorrectly creates multiple OPP tables for the devices even if they are sharing the OPP table in DT. This happens when the request comes using different CPU devices. For example, dev_pm_opp_set_supported_hw() getting called using CPU0 and dev_pm_opp_of_add_table() getting called using CPU1. This series redesigns the internals of the OPP core to fix that. The redesign has simplified the core itself though. The first three patches are fixes really for the current code and the rest of them are making necessary changes to fix the issue defined in $subject here. Nikklas already tested this series and his Tested-by is already applied to series here. I would like to get this merged during the 4.20 merge window and will push the series to linux-next soon to get more test coverage. Please provide comments as soon as possible, else will send it as part of the pull request to Rafael for 4.20. -- viresh V1->V2: - Nikklas reported another regressions which is fixed by the 2nd commit in this series. Viresh Kumar (12): OPP: Free OPP table properly on performance state irregularities OPP: Don't try to remove all OPP tables on failure OPP: Protect dev_list with opp_table lock OPP: Pass index to _of_init_opp_table() OPP: Parse OPP table's DT properties from _of_init_opp_table() OPP: Don't take OPP table's kref for static OPPs OPP: Create separate kref for static OPPs list cpufreq: mvebu: Remove OPPs using dev_pm_opp_remove() OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table() OPP: Use a single mechanism to free the OPP table OPP: Prevent creating multiple OPP tables for devices sharing OPP nodes OPP: Pass OPP table to _of_add_opp_table_v{1|2}() drivers/cpufreq/mvebu-cpufreq.c | 9 +- drivers/opp/core.c | 147 ++++++++++++++++++++----------- drivers/opp/cpu.c | 15 ++-- drivers/opp/of.c | 188 +++++++++++++++++++++------------------- drivers/opp/opp.h | 19 ++-- include/linux/pm_opp.h | 6 ++ 6 files changed, 226 insertions(+), 158 deletions(-) -- 2.14.1

6 years, 7 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2018