Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

316 participants
124218 discussions

by Jessica

Editing for photos. Retouching for photos. Cutting out for photos, We are a photo team of 20 image editors and we can edit your photos today if you need help, We mainly work on: Clipping path - image cut out Shadow creation Image masking Image retouching Beauty model retouching Please reply if interested. Thanks, Jessica

7 years

Question 22

by Jessica

7 years

[PATCH] drivers/perf: hisi: Fixup one DDRC PMU register offset

by Shaokun Zhang

For DDRC PMU, each PMU counter is fixed-purpose. There is a mismatch between perf list and driver definition on rw_chg event. # perf list | grep chg hisi_sccl1_ddrc0/rnk_chg/ [Kernel PMU event] hisi_sccl1_ddrc0/rw_chg/ [Kernel PMU event] But the register offset of rw_chg event is not defined in the driver, meanwhile bnk_chg register offset is mis-defined, let's fixup it. Fixes: 904dcf03f086 ("perf: hisi: Add support for HiSilicon SoC DDRC PMU driver") Cc: stable(a)vger.kernel.org Cc: John Garry <john.garry(a)huawei.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Mark Rutland <mark.rutland(a)arm.com> Reported-by: Weijian Huang <huangweijian4(a)hisilicon.com> Signed-off-by: Shaokun Zhang <zhangshaokun(a)hisilicon.com> --- drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c index 1b10ea05a914..69372e2bc93c 100644 --- a/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c +++ b/drivers/perf/hisilicon/hisi_uncore_ddrc_pmu.c @@ -30,8 +30,8 @@ #define DDRC_FLUX_RCMD 0x38c #define DDRC_PRE_CMD 0x3c0 #define DDRC_ACT_CMD 0x3c4 -#define DDRC_BNK_CHG 0x3c8 #define DDRC_RNK_CHG 0x3cc +#define DDRC_RW_CHG 0x3d0 #define DDRC_EVENT_CTRL 0x6C0 #define DDRC_INT_MASK 0x6c8 #define DDRC_INT_STATUS 0x6cc @@ -51,7 +51,7 @@ static const u32 ddrc_reg_off[] = { DDRC_FLUX_WR, DDRC_FLUX_RD, DDRC_FLUX_WCMD, DDRC_FLUX_RCMD, - DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_BNK_CHG, DDRC_RNK_CHG + DDRC_PRE_CMD, DDRC_ACT_CMD, DDRC_RNK_CHG, DDRC_RW_CHG }; /* -- 2.7.4

7 years

[PATCH v3 1/1] scsi: Synchronize request queue PM status only on successful resume

by stanley.chu＠mediatek.com

