October 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] ksmbd: fix race condition from parallel smb2 lock requests" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 75ac9a3dd65f7eab4d12b0a0f744234b5300a491 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100806-buckwheat-epiphany-17f3@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 75ac9a3dd65f ("ksmbd: fix race condition from parallel smb2 lock requests") 38c8a9a52082 ("smb: move client and server files to common directory fs/smb") 3a9b557f44ea ("ksmbd: delete asynchronous work from list") d3ca9f7aeba7 ("ksmbd: fix possible memory leak in smb2_lock()") f8d6e7442aa7 ("ksmbd: fix typo, syncronous->synchronous") abdb1742a312 ("cifs: get rid of mount options string parsing") 9fd29a5bae6e ("cifs: use fs_context for automounts") 5dd8ce24667a ("cifs: missing directory in MAINTAINERS file") 332019e23a51 ("Merge tag '5.20-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 75ac9a3dd65f7eab4d12b0a0f744234b5300a491 Mon Sep 17 00:00:00 2001 From: Namjae Jeon <linkinjeon(a)kernel.org> Date: Wed, 4 Oct 2023 18:31:03 +0900 Subject: [PATCH] ksmbd: fix race condition from parallel smb2 lock requests There is a race condition issue between parallel smb2 lock request. Time + Thread A | Thread A smb2_lock | smb2_lock | insert smb_lock to lock_list | spin_unlock(&work->conn->llist_lock) | | | spin_lock(&conn->llist_lock); | kfree(cmp_lock); | // UAF! | list_add(&smb_lock->llist, &rollback_list) + This patch swaps the line for adding the smb lock to the rollback list and adding the lock list of connection to fix the race issue. Reported-by: luosili <rootlab(a)huawei.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index e774c9855f7f..fd6f05786ac2 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -7038,10 +7038,6 @@ int smb2_lock(struct ksmbd_work *work) ksmbd_debug(SMB, "would have to wait for getting lock\n"); - spin_lock(&work->conn->llist_lock); - list_add_tail(&smb_lock->clist, - &work->conn->lock_list); - spin_unlock(&work->conn->llist_lock); list_add(&smb_lock->llist, &rollback_list); argv = kmalloc(sizeof(void *), GFP_KERNEL); @@ -7072,9 +7068,6 @@ int smb2_lock(struct ksmbd_work *work) if (work->state != KSMBD_WORK_ACTIVE) { list_del(&smb_lock->llist); - spin_lock(&work->conn->llist_lock); - list_del(&smb_lock->clist); - spin_unlock(&work->conn->llist_lock); locks_free_lock(flock); if (work->state == KSMBD_WORK_CANCELLED) { @@ -7094,19 +7087,16 @@ int smb2_lock(struct ksmbd_work *work) } list_del(&smb_lock->llist); - spin_lock(&work->conn->llist_lock); - list_del(&smb_lock->clist); - spin_unlock(&work->conn->llist_lock); release_async_work(work); goto retry; } else if (!rc) { + list_add(&smb_lock->llist, &rollback_list); spin_lock(&work->conn->llist_lock); list_add_tail(&smb_lock->clist, &work->conn->lock_list); list_add_tail(&smb_lock->flist, &fp->lock_list); spin_unlock(&work->conn->llist_lock); - list_add(&smb_lock->llist, &rollback_list); ksmbd_debug(SMB, "successful in taking lock\n"); } else { goto out;

1 year, 1 month

1
0
0 0

[tip: perf/urgent] perf/x86/lbr: Filter vsyscall addresses

