September 2018 - Linux-stable-mirror

[PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

by Daniel Vetter

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. As a stop-gap plug this problem by demoting nonblocking commits which might cause issues by including CRTCs not in the original request to blocking commits. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568 Cc: Daniel Stone <daniel(a)fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.co.uk> Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++--- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index d5cefb1cb2a2..058512f14772 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -2018,15 +2018,43 @@ EXPORT_SYMBOL(drm_atomic_commit); int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; - int ret; + unsigned requested_crtc = 0; + unsigned affected_crtc = 0; + struct drm_crtc *crtc; + struct drm_crtc_state *crtc_state; + bool nonblocking = true; + int ret, i; + + /* + * For commits that allow modesets drivers can add other CRTCs to the + * atomic commit, e.g. when they need to reallocate global resources. + * + * But when userspace also requests a nonblocking commit then userspace + * cannot know that the commit affects other CRTCs, which can result in + * spurious EBUSY failures. Until we have better uapi plug this by + * demoting such commits to blocking mode. + */ + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + requested_crtc |= drm_crtc_mask(crtc); ret = drm_atomic_check_only(state); if (ret) return ret; - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + for_each_new_crtc_in_state(state, crtc, crtc_state, i) + affected_crtc |= drm_crtc_mask(crtc); + + if (affected_crtc != requested_crtc) { + /* adding other CRTC is only allowed for modeset commits */ + WARN_ON(state->allow_modeset); + + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state); + nonblocking = false; + } else { + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); + } - return config->funcs->atomic_commit(state->dev, state, true); + return config->funcs->atomic_commit(state->dev, state, nonblocking); } EXPORT_SYMBOL(drm_atomic_nonblocking_commit); -- 2.18.0

3 years, 6 months

3
11
0 0

[PATCH] [Patch v2] usbtv: Fix refcounting mixup

by Oliver Neukum

