- Linux-stable-mirror - lists.linaro.org

Patch "blk-mq: fix kernel oops in blk_mq_tag_idle()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled blk-mq: fix kernel oops in blk_mq_tag_idle() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Ming Lei <ming.lei(a)redhat.com> Date: Tue, 9 Jan 2018 21:28:29 +0800 Subject: blk-mq: fix kernel oops in blk_mq_tag_idle() From: Ming Lei <ming.lei(a)redhat.com> [ Upstream commit 8ab0b7dc73e1b3e2987d42554b2bff503f692772 ] HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(), then we need to check it before calling blk_mq_tag_idle(), otherwise the following kernel oops can be triggered, so fix it by checking if the hw queue is unmapped since it doesn't make sense to idle the tags any more after hw queues are unmapped. [ 440.771298] Workqueue: nvme-wq nvme_rdma_del_ctrl_work [nvme_rdma] [ 440.779104] task: ffff894bae755ee0 ti: ffff893bf9bc8000 task.ti: ffff893bf9bc8000 [ 440.788359] RIP: 0010:[<ffffffffb730e2b4>] [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 440.798697] RSP: 0018:ffff893bf9bcbd10 EFLAGS: 00010286 [ 440.805538] RAX: 0000000000000000 RBX: ffff895bb131dc00 RCX: 000000000000011f [ 440.814426] RDX: 00000000ffffffff RSI: 0000000000000120 RDI: ffff895bb131dc00 [ 440.823301] RBP: ffff893bf9bcbd10 R08: 000000000001b860 R09: 4a51d361c00c0000 [ 440.832193] R10: b5907f32b4cc7003 R11: ffffd6cabfb57000 R12: ffff894bafd1e008 [ 440.841091] R13: 0000000000000001 R14: ffff895baf770000 R15: 0000000000000080 [ 440.849988] FS: 0000000000000000(0000) GS:ffff894bbdcc0000(0000) knlGS:0000000000000000 [ 440.859955] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 440.867274] CR2: 0000000000000008 CR3: 000000103d098000 CR4: 00000000001407e0 [ 440.876169] Call Trace: [ 440.879818] [<ffffffffb7309d68>] blk_mq_exit_hctx+0xd8/0xe0 [ 440.887051] [<ffffffffb730dc40>] blk_mq_free_queue+0xf0/0x160 [ 440.894465] [<ffffffffb72ff679>] blk_cleanup_queue+0xd9/0x150 [ 440.901881] [<ffffffffc08a802b>] nvme_ns_remove+0x5b/0xb0 [nvme_core] [ 440.910068] [<ffffffffc08a811b>] nvme_remove_namespaces+0x3b/0x60 [nvme_core] [ 440.919026] [<ffffffffc08b817b>] __nvme_rdma_remove_ctrl+0x2b/0xb0 [nvme_rdma] [ 440.928079] [<ffffffffc08b8237>] nvme_rdma_del_ctrl_work+0x17/0x20 [nvme_rdma] [ 440.937126] [<ffffffffb70ab58a>] process_one_work+0x17a/0x440 [ 440.944517] [<ffffffffb70ac3a8>] worker_thread+0x278/0x3c0 [ 440.951607] [<ffffffffb70ac130>] ? manage_workers.isra.24+0x2a0/0x2a0 [ 440.959760] [<ffffffffb70b352f>] kthread+0xcf/0xe0 [ 440.966055] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.973715] [<ffffffffb76d8658>] ret_from_fork+0x58/0x90 [ 440.980586] [<ffffffffb70b3460>] ? insert_kthread_work+0x40/0x40 [ 440.988229] Code: 5b 41 5c 5d c3 66 90 0f 1f 44 00 00 48 8b 87 20 01 00 00 f0 0f ba 77 40 01 19 d2 85 d2 75 08 c3 0f 1f 80 00 00 00 00 55 48 89 e5 <f0> ff 48 08 48 8d 78 10 e8 7f 0f 05 00 5d c3 0f 1f 00 66 2e 0f [ 441.011620] RIP [<ffffffffb730e2b4>] __blk_mq_tag_idle+0x24/0x40 [ 441.019301] RSP <ffff893bf9bcbd10> [ 441.024052] CR2: 0000000000000008 Reported-by: Zhang Yi <yizhan(a)redhat.com> Tested-by: Zhang Yi <yizhan(a)redhat.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/blk-mq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1634,7 +1634,8 @@ static void blk_mq_exit_hctx(struct requ { unsigned flush_start_tag = set->queue_depth; - blk_mq_tag_idle(hctx); + if (blk_mq_hw_queue_mapped(hctx)) + blk_mq_tag_idle(hctx); if (set->ops->exit_request) set->ops->exit_request(set->driver_data, Patches currently in stable-queue which might be from ming.lei(a)redhat.com are queue-4.4/blk-mq-fix-kernel-oops-in-blk_mq_tag_idle.patch queue-4.4/fix-loop-device-flush-before-configure-v3.patch