From: Stanley Chu <stanley.chu(a)mediatek.com> The commit 356fd2663cff ("scsi: Set request queue runtime PM status back to active on resume") fixed up the inconsistent RPM status between request queue and device. However changing request queue RPM status shall be done only on successful resume, otherwise status may be still inconsistent as below, Request queue: RPM_ACTIVE Device: RPM_SUSPENDED This ends up soft lockup because requests can be submitted to underlying devices but those devices and their required resource are not resumed. For example, After above inconsistent status happens, IO request can be submitted to UFS device driver but required resource (like clock) is not resumed yet thus lead to warning as below call stack, WARN_ON(hba->clk_gating.state != CLKS_ON); ufshcd_queuecommand scsi_dispatch_cmd scsi_request_fn __blk_run_queue cfq_insert_request __elv_add_request blk_flush_plug_list blk_finish_plug jbd2_journal_commit_transaction kjournald2 We may see all behind IO requests hang because of no response from storage host or device and then soft lockup happens in system. In the end, system may crash in many ways. Fixes: 356fd2663cff (scsi: Set request queue runtime PM status back to active on resume) Cc: stable(a)vger.kernel.org Signed-off-by: Stanley Chu <stanley.chu(a)mediatek.com> --- drivers/scsi/scsi_pm.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index a2b4179bfdf7..7639df91b110 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -80,8 +80,22 @@ static int scsi_dev_type_resume(struct device *dev, if (err == 0) { pm_runtime_disable(dev); - pm_runtime_set_active(dev); + err = pm_runtime_set_active(dev); pm_runtime_enable(dev); + + /* + * Forcibly set runtime PM status of request queue to "active" + * to make sure we can again get requests from the queue + * (see also blk_pm_peek_request()). + * + * The resume hook will correct runtime PM status of the disk. + */ + if (!err && scsi_is_sdev_device(dev)) { + struct scsi_device *sdev = to_scsi_device(dev); + + if (sdev->request_queue->dev) + blk_set_runtime_active(sdev->request_queue); + } } return err; @@ -140,16 +154,6 @@ static int scsi_bus_resume_common(struct device *dev, else fn = NULL; - /* - * Forcibly set runtime PM status of request queue to "active" to - * make sure we can again get requests from the queue (see also - * blk_pm_peek_request()). - * - * The resume hook will correct runtime PM status of the disk. - */ - if (scsi_is_sdev_device(dev) && pm_runtime_suspended(dev)) - blk_set_runtime_active(to_scsi_device(dev)->request_queue); - if (fn) { async_schedule_domain(fn, dev, &scsi_sd_pm_domain); -- 2.18.0

7 years

[PATCH 02/16] crypto: cfb - remove bogus memcpy() with src == dest

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> The memcpy() in crypto_cfb_decrypt_inplace() uses walk->iv as both the source and destination, which has undefined behavior. It is unneeded because walk->iv is already used to hold the previous ciphertext block; thus, walk->iv is already updated to its final value. So, remove it. Also, note that in-place decryption is the only case where the previous ciphertext block is not directly available. Therefore, as a related cleanup I also updated crypto_cfb_encrypt_segment() to directly use the previous ciphertext block rather than save it into walk->iv. This makes it consistent with in-place encryption and out-of-place decryption; now only in-place decryption is different, because it has to be. Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: <stable(a)vger.kernel.org> # v4.17+ Cc: James Bottomley <James.Bottomley(a)HansenPartnership.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/cfb.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/crypto/cfb.c b/crypto/cfb.c index 183e8a9c33128..4abfe32ff8451 100644 --- a/crypto/cfb.c +++ b/crypto/cfb.c @@ -77,12 +77,14 @@ static int crypto_cfb_encrypt_segment(struct skcipher_walk *walk, do { crypto_cfb_encrypt_one(tfm, iv, dst); crypto_xor(dst, src, bsize); - memcpy(iv, dst, bsize); + iv = dst; src += bsize; dst += bsize; } while ((nbytes -= bsize) >= bsize); + memcpy(walk->iv, iv, bsize); + return nbytes; } @@ -162,7 +164,7 @@ static int crypto_cfb_decrypt_inplace(struct skcipher_walk *walk, const unsigned int bsize = crypto_cfb_bsize(tfm); unsigned int nbytes = walk->nbytes; u8 *src = walk->src.virt.addr; - u8 *iv = walk->iv; + u8 * const iv = walk->iv; u8 tmp[MAX_CIPHER_BLOCKSIZE]; do { @@ -172,8 +174,6 @@ static int crypto_cfb_decrypt_inplace(struct skcipher_walk *walk, src += bsize; } while ((nbytes -= bsize) >= bsize); - memcpy(walk->iv, iv, bsize); - return nbytes; } -- 2.20.1

7 years

[PATCH 01/16] crypto: cfb - add missing 'chunksize' property

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Like some other block cipher mode implementations, the CFB implementation assumes that while walking through the scatterlist, a partial block does not occur until the end. But the walk is incorrectly being done with a blocksize of 1, as 'cra_blocksize' is set to 1 (since CFB is a stream cipher) but no 'chunksize' is set. This bug causes incorrect encryption/decryption for some scatterlist layouts. Fix it by setting the 'chunksize'. Also extend the CFB test vectors to cover this bug as well as cases where the message length is not a multiple of the block size. Fixes: a7d85e06ed80 ("crypto: cfb - add support for Cipher FeedBack mode") Cc: <stable(a)vger.kernel.org> # v4.17+ Cc: James Bottomley <James.Bottomley(a)HansenPartnership.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- crypto/cfb.c | 6 ++++++ crypto/testmgr.h | 25 +++++++++++++++++++++++++ 2 files changed, 31 insertions(+) diff --git a/crypto/cfb.c b/crypto/cfb.c index e81e456734985..183e8a9c33128 100644 --- a/crypto/cfb.c +++ b/crypto/cfb.c @@ -298,6 +298,12 @@ static int crypto_cfb_create(struct crypto_template *tmpl, struct rtattr **tb) inst->alg.base.cra_blocksize = 1; inst->alg.base.cra_alignmask = alg->cra_alignmask; + /* + * To simplify the implementation, configure the skcipher walk to only + * give a partial block at the very end, never earlier. + */ + inst->alg.chunksize = alg->cra_blocksize; + inst->alg.ivsize = alg->cra_blocksize; inst->alg.min_keysize = alg->cra_cipher.cia_min_keysize; inst->alg.max_keysize = alg->cra_cipher.cia_max_keysize; diff --git a/crypto/testmgr.h b/crypto/testmgr.h index e8f47d7b92cdd..7f4dae7a57a1c 100644 --- a/crypto/testmgr.h +++ b/crypto/testmgr.h @@ -12870,6 +12870,31 @@ static const struct cipher_testvec aes_cfb_tv_template[] = { "\x75\xa3\x85\x74\x1a\xb9\xce\xf8" "\x20\x31\x62\x3d\x55\xb1\xe4\x71", .len = 64, + .also_non_np = 1, + .np = 2, + .tap = { 31, 33 }, + }, { /* > 16 bytes, not a multiple of 16 bytes */ + .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6" + "\xab\xf7\x15\x88\x09\xcf\x4f\x3c", + .klen = 16, + .iv = "\x00\x01\x02\x03\x04\x05\x06\x07" + "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f", + .ptext = "\x6b\xc1\xbe\xe2\x2e\x40\x9f\x96" + "\xe9\x3d\x7e\x11\x73\x93\x17\x2a" + "\xae", + .ctext = "\x3b\x3f\xd9\x2e\xb7\x2d\xad\x20" + "\x33\x34\x49\xf8\xe8\x3c\xfb\x4a" + "\xc8", + .len = 17, + }, { /* < 16 bytes */ + .key = "\x2b\x7e\x15\x16\x28\xae\xd2\xa6" + "\xab\xf7\x15\x88\x09\xcf\x4f\x3c", + .klen = 16, + .iv = "\x00\x01\x02\x03\x04\x05\x06\x07" + "\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f", + .ptext = "\x6b\xc1\xbe\xe2\x2e\x40\x9f", + .ctext = "\x3b\x3f\xd9\x2e\xb7\x2d\xad", + .len = 7, }, }; -- 2.20.1

7 years

[PATCH] drm/amd/display: Fix unintialized max_bpc state values

by Alex Deucher

From: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> [Why] If the "max bpc" isn't explicitly set in the atomic state then it have a value of 0. This has the correct behavior of limiting a panel to 8bpc in the case where the panel supports 8bpc. In the case of eDP panels this isn't a true assumption - there are panels that can only do 6bpc. Banding occurs for these displays. [How] Initialize the max_bpc when the connector resets to 8bpc. Also carry over the value when the state is duplicated. Bugzilla: https://bugs.freedesktop.org/108825 Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property") Backport of commit 49f1c44b581b08e3289127ffe58bd208c3166701 upstream. Fixes regression caused by the automatic patch select of these two patches: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109122 Cc: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 49f1c44b581b08e3289127ffe58bd208c3166701) Cc: <stable(a)vger.kernel.org> # 4.19.x --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 299def84e69c..d792735f1365 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2894,6 +2894,7 @@ void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector) state->underscan_enable = false; state->underscan_hborder = 0; state->underscan_vborder = 0; + state->max_bpc = 8; __drm_atomic_helper_connector_reset(connector, &state->base); } @@ -2911,6 +2912,7 @@ amdgpu_dm_connector_atomic_duplicate_state(struct drm_connector *connector) if (new_state) { __drm_atomic_helper_connector_duplicate_state(connector, &new_state->base); + new_state->max_bpc = state->max_bpc; return &new_state->base; } -- 2.20.1

7 years

+ mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/vmalloc: fix size check for remap_vmalloc_range_partial() has been added to the -mm tree. Its filename is mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-vmalloc-fix-size-check-for-rema… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-vmalloc-fix-size-check-for-rema… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Roman Penyaev <rpenyaev(a)suse.de> Subject: mm/vmalloc: fix size check for remap_vmalloc_range_partial() area->size can include adjacent guard page but get_vm_area_size() returns actual size of the area. This fixes possible kernel crash when userspace tries to map area on 1 page bigger: size check passes but the following vmalloc_to_page() returns NULL on last guard (non-existing) page. Link: http://lkml.kernel.org/r/20190103145954.16942-2-rpenyaev@suse.de Signed-off-by: Roman Penyaev <rpenyaev(a)suse.de> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: Joe Perches <joe(a)perches.com> Cc: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/vmalloc.c~mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial +++ a/mm/vmalloc.c @@ -2248,7 +2248,7 @@ int remap_vmalloc_range_partial(struct v if (!(area->flags & VM_USERMAP)) return -EINVAL; - if (kaddr + size > area->addr + area->size) + if (kaddr + size > area->addr + get_vm_area_size(area)) return -EINVAL; do { _ Patches currently in -mm which might be from rpenyaev(a)suse.de are epoll-make-sure-all-elements-in-ready-list-are-in-fifo-order.patch epoll-loosen-irq-safety-in-ep_poll_callback.patch epoll-unify-awaking-of-wakeup-source-on-ep_poll_callback-path.patch epoll-use-rwlock-in-order-to-reduce-ep_poll_callback-contention.patch mm-vmalloc-fix-size-check-for-remap_vmalloc_range_partial.patch mm-vmalloc-do-not-call-kmemleak_free-on-not-yet-accounted-memory.patch mm-vmalloc-pass-vm_usermap-flags-directly-to-__vmalloc_node_range.patch

7 years

Re: [PATCH 1/2] x86/pkeys: properly copy pkey state at fork()

by Dave Hansen

On 1/3/19 5:52 AM, Sasha Levin wrote: > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: e8c24d3a23a4 x86/pkeys: Allocation/free syscalls. > > The bot has tested the following trees: v4.20.0, v4.19.13, v4.14.91, v4.9.148, > > v4.20.0: Build OK! > v4.19.13: Build OK! > v4.14.91: Build OK! > v4.9.148: Failed to apply! Possible dependencies: > c10e83f598d0 ("arch, mm: Allow arch_dup_mmap() to fail") > > > How should we proceed with this patch? The 4.9 version of arch_dup_mmap() does not contain the ldt_dup_context() line. We just need to add arch_dup_pkeys(), like so: void arch_dup_mmap(struct mm_struct *oldmm, struct mm_struct *mm) { + arch_dup_pkeys(oldmm, mm); paravirt_arch_dup_mmap(oldmm, mm); } Should be a pretty simple merge. We can basically ignore the ldt_dup_context() changes.

7 years

[PATCH v2] nvmet-rdma: fix null dereference under heavy load

by Raju Rangoju

Under heavy load if we don't have any pre-allocated rsps left, we dynamically allocate a rsp, but we are not actually allocating memory for nvme_completion (rsp->req.rsp). In such a case, accessing pointer fields (req->rsp->status) in nvmet_req_init() will result in crash. To fix this, allocate the memory for nvme_completion by calling nvmet_rdma_alloc_rsp() Fixes: 8407879c("nvmet-rdma:fix possible bogus dereference under heavy load") Cc: <stable(a)vger.kernel.org> Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Raju Rangoju <rajur(a)chelsio.com> -- Changes from v1: - Moved integer to 'if' block - Used 'unlikely' in datapath flow condition --- drivers/nvme/target/rdma.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c index a8d23eb80192..8f9e6645fcf9 100644 --- a/drivers/nvme/target/rdma.c +++ b/drivers/nvme/target/rdma.c @@ -139,6 +139,10 @@ static void nvmet_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_read_data_done(struct ib_cq *cq, struct ib_wc *wc); static void nvmet_rdma_qp_event(struct ib_event *event, void *priv); static void nvmet_rdma_queue_disconnect(struct nvmet_rdma_queue *queue); +static void nvmet_rdma_free_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); +static int nvmet_rdma_alloc_rsp(struct nvmet_rdma_device *ndev, + struct nvmet_rdma_rsp *r); static const struct nvmet_fabrics_ops nvmet_rdma_ops; @@ -182,9 +186,17 @@ nvmet_rdma_get_rsp(struct nvmet_rdma_queue *queue) spin_unlock_irqrestore(&queue->rsps_lock, flags); if (unlikely(!rsp)) { - rsp = kmalloc(sizeof(*rsp), GFP_KERNEL); + int ret = -EINVAL; + + rsp = kzalloc(sizeof(*rsp), GFP_KERNEL); if (unlikely(!rsp)) return NULL; + ret = nvmet_rdma_alloc_rsp(queue->dev, rsp); + if (unlikely(ret)) { + kfree(rsp); + return NULL; + } + rsp->allocated = true; } @@ -197,6 +209,7 @@ nvmet_rdma_put_rsp(struct nvmet_rdma_rsp *rsp) unsigned long flags; if (unlikely(rsp->allocated)) { + nvmet_rdma_free_rsp(rsp->queue->dev, rsp); kfree(rsp); return; } -- 2.12.0

7 years

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror