summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-07-23scsi: scsi_dh_alua: always use a 2 second delay before retrying RTPGHannes Reinecke
Retrying immediately after we've received a 'transitioning' sense code is pretty much pointless, we should always use a delay before retrying. So ensure the default delay is applied before retrying. Signed-off-by: Hannes Reinecke <hare@suse.com> Tested-by: Zhangguanghui <zhang.guanghui@h3c.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23scsi: ibmvfc: fix WARN_ON during event pool releaseTyrel Datwyler
While removing an ibmvfc client adapter a WARN_ON like the following WARN_ON is seen in the kernel log: WARNING: CPU: 6 PID: 5421 at ./include/linux/dma-mapping.h:541 ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc] CPU: 6 PID: 5421 Comm: rmmod Tainted: G E 4.17.0-rc1-next-20180419-autotest #1 NIP: d00000000290328c LR: d00000000290325c CTR: c00000000036ee20 REGS: c000000288d1b7e0 TRAP: 0700 Tainted: G E (4.17.0-rc1-next-20180419-autotest) MSR: 800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 44008828 XER: 20000000 CFAR: c00000000036e408 SOFTE: 1 GPR00: d00000000290325c c000000288d1ba60 d000000002917900 c000000289d75448 GPR04: 0000000000000071 c0000000ff870000 0000000018040000 0000000000000001 GPR08: 0000000000000000 c00000000156e838 0000000000000001 d00000000290c640 GPR12: c00000000036ee20 c00000001ec4dc00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 00000100276901e0 0000000010020598 GPR20: 0000000010020550 0000000010020538 0000000010020578 00000000100205b0 GPR24: 0000000000000000 0000000000000000 0000000010020590 5deadbeef0000100 GPR28: 5deadbeef0000200 d000000002910b00 0000000000000071 c0000002822f87d8 NIP [d00000000290328c] ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc] LR [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc] Call Trace: [c000000288d1ba60] [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc] (unreliable) [c000000288d1baf0] [d000000002909390] ibmvfc_abort_task_set+0x7b0/0x8b0 [ibmvfc] [c000000288d1bb70] [c0000000000d8c68] vio_bus_remove+0x68/0x100 [c000000288d1bbb0] [c0000000007da7c4] device_release_driver_internal+0x1f4/0x2d0 [c000000288d1bc00] [c0000000007da95c] driver_detach+0x7c/0x100 [c000000288d1bc40] [c0000000007d8af4] bus_remove_driver+0x84/0x140 [c000000288d1bcb0] [c0000000007db6ac] driver_unregister+0x4c/0xa0 [c000000288d1bd20] [c0000000000d6e7c] vio_unregister_driver+0x2c/0x50 [c000000288d1bd50] [d00000000290ba0c] cleanup_module+0x24/0x15e0 [ibmvfc] [c000000288d1bd70] [c0000000001dadb0] sys_delete_module+0x220/0x2d0 [c000000288d1be30] [c00000000000b284] system_call+0x58/0x6c Instruction dump: e8410018 e87f0068 809f0078 e8bf0080 e8df0088 2fa30000 419e008c e9230200 2fa90000 419e0080 894d098a 794a07e0 <0b0a0000> e9290008 2fa90000 419e0028 This is tripped as a result of irqs being disabled during the call to dma_free_coherent() by ibmvfc_free_event_pool(). At this point in the code path we have quiesced the adapter and its overly paranoid anyways to be holding the host lock. Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23scsi: fcoe: fix a typoChristophe JAILLET
#define relative to FCOE CTLR start with FCOE_CTLR, except FCOE_CTRL_SOL_TOV. This is likely a typo and CTRL should be CTLR here as well. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23scsi: megaraid_sas: Make some functions staticYueHaibing
Fix sparse warnings: drivers/scsi/megaraid/megaraid_sas_fusion.c:541:1: warning: symbol 'megasas_alloc_cmdlist_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:580:1: warning: symbol 'megasas_alloc_request_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:661:1: warning: symbol 'megasas_alloc_reply_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:738:1: warning: symbol 'megasas_alloc_rdpq_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:920:1: warning: symbol 'megasas_alloc_cmds_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:1740:1: warning: symbol 'megasas_init_adapter_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:1966:1: warning: symbol 'map_cmd_status' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:2379:1: warning: symbol 'megasas_set_pd_lba' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:2718:1: warning: symbol 'megasas_build_ldio_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:3215:1: warning: symbol 'megasas_build_io_fusion' was not declared. Should it be static? drivers/scsi/megaraid/megaraid_sas_fusion.c:3328:6: warning: symbol 'megasas_prepare_secondRaid1_IO' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23scsi: megaraid_sas: fix panic on loading firmware crashdumpJunxiao Bi
While loading fw crashdump in function fw_crash_buffer_show(), left bytes in one dma chunk was not checked, if copying size over it, overflow access will cause kernel panic. Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com> Acked-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23scsi: megaraid_sas: fix spelling mistake "megarid_sas" -> "megaraid_sas"Colin Ian King
Fix spelling mistake in kernel warning message and replace printk with with pr_warn. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-23Merge branch 'parisc-5.3-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: - Fix build issues when kprobes are enabled - Speed up ITLB/DTLB cache flushes when running on machines with combined TLBs * 'parisc-5.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Flush ITLB in flush_tlb_all_local() only on split TLB machines parisc: add kprobe_fault_handler()
2019-07-23drm/amd/display: Set enabled to false at start of audio disableNicholas Kazlauskas
[Why] In an effort to stop redundant calls to dce110_disable_audio_stream the audio->enabled flag was added to the audio resource struct. While this state probably shouldn't have been tracked on the audio struct itself it still works fine for some sequences. However, it does not work for cases where we're freeing the audio resource (such as hotplugs) or when dynamic audio is enabled. In these cases the pipe_ctx->stream_res.audio = NULL before we can set audio->enabled = false. The next time we acquire the audio resource such as on hotplug the audio will not be enabled for the stream since DC thinks it's still enabled. Audio state tracking should cover this sequence. [How] Set audio->enabled = false at the start as long as we have pipe_ctx->stream_res.audio. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-23Revert "nvme-pci: don't create a read hctx mapping without read queues"yangerkun
This reverts commit 0298d5435276e7795b0b939d74827f6e775e7009. With this patch, set 'poll_queues > hard queues' will lead to 'nr_read_queues = 0' in nvme_calc_irq_sets. Then poll_queues setting can fail since dev->tagset.nr_maps equals to 2 and nvme_pci_map_queues will not do map for poll queues. Signed-off-by: yangerkun <yangerkun@huawei.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-07-23nvme: fix multipath crash when ANA is deactivatedMarta Rybczynska
Fix a crash with multipath activated. It happends when ANA log page is larger than MDTS and because of that ANA is disabled. The driver then tries to access unallocated buffer when connecting to a nvme target. The signature is as follows: [ 300.433586] nvme nvme0: ANA log page size (8208) larger than MDTS (8192). [ 300.435387] nvme nvme0: disabling ANA support. [ 300.437835] nvme nvme0: creating 4 I/O queues. [ 300.459132] nvme nvme0: new ctrl: NQN "nqn.0.0.0", addr 10.91.0.1:8009 [ 300.464609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [ 300.466342] #PF error: [normal kernel read fault] [ 300.467385] PGD 0 P4D 0 [ 300.467987] Oops: 0000 [#1] SMP PTI [ 300.468787] CPU: 3 PID: 50 Comm: kworker/u8:1 Not tainted 5.0.20kalray+ #4 [ 300.470264] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 300.471532] Workqueue: nvme-wq nvme_scan_work [nvme_core] [ 300.472724] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.474038] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.477374] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296 [ 300.478334] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000 [ 300.479784] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258 [ 300.481488] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 [ 300.483203] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0 [ 300.484928] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0 [ 300.486626] FS: 0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000 [ 300.488538] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 300.489907] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0 [ 300.491612] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 300.493303] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 300.494991] Call Trace: [ 300.495645] nvme_mpath_add_disk+0x5c/0xb0 [nvme_core] [ 300.496880] nvme_validate_ns+0x2ef/0x550 [nvme_core] [ 300.498105] ? nvme_identify_ctrl.isra.45+0x6a/0xb0 [nvme_core] [ 300.499539] nvme_scan_work+0x2b4/0x370 [nvme_core] [ 300.500717] ? __switch_to_asm+0x35/0x70 [ 300.501663] process_one_work+0x171/0x380 [ 300.502340] worker_thread+0x49/0x3f0 [ 300.503079] kthread+0xf8/0x130 [ 300.503795] ? max_active_store+0x80/0x80 [ 300.504690] ? kthread_bind+0x10/0x10 [ 300.505502] ret_from_fork+0x35/0x40 [ 300.506280] Modules linked in: nvme_tcp nvme_rdma rdma_cm iw_cm ib_cm ib_core nvme_fabrics nvme_core xt_physdev ip6table_raw ip6table_mangle ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_CHECKSUM iptable_mangle iptable_filter veth ebtable_filter ebtable_nat ebtables iptable_raw vxlan ip6_udp_tunnel udp_tunnel sunrpc joydev pcspkr virtio_balloon br_netfilter bridge stp llc ip_tables xfs libcrc32c ata_generic pata_acpi virtio_net virtio_console net_failover virtio_blk failover ata_piix serio_raw libata virtio_pci virtio_ring virtio [ 300.514984] CR2: 0000000000000008 [ 300.515569] ---[ end trace faa2eefad7e7f218 ]--- [ 300.516354] RIP: 0010:nvme_parse_ana_log+0x21/0x140 [nvme_core] [ 300.517330] Code: 45 01 d2 d8 48 98 c3 66 90 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 08 48 8b af 20 0a 00 00 48 89 34 24 <66> 83 7d 08 00 0f 84 c6 00 00 00 44 8b 7d 14 49 89 d5 8b 55 10 48 [ 300.520353] RSP: 0018:ffffa50e80fd7cb8 EFLAGS: 00010296 [ 300.521229] RAX: 0000000000000001 RBX: ffff9130f1872258 RCX: 0000000000000000 [ 300.522399] RDX: ffffffffc06c4c30 RSI: ffff9130edad4280 RDI: ffff9130f1872258 [ 300.523560] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000044 [ 300.524734] R10: 0000000000000220 R11: 0000000000000040 R12: ffff9130f18722c0 [ 300.525915] R13: ffff9130f18722d0 R14: ffff9130edad4280 R15: ffff9130f18722c0 [ 300.527084] FS: 0000000000000000(0000) GS:ffff9130f7b80000(0000) knlGS:0000000000000000 [ 300.528396] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 300.529440] CR2: 0000000000000008 CR3: 00000002365e6000 CR4: 00000000000006e0 [ 300.530739] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 300.531989] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 300.533264] Kernel panic - not syncing: Fatal exception [ 300.534338] Kernel Offset: 0x17c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 300.536227] ---[ end Kernel panic - not syncing: Fatal exception ]--- Condition check refactoring from Christoph Hellwig. Signed-off-by: Marta Rybczynska <marta.rybczynska@kalray.eu> Tested-by: Jean-Baptiste Riaux <jbriaux@kalray.eu> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-07-23nvme: fix memory leak caused by incorrect subsystem freeLogan Gunthorpe
When freeing the subsystem after finding another match with __nvme_find_get_subsystem(), use put_device() instead of __nvme_release_subsystem() which calls kfree() directly. Per the documentation, put_device() should always be used after device_initialization() is called. Otherwise, leaks like the one below which was detected by kmemleak may occur. Once the call of __nvme_release_subsystem() is removed it no longer makes sense to keep the helper, so fold it back into nvme_release_subsystem(). unreferenced object 0xffff8883d12bfbc0 (size 16): comm "nvme", pid 2635, jiffies 4294933602 (age 739.952s) hex dump (first 16 bytes): 6e 76 6d 65 2d 73 75 62 73 79 73 32 00 88 ff ff nvme-subsys2.... backtrace: [<000000007d8fc208>] __kmalloc_track_caller+0x16d/0x2a0 [<0000000081169e5f>] kvasprintf+0xad/0x130 [<0000000025626f25>] kvasprintf_const+0x47/0x120 [<00000000fa66ad36>] kobject_set_name_vargs+0x44/0x120 [<000000004881f8b3>] dev_set_name+0x98/0xc0 [<000000007124dae3>] nvme_init_identify+0x1995/0x38e0 [<000000009315020a>] nvme_loop_configure_admin_queue+0x4fa/0x5e0 [<000000001a63e766>] nvme_loop_create_ctrl+0x489/0xf80 [<00000000a46ecc23>] nvmf_dev_write+0x1a12/0x2220 [<000000002259b3d5>] __vfs_write+0x66/0x120 [<000000002f6df81e>] vfs_write+0x154/0x490 [<000000007e8cfc19>] ksys_write+0x10a/0x240 [<00000000ff5c7b85>] __x64_sys_write+0x73/0xb0 [<00000000fee6d692>] do_syscall_64+0xaa/0x470 [<00000000997e1ede>] entry_SYSCALL_64_after_hwframe+0x49/0xbe Fixes: ab9e00cc72fa ("nvme: track subsystems") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-07-23nvme: ignore subnqn for ADATA SX6000LNPMisha Nasledov
The ADATA SX6000LNP NVMe SSDs have the same subnqn and, due to this, a system with more than one of these SSDs will only have one usable. [ 0.942706] nvme nvme1: ignoring ctrl due to duplicate subnqn (nqn.2018-05.com.example:nvme:nvm-subsystem-OUI00E04C). [ 0.943017] nvme nvme1: Removing after probe failure status: -22 02:00.0 Non-Volatile memory controller [0108]: Realtek Semiconductor Co., Ltd. Device [10ec:5762] (rev 01) 71:00.0 Non-Volatile memory controller [0108]: Realtek Semiconductor Co., Ltd. Device [10ec:5762] (rev 01) There are no firmware updates available from the vendor, unfortunately. Applying the NVME_QUIRK_IGNORE_DEV_SUBNQN quirk for these SSDs resolves the issue, and they all work after this patch: /dev/nvme0n1 2J1120050420 ADATA SX6000LNP [...] /dev/nvme1n1 2J1120050540 ADATA SX6000LNP [...] Signed-off-by: Misha Nasledov <misha@nasledov.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-07-23dma-mapping: use dma_get_mask in dma_addressing_limitedEric Auger
We currently have cases where the dma_addressing_limited() gets called with dma_mask unset. This causes a NULL pointer dereference. Use dma_get_mask() accessor to prevent the crash. Fixes: b866455423e0 ("dma-mapping: add a dma_addressing_limited helper") Signed-off-by: Eric Auger <eric.auger@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-07-23iommu/amd: Add support for X2APIC IOMMU interruptsSuthikulpanit, Suravee
AMD IOMMU requires IntCapXT registers to be setup in order to generate its own interrupts (for Event Log, PPR Log, and GA Log) with 32-bit APIC destination ID. Without this support, AMD IOMMU MSI interrupts will not be routed correctly when booting the system in X2APIC mode. Cc: Joerg Roedel <joro@8bytes.org> Fixes: 90fcffd9cf5e ('iommu/amd: Add support for IOMMU XT mode') Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-07-23ACPI/IORT: Fix off-by-one check in iort_dev_find_its_id()Lorenzo Pieralisi
Static analysis identified that index comparison against ITS entries in iort_dev_find_its_id() is off by one. Update the comparison condition and clarify the resulting error message. Fixes: 4bf2efd26d76 ("ACPI: Add new IORT functions to support MSI domain handling") Link: https://lore.kernel.org/linux-arm-kernel/20190613065410.GB16334@mwanda/ Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Will Deacon <will@kernel.org> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-07-23drbd: dynamically allocate shash descriptorArnd Bergmann
Building with clang and KASAN, we get a warning about an overly large stack frame on 32-bit architectures: drivers/block/drbd/drbd_receiver.c:921:31: error: stack frame size of 1280 bytes in function 'conn_connect' [-Werror,-Wframe-larger-than=] We already allocate other data dynamically in this function, so just do the same for the shash descriptor, which makes up most of this memory. Link: https://lore.kernel.org/lkml/20190617132440.2721536-1-arnd@arndb.de/ Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Roland Kammerer <roland.kammerer@linbit.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-07-23block: blk-mq: Remove blk_mq_sched_started_request and started_requestMarcos Paulo de Souza
blk_mq_sched_completed_request is a function that checks if the elevator related to the request has started_request implemented, but currently, none of the available IO schedulers implement started_request, so remove both. Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-07-23ALSA: ac97: Fix double free of ac97_codec_deviceDing Xiang
put_device will call ac97_codec_release to free ac97_codec_device and other resources, so remove the kfree and other redundant code. Fixes: 74426fbff66e ("ALSA: ac97: add an ac97 bus") Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-23ALSA: compress: Be more restrictive about when a drain is allowedCharles Keepax
Draining makes little sense in the situation of hardware overrun, as the hardware will have consumed all its available samples. Additionally, draining whilst the stream is paused would presumably get stuck as no data is being consumed on the DSP side. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-23ALSA: compress: Don't allow paritial drain operations on capture streamsCharles Keepax
Partial drain and next track are intended for gapless playback and don't really have an obvious interpretation for a capture stream, so makes sense to not allow those operations on capture streams. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-23ALSA: compress: Prevent bypasses of set_paramsCharles Keepax
Currently, whilst in SNDRV_PCM_STATE_OPEN it is possible to call snd_compr_stop, snd_compr_drain and snd_compr_partial_drain, which allow a transition to SNDRV_PCM_STATE_SETUP. The stream should only be able to move to the setup state once it has received a SNDRV_COMPRESS_SET_PARAMS ioctl. Fix this issue by not allowing those ioctls whilst in the open state. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-23ALSA: compress: Fix regression on compressed capture streamsCharles Keepax
A previous fix to the stop handling on compressed capture streams causes some knock on issues. The previous fix updated snd_compr_drain_notify to set the state back to PREPARED for capture streams. This causes some issues however as the handling for snd_compr_poll differs between the two states and some user-space applications were relying on the poll failing after the stream had been stopped. To correct this regression whilst still fixing the original problem the patch was addressing, update the capture handling to skip the PREPARED state rather than skipping the SETUP state as it has done until now. Fixes: 4f2ab5e1d13d ("ALSA: compress: Fix stop handling on compressed capture streams") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-07-23s390/kasan: add bitops instrumentationVasily Gorbik
Add KASAN instrumentation of architecture-specific asm implementation of bitops. It also covers s390 specific *_inv functions. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390/bitops: make test functions return boolVasily Gorbik
Make s390/bitops test functions return bool values. That enforces return value range to 0 and 1 and matches with asm-generic/bitops-instrumented.h declarations as well as some other architectures implementations. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390: wire up clone3 system callVasily Gorbik
Tested (64-bit and compat mode) using program from http://lkml.kernel.org/r/20190604212930.jaaztvkent32b7d3@brauner.io with the following: return syscall(__NR_clone, flags, 0, pidfd, 0, 0); changed to: return syscall(__NR_clone, 0, flags, pidfd, 0, 0); due to CLONE_BACKWARDS2. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23kbuild: enable arch/s390/include/uapi/asm/zcrypt.h for uapi header testHeiko Carstens
Masahiro Yamada changed the zcrypt.h header file to use __u{16,32,64} instead of uint{16,32,64}_t with ("s390: use __u{16,32,64} instead of uint{16,32,64}_t in uapi header"). This makes all s390 header files pass - remove zcrypt.h from the blacklist. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390: use __u{16,32,64} instead of uint{16,32,64}_t in uapi headerMasahiro Yamada
When CONFIG_UAPI_HEADER_TEST=y, exported headers are compile-tested to make sure they can be included from user-space. Currently, zcrypt.h is excluded from the test coverage. To make it join the compile-test, we need to fix the build errors attached below. For a case like this, we decided to use __u{8,16,32,64} variable types in this discussion: https://lkml.org/lkml/2019/6/5/18 Build log: CC usr/include/asm/zcrypt.h.s In file included from <command-line>:32:0: ./usr/include/asm/zcrypt.h:163:2: error: unknown type name ‘uint16_t’ uint16_t cprb_len; ^~~~~~~~ ./usr/include/asm/zcrypt.h:168:2: error: unknown type name ‘uint32_t’ uint32_t source_id; ^~~~~~~~ ./usr/include/asm/zcrypt.h:169:2: error: unknown type name ‘uint32_t’ uint32_t target_id; ^~~~~~~~ ./usr/include/asm/zcrypt.h:170:2: error: unknown type name ‘uint32_t’ uint32_t ret_code; ^~~~~~~~ ./usr/include/asm/zcrypt.h:171:2: error: unknown type name ‘uint32_t’ uint32_t reserved1; ^~~~~~~~ ./usr/include/asm/zcrypt.h:172:2: error: unknown type name ‘uint32_t’ uint32_t reserved2; ^~~~~~~~ ./usr/include/asm/zcrypt.h:173:2: error: unknown type name ‘uint32_t’ uint32_t payload_len; ^~~~~~~~ ./usr/include/asm/zcrypt.h:182:2: error: unknown type name ‘uint16_t’ uint16_t ap_id; ^~~~~~~~ ./usr/include/asm/zcrypt.h:183:2: error: unknown type name ‘uint16_t’ uint16_t dom_id; ^~~~~~~~ ./usr/include/asm/zcrypt.h:198:2: error: unknown type name ‘uint16_t’ uint16_t targets_num; ^~~~~~~~ ./usr/include/asm/zcrypt.h:199:2: error: unknown type name ‘uint64_t’ uint64_t targets; ^~~~~~~~ ./usr/include/asm/zcrypt.h:200:2: error: unknown type name ‘uint64_t’ uint64_t weight; ^~~~~~~~ ./usr/include/asm/zcrypt.h:201:2: error: unknown type name ‘uint64_t’ uint64_t req_no; ^~~~~~~~ ./usr/include/asm/zcrypt.h:202:2: error: unknown type name ‘uint64_t’ uint64_t req_len; ^~~~~~~~ ./usr/include/asm/zcrypt.h:203:2: error: unknown type name ‘uint64_t’ uint64_t req; ^~~~~~~~ ./usr/include/asm/zcrypt.h:204:2: error: unknown type name ‘uint64_t’ uint64_t resp_len; ^~~~~~~~ ./usr/include/asm/zcrypt.h:205:2: error: unknown type name ‘uint64_t’ uint64_t resp; ^~~~~~~~ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390/hypfs: fix a typo in the name of a functionChristophe JAILLET
Everything is about hypfs_..., except 'hpyfs_vm_create_guest()' s/hpy/hyp/ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23Merge tag 'vfio-ccw-20190717-2' of ↵Heiko Carstens
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into fixes Fixes in vfio-ccw for older and newer issues.
2019-07-23s390/qdio: restrict QAOB usage to IQD unicast queuesJulian Wiedmann
The IQD mcast queue doesn't support QAOB mode, so skip the qdio_enable_async_operation() setup call for this queue. This avoids the allocation of an unneeded QAOB pointer array, and sets up q->use_cq properly so that drivers are prohibited from using QAOBs for mcast traffic. Take this opportunity to streamline the q->use_cq and aob != 0 checks. The path to qdio_siga_output() is straight-forward, we don't need to worry about being called with bad operands. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390/qdio: add sanity checks to the fast-requeue pathJulian Wiedmann
If the device driver were to send out a full queue's worth of SBALs, current code would end up discovering the last of those SBALs as PRIMED and erroneously skip the SIGA-w. This immediately stalls the queue. Add a check to not attempt fast-requeue in this case. While at it also make sure that the state of the previous SBAL was successfully extracted before inspecting it. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23s390: enable detection of kernel version from bzImageVasily Gorbik
Extend "parmarea" to include an offset of the version string, which is stored as 8-byte big endian value. To retrieve version string from bzImage reliably, one should check the presence of "S390EP" ascii string at 0x10008 (available since v3.2), then read the version string offset from 0x10428 (which has been 0 since v3.2 up to now). The string is null terminated. Could be retrieved with the following "file" command magic (requires file v5.34): 8 string \x02\x00\x00\x18\x60\x00\x00\x50\x02\x00\x00\x68\x60\x00\x00\x50\x40\x40\x40\x40\x40\x40\x40\x40 Linux S390 >0x10008 string S390EP >>0x10428 bequad >0 >>>(0x10428.Q) string >\0 \b, version %s Reported-by: Petr Tesarik <ptesarik@suse.com> Suggested-by: Petr Tesarik <ptesarik@suse.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23iommu/iova: Fix compilation error with !CONFIG_IOMMU_IOVAJoerg Roedel
The stub function for !CONFIG_IOMMU_IOVA needs to be 'static inline'. Fixes: effa467870c76 ('iommu/vt-d: Don't queue_iova() if there is no flush queue') Signed-off-by: Joerg Roedel <jroedel@suse.de>
2019-07-23cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init()Wen Yang
The cpu variable is still being used in the of_get_property() call after the of_node_put() call, which may result in use-after-free. Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak") Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-23int340X/processor_thermal_device: Fix proc_thermal_rapl_remove()Rafael J. Wysocki
Passing 0 to cpuhp_remove_state() triggers the BUG_ON() in __cpuhp_remove_state_cpuslocked() and the argument passed to powercap_unregister_control_type() is expected to be a valid pointer, so avoid calling these functions with incorrect arguments from proc_thermal_rapl_remove(). Fixes: 555c45fe0d04 ("int340X/processor_thermal_device: add support for MMIO RAPL") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com>
2019-07-22scsi: core: fix the dma_max_mapping_size callChristoph Hellwig
We should only call dma_max_mapping_size for devices that have a DMA mask set, otherwise we can run into a NULL pointer dereference that will crash the system. Also we need to do right shift to get the sectors from the size in bytes, not a left shift. Fixes: bdd17bdef7d8 ("scsi: core: take the DMA max mapping size into account") Reported-by: Bart Van Assche <bvanassche@acm.org> Reported-by: Ming Lei <tom.leiming@gmail.com> Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-22scsi: fdomain: fix building pcmcia front-endArnd Bergmann
We get a warning when CONFIG_SCSI_LOWLEVEL is disabled here: WARNING: unmet direct dependencies detected for SCSI_FDOMAIN Depends on [n]: SCSI_LOWLEVEL [=n] && SCSI [=y] Selected by [m]: - PCMCIA_FDOMAIN [=m] && SCSI_LOWLEVEL_PCMCIA [=y] && SCSI [=y] && PCMCIA [=y] && m && MODULES [=y] Move all of SCSI_LOWLEVEL_PCMCIA inside of the existing SCSI_LOWLEVEL section. Very few people use the PCMCIA support these days, and they likely don't mind having to turn on SCSI_LOWLEVEL as well. This way we avoid the link error and get a more sensible structure. Fixes: 7d47fa065e62 ("scsi: fdomain: Add PCMCIA support") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-22riscv: dts: Add DT node for SiFive FU540 Ethernet controller driverYash Shah
DT node for SiFive FU540-C000 GEMGXL Ethernet controller driver added Signed-off-by: Yash Shah <yash.shah@sifive.com> Reviewed-by: Sagar Kadam <sagar.kadam@sifive.com> Cc: Andrew Lunn <andrew@lunn.ch> [paul.walmsley@sifive.com: changed "phy1" to "phy0" at Andrew Lunn's suggestion] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-07-22scsi: target: cxgbit: add support for IEEE_8021QAZ_APP_SEL_STREAM selectorVarun Prakash
IEEE_8021QAZ_APP_SEL_STREAM is a valid selector for iSCSI connections, so add code to use IEEE_8021QAZ_APP_SEL_STREAM selector to get priority mask. Signed-off-by: Varun Prakash <varun@chelsio.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-22doc:it_IT: translations in process/Federico Vaga
This patch add translations for: - programming-languages - kernel-docs (It is better to not translate this since English is a requirement to get something useful out of it) Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-07-22docs/vm: transhuge: fix typo in madvise referenceJeremy Cline
Fix an off-by-one typo in the transparent huge pages admin documentation. Signed-off-by: Jeremy Cline <jcline@redhat.com> Acked-by: Mike Rapoport <rppt@linux.ibm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-07-22drm/amdgpu/smu: move fan rpm query into the asic specific codeAlex Deucher
On vega20, there is an SMU message to query it. On navi, it's fetched from the metrics table. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/amd/powerplay: custom peak clock freq for navi10Kevin Wang
v2: add function smu_default_set_performance_level as default dpm level handler. change function name smu_set_performance_level to smu_asic_set_performance_level v1: 1.NAVI10_PEAK_SCLK_XTX 1830 Mhz 2.NAVI10_PEAK_SCLK_XT 1755 Mhz 3.NAVI10_PEAK_SCLK_XL 1625 Mhz Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Jack Gui <Jack.Gui@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22riscv: include generic support for MSI irqdomainsWesley Terpstra
Some RISC-V systems include PCIe host controllers that support PCIe message-signaled interrupts. For this to work on Linux, we need to enable PCI_MSI_IRQ_DOMAIN and define struct msi_alloc_info. Support for the latter is enabled by including the architecture-generic msi.h include. Signed-off-by: Wesley Terpstra <wesley@sifive.com> [paul.walmsley@sifive.com: split initial patch into one arch/riscv patch and one drivers/pci patch] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-07-22drm: silence variable 'conn' set but not usedQian Cai
The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-cai@lca.pw
2019-07-22MAINTAINERS: Add Paul as a RISC-V maintainerPalmer Dabbelt
The RISC-V port has grown significantly over the past year. Paul's been helping out for a while ago. We agreed in person that he'd take over collecting the patches and submitting the PRs, but it looks like I forgot to make it official. Signed-off-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-07-22Merge branch 'pdf_fixes_v1' of https://git.linuxtv.org/mchehab/experimental ↵Jonathan Corbet
into mauro Bring in a set of post-thrashup fixes from Mauro.
2019-07-22doc:it_IT: rephrase statementFederico Vaga
The statement sounds more like a literal translation Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-07-22doc:it_IT: align translation to mainlineFederico Vaga
The patch translates the following patches in Italian: d9d7c0c497b8 docs: Note that :c:func: should no longer be used 83e8b971f81c sphinx.rst: Add note about code snippets embedded in the text cca5e0b8a430 Documentation: PGP: update for newer HW devices Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-07-22Merge tag 'v5.3-rc1' into docs-nextJonathan Corbet
Pull in all of the massive docs changes from elsewhere.
generated by cgit (git 2.34.1) at 2025-09-15 06:45:12 +0000