by tip-bot2 for JP Kobryn

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: e53899771a02f798d436655efbd9d4b46c0f9265 Gitweb: https://git.kernel.org/tip/e53899771a02f798d436655efbd9d4b46c0f9265 Author: JP Kobryn <inwardvessel(a)gmail.com> AuthorDate: Fri, 06 Oct 2023 11:57:26 -07:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Sun, 08 Oct 2023 12:25:18 +02:00 perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. Suggested-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: JP Kobryn <inwardvessel(a)gmail.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org --- arch/x86/events/utils.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/utils.c b/arch/x86/events/utils.c index 76b1f8b..dab4ed1 100644 --- a/arch/x86/events/utils.c +++ b/arch/x86/events/utils.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include <asm/insn.h> +#include <linux/mm.h> #include "perf_event.h" @@ -132,9 +133,9 @@ static int get_branch_type(unsigned long from, unsigned long to, int abort, * The LBR logs any address in the IP, even if the IP just * faulted. This means userspace can control the from address. * Ensure we don't blindly read any address by validating it is - * a known text address. + * a known text address and not a vsyscall address. */ - if (kernel_text_address(from)) { + if (kernel_text_address(from) && !in_gate_area_no_mm(from)) { addr = (void *)from; /* * Assume we can get the maximum possible size

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] RDMA/srp: Do not call scsi_done() from srp_abort()" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x e193b7955dfad68035b983a0011f4ef3590c85eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100815-gratify-carrot-85a6@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()") 5f9ae9eecb15 ("scsi: ib_srp: Call scsi_done() directly") ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") 7ec2e27a3aff ("RDMA/srp: Fix a recently introduced memory leak") 2b5715fc1738 ("RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes") f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration") 87fee61c3513 ("RDMA/srp: Make the channel count configurable per target") 547ed331bbe8 ("RDMA/srp: Add parse function for maximum initiator to target IU size") a163afc88556 ("IB/core: Remove ib_sg_dma_address() and ib_sg_dma_len()") 882981f4a411 ("RDMA/srp: Add support for immediate data") 513d5647116b ("RDMA/srp: Rework handling of the maximum information unit length") 4f6d498c360c ("RDMA/srp: Move srp_rdma_ch.max_ti_iu_len declaration") 482fffc43c03 ("RDMA/srp: Handle large SCSI CDBs correctly") 3023a1e93656 ("RDMA: Start use ib_device_ops") 02a42f8e40ca ("RDMA/rdmavt: Initialize ib_device_ops struct") 521ed0d92ab0 ("RDMA/core: Introduce ib_device_ops") 9af3f5cf9d64 ("RDMA/core: Validate port number in query_pkey verb") 7eebced1bae0 ("RDMA/uverbs: Simplify ib_uverbs_ex_query_device") 9a0738575f26 ("RDMA/uverbs: Use uverbs_response() for remaining response copying") 07f05f40d956 ("RDMA/uverbs: Use uverbs_attr_bundle to pass udata for ioctl()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Wed, 23 Aug 2023 13:57:27 -0700 Subject: [PATCH] RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. Cc: Bob Pearson <rpearsonhpe(a)gmail.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon(a)kernel.org> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 1574218764e0..2916e77f589b 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *scmnd) u32 tag; u16 ch_idx; struct srp_rdma_ch *ch; - int ret; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); @@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *scmnd) shost_printk(KERN_ERR, target->scsi_host, "Sending SRP abort for tag %#x\n", tag); if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, - SRP_TSK_ABORT_TASK, NULL) == 0) - ret = SUCCESS; - else if (target->rport->state == SRP_RPORT_LOST) - ret = FAST_IO_FAIL; - else - ret = FAILED; - if (ret == SUCCESS) { + SRP_TSK_ABORT_TASK, NULL) == 0) { srp_free_req(ch, req, scmnd, 0); - scmnd->result = DID_ABORT << 16; - scsi_done(scmnd); + return SUCCESS; } + if (target->rport->state == SRP_RPORT_LOST) + return FAST_IO_FAIL; - return ret; + return FAILED; } static int srp_reset_device(struct scsi_cmnd *scmnd)

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] RDMA/srp: Do not call scsi_done() from srp_abort()" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x e193b7955dfad68035b983a0011f4ef3590c85eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100813-tweak-designing-9e34@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()") 5f9ae9eecb15 ("scsi: ib_srp: Call scsi_done() directly") ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") 7ec2e27a3aff ("RDMA/srp: Fix a recently introduced memory leak") 2b5715fc1738 ("RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes") f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration") 87fee61c3513 ("RDMA/srp: Make the channel count configurable per target") 547ed331bbe8 ("RDMA/srp: Add parse function for maximum initiator to target IU size") a163afc88556 ("IB/core: Remove ib_sg_dma_address() and ib_sg_dma_len()") 882981f4a411 ("RDMA/srp: Add support for immediate data") 513d5647116b ("RDMA/srp: Rework handling of the maximum information unit length") 4f6d498c360c ("RDMA/srp: Move srp_rdma_ch.max_ti_iu_len declaration") 482fffc43c03 ("RDMA/srp: Handle large SCSI CDBs correctly") 3023a1e93656 ("RDMA: Start use ib_device_ops") 02a42f8e40ca ("RDMA/rdmavt: Initialize ib_device_ops struct") 521ed0d92ab0 ("RDMA/core: Introduce ib_device_ops") 9af3f5cf9d64 ("RDMA/core: Validate port number in query_pkey verb") 7eebced1bae0 ("RDMA/uverbs: Simplify ib_uverbs_ex_query_device") 9a0738575f26 ("RDMA/uverbs: Use uverbs_response() for remaining response copying") 07f05f40d956 ("RDMA/uverbs: Use uverbs_attr_bundle to pass udata for ioctl()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Wed, 23 Aug 2023 13:57:27 -0700 Subject: [PATCH] RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. Cc: Bob Pearson <rpearsonhpe(a)gmail.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon(a)kernel.org> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 1574218764e0..2916e77f589b 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *scmnd) u32 tag; u16 ch_idx; struct srp_rdma_ch *ch; - int ret; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); @@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *scmnd) shost_printk(KERN_ERR, target->scsi_host, "Sending SRP abort for tag %#x\n", tag); if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, - SRP_TSK_ABORT_TASK, NULL) == 0) - ret = SUCCESS; - else if (target->rport->state == SRP_RPORT_LOST) - ret = FAST_IO_FAIL; - else - ret = FAILED; - if (ret == SUCCESS) { + SRP_TSK_ABORT_TASK, NULL) == 0) { srp_free_req(ch, req, scmnd, 0); - scmnd->result = DID_ABORT << 16; - scsi_done(scmnd); + return SUCCESS; } + if (target->rport->state == SRP_RPORT_LOST) + return FAST_IO_FAIL; - return ret; + return FAILED; } static int srp_reset_device(struct scsi_cmnd *scmnd)

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] RDMA/srp: Do not call scsi_done() from srp_abort()" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x e193b7955dfad68035b983a0011f4ef3590c85eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100812-clump-absently-aa46@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()") 5f9ae9eecb15 ("scsi: ib_srp: Call scsi_done() directly") ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") 7ec2e27a3aff ("RDMA/srp: Fix a recently introduced memory leak") 2b5715fc1738 ("RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes") f273ad4f8d90 ("RDMA/srp: Remove support for FMR memory registration") 87fee61c3513 ("RDMA/srp: Make the channel count configurable per target") 547ed331bbe8 ("RDMA/srp: Add parse function for maximum initiator to target IU size") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Wed, 23 Aug 2023 13:57:27 -0700 Subject: [PATCH] RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. Cc: Bob Pearson <rpearsonhpe(a)gmail.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon(a)kernel.org> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 1574218764e0..2916e77f589b 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *scmnd) u32 tag; u16 ch_idx; struct srp_rdma_ch *ch; - int ret; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); @@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *scmnd) shost_printk(KERN_ERR, target->scsi_host, "Sending SRP abort for tag %#x\n", tag); if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, - SRP_TSK_ABORT_TASK, NULL) == 0) - ret = SUCCESS; - else if (target->rport->state == SRP_RPORT_LOST) - ret = FAST_IO_FAIL; - else - ret = FAILED; - if (ret == SUCCESS) { + SRP_TSK_ABORT_TASK, NULL) == 0) { srp_free_req(ch, req, scmnd, 0); - scmnd->result = DID_ABORT << 16; - scsi_done(scmnd); + return SUCCESS; } + if (target->rport->state == SRP_RPORT_LOST) + return FAST_IO_FAIL; - return ret; + return FAILED; } static int srp_reset_device(struct scsi_cmnd *scmnd)

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] RDMA/srp: Do not call scsi_done() from srp_abort()" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x e193b7955dfad68035b983a0011f4ef3590c85eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100810-consensus-basically-78d8@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()") 5f9ae9eecb15 ("scsi: ib_srp: Call scsi_done() directly") ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") 7ec2e27a3aff ("RDMA/srp: Fix a recently introduced memory leak") 2b5715fc1738 ("RDMA/srp: Fix support for unpopulated and unbalanced NUMA nodes") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Wed, 23 Aug 2023 13:57:27 -0700 Subject: [PATCH] RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. Cc: Bob Pearson <rpearsonhpe(a)gmail.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon(a)kernel.org> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 1574218764e0..2916e77f589b 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *scmnd) u32 tag; u16 ch_idx; struct srp_rdma_ch *ch; - int ret; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); @@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *scmnd) shost_printk(KERN_ERR, target->scsi_host, "Sending SRP abort for tag %#x\n", tag); if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, - SRP_TSK_ABORT_TASK, NULL) == 0) - ret = SUCCESS; - else if (target->rport->state == SRP_RPORT_LOST) - ret = FAST_IO_FAIL; - else - ret = FAILED; - if (ret == SUCCESS) { + SRP_TSK_ABORT_TASK, NULL) == 0) { srp_free_req(ch, req, scmnd, 0); - scmnd->result = DID_ABORT << 16; - scsi_done(scmnd); + return SUCCESS; } + if (target->rport->state == SRP_RPORT_LOST) + return FAST_IO_FAIL; - return ret; + return FAILED; } static int srp_reset_device(struct scsi_cmnd *scmnd)

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] RDMA/srp: Do not call scsi_done() from srp_abort()" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x e193b7955dfad68035b983a0011f4ef3590c85eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100808-discourse-comfy-1731@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: e193b7955dfa ("RDMA/srp: Do not call scsi_done() from srp_abort()") 5f9ae9eecb15 ("scsi: ib_srp: Call scsi_done() directly") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bvanassche(a)acm.org> Date: Wed, 23 Aug 2023 13:57:27 -0700 Subject: [PATCH] RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. Cc: Bob Pearson <rpearsonhpe(a)gmail.com> Cc: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky <leon(a)kernel.org> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp/srp/ib_srp.c index 1574218764e0..2916e77f589b 100644 --- a/drivers/infiniband/ulp/srp/ib_srp.c +++ b/drivers/infiniband/ulp/srp/ib_srp.c @@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *scmnd) u32 tag; u16 ch_idx; struct srp_rdma_ch *ch; - int ret; shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); @@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *scmnd) shost_printk(KERN_ERR, target->scsi_host, "Sending SRP abort for tag %#x\n", tag); if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, - SRP_TSK_ABORT_TASK, NULL) == 0) - ret = SUCCESS; - else if (target->rport->state == SRP_RPORT_LOST) - ret = FAST_IO_FAIL; - else - ret = FAILED; - if (ret == SUCCESS) { + SRP_TSK_ABORT_TASK, NULL) == 0) { srp_free_req(ch, req, scmnd, 0); - scmnd->result = DID_ABORT << 16; - scsi_done(scmnd); + return SUCCESS; } + if (target->rport->state == SRP_RPORT_LOST) + return FAST_IO_FAIL; - return ret; + return FAILED; } static int srp_reset_device(struct scsi_cmnd *scmnd)

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors" 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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x 914988e099fc658436fbd7b8f240160c352b6552 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100809-rethink-refueling-8ca3@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: 914988e099fc ("parisc: Restore __ldcw_align for PA-RISC 2.0 processors") 15e64ef6520e ("parisc: Add lightweight spinlock checks") 4aae683f1327 ("tracing: Refactor TRACE_IRQFLAGS_SUPPORT in Kconfig") 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN") 63703f37aa09 ("mm: generalize ZONE_[DMA|DMA32]") ca6e51d592d2 ("arm64/Kconfig: introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE") 91024b3ce247 ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]") c2280be81de4 ("mm: generalize ARCH_HAS_CACHE_LINE_SIZE") 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") 18107f8a2df6 ("arm64: Support execute-only permissions with Enhanced PAN") 07fb6dc327f1 ("arm64/mm: Drop redundant ARCH_WANT_HUGE_PMD_SHARE") 591fd30eee47 ("Merge branch 'work.elf-compat' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 914988e099fc658436fbd7b8f240160c352b6552 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave(a)parisc-linux.org> Date: Tue, 19 Sep 2023 17:51:40 +0000 Subject: [PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors Back in 2005, Kyle McMartin removed the 16-byte alignment for ldcw semaphores on PA 2.0 machines (CONFIG_PA20). This broke spinlocks on pre PA8800 processors. The main symptom was random faults in mmap'd memory (e.g., gcc compilations, etc). Unfortunately, the errata for this ldcw change is lost. The issue is the 16-byte alignment required for ldcw semaphore instructions can only be reduced to natural alignment when the ldcw operation can be handled coherently in cache. Only PA8800 and PA8900 processors actually support doing the operation in cache. Aligning the spinlock dynamically adds two integer instructions to each spinlock. Tested on rp3440, c8000 and a500. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Link: https://lore.kernel.org/linux-parisc/6b332788-2227-127f-ba6d-55e99ecf4ed8@b… Link: https://lore.kernel.org/linux-parisc/20050609050702.GB4641@roadwarrior.mcma… Cc: stable(a)vger.kernel.org Signed-off-by: Helge Deller <deller(a)gmx.de> diff --git a/arch/parisc/include/asm/ldcw.h b/arch/parisc/include/asm/ldcw.h index 6d28b5514699..ee9e071859b2 100644 --- a/arch/parisc/include/asm/ldcw.h +++ b/arch/parisc/include/asm/ldcw.h @@ -2,39 +2,42 @@ #ifndef __PARISC_LDCW_H #define __PARISC_LDCW_H -#ifndef CONFIG_PA20 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, and GCC only guarantees 8-byte alignment for stack locals, we can't be assured of 16-byte alignment for atomic lock data even if we specify "__attribute ((aligned(16)))" in the type declaration. So, we use a struct containing an array of four ints for the atomic lock type and dynamically select the 16-byte aligned int from the array - for the semaphore. */ + for the semaphore. */ + +/* From: "Jim Hull" <jim.hull of hp.com> + I've attached a summary of the change, but basically, for PA 2.0, as + long as the ",CO" (coherent operation) completer is implemented, then the + 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead + they only require "natural" alignment (4-byte for ldcw, 8-byte for + ldcd). + + Although the cache control hint is accepted by all PA 2.0 processors, + it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still + require 16-byte alignment. If the address is unaligned, the operation + of the instruction is undefined. The ldcw instruction does not generate + unaligned data reference traps so misaligned accesses are not detected. + This hid the problem for years. So, restore the 16-byte alignment dropped + by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */ #define __PA_LDCW_ALIGNMENT 16 -#define __PA_LDCW_ALIGN_ORDER 4 #define __ldcw_align(a) ({ \ unsigned long __ret = (unsigned long) &(a)->lock[0]; \ __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ & ~(__PA_LDCW_ALIGNMENT - 1); \ (volatile unsigned int *) __ret; \ }) -#define __LDCW "ldcw" -#else /*CONFIG_PA20*/ -/* From: "Jim Hull" <jim.hull of hp.com> - I've attached a summary of the change, but basically, for PA 2.0, as - long as the ",CO" (coherent operation) completer is specified, then the - 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead - they only require "natural" alignment (4-byte for ldcw, 8-byte for - ldcd). */ - -#define __PA_LDCW_ALIGNMENT 4 -#define __PA_LDCW_ALIGN_ORDER 2 -#define __ldcw_align(a) (&(a)->slock) +#ifdef CONFIG_PA20 #define __LDCW "ldcw,co" - -#endif /*!CONFIG_PA20*/ +#else +#define __LDCW "ldcw" +#endif /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. We don't explicitly expose that "*a" may be written as reload diff --git a/arch/parisc/include/asm/spinlock_types.h b/arch/parisc/include/asm/spinlock_types.h index efd06a897c6a..7b986b09dba8 100644 --- a/arch/parisc/include/asm/spinlock_types.h +++ b/arch/parisc/include/asm/spinlock_types.h @@ -9,15 +9,10 @@ #ifndef __ASSEMBLY__ typedef struct { -#ifdef CONFIG_PA20 - volatile unsigned int slock; -# define __ARCH_SPIN_LOCK_UNLOCKED { __ARCH_SPIN_LOCK_UNLOCKED_VAL } -#else volatile unsigned int lock[4]; # define __ARCH_SPIN_LOCK_UNLOCKED \ { { __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL, \ __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL } } -#endif } arch_spinlock_t;

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 914988e099fc658436fbd7b8f240160c352b6552 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100807-gas-buffer-2df7@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 914988e099fc ("parisc: Restore __ldcw_align for PA-RISC 2.0 processors") 15e64ef6520e ("parisc: Add lightweight spinlock checks") 4aae683f1327 ("tracing: Refactor TRACE_IRQFLAGS_SUPPORT in Kconfig") 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN") 63703f37aa09 ("mm: generalize ZONE_[DMA|DMA32]") ca6e51d592d2 ("arm64/Kconfig: introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE") 91024b3ce247 ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]") c2280be81de4 ("mm: generalize ARCH_HAS_CACHE_LINE_SIZE") 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") 18107f8a2df6 ("arm64: Support execute-only permissions with Enhanced PAN") 07fb6dc327f1 ("arm64/mm: Drop redundant ARCH_WANT_HUGE_PMD_SHARE") 591fd30eee47 ("Merge branch 'work.elf-compat' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 914988e099fc658436fbd7b8f240160c352b6552 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave(a)parisc-linux.org> Date: Tue, 19 Sep 2023 17:51:40 +0000 Subject: [PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors Back in 2005, Kyle McMartin removed the 16-byte alignment for ldcw semaphores on PA 2.0 machines (CONFIG_PA20). This broke spinlocks on pre PA8800 processors. The main symptom was random faults in mmap'd memory (e.g., gcc compilations, etc). Unfortunately, the errata for this ldcw change is lost. The issue is the 16-byte alignment required for ldcw semaphore instructions can only be reduced to natural alignment when the ldcw operation can be handled coherently in cache. Only PA8800 and PA8900 processors actually support doing the operation in cache. Aligning the spinlock dynamically adds two integer instructions to each spinlock. Tested on rp3440, c8000 and a500. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Link: https://lore.kernel.org/linux-parisc/6b332788-2227-127f-ba6d-55e99ecf4ed8@b… Link: https://lore.kernel.org/linux-parisc/20050609050702.GB4641@roadwarrior.mcma… Cc: stable(a)vger.kernel.org Signed-off-by: Helge Deller <deller(a)gmx.de> diff --git a/arch/parisc/include/asm/ldcw.h b/arch/parisc/include/asm/ldcw.h index 6d28b5514699..ee9e071859b2 100644 --- a/arch/parisc/include/asm/ldcw.h +++ b/arch/parisc/include/asm/ldcw.h @@ -2,39 +2,42 @@ #ifndef __PARISC_LDCW_H #define __PARISC_LDCW_H -#ifndef CONFIG_PA20 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, and GCC only guarantees 8-byte alignment for stack locals, we can't be assured of 16-byte alignment for atomic lock data even if we specify "__attribute ((aligned(16)))" in the type declaration. So, we use a struct containing an array of four ints for the atomic lock type and dynamically select the 16-byte aligned int from the array - for the semaphore. */ + for the semaphore. */ + +/* From: "Jim Hull" <jim.hull of hp.com> + I've attached a summary of the change, but basically, for PA 2.0, as + long as the ",CO" (coherent operation) completer is implemented, then the + 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead + they only require "natural" alignment (4-byte for ldcw, 8-byte for + ldcd). + + Although the cache control hint is accepted by all PA 2.0 processors, + it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still + require 16-byte alignment. If the address is unaligned, the operation + of the instruction is undefined. The ldcw instruction does not generate + unaligned data reference traps so misaligned accesses are not detected. + This hid the problem for years. So, restore the 16-byte alignment dropped + by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */ #define __PA_LDCW_ALIGNMENT 16 -#define __PA_LDCW_ALIGN_ORDER 4 #define __ldcw_align(a) ({ \ unsigned long __ret = (unsigned long) &(a)->lock[0]; \ __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ & ~(__PA_LDCW_ALIGNMENT - 1); \ (volatile unsigned int *) __ret; \ }) -#define __LDCW "ldcw" -#else /*CONFIG_PA20*/ -/* From: "Jim Hull" <jim.hull of hp.com> - I've attached a summary of the change, but basically, for PA 2.0, as - long as the ",CO" (coherent operation) completer is specified, then the - 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead - they only require "natural" alignment (4-byte for ldcw, 8-byte for - ldcd). */ - -#define __PA_LDCW_ALIGNMENT 4 -#define __PA_LDCW_ALIGN_ORDER 2 -#define __ldcw_align(a) (&(a)->slock) +#ifdef CONFIG_PA20 #define __LDCW "ldcw,co" - -#endif /*!CONFIG_PA20*/ +#else +#define __LDCW "ldcw" +#endif /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. We don't explicitly expose that "*a" may be written as reload diff --git a/arch/parisc/include/asm/spinlock_types.h b/arch/parisc/include/asm/spinlock_types.h index efd06a897c6a..7b986b09dba8 100644 --- a/arch/parisc/include/asm/spinlock_types.h +++ b/arch/parisc/include/asm/spinlock_types.h @@ -9,15 +9,10 @@ #ifndef __ASSEMBLY__ typedef struct { -#ifdef CONFIG_PA20 - volatile unsigned int slock; -# define __ARCH_SPIN_LOCK_UNLOCKED { __ARCH_SPIN_LOCK_UNLOCKED_VAL } -#else volatile unsigned int lock[4]; # define __ARCH_SPIN_LOCK_UNLOCKED \ { { __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL, \ __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL } } -#endif } arch_spinlock_t;

1 year, 1 month

1
0
0 0

FAILED: patch "[PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 914988e099fc658436fbd7b8f240160c352b6552 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023100806-award-delirium-71f7@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 914988e099fc ("parisc: Restore __ldcw_align for PA-RISC 2.0 processors") 15e64ef6520e ("parisc: Add lightweight spinlock checks") 4aae683f1327 ("tracing: Refactor TRACE_IRQFLAGS_SUPPORT in Kconfig") 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN") 63703f37aa09 ("mm: generalize ZONE_[DMA|DMA32]") ca6e51d592d2 ("arm64/Kconfig: introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE") 91024b3ce247 ("mm: generalize ARCH_ENABLE_MEMORY_[HOTPLUG|HOTREMOVE]") c2280be81de4 ("mm: generalize ARCH_HAS_CACHE_LINE_SIZE") 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") 18107f8a2df6 ("arm64: Support execute-only permissions with Enhanced PAN") 07fb6dc327f1 ("arm64/mm: Drop redundant ARCH_WANT_HUGE_PMD_SHARE") 591fd30eee47 ("Merge branch 'work.elf-compat' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 914988e099fc658436fbd7b8f240160c352b6552 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave(a)parisc-linux.org> Date: Tue, 19 Sep 2023 17:51:40 +0000 Subject: [PATCH] parisc: Restore __ldcw_align for PA-RISC 2.0 processors Back in 2005, Kyle McMartin removed the 16-byte alignment for ldcw semaphores on PA 2.0 machines (CONFIG_PA20). This broke spinlocks on pre PA8800 processors. The main symptom was random faults in mmap'd memory (e.g., gcc compilations, etc). Unfortunately, the errata for this ldcw change is lost. The issue is the 16-byte alignment required for ldcw semaphore instructions can only be reduced to natural alignment when the ldcw operation can be handled coherently in cache. Only PA8800 and PA8900 processors actually support doing the operation in cache. Aligning the spinlock dynamically adds two integer instructions to each spinlock. Tested on rp3440, c8000 and a500. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Link: https://lore.kernel.org/linux-parisc/6b332788-2227-127f-ba6d-55e99ecf4ed8@b… Link: https://lore.kernel.org/linux-parisc/20050609050702.GB4641@roadwarrior.mcma… Cc: stable(a)vger.kernel.org Signed-off-by: Helge Deller <deller(a)gmx.de> diff --git a/arch/parisc/include/asm/ldcw.h b/arch/parisc/include/asm/ldcw.h index 6d28b5514699..ee9e071859b2 100644 --- a/arch/parisc/include/asm/ldcw.h +++ b/arch/parisc/include/asm/ldcw.h @@ -2,39 +2,42 @@ #ifndef __PARISC_LDCW_H #define __PARISC_LDCW_H -#ifndef CONFIG_PA20 /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, and GCC only guarantees 8-byte alignment for stack locals, we can't be assured of 16-byte alignment for atomic lock data even if we specify "__attribute ((aligned(16)))" in the type declaration. So, we use a struct containing an array of four ints for the atomic lock type and dynamically select the 16-byte aligned int from the array - for the semaphore. */ + for the semaphore. */ + +/* From: "Jim Hull" <jim.hull of hp.com> + I've attached a summary of the change, but basically, for PA 2.0, as + long as the ",CO" (coherent operation) completer is implemented, then the + 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead + they only require "natural" alignment (4-byte for ldcw, 8-byte for + ldcd). + + Although the cache control hint is accepted by all PA 2.0 processors, + it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still + require 16-byte alignment. If the address is unaligned, the operation + of the instruction is undefined. The ldcw instruction does not generate + unaligned data reference traps so misaligned accesses are not detected. + This hid the problem for years. So, restore the 16-byte alignment dropped + by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */ #define __PA_LDCW_ALIGNMENT 16 -#define __PA_LDCW_ALIGN_ORDER 4 #define __ldcw_align(a) ({ \ unsigned long __ret = (unsigned long) &(a)->lock[0]; \ __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ & ~(__PA_LDCW_ALIGNMENT - 1); \ (volatile unsigned int *) __ret; \ }) -#define __LDCW "ldcw" -#else /*CONFIG_PA20*/ -/* From: "Jim Hull" <jim.hull of hp.com> - I've attached a summary of the change, but basically, for PA 2.0, as - long as the ",CO" (coherent operation) completer is specified, then the - 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead - they only require "natural" alignment (4-byte for ldcw, 8-byte for - ldcd). */ - -#define __PA_LDCW_ALIGNMENT 4 -#define __PA_LDCW_ALIGN_ORDER 2 -#define __ldcw_align(a) (&(a)->slock) +#ifdef CONFIG_PA20 #define __LDCW "ldcw,co" - -#endif /*!CONFIG_PA20*/ +#else +#define __LDCW "ldcw" +#endif /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. We don't explicitly expose that "*a" may be written as reload diff --git a/arch/parisc/include/asm/spinlock_types.h b/arch/parisc/include/asm/spinlock_types.h index efd06a897c6a..7b986b09dba8 100644 --- a/arch/parisc/include/asm/spinlock_types.h +++ b/arch/parisc/include/asm/spinlock_types.h @@ -9,15 +9,10 @@ #ifndef __ASSEMBLY__ typedef struct { -#ifdef CONFIG_PA20 - volatile unsigned int slock; -# define __ARCH_SPIN_LOCK_UNLOCKED { __ARCH_SPIN_LOCK_UNLOCKED_VAL } -#else volatile unsigned int lock[4]; # define __ARCH_SPIN_LOCK_UNLOCKED \ { { __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL, \ __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL } } -#endif } arch_spinlock_t;

1 year, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023