Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
57b736fc |
| 09-Apr-2024 |
Yi Zhang <yi.zhang@redhat.com> |
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line
nvme: fix warn output about shared namespaces without CONFIG_NVME_MULTIPATH
[ Upstream commit 0bc2e80b9be51712b19e919db5abc97a418f8292 ]
Move the stray '.' that is currently at the end of the line after newline '\n' to before newline character which is the right position.
Fixes: ce8d78616a6b ("nvme: warn about shared namespaces without CONFIG_NVME_MULTIPATH") Signed-off-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23 |
|
#
ff2f90f8 |
| 10-Mar-2024 |
Chunguang Xu <chunguang.xu@shopee.com> |
nvme: fix reconnection fail due to reserved tag allocation
[ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]
We found a issue on production environment while using NVMe over RDMA, admin_
nvme: fix reconnection fail due to reserved tag allocation
[ Upstream commit de105068fead55ed5c07ade75e9c8e7f86a00d1d ]
We found a issue on production environment while using NVMe over RDMA, admin_q reconnect failed forever while remote target and network is ok. After dig into it, we found it may caused by a ABBA deadlock due to tag allocation. In my case, the tag was hold by a keep alive request waiting inside admin_q, as we quiesced admin_q while reset ctrl, so the request maked as idle and will not process before reset success. As fabric_q shares tagset with admin_q, while reconnect remote target, we need a tag for connect command, but the only one reserved tag was held by keep alive command which waiting inside admin_q. As a result, we failed to reconnect admin_q forever. In order to fix this issue, I think we should keep two reserved tags for admin queue.
Fixes: ed01fee283a0 ("nvme-fabrics: only reserve a single tag") Signed-off-by: Chunguang Xu <chunguang.xu@shopee.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4 |
|
#
c52d545c |
| 29-Nov-2023 |
Bitao Hu <yaoma@linux.alibaba.com> |
nvme: fix deadlock between reset and scan
[ Upstream commit 839a40d1e730977d4448d141fa653517c2959a88 ]
If controller reset occurs when allocating namespace, both nvme_reset_work and nvme_scan_work
nvme: fix deadlock between reset and scan
[ Upstream commit 839a40d1e730977d4448d141fa653517c2959a88 ]
If controller reset occurs when allocating namespace, both nvme_reset_work and nvme_scan_work will hang, as shown below.
Test Scripts:
for ((t=1;t<=128;t++)) do nsid=`nvme create-ns /dev/nvme1 -s 14537724 -c 14537724 -f 0 -m 0 \ -d 0 | awk -F: '{print($NF);}'` nvme attach-ns /dev/nvme1 -n $nsid -c 0 done nvme reset /dev/nvme1
We will find that both nvme_reset_work and nvme_scan_work hung:
INFO: task kworker/u249:4:17848 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u249:4 state:D stack: 0 pid:17848 ppid: 2 flags:0x00000028 Workqueue: nvme-reset-wq nvme_reset_work [nvme] Call trace: __switch_to+0xb4/0xfc __schedule+0x22c/0x670 schedule+0x4c/0xd0 blk_mq_freeze_queue_wait+0x84/0xc0 nvme_wait_freeze+0x40/0x64 [nvme_core] nvme_reset_work+0x1c0/0x5cc [nvme] process_one_work+0x1d8/0x4b0 worker_thread+0x230/0x440 kthread+0x114/0x120 INFO: task kworker/u249:3:22404 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u249:3 state:D stack: 0 pid:22404 ppid: 2 flags:0x00000028 Workqueue: nvme-wq nvme_scan_work [nvme_core] Call trace: __switch_to+0xb4/0xfc __schedule+0x22c/0x670 schedule+0x4c/0xd0 rwsem_down_write_slowpath+0x32c/0x98c down_write+0x70/0x80 nvme_alloc_ns+0x1ac/0x38c [nvme_core] nvme_validate_or_alloc_ns+0xbc/0x150 [nvme_core] nvme_scan_ns_list+0xe8/0x2e4 [nvme_core] nvme_scan_work+0x60/0x500 [nvme_core] process_one_work+0x1d8/0x4b0 worker_thread+0x260/0x440 kthread+0x114/0x120 INFO: task nvme:28428 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:nvme state:D stack: 0 pid:28428 ppid: 27119 flags:0x00000000 Call trace: __switch_to+0xb4/0xfc __schedule+0x22c/0x670 schedule+0x4c/0xd0 schedule_timeout+0x160/0x194 do_wait_for_common+0xac/0x1d0 __wait_for_common+0x78/0x100 wait_for_completion+0x24/0x30 __flush_work.isra.0+0x74/0x90 flush_work+0x14/0x20 nvme_reset_ctrl_sync+0x50/0x74 [nvme_core] nvme_dev_ioctl+0x1b0/0x250 [nvme_core] __arm64_sys_ioctl+0xa8/0xf0 el0_svc_common+0x88/0x234 do_el0_svc+0x7c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180
The reason for the hang is that nvme_reset_work occurs while nvme_scan_work is still running. nvme_scan_work may add new ns into ctrl->namespaces list after nvme_reset_work frozen all ns->q in ctrl->namespaces list. The newly added ns is not frozen, so nvme_wait_freeze will wait forever. Unfortunately, ctrl->namespaces_rwsem is held by nvme_reset_work, so nvme_scan_work will also wait forever. Now we are deadlocked!
PROCESS1 PROCESS2 ============== ============== nvme_scan_work ... nvme_reset_work nvme_validate_or_alloc_ns nvme_dev_disable nvme_alloc_ns nvme_start_freeze down_write ... nvme_ns_add_to_ctrl_list ... up_write nvme_wait_freeze ... down_read nvme_alloc_ns blk_mq_freeze_queue_wait down_write
Fix by marking the ctrl with say NVME_CTRL_FROZEN flag set in nvme_start_freeze and cleared in nvme_unfreeze. Then the scan can check it before adding the new namespace (under the namespaces_rwsem).
Signed-off-by: Bitao Hu <yaoma@linux.alibaba.com> Reviewed-by: Guixin Liu <kanie@linux.alibaba.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6 |
|
#
8884a56d |
| 27-Oct-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: ensure reset state check ordering
[ Upstream commit e6e7f7ac03e40795346f1b2994a05f507ad8d345 ]
A different CPU may be setting the ctrl->state value, so ensure proper barriers to prevent optim
nvme: ensure reset state check ordering
[ Upstream commit e6e7f7ac03e40795346f1b2994a05f507ad8d345 ]
A different CPU may be setting the ctrl->state value, so ensure proper barriers to prevent optimizing to a stale state. Normally it isn't a problem to observe the wrong state as it is merely advisory to take a quicker path during initialization and error recovery, but seeing an old state can report unexpected ENETRESET errors when a reset request was in fact successful.
Reported-by: Minh Hoang <mh2022@meta.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
a4848c45 |
| 28-Nov-2023 |
Keith Busch <kbusch@kernel.org> |
nvme-core: check for too small lba shift
[ Upstream commit 74fbc88e161424b3b96a22b23a8e3e1edab9d05c ]
The block layer doesn't support logical block sizes smaller than 512 bytes. The nvme spec doesn
nvme-core: check for too small lba shift
[ Upstream commit 74fbc88e161424b3b96a22b23a8e3e1edab9d05c ]
The block layer doesn't support logical block sizes smaller than 512 bytes. The nvme spec doesn't support that small either, but the driver isn't checking to make sure the device responded with usable data. Failing to catch this will result in a kernel bug, either from a division by zero when stacking, or a zero length bio.
Reviewed-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
75cc56af |
| 23-Nov-2023 |
Maurizio Lombardi <mlombard@redhat.com> |
nvme-core: fix a memory leak in nvme_ns_info_from_identify()
[ Upstream commit e3139cef8257fcab1725441e2fd5fd0ccb5481b1 ]
In case of error, free the nvme_id_ns structure that was allocated by nvme_
nvme-core: fix a memory leak in nvme_ns_info_from_identify()
[ Upstream commit e3139cef8257fcab1725441e2fd5fd0ccb5481b1 ]
In case of error, free the nvme_id_ns structure that was allocated by nvme_identify_ns().
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Kanchan Joshi <joshi.k@samsung.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
fedbc873 |
| 19-Dec-2023 |
Maurizio Lombardi <mlombard@redhat.com> |
nvme-pci: fix sleeping function called from interrupt context
[ Upstream commit f6fe0b2d35457c10ec37acc209d19726bdc16dbd ]
the nvme_handle_cqe() interrupt handler calls nvme_complete_async_event()
nvme-pci: fix sleeping function called from interrupt context
[ Upstream commit f6fe0b2d35457c10ec37acc209d19726bdc16dbd ]
the nvme_handle_cqe() interrupt handler calls nvme_complete_async_event() but the latter may call nvme_auth_stop() which is a blocking function. Sleeping functions can't be called in interrupt context
BUG: sleeping function called from invalid context in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/15 Call Trace: <IRQ> __cancel_work_timer+0x31e/0x460 ? nvme_change_ctrl_state+0xcf/0x3c0 [nvme_core] ? nvme_change_ctrl_state+0xcf/0x3c0 [nvme_core] nvme_complete_async_event+0x365/0x480 [nvme_core] nvme_poll_cq+0x262/0xe50 [nvme]
Fix the bug by moving nvme_auth_stop() to fw_act_work (executed by the nvme_wq workqueue)
Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
9514925a |
| 14-Nov-2023 |
Hannes Reinecke <hare@suse.de> |
nvme: catch errors from nvme_configure_metadata()
[ Upstream commit cd9aed606088d36a7ffff3e808db4e76b1854285 ]
nvme_configure_metadata() is issuing I/O, so we might incur an I/O error which will ca
nvme: catch errors from nvme_configure_metadata()
[ Upstream commit cd9aed606088d36a7ffff3e808db4e76b1854285 ]
nvme_configure_metadata() is issuing I/O, so we might incur an I/O error which will cause the connection to be reset. But in that case any further probing will race with reset and cause UAF errors. So return a status from nvme_configure_metadata() and abort probing if there was an I/O error.
Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
2bda53ca |
| 27-Nov-2023 |
Ewan D. Milne <emilne@redhat.com> |
nvme: check for valid nvme_identify_ns() before using it
commit d8b90d600aff181936457f032d116dbd8534db06 upstream.
When scanning namespaces, it is possible to get valid data from the first call to
nvme: check for valid nvme_identify_ns() before using it
commit d8b90d600aff181936457f032d116dbd8534db06 upstream.
When scanning namespaces, it is possible to get valid data from the first call to nvme_identify_ns() in nvme_alloc_ns(), but not from the second call in nvme_update_ns_info_block(). In particular, if the NSID becomes inactive between the two commands, a storage device may return a buffer filled with zero as per 4.1.5.1. In this case, we can get a kernel crash due to a divide-by-zero in blk_stack_limits() because ns->lba_shift will be set to zero.
PID: 326 TASK: ffff95fec3cd8000 CPU: 29 COMMAND: "kworker/u98:10" #0 [ffffad8f8702f9e0] machine_kexec at ffffffff91c76ec7 #1 [ffffad8f8702fa38] __crash_kexec at ffffffff91dea4fa #2 [ffffad8f8702faf8] crash_kexec at ffffffff91deb788 #3 [ffffad8f8702fb00] oops_end at ffffffff91c2e4bb #4 [ffffad8f8702fb20] do_trap at ffffffff91c2a4ce #5 [ffffad8f8702fb70] do_error_trap at ffffffff91c2a595 #6 [ffffad8f8702fbb0] exc_divide_error at ffffffff928506e6 #7 [ffffad8f8702fbd0] asm_exc_divide_error at ffffffff92a00926 [exception RIP: blk_stack_limits+434] RIP: ffffffff92191872 RSP: ffffad8f8702fc80 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff95efa0c91800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 RBP: 00000000ffffffff R8: ffff95fec7df35a8 R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff95fed33c09a8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffffad8f8702fce0] nvme_update_ns_info_block at ffffffffc06d3533 [nvme_core] #9 [ffffad8f8702fd18] nvme_scan_ns at ffffffffc06d6fa7 [nvme_core]
This happened when the check for valid data was moved out of nvme_identify_ns() into one of the callers. Fix this by checking in both callers.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218186 Fixes: 0dd6fff2aad4 ("nvme: bring back auto-removal of deleted namespaces during sequential scan") Cc: stable@vger.kernel.org Signed-off-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3 |
|
#
6cc834ba |
| 12-Sep-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: avoid bogus CRTO values
Some devices are reporting controller ready mode support, but return 0 for CRTO. These devices require a much higher time to ready than that, so they are failing to ini
nvme: avoid bogus CRTO values
Some devices are reporting controller ready mode support, but return 0 for CRTO. These devices require a much higher time to ready than that, so they are failing to initialize after the driver starter preferring that value over CAP.TO.
The spec requires that CAP.TO match the appropritate CRTO value, or be set to 0xff if CRTO is larger than that. This means that CAP.TO can be used to validate if CRTO is reliable, and provides an appropriate fallback for setting the timeout value if not. Use whichever is larger.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217863 Reported-by: Cláudio Sampaio <patola@gmail.com> Reported-by: Felix Yan <felixonmars@archlinux.org> Tested-by: Felix Yan <felixonmars@archlinux.org> Based-on-a-patch-by: Felix Yan <felixonmars@archlinux.org> Cc: stable@vger.kernel.org Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
Revision tags: v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
1b95e817 |
| 11-Jul-2023 |
Ming Lei <ming.lei@redhat.com> |
nvme: fix possible hang when removing a controller during error recovery
Error recovery can be interrupted by controller removal, then the controller is left as quiesced, and IO hang can be caused.
nvme: fix possible hang when removing a controller during error recovery
Error recovery can be interrupted by controller removal, then the controller is left as quiesced, and IO hang can be caused.
Fix the issue by unquiescing controller unconditionally when removing namespaces.
This way is reasonable and safe given forward progress can be made when removing namespaces.
Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reported-by: Chunguang Xu <brookxu.cn@gmail.com> Closes: https://lore.kernel.org/linux-nvme/cover.1685350577.git.chunguang.xu@shopee.com/ Cc: stable@vger.kernel.org Signed-off-by: Ming Lei <ming.lei@redhat.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
ac522fc6 |
| 13-Jul-2023 |
Christoph Hellwig <hch@lst.de> |
nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices
While duplicate IDs are still very harmful, including the potential to easily see changing devices in /dev/disk/by-id, it
nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices
While duplicate IDs are still very harmful, including the potential to easily see changing devices in /dev/disk/by-id, it turn out they are extremely common for cheap end user NVMe devices.
Relax our check for them for so that it doesn't reject the probe on single-ported PCIe devices, but prints a big warning instead. In doubt we'd still like to see quirk entries to disable the potential for changing supposed stable device identifier links, but this will at least allow users how have two (or more) of these devices to use them without having to manually add a new PCI ID entry with the quirk through sysfs or by patching the kernel.
Fixes: 2079f41ec6ff ("nvme: check that EUI/GUID/UUID are globally unique") Cc: stable@vger.kernel.org # 6.0+ Co-developed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
d0dd594b |
| 15-Jun-2023 |
Breno Leitao <leitao@debian.org> |
nvme: Print capabilities changes just once
This current dev_info() could be very verbose and being printed very frequently depending on some userspace application sending some specific commands.
Ju
nvme: Print capabilities changes just once
This current dev_info() could be very verbose and being printed very frequently depending on some userspace application sending some specific commands.
Just print this message once and skip it until the controller resets. Use a controller flag (NVME_CTRL_DIRTY_CAPABILITY) to track if the capability needs a reset.
Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
Revision tags: v6.1.34, v6.1.33, v6.1.32 |
|
#
c917dd96 |
| 30-May-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: skip optional id ctrl csi if it failed
A frequently recieved report is the driver requests the optional Command Set Specific Identify Controller structure. Some controllers report this in thei
nvme: skip optional id ctrl csi if it failed
A frequently recieved report is the driver requests the optional Command Set Specific Identify Controller structure. Some controllers report this in their error log, which tiggers other warnings to user space monitoring the devices.
These error entries are harmless and of questionable value to save in the log, but let's reduce their occurance by not resending the command if it previously failed. This will not prevent the errors on the initial module load, but will greatly reduce their occurance on any rescans and resumes from suspend.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217445 Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
Revision tags: v6.1.31, v6.1.30 |
|
#
35e797b0 |
| 18-May-2023 |
Irvin Cote <irvincoteg@gmail.com> |
nvme-core: use nvme_ns_head_multipath instead of ns->head->disk
Change the way we check for a multipath nshead so as to consistently use the same check to assert the same condition.
Signed-off-by:
nvme-core: use nvme_ns_head_multipath instead of ns->head->disk
Change the way we check for a multipath nshead so as to consistently use the same check to assert the same condition.
Signed-off-by: Irvin Cote <irvincoteg@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
bdbfcd5f |
| 30-May-2023 |
Daniel Gomez <da.gomez@samsung.com> |
nvme: Increase block size variable size to 32-bit
Increase block size variable size to 32-bit unsigned to be able to support block devices larger than 32k (starting from 64 KiB).
Physical and logic
nvme: Increase block size variable size to 32-bit
Increase block size variable size to 32-bit unsigned to be able to support block devices larger than 32k (starting from 64 KiB).
Physical and logical block size already support unsigned 32-bit.
Signed-off-by: Daniel Gomez <da.gomez@samsung.com> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
2110a6bc |
| 17-May-2023 |
Irvin Cote <irvincoteg@gmail.com> |
nvme-core: remove redundant check from nvme_init_ns_head
nvme_find_ns_head already checks that the list of namescpaces in an already existing namespace head is not empty
Signed-off-by: Irvin Cote <
nvme-core: remove redundant check from nvme_init_ns_head
nvme_find_ns_head already checks that the list of namescpaces in an already existing namespace head is not empty
Signed-off-by: Irvin Cote <irvincoteg@gmail.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26 |
|
#
942e21c0 |
| 24-Apr-2023 |
Max Gurtovoy <mgurtovoy@nvidia.com> |
nvme: move sysfs code to a dedicated sysfs.c file
The core.c file became long and hard to maintain. Create a dedicated file to centralize the sysfs functionality. This is a common practice to separa
nvme: move sysfs code to a dedicated sysfs.c file
The core.c file became long and hard to maintain. Create a dedicated file to centralize the sysfs functionality. This is a common practice to separate sysfs/configfs related logic from the main driver logic .c file. For example, in the nvmet module the configfs interface has its own dedicated file.
This patch does not include any functional changes.
Reviewed-by: Keith Busch <kbusch@kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> [merged dhchap memleak fixes, include nvme-auth.h] Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
7ed5cf8e |
| 28-Apr-2023 |
Chaitanya Kulkarni <kch@nvidia.com> |
nvme-core: fix dev_pm_qos memleak
Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to avoid following kmemleak:-
blktests (master) # kmemleak-clear; ./check nvme/044; blktests (ma
nvme-core: fix dev_pm_qos memleak
Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to avoid following kmemleak:-
blktests (master) # kmemleak-clear; ./check nvme/044; blktests (master) # kmemleak-scan ; kmemleak-show nvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124s unreferenced object 0xffff888110c46240 (size 96): comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Link: https://lore.kernel.org/linux-nvme/CAHj4cs-nDaKzMx2txO4dbE+Mz9ePwLtU0e3egz+StmzOUgWUrA@mail.gmail.com/ Fixes: f50fff73d620 ("nvme: implement In-Band authentication") Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Tested-by: Yi Zhang <yi.zhang@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|