7 years, 8 months

1
0
0 0

Patch "bio-integrity: Do not allocate integrity context for bio w/o data" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bio-integrity: Do not allocate integrity context for bio w/o data to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bio-integrity-do-not-allocate-integrity-context-for-bio-w-o-data.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Dmitry Monakhov <dmonakhov(a)openvz.org> Date: Wed, 10 May 2017 19:20:44 +0400 Subject: bio-integrity: Do not allocate integrity context for bio w/o data From: Dmitry Monakhov <dmonakhov(a)openvz.org> [ Upstream commit 3116a23bb30272d74ea81baf5d0ee23f602dd15b ] If bio has no data, such as ones from blkdev_issue_flush(), then we have nothing to protect. This patch prevent bugon like follows: kfree_debugcheck: out of range ptr ac1fa1d106742a5ah kernel BUG at mm/slab.c:2773! invalid opcode: 0000 [#1] SMP Modules linked in: bcache CPU: 0 PID: 4428 Comm: xfs_io Tainted: G W 4.11.0-rc4-ext4-00041-g2ef0043-dirty #43 Hardware name: Virtuozzo KVM, BIOS seabios-1.7.5-11.vz7.4 04/01/2014 task: ffff880137786440 task.stack: ffffc90000ba8000 RIP: 0010:kfree_debugcheck+0x25/0x2a RSP: 0018:ffffc90000babde0 EFLAGS: 00010082 RAX: 0000000000000034 RBX: ac1fa1d106742a5a RCX: 0000000000000007 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88013f3ccb40 RBP: ffffc90000babde8 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000fcb76420 R11: 00000000725172ed R12: 0000000000000282 R13: ffffffff8150e766 R14: ffff88013a145e00 R15: 0000000000000001 FS: 00007fb09384bf40(0000) GS:ffff88013f200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0172f9e40 CR3: 0000000137fa9000 CR4: 00000000000006f0 Call Trace: kfree+0xc8/0x1b3 bio_integrity_free+0xc3/0x16b bio_free+0x25/0x66 bio_put+0x14/0x26 blkdev_issue_flush+0x7a/0x85 blkdev_fsync+0x35/0x42 vfs_fsync_range+0x8e/0x9f vfs_fsync+0x1c/0x1e do_fsync+0x31/0x4a SyS_fsync+0x10/0x14 entry_SYSCALL_64_fastpath+0x1f/0xc2 Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Dmitry Monakhov <dmonakhov(a)openvz.org> Signed-off-by: Jens Axboe <axboe(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/bio-integrity.c | 3 +++ 1 file changed, 3 insertions(+) --- a/block/bio-integrity.c +++ b/block/bio-integrity.c @@ -175,6 +175,9 @@ bool bio_integrity_enabled(struct bio *b if (!bio_is_rw(bio)) return false; + if (!bio_sectors(bio)) + return false; + /* Already protected? */ if (bio_integrity(bio)) return false; Patches currently in stable-queue which might be from dmonakhov(a)openvz.org are queue-4.4/bio-integrity-do-not-allocate-integrity-context-for-bio-w-o-data.patch

7 years, 8 months

1
0
0 0

Patch "bcache: stop writeback thread after detaching" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: stop writeback thread after detaching to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-stop-writeback-thread-after-detaching.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Tang Junhui <tang.junhui(a)zte.com.cn> Date: Mon, 8 Jan 2018 12:21:19 -0800 Subject: bcache: stop writeback thread after detaching From: Tang Junhui <tang.junhui(a)zte.com.cn> [ Upstream commit 8d29c4426b9f8afaccf28de414fde8a722b35fdf ] Currently, when a cached device detaching from cache, writeback thread is not stopped, and writeback_rate_update work is not canceled. For example, after the following command: echo 1 >/sys/block/sdb/bcache/detach you can still see the writeback thread. Then you attach the device to the cache again, bcache will create another writeback thread, for example, after below command: echo ba0fb5cd-658a-4533-9806-6ce166d883b9 > /sys/block/sdb/bcache/attach then you will see 2 writeback threads. This patch stops writeback thread and cancels writeback_rate_update work when cached device detaching from cache. Compare with patch v1, this v2 patch moves code down into the register lock for safety in case of any future changes as Coly and Mike suggested. [edit by mlyle: commit log spelling/formatting] Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/super.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -890,6 +890,12 @@ static void cached_dev_detach_finish(str mutex_lock(&bch_register_lock); + cancel_delayed_work_sync(&dc->writeback_rate_update); + if (!IS_ERR_OR_NULL(dc->writeback_thread)) { + kthread_stop(dc->writeback_thread); + dc->writeback_thread = NULL; + } + memset(&dc->sb.set_uuid, 0, 16); SET_BDEV_STATE(&dc->sb, BDEV_STATE_NONE); Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-4.4/bcache-segregate-flash-only-volume-write-streams.patch queue-4.4/bcache-stop-writeback-thread-after-detaching.patch

7 years, 8 months

1
0
0 0

Patch "bcache: segregate flash only volume write streams" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bcache: segregate flash only volume write streams to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bcache-segregate-flash-only-volume-write-streams.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Tang Junhui <tang.junhui(a)zte.com.cn> Date: Mon, 8 Jan 2018 12:21:21 -0800 Subject: bcache: segregate flash only volume write streams From: Tang Junhui <tang.junhui(a)zte.com.cn> [ Upstream commit 4eca1cb28d8b0574ca4f1f48e9331c5f852d43b9 ] In such scenario that there are some flash only volumes , and some cached devices, when many tasks request these devices in writeback mode, the write IOs may fall to the same bucket as bellow: | cached data | flash data | cached data | cached data| flash data| then after writeback of these cached devices, the bucket would be like bellow bucket: | free | flash data | free | free | flash data | So, there are many free space in this bucket, but since data of flash only volumes still exists, so this bucket cannot be reclaimable, which would cause waste of bucket space. In this patch, we segregate flash only volume write streams from cached devices, so data from flash only volumes and cached devices can store in different buckets. Compare to v1 patch, this patch do not add a additionally open bucket list, and it is try best to segregate flash only volume write streams from cached devices, sectors of flash only volumes may still be mixed with dirty sectors of cached device, but the number is very small. [mlyle: fixed commit log formatting, permissions, line endings] Signed-off-by: Tang Junhui <tang.junhui(a)zte.com.cn> Reviewed-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/bcache/alloc.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) --- a/drivers/md/bcache/alloc.c +++ b/drivers/md/bcache/alloc.c @@ -514,15 +514,21 @@ struct open_bucket { /* * We keep multiple buckets open for writes, and try to segregate different - * write streams for better cache utilization: first we look for a bucket where - * the last write to it was sequential with the current write, and failing that - * we look for a bucket that was last used by the same task. + * write streams for better cache utilization: first we try to segregate flash + * only volume write streams from cached devices, secondly we look for a bucket + * where the last write to it was sequential with the current write, and + * failing that we look for a bucket that was last used by the same task. * * The ideas is if you've got multiple tasks pulling data into the cache at the * same time, you'll get better cache utilization if you try to segregate their * data and preserve locality. * - * For example, say you've starting Firefox at the same time you're copying a + * For example, dirty sectors of flash only volume is not reclaimable, if their + * dirty sectors mixed with dirty sectors of cached device, such buckets will + * be marked as dirty and won't be reclaimed, though the dirty data of cached + * device have been written back to backend device. + * + * And say you've starting Firefox at the same time you're copying a * bunch of files. Firefox will likely end up being fairly hot and stay in the * cache awhile, but the data you copied might not be; if you wrote all that * data to the same buckets it'd get invalidated at the same time. @@ -539,7 +545,10 @@ static struct open_bucket *pick_data_buc struct open_bucket *ret, *ret_task = NULL; list_for_each_entry_reverse(ret, &c->data_buckets, list) - if (!bkey_cmp(&ret->key, search)) + if (UUID_FLASH_ONLY(&c->uuids[KEY_INODE(&ret->key)]) != + UUID_FLASH_ONLY(&c->uuids[KEY_INODE(search)])) + continue; + else if (!bkey_cmp(&ret->key, search)) goto found; else if (ret->last_write_point == write_point) ret_task = ret; Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are queue-4.4/bcache-segregate-flash-only-volume-write-streams.patch queue-4.4/bcache-stop-writeback-thread-after-detaching.patch

7 years, 8 months

1
0
0 0

Patch "ath5k: fix memory leak on buf on failed eeprom read" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ath5k: fix memory leak on buf on failed eeprom read to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Colin Ian King <colin.king(a)canonical.com> Date: Wed, 3 May 2017 15:26:00 +0100 Subject: ath5k: fix memory leak on buf on failed eeprom read From: Colin Ian King <colin.king(a)canonical.com> [ Upstream commit 8fed6823e06e43ee9cf7c0ffecec2f9111ce6201 ] The AR5K_EEPROM_READ macro returns with -EIO if a read error occurs causing a memory leak on the allocated buffer buf. Fix this by explicitly calling ath5k_hw_nvram_read and exiting on the via the freebuf label that performs the necessary free'ing of buf when a read error occurs. Detected by CoverityScan, CID#1248782 ("Resource Leak") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/ath/ath5k/debug.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/net/wireless/ath/ath5k/debug.c +++ b/drivers/net/wireless/ath/ath5k/debug.c @@ -939,7 +939,10 @@ static int open_file_eeprom(struct inode } for (i = 0; i < eesize; ++i) { - AR5K_EEPROM_READ(i, val); + if (!ath5k_hw_nvram_read(ah, i, &val)) { + ret = -EIO; + goto freebuf; + } buf[i] = val; } Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.4/wl1251-check-return-from-call-to-wl1251_acx_arp_ip_filter.patch queue-4.4/netxen_nic-set-rcode-to-the-return-status-from-the-call-to-netxen_issue_cmd.patch queue-4.4/btrfs-fix-incorrect-error-return-ret-being-passed-to-mapping_set_error.patch queue-4.4/ath5k-fix-memory-leak-on-buf-on-failed-eeprom-read.patch

7 years, 8 months

1
0
0 0

Patch "ata: libahci: properly propagate return value of platform_get_irq()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ata: libahci: properly propagate return value of platform_get_irq() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Date: Tue, 16 May 2017 14:06:12 +0200 Subject: ata: libahci: properly propagate return value of platform_get_irq() From: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> [ Upstream commit c034640a32f8456018d9c8c83799ead683046b95 ] When platform_get_irq() fails, it returns an error code, which libahci_platform and replaces it by -EINVAL. This commit fixes that by propagating the error code. It fixes the situation where platform_get_irq() returns -EPROBE_DEFER because the interrupt controller is not available yet, and generally looks like the right thing to do. We pay attention to not show the "no irq" message when we are in an EPROBE_DEFER situation, because the driver probing will be retried later on, once the interrupt controller becomes available to provide the interrupt. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com> Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/ata/libahci_platform.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/ata/libahci_platform.c +++ b/drivers/ata/libahci_platform.c @@ -514,8 +514,9 @@ int ahci_platform_init_host(struct platf irq = platform_get_irq(pdev, 0); if (irq <= 0) { - dev_err(dev, "no irq\n"); - return -EINVAL; + if (irq != -EPROBE_DEFER) + dev_err(dev, "no irq\n"); + return irq; } hpriv->irq = irq; Patches currently in stable-queue which might be from thomas.petazzoni(a)free-electrons.com are queue-4.4/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch

7 years, 8 months

1
0
0 0

Patch "async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: async_tx-fix-dma_prep_fence-usage-in-do_async_gen_syndrome.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Anup Patel <anup.patel(a)broadcom.com> Date: Mon, 15 May 2017 10:34:53 +0530 Subject: async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome() From: Anup Patel <anup.patel(a)broadcom.com> [ Upstream commit baae03a0e2497f49704628fd0aaf993cf98e1b99 ] The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output of Tx descriptor is to be used by next/dependent Tx descriptor. The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome() when calling dma->device_prep_dma_pq() under following conditions: 1. ASYNC_TX_FENCE not set in submit->flags 2. DMA_PREP_FENCE not set in dma_flags 3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags) This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking inspiration from do_async_xor() implementation. Signed-off-by: Anup Patel <anup.patel(a)broadcom.com> Reviewed-by: Ray Jui <ray.jui(a)broadcom.com> Reviewed-by: Scott Branden <scott.branden(a)broadcom.com> Acked-by: Dan Williams <dan.j.williams(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/async_tx/async_pq.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/crypto/async_tx/async_pq.c +++ b/crypto/async_tx/async_pq.c @@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *c dma_addr_t dma_dest[2]; int src_off = 0; - if (submit->flags & ASYNC_TX_FENCE) - dma_flags |= DMA_PREP_FENCE; - while (src_cnt > 0) { submit->flags = flags_orig; pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags)); @@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *c if (cb_fn_orig) dma_flags |= DMA_PREP_INTERRUPT; } + if (submit->flags & ASYNC_TX_FENCE) + dma_flags |= DMA_PREP_FENCE; /* Drivers force forward progress in case they can not provide * a descriptor Patches currently in stable-queue which might be from anup.patel(a)broadcom.com are queue-4.4/async_tx-fix-dma_prep_fence-usage-in-do_async_gen_syndrome.patch

7 years, 8 months

1
0
0 0

Patch "ASoC: rsnd: SSI PIO adjust to 24bit mode" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: rsnd: SSI PIO adjust to 24bit mode to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-rsnd-ssi-pio-adjust-to-24bit-mode.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Date: Wed, 24 May 2017 01:17:10 +0000 Subject: ASoC: rsnd: SSI PIO adjust to 24bit mode From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> [ Upstream commit 7819a942de7b993771bd9377babc80485fe7606b ] commit 90431eb49bff ("ASoC: rsnd: don't use PDTA bit for 24bit on SSI") fixups 24bit mode data alignment, but PIO was not cared. This patch fixes PIO mode 24bit data alignment Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sh/rcar/ssi.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) --- a/sound/soc/sh/rcar/ssi.c +++ b/sound/soc/sh/rcar/ssi.c @@ -453,6 +453,13 @@ static void __rsnd_ssi_interrupt(struct struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io); u32 *buf = (u32 *)(runtime->dma_area + rsnd_dai_pointer_offset(io, 0)); + int shift = 0; + + switch (runtime->sample_bits) { + case 32: + shift = 8; + break; + } /* * 8/16/32 data can be assesse to TDR/RDR register @@ -460,9 +467,9 @@ static void __rsnd_ssi_interrupt(struct * see rsnd_ssi_init() */ if (rsnd_io_is_play(io)) - rsnd_mod_write(mod, SSITDR, *buf); + rsnd_mod_write(mod, SSITDR, (*buf) << shift); else - *buf = rsnd_mod_read(mod, SSIRDR); + *buf = (rsnd_mod_read(mod, SSIRDR) >> shift); elapsed = rsnd_dai_pointer_update(io, sizeof(*buf)); } Patches currently in stable-queue which might be from kuninori.morimoto.gx(a)renesas.com are queue-4.4/asoc-rsnd-ssi-pio-adjust-to-24bit-mode.patch

7 years, 8 months

1
0
0 0

Patch "ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()'" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sat, 6 Jan 2018 21:18:24 +0100 Subject: ASoC: Intel: sst: Fix the return value of 'sst_send_byte_stream_mrfld()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit eaadb1caa966a91128297b754e90b7c92b350a00 ] In some error handling paths, an error code is assiegned to 'ret'. However, the function always return 0. Fix it and return the error code if such an error paths is taken. Fixes: 3d9ff34622ba ("ASoC: Intel: sst: add stream operations") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/atom/sst/sst_stream.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/sound/soc/intel/atom/sst/sst_stream.c +++ b/sound/soc/intel/atom/sst/sst_stream.c @@ -221,7 +221,7 @@ int sst_send_byte_stream_mrfld(struct in sst_free_block(sst_drv_ctx, block); out: test_and_clear_bit(pvt_id, &sst_drv_ctx->pvt_id); - return 0; + return ret; } /* Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.4/cpuidle-dt-add-missing-of_node_put.patch queue-4.4/edac-mv64x60-fix-an-error-handling-path.patch queue-4.4/smb2-fix-share-type-handling.patch queue-4.4/asoc-intel-sst-fix-the-return-value-of-sst_send_byte_stream_mrfld.patch

7 years, 8 months

1
0
0 0

Patch "ASoC: Intel: cht_bsw_rt5645: Analog Mic support" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ASoC: Intel: cht_bsw_rt5645: Analog Mic support to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: asoc-intel-cht_bsw_rt5645-analog-mic-support.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Apr 10 10:31:53 CEST 2018 From: Hans de Goede <hdegoede(a)redhat.com> Date: Tue, 2 Jan 2018 19:53:14 +0100 Subject: ASoC: Intel: cht_bsw_rt5645: Analog Mic support From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit b70b309950418437bbd2a30afd169c4f09dee3e5 ] Various Cherry Trail boards with a rt5645 codec have an analog mic connected to IN2P + IN2N. The mic on this boards also needs micbias to be enabled, on some boards micbias1 is used and on others micbias2, so we enable both. This commit adds a new "Int Analog Mic" DAPM widget for this, so that we do not end up enabling micbias on boards with a digital mic which uses the already present "Int Mic" widget. Some existing UCM files already refer to "Int Mic" for their "Internal Analog Microphones" SectionDevice, but these don't work anyways since they enable the RECMIX BST1 Switch instead of the BST2 switch. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/intel/boards/cht_bsw_rt5645.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -96,6 +96,7 @@ static const struct snd_soc_dapm_widget SND_SOC_DAPM_HP("Headphone", NULL), SND_SOC_DAPM_MIC("Headset Mic", NULL), SND_SOC_DAPM_MIC("Int Mic", NULL), + SND_SOC_DAPM_MIC("Int Analog Mic", NULL), SND_SOC_DAPM_SPK("Ext Spk", NULL), SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, platform_clock_control, SND_SOC_DAPM_POST_PMD), @@ -106,6 +107,8 @@ static const struct snd_soc_dapm_route c {"IN1N", NULL, "Headset Mic"}, {"DMIC L1", NULL, "Int Mic"}, {"DMIC R1", NULL, "Int Mic"}, + {"IN2P", NULL, "Int Analog Mic"}, + {"IN2N", NULL, "Int Analog Mic"}, {"Headphone", NULL, "HPOL"}, {"Headphone", NULL, "HPOR"}, {"Ext Spk", NULL, "SPOL"}, @@ -119,6 +122,9 @@ static const struct snd_soc_dapm_route c {"Headphone", NULL, "Platform Clock"}, {"Headset Mic", NULL, "Platform Clock"}, {"Int Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "Platform Clock"}, + {"Int Analog Mic", NULL, "micbias1"}, + {"Int Analog Mic", NULL, "micbias2"}, {"Ext Spk", NULL, "Platform Clock"}, }; @@ -147,6 +153,7 @@ static const struct snd_kcontrol_new cht SOC_DAPM_PIN_SWITCH("Headphone"), SOC_DAPM_PIN_SWITCH("Headset Mic"), SOC_DAPM_PIN_SWITCH("Int Mic"), + SOC_DAPM_PIN_SWITCH("Int Analog Mic"), SOC_DAPM_PIN_SWITCH("Ext Spk"), }; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.4/ata-libahci-properly-propagate-return-value-of-platform_get_irq.patch queue-4.4/asoc-intel-cht_bsw_rt5645-analog-mic-support.patch

7 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror