summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-12-20parisc: Fix compiler warnings in debug_core.cHelge Deller
Fix this compiler warning: kernel/debug/debug_core.c: In function ‘kgdb_cpu_enter’: arch/parisc/include/asm/cmpxchg.h:48:3: warning: value computed is not used [-Wunused-value] 48 | ((__typeof__(*(ptr)))__xchg((unsigned long)(x), (ptr), sizeof(*(ptr)))) arch/parisc/include/asm/atomic.h:78:30: note: in expansion of macro ‘xchg’ 78 | #define atomic_xchg(v, new) (xchg(&((v)->counter), new)) | ^~~~ kernel/debug/debug_core.c:596:4: note: in expansion of macro ‘atomic_xchg’ 596 | atomic_xchg(&kgdb_active, cpu); | ^~~~~~~~~~~ Signed-off-by: Helge Deller <deller@gmx.de>
2019-12-20block: fix memleak when __blk_rq_map_user_iov() is failedYang Yingliang
When I doing fuzzy test, get the memleak report: BUG: memory leak unreferenced object 0xffff88837af80000 (size 4096): comm "memleak", pid 3557, jiffies 4294817681 (age 112.499s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 00 10 01 00 00 00 00 00 00 01 00 00 00 ............... backtrace: [<000000001c894df8>] bio_alloc_bioset+0x393/0x590 [<000000008b139a3c>] bio_copy_user_iov+0x300/0xcd0 [<00000000a998bd8c>] blk_rq_map_user_iov+0x2f1/0x5f0 [<000000005ceb7f05>] blk_rq_map_user+0xf2/0x160 [<000000006454da92>] sg_common_write.isra.21+0x1094/0x1870 [<00000000064bb208>] sg_write.part.25+0x5d9/0x950 [<000000004fc670f6>] sg_write+0x5f/0x8c [<00000000b0d05c7b>] __vfs_write+0x7c/0x100 [<000000008e177714>] vfs_write+0x1c3/0x500 [<0000000087d23f34>] ksys_write+0xf9/0x200 [<000000002c8dbc9d>] do_syscall_64+0x9f/0x4f0 [<00000000678d8e9a>] entry_SYSCALL_64_after_hwframe+0x49/0xbe If __blk_rq_map_user_iov() is failed in blk_rq_map_user_iov(), the bio(s) which is allocated before this failing will leak. The refcount of the bio(s) is init to 1 and increased to 2 by calling bio_get(), but __blk_rq_unmap_user() only decrease it to 1, so the bio cannot be freed. Fix it by calling blk_rq_unmap_user(). Reviewed-by: Bob Liu <bob.liu@oracle.com> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20s390/dasd: fix typo in copyright statementStefan Haberland
coypright -> copyright Reported-by: Kate Stewart <kstewart@linuxfoundation.org> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20s390/dasd: fix memleak in path handling error caseStefan Haberland
If for whatever reason the dasd_eckd_check_characteristics() function exits after at least some paths have their configuration data allocated those data is never freed again. In the error case the device->private pointer is set to NULL and dasd_eckd_uncheck_device() will exit without freeing the path data because of this NULL pointer. Fix by calling dasd_eckd_clear_conf_data() for error cases. Also use dasd_eckd_clear_conf_data() in dasd_eckd_uncheck_device() to avoid code duplication. Reported-by: Qian Cai <cai@lca.pw> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20s390/dasd/cio: Interpret ccw_device_get_mdc return value correctlyJan Höppner
The max data count (mdc) is an unsigned 16-bit integer value as per AR documentation and is received via ccw_device_get_mdc() for a specific path mask from the CIO layer. The function itself also always returns a positive mdc value or 0 in case mdc isn't supported or couldn't be determined. Though, the comment for this function describes a negative return value to indicate failures. As a result, the DASD device driver interprets the return value of ccw_device_get_mdc() incorrectly. The error case is essentially a dead code path. To fix this behaviour, check explicitly for a return value of 0 and change the comment for ccw_device_get_mdc() accordingly. This fix merely enables the error code path in the DASD functions get_fcx_max_data() and verify_fcx_max_data(). The actual functionality stays the same and is still correct. Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20block: Fix a lockdep complaint triggered by request queue flushingBart Van Assche
Avoid that running test nvme/012 from the blktests suite triggers the following false positive lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Not tainted -------------------------------------------- ksoftirqd/1/16 is trying to acquire lock: 000000000282032e (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 but task is already holding lock: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&fq->mq_flush_lock)->rlock); lock(&(&fq->mq_flush_lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by ksoftirqd/1/16: #0: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 stack backtrace: CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0x67/0x90 __lock_acquire.cold.45+0x2b4/0x313 lock_acquire+0x98/0x160 _raw_spin_lock_irqsave+0x3b/0x80 flush_end_io+0x4e/0x1d0 blk_mq_complete_request+0x76/0x110 nvmet_req_complete+0x15/0x110 [nvmet] nvmet_bio_done+0x27/0x50 [nvmet] blk_update_request+0xd7/0x2d0 blk_mq_end_request+0x1a/0x100 blk_flush_complete_seq+0xe5/0x350 flush_end_io+0x12f/0x1d0 blk_done_softirq+0x9f/0xd0 __do_softirq+0xca/0x440 run_ksoftirqd+0x24/0x50 smpboot_thread_fn+0x113/0x1e0 kthread+0x121/0x140 ret_from_fork+0x3a/0x50 Cc: Christoph Hellwig <hch@infradead.org> Cc: Ming Lei <ming.lei@redhat.com> Cc: Hannes Reinecke <hare@suse.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20block: Fix the type of 'sts' in bsg_queue_rq()Bart Van Assche
This patch fixes the following sparse warnings: block/bsg-lib.c:269:19: warning: incorrect type in initializer (different base types) block/bsg-lib.c:269:19: expected int sts block/bsg-lib.c:269:19: got restricted blk_status_t [usertype] block/bsg-lib.c:286:16: warning: incorrect type in return expression (different base types) block/bsg-lib.c:286:16: expected restricted blk_status_t block/bsg-lib.c:286:16: got int [assigned] sts Cc: Martin Wilck <mwilck@suse.com> Fixes: d46fe2cb2dce ("block: drop device references in bsg_queue_rq()") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20parisc: soft_offline_page() now takes the pfnHelge Deller
Switch page deallocation table (pdt) driver to use pfn instead of a page pointer in soft_offline_page(). Fixes: feec24a6139d ("mm, soft-offline: convert parameter to pfn") Signed-off-by: Helge Deller <deller@gmx.de>
2019-12-20Merge tag 'iommu-fixes-v5.5-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu Pull iommu fixes from Joerg Roedel: - Fix kmemleak warning in IOVA code - Fix compile warnings on ARM32/64 in dma-iommu code due to dma_mask type mismatches - Make ISA reserved regions relaxable, so that VFIO can assign devices which have such regions defined - Fix mapping errors resulting in IO page-faults in the VT-d driver - Make sure direct mappings for a domain are created after the default domain is updated - Map ISA reserved regions in the VT-d driver with correct permissions - Remove unneeded check for PSI capability in the IOTLB flush code of the VT-d driver - Lockdep fix iommu_dma_prepare_msi() * tag 'iommu-fixes-v5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/dma: Relax locking in iommu_dma_prepare_msi() iommu/vt-d: Remove incorrect PSI capability check iommu/vt-d: Allocate reserved region for ISA with correct permission iommu: set group default domain before creating direct mappings iommu/vt-d: Fix dmar pte read access not set error iommu/vt-d: Set ISA bridge reserved region as relaxable iommu/dma: Rationalise types for DMA masks iommu/iova: Init the struct iova to fix the possible memleak
2019-12-20Merge tag 'platform-drivers-x86-v5.5-2' of ↵Linus Torvalds
git://git.infradead.org/linux-platform-drivers-x86 Pull x86 platform driver fixes from Andy Shevchenko: "Bucket of fixes for PDx86. Note, that there is no ABI breakage in Mellanox driver because it has been introduced in v5.5-rc1, so we can change it. Summary: - Add support of APUv4 and fix an assignment of simswap GPIO - Add Siemens CONNECT X300 to DMI table to avoid stuck during boot - Correct arguments of WMI call on HP Envy x360 15-cp0xxx model - Fix the mlx-bootctl sysfs attributes to be device related" * tag 'platform-drivers-x86-v5.5-2' of git://git.infradead.org/linux-platform-drivers-x86: platform/x86: pcengines-apuv2: Spelling fixes in the driver platform/x86: pcengines-apuv2: detect apuv4 board platform/x86: pcengines-apuv2: fix simswap GPIO assignment platform/x86: pmc_atom: Add Siemens CONNECT X300 to critclk_systems DMI table platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes platform/mellanox: fix the mlx-bootctl sysfs
2019-12-20Merge tag 'mmc-v5.5-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC host fixes from Ulf Hansson: - mtk-sd: Fix tuning for MT8173 HS200/HS400 mode - sdhci: Revert a fix for incorrect switch to HS mode - sdhci-msm: Fixup accesses to the DDR_CONFIG register - sdhci-of-esdhc: Revert a bad fix for erratum A-009204 - sdhci-of-esdhc: Re-implement fix for erratum A-009204 - sdhci-of-esdhc: Fixup P2020 errata handling - sdhci-pci: Disable broken CMDQ on Intel GLK based Lenovo systems * tag 'mmc-v5.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-of-esdhc: re-implement erratum A-009204 workaround mmc: sdhci: Add a quirk for broken command queuing mmc: sdhci: Workaround broken command queuing on Intel GLK mmc: sdhci-of-esdhc: fix P2020 errata handling mmc: sdhci: Update the tuning failed messages to pr_debug level mmc: sdhci-of-esdhc: Revert "mmc: sdhci-of-esdhc: add erratum A-009204 support" mmc: mediatek: fix CMD_TA to 2 for MT8173 HS200/HS400 mode mmc: sdhci-msm: Correct the offset and value for DDR_CONFIG register Revert "mmc: sdhci: Fix incorrect switch to HS mode"
2019-12-20Merge tag 'char-misc-5.5-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small char and other driver fixes for 5.5-rc3. The most noticable one is a much-reported fix for a random driver issue that came up from 5.5-rc1 compat_ioctl cleanups. The others are a chunk of habanalab driver fixes and intel_th driver fixes and new device ids. All have been in linux-next with no reported issues" * tag 'char-misc-5.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: random: don't forget compat_ioctl on urandom intel_th: msu: Fix window switching without windows intel_th: Fix freeing IRQs intel_th: pci: Add Elkhart Lake SOC support intel_th: pci: Add Comet Lake PCH-V support habanalabs: remove variable 'val' set but not used habanalabs: rate limit error msg on waiting for CS
2019-12-20Merge tag 'staging-5.5-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are some small staging driver fixes for a number of reported issues. The majority here are some fixes for the wfx driver, but also in here is a comedi driver fix found during some code review, and an axis-fifo build dependancy issue to resolve some reported testing problems. All of these have been in linux-next with no reported issues" * tag 'staging-5.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: wfx: fix wrong error message staging: wfx: fix hif_set_mfp() with big endian hosts staging: wfx: detect race condition in WEP authentication staging: wfx: ensure that retry policy always fallbacks to MCS0 / 1Mbps staging: wfx: fix rate control handling staging: wfx: firmware does not support more than 32 total retries staging: wfx: use boolean appropriately staging: wfx: fix counter overflow staging: wfx: fix case of lack of tx_retry_policies staging: wfx: fix the cache of rate policies on interface reset staging: axis-fifo: add unspecified HAS_IOMEM dependency staging: comedi: gsc_hpdi: check dma_alloc_coherent() return value
2019-12-20arm64: cpu_errata: Add Hisilicon TSV110 to spectre-v2 safe listWei Li
HiSilicon Taishan v110 CPUs didn't implement CSV2 field of the ID_AA64PFR0_EL1, but spectre-v2 is mitigated by hardware, so whitelist the MIDR in the safe list. Signed-off-by: Wei Li <liwei391@huawei.com> [hanjun: re-write the commit log] Signed-off-by: Hanjun Guo <guohanjun@huawei.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-12-20Merge tag 'tty-5.5-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial fixes from Greg KH: "Here are some small tty and serial driver fixes for 5.5-rc3. Only four small patches here: - atmel serial driver fix - msm_serial driver fix - sprd serial driver fix - tty core port fix The last tty core fix should resolve a long-standing bug with a race at port creation time that some people would see, and Sudip finally tracked down. All of these have been in linux-next with no reported issues" * tag 'tty-5.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty/serial: atmel: fix out of range clock divider handling tty: link tty and port before configuring it as console serial: sprd: Add clearing break interrupt operation tty: serial: msm_serial: Fix lockup for sysrq and oops
2019-12-20Merge tag 'usb-5.5-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB fixes for some reported issues. Included in here are: - xhci build warning fix - ehci disconnect warning fix - usbip lockup fix and error cleanup fix - typec build fix All of these have been in linux-next with no reported issues" * tag 'usb-5.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: xhci: Fix build warning seen with CONFIG_PM=n usbip: Fix error path of vhci_recv_ret_submit() usbip: Fix receive error in vhci-hcd when using scatter-gather USB: EHCI: Do not return -EPIPE when hub is disconnected usb: typec: fusb302: Fix an undefined reference to 'extcon_get_state'
2019-12-20Merge tag 'pinctrl-v5.5-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Sorry that this fixes pull request took a while. Too much christmas business going on. This contains a few really important Intel fixes and some odd fixes: - A host of fixes for the Intel baytrail and cherryview: properly serialize all register accesses and add the irqchip with the gpiochip as we need to, fix some pin lists and initialize the hardware in the right order. - Fix the Aspeed G6 LPC configuration. - Handle a possible NULL pointer exception in the core. - Fix the Kconfig dependencies for the Equilibrium driver" * tag 'pinctrl-v5.5-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: ingenic: Fixup PIN_CONFIG_OUTPUT config pinctrl: Modify Kconfig to fix linker error pinctrl: pinmux: fix a possible null pointer in pinmux_can_be_used_for_gpio pinctrl: aspeed-g6: Fix LPC/eSPI mux configuration pinctrl: cherryview: Pass irqchip when adding gpiochip pinctrl: cherryview: Add GPIO <-> pin mapping ranges via callback pinctrl: cherryview: Split out irq hw-init into a separate helper function pinctrl: baytrail: Pass irqchip when adding gpiochip pinctrl: baytrail: Add GPIO <-> pin mapping ranges via callback pinctrl: baytrail: Update North Community pin list pinctrl: baytrail: Really serialize all register accesses
2019-12-20io_uring: pass in 'sqe' to the prep handlersJens Axboe
This moves the prep handlers outside of the opcode handlers, and allows us to pass in the sqe directly. If the sqe is non-NULL, it means that the request should be prepared for the first time. With the opcode handlers not having access to the sqe at all, we are guaranteed that the prep handler has setup the request fully by the time we get there. As before, for opcodes that need to copy in more data then the io_kiocb allows for, the io_async_ctx holds that info. If a prep handler is invoked with req->io set, it must use that to retain information for later. Finally, we can remove io_kiocb->sqe as well. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20io_uring: standardize the prep methodsJens Axboe
We currently have a mix of use cases. Most of the newer ones are pretty uniform, but we have some older ones that use different calling calling conventions. This is confusing. For the opcodes that currently rely on the req->io->sqe copy saving them from reuse, add a request type struct in the io_kiocb command union to store the data they need. Prepare for all opcodes having a standard prep method, so we can call it in a uniform fashion and outside of the opcode handler. This is in preparation for passing in the 'sqe' pointer, rather than storing it in the io_kiocb. Once we have uniform prep handlers, we can leave all the prep work to that part, and not even pass in the sqe to the opcode handler. This ensures that we don't reuse sqe data inadvertently. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20platform/x86: pcengines-apuv2: Spelling fixes in the driverAndy Shevchenko
Mainly does: - capitalize gpio and bios to GPIO and BIOS - capitalize beginning of comments - add periods in multi-line comments Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20platform/x86: pcengines-apuv2: detect apuv4 boardEnrico Weigelt, metux IT consult
GPIO stuff on APUv4 seems to be the same as on APUv2, so we just need to match on DMI data. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20platform/x86: pcengines-apuv2: fix simswap GPIO assignmentEnrico Weigelt, metux IT consult
The mapping entry has to hold the GPIO line index instead of controller's register number. Fixes: 5037d4ddda31 ("platform/x86: pcengines-apuv2: wire up simswitch gpio as led") Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20platform/x86: pmc_atom: Add Siemens CONNECT X300 to critclk_systems DMI tableMichael Haener
The CONNECT X300 uses the PMC clock for on-board components and gets stuck during boot if the clock is disabled. Therefore, add this device to the critical systems list. Tested on CONNECT X300. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Signed-off-by: Michael Haener <michael.haener@siemens.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytesHans de Goede
At least on the HP Envy x360 15-cp0xxx model the WMI interface for HPWMI_FEATURE2_QUERY requires an outsize of at least 128 bytes, otherwise it fails with an error code 5 (HPWMI_RET_INVALID_PARAMETERS): Dec 06 00:59:38 kernel: hp_wmi: query 0xd returned error 0x5 We do not care about the contents of the buffer, we just want to know if the HPWMI_FEATURE2_QUERY command is supported. This commits bumps the buffer size, fixing the error. Fixes: 8a1513b4932 ("hp-wmi: limit hotkey enable") Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20platform/mellanox: fix the mlx-bootctl sysfsLiming Sun
This is a follow-up commit for the sysfs attributes to change from DRIVER_ATTR to DEVICE_ATTR according to some initial comments. In such case, it's better to point the sysfs path to the device itself instead of the driver. The ABI document is also updated. Fixes: 79e29cb8fbc5 ("platform/mellanox: Add bootctl driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun <lsun@mellanox.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-12-20io_uring: read 'count' for IORING_OP_TIMEOUT in prep handlerJens Axboe
Add the count field to struct io_timeout, and ensure the prep handler has read it. Timeout also needs an async context always, set it up in the prep handler if we don't have one. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20io_uring: move all prep state for IORING_OP_{SEND,RECV}_MGS to prep handlerJens Axboe
Add struct io_sr_msg in our io_kiocb per-command union, and ensure that the send/recvmsg prep handlers have grabbed what they need from the SQE by the time prep is done. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20io_uring: move all prep state for IORING_OP_CONNECT to prep handlerJens Axboe
Add struct io_connect in our io_kiocb per-command union, and ensure that io_connect_prep() has grabbed what it needs from the SQE. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20io_uring: add and use struct io_rw for read/writesJens Axboe
Put the kiocb in struct io_rw, and add the addr/len for the request as well. Use the kiocb->private field for the buffer index for fixed reads and writes. Any use of kiocb->ki_filp is flipped to req->file. It's the same thing, and less confusing. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20rxrpc: Fix missing security check on incoming callsDavid Howells
Fix rxrpc_new_incoming_call() to check that we have a suitable service key available for the combination of service ID and security class of a new incoming call - and to reject calls for which we don't. This causes an assertion like the following to appear: rxrpc: Assertion failed - 6(0x6) == 12(0xc) is false kernel BUG at net/rxrpc/call_object.c:456! Where call->state is RXRPC_CALL_SERVER_SECURING (6) rather than RXRPC_CALL_COMPLETE (12). Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Reported-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com>
2019-12-20rxrpc: Don't take call->user_mutex in rxrpc_new_incoming_call()David Howells
Standard kernel mutexes cannot be used in any way from interrupt or softirq context, so the user_mutex which manages access to a call cannot be a mutex since on a new call the mutex must start off locked and be unlocked within the softirq handler to prevent userspace interfering with a call we're setting up. Commit a0855d24fc22d49cdc25664fb224caee16998683 ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") causes big warnings to be splashed in dmesg for each a new call that comes in from the server. Whilst it *seems* like it should be okay, since the accept path uses trylock, there are issues with PI boosting and marking the wrong task as the owner. Fix this by not taking the mutex in the softirq path at all. It's not obvious that there should be any need for it as the state is set before the first notification is generated for the new call. There's also no particular reason why the link-assessing ping should be triggered inside the mutex. It's not actually transmitted there anyway, but rather it has to be deferred to a workqueue. Further, I don't think that there's any particular reason that the socket notification needs to be done from within rx->incoming_lock, so the amount of time that lock is held can be shortened too and the ping prepared before the new call notification is sent. Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg") Signed-off-by: David Howells <dhowells@redhat.com> cc: Peter Zijlstra (Intel) <peterz@infradead.org> cc: Ingo Molnar <mingo@redhat.com> cc: Will Deacon <will@kernel.org> cc: Davidlohr Bueso <dave@stgolabs.net>
2019-12-20rxrpc: Unlock new call in rxrpc_new_incoming_call() rather than the callerDavid Howells
Move the unlock and the ping transmission for a new incoming call into rxrpc_new_incoming_call() rather than doing it in the caller. This makes it clearer to see what's going on. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> cc: Ingo Molnar <mingo@redhat.com> cc: Will Deacon <will@kernel.org> cc: Davidlohr Bueso <dave@stgolabs.net>
2019-12-20xfs: Make the symbol 'xfs_rtalloc_log_count' staticChen Wandun
Fix the following sparse warning: fs/xfs/libxfs/xfs_trans_resv.c:206:1: warning: symbol 'xfs_rtalloc_log_count' was not declared. Should it be static? Fixes: b1de6fc7520f ("xfs: fix log reservation overflows when allocating large rt extents") Signed-off-by: Chen Wandun <chenwandun@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
2019-12-20io_uring: use u64_to_user_ptr() consistentlyJens Axboe
We use it in some spots, but not consistently. Convert the rest over, makes it easier to read as well. No functional changes in this patch. Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-12-20drm/arm/mali: make malidp_mw_connector_helper_funcs staticBen Dooks (Codethink)
The malidp_mw_connector_helper_funcs is not referenced by name outside of the file it is in, so make it static to avoid the following warning: drivers/gpu/drm/arm/malidp_mw.c:59:41: warning: symbol 'malidp_mw_connector_helper_funcs' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217115309.2133503-1-ben.dooks@codethink.co.uk
2019-12-20xen/grant-table: remove multiple BUG_ON on gnttab_interfaceAditya Pakki
gnttab_request_version() always sets the gnttab_interface variable and the assertions to check for empty gnttab_interface is unnecessary. The patch eliminates multiple such assertions. Signed-off-by: Aditya Pakki <pakki001@umn.edu> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20xen-blkback: support dynamic unbind/bindPaul Durrant
By simply re-attaching to shared rings during connect_ring() rather than assuming they are freshly allocated (i.e assuming the counters are zero) it is possible for vbd instances to be unbound and re-bound from and to (respectively) a running guest. This has been tested by running: while true; do fio --name=randwrite --ioengine=libaio --iodepth=16 \ --rw=randwrite --bs=4k --direct=1 --size=1G --verify=crc32; done in a PV guest whilst running: while true; do echo vbd-$DOMID-$VBD >unbind; echo unbound; sleep 5; echo vbd-$DOMID-$VBD >bind; echo bound; sleep 3; done in dom0 from /sys/bus/xen-backend/drivers/vbd to continuously unbind and re-bind its system disk image. This is a highly useful feature for a backend module as it allows it to be unloaded and re-loaded (i.e. updated) without requiring domUs to be halted. This was also tested by running: while true; do echo vbd-$DOMID-$VBD >unbind; echo unbound; sleep 5; rmmod xen-blkback; echo unloaded; sleep 1; modprobe xen-blkback; echo bound; cd $(pwd); sleep 3; done in dom0 whilst running the same loop as above in the (single) PV guest. Some (less stressful) testing has also been done using a Windows HVM guest with the latest 9.0 PV drivers installed. Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20xen/interface: re-define FRONT/BACK_RING_ATTACH()Paul Durrant
Currently these macros are defined to re-initialize a front/back ring (respectively) to values read from the shared ring in such a way that any requests/responses that are added to the shared ring whilst the front/back is detached will be skipped over. This, in general, is not a desirable semantic since most frontend implementations will eventually block waiting for a response which would either never appear or never be processed. Since the macros are currently unused, take this opportunity to re-define them to re-initialize a front/back ring using specified values. This also allows FRONT/BACK_RING_INIT() to be re-defined in terms of FRONT/BACK_RING_ATTACH() using a specified value of 0. NOTE: BACK_RING_ATTACH() will be used directly in a subsequent patch. Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20xenbus: limit when state is forced to closedPaul Durrant
If a driver probe() fails then leave the xenstore state alone. There is no reason to modify it as the failure may be due to transient resource allocation issues and hence a subsequent probe() may succeed. If the driver supports re-binding then only force state to closed during remove() only in the case when the toolstack may need to clean up. This can be detected by checking whether the state in xenstore has been set to closing prior to device removal. NOTE: Re-bind support is indicated by new boolean in struct xenbus_driver, which defaults to false. Subsequent patches will add support to some backend drivers. Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20xenbus: move xenbus_dev_shutdown() into frontend code...Paul Durrant
...and make it static xenbus_dev_shutdown() is seemingly intended to cause clean shutdown of PV frontends when a guest is rebooted. Indeed the function waits for a conpletion which is only set by a call to xenbus_frontend_closed(). This patch removes the shutdown() method from backends and moves xenbus_dev_shutdown() from xenbus_probe.c into xenbus_probe_frontend.c, renaming it appropriately and making it static. NOTE: In the case where the backend is running in a driver domain, the toolstack should have already terminated any frontends that may be using it (since Xen does not support re-startable PV driver domains) so xenbus_dev_shutdown() should never be called. Signed-off-by: Paul Durrant <pdurrant@amazon.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20xen/blkfront: Adjust indentation in xlvbd_alloc_gendiskNathan Chancellor
Clang warns: ../drivers/block/xen-blkfront.c:1117:4: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] nr_parts = PARTS_PER_DISK; ^ ../drivers/block/xen-blkfront.c:1115:3: note: previous statement is here if (err) ^ This is because there is a space at the beginning of this line; remove it so that the indentation is consistent according to the Linux kernel coding style and clang no longer warns. While we are here, the previous line has some trailing whitespace; clean that up as well. Fixes: c80a420995e7 ("xen-blkfront: handle Xen major numbers other than XENVBD") Link: https://github.com/ClangBuiltLinux/linux/issues/791 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com>
2019-12-20phy: qcom-qmp: Increase PHY ready timeoutBjorn Andersson
It's typical for the QHP PHY to take slightly above 1ms to initialize, so increase the timeout of the PHY ready check to 10ms - as already done in the downstream PCIe driver. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Evan Green <evgreen@chromium.org> Tested-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-12-20riscv: move sifive_l2_cache.c to drivers/socChristoph Hellwig
The sifive_l2_cache.c is in no way related to RISC-V architecture memory management. It is a little stub driver working around the fact that the EDAC maintainers prefer their drivers to be structured in a certain way that doesn't fit the SiFive SOCs. Move the file to drivers/soc and add a Kconfig option for it, as well as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE. Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Borislav Petkov <bp@suse.de> [paul.walmsley@sifive.com: keep the MAINTAINERS change specific to the L2$ controller code] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: define vmemmap before pfn_to_page callsDavid Abdurachmanov
pfn_to_page & page_to_pfn depend on vmemmap being available before the calls if kernel is configured with CONFIG_SPARSEMEM_VMEMMAP=y. This was caused by NOMMU changes which moved vmemmap definition bellow functions definitions calling pfn_to_page & page_to_pfn. Noticed while compiled 5.5-rc2 kernel for Fedora/RISCV. v2: - Add a comment for vmemmap in source Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com> Fixes: 6bd33e1ece52 ("riscv: add nommu support") Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: fix scratch register clearing in M-mode.Greentime Hu
This patch fixes that the sscratch register clearing in M-mode. It cleared sscratch register in M-mode, but it should clear mscratch register. That will cause kernel trap if the CPU core doesn't support S-mode when trying to access sscratch. Fixes: 9e80635619b5 ("riscv: clear the instruction cache and all registers when booting") Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: Fix use of undefined config option CONFIG_CONFIG_MMUAndreas Schwab
In Kconfig files, config options are written without the CONFIG_ prefix. Fixes: 6bd33e1ece52 ("riscv: add nommu support") Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20phy: cpcap-usb: Fix error path when no host driver is loadedTony Lindgren
If musb_mailbox() returns an error, we must still continue to finish configuring the phy. Otherwise the phy state may end up only half initialized, and this can cause the debug serial console to stop working. And this will happen if the usb driver musb controller is not loaded. Let's fix the issue by adding helper for cpcap_usb_try_musb_mailbox(). Fixes: 6d6ce40f63af ("phy: cpcap-usb: Add CPCAP PMIC USB support") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
2019-12-20USB: serial: option: add ZLP support for 0x1bc7/0x9010Daniele Palmas
Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet to be sent if out data size is is equal to the endpoint max size. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> [ johan: switch operands in conditional ] Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-12-20ALSA: usb-audio: fix set_format altsetting sanity checkJohan Hovold
Make sure to check the return value of usb_altnum_to_altsetting() to avoid dereferencing a NULL pointer when the requested alternate settings is missing. The format altsetting number may come from a quirk table and there does not seem to be any other validation of it (the corresponding index is checked however). Fixes: b099b9693d23 ("ALSA: usb-audio: Avoid superfluous usb_set_interface() calls") Cc: stable <stable@vger.kernel.org> # 4.18 Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20191220093134.1248-1-johan@kernel.org Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-19Merge branch 'cls_u32-fix-refcount-leak'David S. Miller
Davide Caratti says: ==================== net/sched: cls_u32: fix refcount leak a refcount leak in the error path of u32_change() has been recently introduced. It can be observed with the following commands: [root@f31 ~]# tc filter replace dev eth0 ingress protocol ip prio 97 \ > u32 match ip src 127.0.0.1/32 indev notexist20 flowid 1:1 action drop RTNETLINK answers: Invalid argument We have an error talking to the kernel [root@f31 ~]# tc filter replace dev eth0 ingress protocol ip prio 98 \ > handle 42:42 u32 divisor 256 Error: cls_u32: Divisor can only be used on a hash table. We have an error talking to the kernel [root@f31 ~]# tc filter replace dev eth0 ingress protocol ip prio 99 \ > u32 ht 47:47 Error: cls_u32: Specified hash table not found. We have an error talking to the kernel they all legitimately return -EINVAL; however, they leave semi-configured filters at eth0 tc ingress: [root@f31 ~]# tc filter show dev eth0 ingress filter protocol ip pref 97 u32 chain 0 filter protocol ip pref 97 u32 chain 0 fh 800: ht divisor 1 filter protocol ip pref 98 u32 chain 0 filter protocol ip pref 98 u32 chain 0 fh 801: ht divisor 1 filter protocol ip pref 99 u32 chain 0 filter protocol ip pref 99 u32 chain 0 fh 802: ht divisor 1 With older kernels, filters were unconditionally considered empty (and thus de-refcounted) on the error path of ->change(). After commit 8b64678e0af8 ("net: sched: refactor tp insert/delete for concurrent execution"), filters were considered empty when the walk() function didn't set 'walker.stop' to 1. Finally, with commit 6676d5e416ee ("net: sched: set dedicated tcf_walker flag when tp is empty"), tc filters are considered empty unless the walker function is called with a non-NULL handle. This last change doesn't fit cls_u32 design, because at least the "root hnode" is (almost) always non-NULL, as it's allocated in u32_init(). - patch 1/2 is a proposal to restore the original kernel behavior, where no filter was installed in the error path of u32_change(). - patch 2/2 adds tdc selftests that can be ued to verify the correct behavior of u32 in the error path of ->change(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-05 14:36:09 +0000