The premature free in the error path is blocked by V4L refcounting, not USB refcounting. Thanks to Ben Hutchings for review. [v2] corrected attributions Signed-off-by: Oliver Neukum <oneukum(a)suse.com> Fixes: 50e704453553 ("media: usbtv: prevent double free in error case") CC: stable(a)vger.kernel.org Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- drivers/media/usb/usbtv/usbtv-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c index 5095c380b2c1..4a03c4d66314 100644 --- a/drivers/media/usb/usbtv/usbtv-core.c +++ b/drivers/media/usb/usbtv/usbtv-core.c @@ -113,7 +113,8 @@ static int usbtv_probe(struct usb_interface *intf, usbtv_audio_fail: /* we must not free at this point */ - usb_get_dev(usbtv->udev); + v4l2_device_get(&usbtv->v4l2_dev); + /* this will undo the v4l2_device_get() */ usbtv_video_free(usbtv); usbtv_video_fail: -- 2.13.6

3 years, 6 months

3
7
0 0

[PATCH 1/2] i2c: i801: Fix runtime PM

by Jarkko Nikula

Commit 9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM") nullified the runtime PM suspend/resume callback pointers while keeping the runtime PM enabled. This causes that device stays in D0 power state and sysfs /sys/bus/pci/devices/.../power/runtime_status shows "error" when runtime PM framework attempts to autosuspend the device. This is due PCI bus runtime PM which checks for driver runtime PM callbacks and returns with -ENOSYS if they are not set. Fix this by having a shared dummy runtime PM callback that returns with success. Fixes: a9c8088c7988 ("i2c: i801: Don't restore config registers on runtime PM") Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> --- drivers/i2c/busses/i2c-i801.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c index aa726607645e..3747484c2669 100644 --- a/drivers/i2c/busses/i2c-i801.c +++ b/drivers/i2c/busses/i2c-i801.c @@ -1731,7 +1731,20 @@ static int i801_resume(struct device *dev) } #endif -static SIMPLE_DEV_PM_OPS(i801_pm_ops, i801_suspend, i801_resume); +static int __maybe_unused i801_runtime_nop(struct device *dev) +{ + /* + * PCI core expects runtime PM suspend/resume callbacks return + * successfully before really suspending/resuming the device. + * Have a shared dummy callback that returns with success. + */ + return 0; +} + +static const struct dev_pm_ops i801_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(i801_suspend, i801_resume) + SET_RUNTIME_PM_OPS(i801_runtime_nop, i801_runtime_nop, NULL) +}; static struct pci_driver i801_driver = { .name = "i801_smbus", -- 2.18.0

3 years, 7 months

5
6
0 0

[PATCH v2 1/3] fs/fuse, splice_write: Don't access pipe->buffers without pipe_lock()

by Andrey Ryabinin

fuse_dev_splice_write() reads pipe->buffers to determine the size of 'bufs' array before taking the pipe_lock(). This is not safe as another thread might change the 'pipe->buffers' between the allocation and taking the pipe_lock(). So we end up with too small 'bufs' array. Move the bufs allocations inside pipe_lock()/pipe_unlock() to fix this. Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: <stable(a)vger.kernel.org> --- fs/fuse/dev.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c index c6b88fa85e2e..702592cce546 100644 --- a/fs/fuse/dev.c +++ b/fs/fuse/dev.c @@ -1944,12 +1944,15 @@ static ssize_t fuse_dev_splice_write(struct pipe_inode_info *pipe, if (!fud) return -EPERM; + pipe_lock(pipe); + bufs = kmalloc_array(pipe->buffers, sizeof(struct pipe_buffer), GFP_KERNEL); - if (!bufs) + if (!bufs) { + pipe_unlock(pipe); return -ENOMEM; + } - pipe_lock(pipe); nbuf = 0; rem = 0; for (idx = 0; idx < pipe->nrbufs && rem < len; idx++) -- 2.16.4

4 years, 10 months

2
2
0 0

[Linux-stable-mirror] [PATCH] drbd: fix discard_zeroes_if_aligned regression

by Eric Wheeler

From: Eric Wheeler <git(a)linux.ewheeler.net> According to drbd.conf documentation, "To not break established and expected behaviour, and suddenly cause fstrim on thin-provisioned LVs to run out-of-space instead of freeing up space, the default value is yes." This behavior regressed in the REQ_OP_WRITE_ZEROES refactor near 45c21793 drbd: implement REQ_OP_WRITE_ZEROES 0dbed96 drbd: make intelligent use of blkdev_issue_zeroout which caused dm-thin backed DRBD volumes to zero blocks and run out of space instead of passing discard to the backing device as defined by the discard_zeroes_if_aligned option. A helper function could reduce code duplication. Signed-off-by: Eric Wheeler <drbd(a)linux.ewheeler.net> Cc: <stable(a)vger.kernel.org> # 4.14 --- drivers/block/drbd/drbd_receiver.c | 22 ++++++++++++++++++++-- drivers/block/drbd/drbd_req.c | 23 +++++++++++++++++++++-- 2 files changed, 41 insertions(+), 4 deletions(-) diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c index 62a902f..58f0e43 100644 --- a/drivers/block/drbd/drbd_receiver.c +++ b/drivers/block/drbd/drbd_receiver.c @@ -1507,9 +1507,27 @@ void drbd_bump_write_ordering(struct drbd_resource *resource, struct drbd_backin static void drbd_issue_peer_discard(struct drbd_device *device, struct drbd_peer_request *peer_req) { struct block_device *bdev = device->ldev->backing_bdev; + struct disk_conf *dc; + bool discard_zeroes_if_aligned, zeroout; - if (blkdev_issue_zeroout(bdev, peer_req->i.sector, peer_req->i.size >> 9, - GFP_NOIO, 0)) + rcu_read_lock(); + dc = rcu_dereference(device->ldev->disk_conf); + discard_zeroes_if_aligned = dc->discard_zeroes_if_aligned; + rcu_read_unlock(); + + /* Use zeroout unless discard_zeroes_if_aligned is set. + * If blkdev_issue_discard fails, then retry with blkdev_issue_zeroout. + * See also drbd_process_discard_req() in drbd_req.c. + */ + zeroout = true; + if (discard_zeroes_if_aligned && + blkdev_issue_discard(bdev, peer_req->i.sector, + peer_req->i.size >> 9, GFP_NOIO, 0) == 0) + zeroout = false; + + if (zeroout && + blkdev_issue_zeroout(bdev, peer_req->i.sector, + peer_req->i.size >> 9, GFP_NOIO, 0) != 0) peer_req->flags |= EE_WAS_ERROR; drbd_endio_write_sec_final(peer_req); diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c index de8566e..070b5e7 100644 --- a/drivers/block/drbd/drbd_req.c +++ b/drivers/block/drbd/drbd_req.c @@ -1158,9 +1158,28 @@ static int drbd_process_write_request(struct drbd_request *req) static void drbd_process_discard_req(struct drbd_request *req) { struct block_device *bdev = req->device->ldev->backing_bdev; + struct drbd_device *device = req->device; + struct disk_conf *dc; + bool discard_zeroes_if_aligned, zeroout; - if (blkdev_issue_zeroout(bdev, req->i.sector, req->i.size >> 9, - GFP_NOIO, 0)) + rcu_read_lock(); + dc = rcu_dereference(device->ldev->disk_conf); + discard_zeroes_if_aligned = dc->discard_zeroes_if_aligned; + rcu_read_unlock(); + + /* Use zeroout unless discard_zeroes_if_aligned is set. + * If blkdev_issue_discard fails, then retry with blkdev_issue_zeroout. + * See also drbd_issue_peer_discard() in drbd_receiver.c. + */ + zeroout = true; + if (discard_zeroes_if_aligned && + blkdev_issue_discard(bdev, req->i.sector, req->i.size >> 9, + GFP_NOIO, 0) == 0) + zeroout = false; + + if (zeroout && + blkdev_issue_zeroout(bdev, req->i.sector, req->i.size >> 9, + GFP_NOIO, 0) != 0) req->private_bio->bi_status = BLK_STS_IOERR; bio_endio(req->private_bio); } -- 1.8.3.1

4 years, 11 months

3
4
0 0

FAILED: patch "[PATCH] dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 432061b3da64e488be3403124a72a9250bbe96d4 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Wed, 5 Sep 2018 09:17:45 -0400 Subject: [PATCH] dm: disable CRYPTO_TFM_REQ_MAY_SLEEP to fix a GFP_KERNEL recursion deadlock There's a XFS on dm-crypt deadlock, recursing back to itself due to the crypto subsystems use of GFP_KERNEL, reported here: https://bugzilla.kernel.org/show_bug.cgi?id=200835 * dm-crypt calls crypt_convert in xts mode * init_crypt from xts.c calls kmalloc(GFP_KERNEL) * kmalloc(GFP_KERNEL) recurses into the XFS filesystem, the filesystem tries to submit some bios and wait for them, causing a deadlock Fix this by updating both the DM crypt and integrity targets to no longer use the CRYPTO_TFM_REQ_MAY_SLEEP flag, which will change the crypto allocations from GFP_KERNEL to GFP_ATOMIC, therefore they can't recurse into a filesystem. A GFP_ATOMIC allocation can fail, but init_crypt() in xts.c handles the allocation failure gracefully - it will fall back to preallocated buffer if the allocation fails. The crypto API maintainer says that the crypto API only needs to allocate memory when dealing with unaligned buffers and therefore turning CRYPTO_TFM_REQ_MAY_SLEEP off is safe (see this discussion: https://www.redhat.com/archives/dm-devel/2018-August/msg00195.html ) Cc: stable(a)vger.kernel.org Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index f266c81f396f..0481223b1deb 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -332,7 +332,7 @@ static int crypt_iv_essiv_init(struct crypt_config *cc) int err; desc->tfm = essiv->hash_tfm; - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; + desc->flags = 0; err = crypto_shash_digest(desc, cc->key, cc->key_size, essiv->salt); shash_desc_zero(desc); @@ -606,7 +606,7 @@ static int crypt_iv_lmk_one(struct crypt_config *cc, u8 *iv, int i, r; desc->tfm = lmk->hash_tfm; - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; + desc->flags = 0; r = crypto_shash_init(desc); if (r) @@ -768,7 +768,7 @@ static int crypt_iv_tcw_whitening(struct crypt_config *cc, /* calculate crc32 for every 32bit part and xor it */ desc->tfm = tcw->crc32_tfm; - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; + desc->flags = 0; for (i = 0; i < 4; i++) { r = crypto_shash_init(desc); if (r) @@ -1251,7 +1251,7 @@ static void crypt_alloc_req_skcipher(struct crypt_config *cc, * requests if driver request queue is full. */ skcipher_request_set_callback(ctx->r.req, - CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP, + CRYPTO_TFM_REQ_MAY_BACKLOG, kcryptd_async_done, dmreq_of_req(cc, ctx->r.req)); } @@ -1268,7 +1268,7 @@ static void crypt_alloc_req_aead(struct crypt_config *cc, * requests if driver request queue is full. */ aead_request_set_callback(ctx->r.req_aead, - CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP, + CRYPTO_TFM_REQ_MAY_BACKLOG, kcryptd_async_done, dmreq_of_req(cc, ctx->r.req_aead)); } diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c index 378878599466..89ccb64342de 100644 --- a/drivers/md/dm-integrity.c +++ b/drivers/md/dm-integrity.c @@ -532,7 +532,7 @@ static void section_mac(struct dm_integrity_c *ic, unsigned section, __u8 result unsigned j, size; desc->tfm = ic->journal_mac; - desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; + desc->flags = 0; r = crypto_shash_init(desc); if (unlikely(r)) { @@ -676,7 +676,7 @@ static void complete_journal_encrypt(struct crypto_async_request *req, int err) static bool do_crypt(bool encrypt, struct skcipher_request *req, struct journal_completion *comp) { int r; - skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP, + skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG, complete_journal_encrypt, comp); if (likely(encrypt)) r = crypto_skcipher_encrypt(req);

5 years

3
2
0 0

aacraid: Regression in 4.14.56 with *genirq/affinity: assign vectors to all possible CPUs*

by Paul Menzel

Dear Greg, Commit ef86f3a7 (genirq/affinity: assign vectors to all possible CPUs) added for Linux 4.14.56 causes the aacraid module to not detect the attached devices anymore on a Dell PowerEdge R720 with two six core 24x E5-2630 @ 2.30GHz. ``` $ dmesg | grep raid [ 0.269768] raid6: sse2x1 gen() 7179 MB/s [ 0.290069] raid6: sse2x1 xor() 5636 MB/s [ 0.311068] raid6: sse2x2 gen() 9160 MB/s [ 0.332076] raid6: sse2x2 xor() 6375 MB/s [ 0.353075] raid6: sse2x4 gen() 11164 MB/s [ 0.374064] raid6: sse2x4 xor() 7429 MB/s [ 0.379001] raid6: using algorithm sse2x4 gen() 11164 MB/s [ 0.386001] raid6: .... xor() 7429 MB/s, rmw enabled [ 0.391008] raid6: using ssse3x2 recovery algorithm [ 3.559682] megaraid cmm: 2.20.2.7 (Release Date: Sun Jul 16 00:01:03 EST 2006) [ 3.570061] megaraid: 2.20.5.1 (Release Date: Thu Nov 16 15:32:35 EST 2006) [ 10.725767] Adaptec aacraid driver 1.2.1[50834]-custom [ 10.731724] aacraid 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.743295] aacraid: Comm Interface type3 enabled $ lspci -nn | grep Adaptec 04:00.0 Serial Attached SCSI controller [0107]: Adaptec Series 8 12G SAS/PCIe 3 [9005:028d] (rev 01) 42:00.0 Serial Attached SCSI controller [0107]: Adaptec Smart Storage PQI 12G SAS/PCIe 3 [9005:028f] (rev 01) ``` But, it still works with a Dell PowerEdge R715 with two eight core AMD Opteron 6136, the card below. ``` $ lspci -nn | grep Adaptec 22:00.0 Serial Attached SCSI controller [0107]: Adaptec Series 8 12G SAS/PCIe 3 [9005:028d] (rev 01) ``` Reverting the commit fixes the issue. commit ef86f3a72adb8a7931f67335560740a7ad696d1d Author: Christoph Hellwig <hch(a)lst.de> Date: Fri Jan 12 10:53:05 2018 +0800 genirq/affinity: assign vectors to all possible CPUs commit 84676c1f21e8ff54befe985f4f14dc1edc10046b upstream. Currently we assign managed interrupt vectors to all present CPUs. This works fine for systems were we only online/offline CPUs. But in case of systems that support physical CPU hotplug (or the virtualized version of it) this means the additional CPUs covered for in the ACPI tables or on the command line are not catered for. To fix this we'd either need to introduce new hotplug CPU states just for this case, or we can start assining vectors to possible but not present CPUs. Reported-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Tested-by: Christian Borntraeger <borntraeger(a)de.ibm.com> Tested-by: Stefan Haberland <sth(a)linux.vnet.ibm.com> Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU") Cc: linux-kernel(a)vger.kernel.org Cc: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> The problem doesn’t happen with Linux 4.17.11, so there are commits in Linux master fixing this. Unfortunately, my attempts to find out failed. I was able to cherry-pick the three commits below on top of 4.14.62, but the problem persists. 6aba81b5a2f5 genirq/affinity: Don't return with empty affinity masks on error 355d7ecdea35 scsi: hpsa: fix selection of reply queue e944e9615741 scsi: virtio_scsi: fix IO hang caused by automatic irq vector affinity Trying to cherry-pick the commits below, referencing the commit in question, gave conflicts. 1. adbe552349f2 scsi: megaraid_sas: fix selection of reply queue 2. d3056812e7df genirq/affinity: Spread irq vectors among present CPUs as far as possible To avoid further trial and error with the server with a slow firmware, do you know what commits should fix the issue? Kind regards, Paul PS: I couldn’t find, who suggested this for stable, that means how it was picked to be added to stable. Is there an easy way to find that out?

5 years, 1 month

6
20
0 0

FAILED: patch "[PATCH] dm verity: fix crash on bufio buffer that was allocated with" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From e4b069e0945fa14c71cf8b5b89f8b1b2aa68dbc2 Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Wed, 22 Aug 2018 12:45:51 -0400 Subject: [PATCH] dm verity: fix crash on bufio buffer that was allocated with vmalloc Since commit d1ac3ff008fb ("dm verity: switch to using asynchronous hash crypto API") dm-verity uses asynchronous crypto calls for verification, so that it can use hardware with asynchronous processing of crypto operations. These asynchronous calls don't support vmalloc memory, but the buffer data can be allocated with vmalloc if dm-bufio is short of memory and uses a reserved buffer that was preallocated in dm_bufio_client_create(). Fix verity_hash_update() so that it deals with vmalloc'd memory correctly. Reported-by: "Xiao, Jin" <jin.xiao(a)intel.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Fixes: d1ac3ff008fb ("dm verity: switch to using asynchronous hash crypto API") Cc: stable(a)vger.kernel.org # 4.12+ Signed-off-by: Mike Snitzer <snitzer(a)redhat.com> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index 12decdbd722d..fc65f0dedf7f 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -99,10 +99,26 @@ static int verity_hash_update(struct dm_verity *v, struct ahash_request *req, { struct scatterlist sg; - sg_init_one(&sg, data, len); - ahash_request_set_crypt(req, &sg, NULL, len); - - return crypto_wait_req(crypto_ahash_update(req), wait); + if (likely(!is_vmalloc_addr(data))) { + sg_init_one(&sg, data, len); + ahash_request_set_crypt(req, &sg, NULL, len); + return crypto_wait_req(crypto_ahash_update(req), wait); + } else { + do { + int r; + size_t this_step = min_t(size_t, len, PAGE_SIZE - offset_in_page(data)); + flush_kernel_vmap_range((void *)data, this_step); + sg_init_table(&sg, 1); + sg_set_page(&sg, vmalloc_to_page(data), this_step, offset_in_page(data)); + ahash_request_set_crypt(req, &sg, NULL, this_step); + r = crypto_wait_req(crypto_ahash_update(req), wait); + if (unlikely(r)) + return r; + data += this_step; + len -= this_step; + } while (len); + return 0; + } } /*

5 years, 3 months

4
3
0 0

Please include d391f120706726826 in v4.9.y [x86/kvm/vmx]: do not use vm-exit instruction length for fast MMIO when running nested

by Mike Haboustak

The following commit fixes freezes in virtio device drivers when KVM is nested under VMWare Workstation/ESXi or Hyper-V. I've encountered problems running KVM inside VMWare since upgrading to Debian 9 (currently testing 4.9.88-1+deb9u1). d391f1207067268261add0485f0f34503539c5b0 The same issue affects 4.4.y as well. A git-bisect within my environment stopped at e9ea5069d9e569c32ab913c39467df32e056b3a7, where the KVM capability was added that QEMU checks before enabling fast mmio. Thanks, Mike

5 years, 3 months

2
4
0 0

[PATCH stable 3.9 to 3.16] staging: comedi: quatech_daqp_cs: fix no-op loop daqp_ao_insn_write()

by Ian Abbott

From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit 1376b0a2160319125c3a2822e8c09bd283cd8141 ] There is a '>' vs '<' typo so this loop is a no-op. Fixes: d35dcc89fc93 ("staging: comedi: quatech_daqp_cs: fix daqp_ao_insn_write()") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/drivers/quatech_daqp_cs.c b/drivers/staging/comedi/drivers/quatech_daqp_cs.c index b3bbec0a0d23..f89a863ea04c 100644 --- a/drivers/staging/comedi/drivers/quatech_daqp_cs.c +++ b/drivers/staging/comedi/drivers/quatech_daqp_cs.c @@ -649,7 +649,7 @@ static int daqp_ao_insn_write(struct comedi_device *dev, /* Make sure D/A update mode is direct update */ outb(0, dev->iobase + DAQP_AUX); - for (i = 0; i > insn->n; i++) { + for (i = 0; i < insn->n; i++) { val = data[0]; val &= 0x0fff; val ^= 0x0800; /* Flip the sign */ -- 2.18.0

5 years, 3 months

2
6
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2018