Merge tag 'v6.6.84' into for/openbmc/dev-6.6

This is the 6.6.84 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmffFS0ACgkQONu9yGCS
# aT53cw/+ND0RyKj

Merge tag 'v6.6.84' into for/openbmc/dev-6.6

This is the 6.6.84 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmffFS0ACgkQONu9yGCS
# aT53cw/+ND0RyKjVr11YxrMGR7mtAUVMUzE4bcJWGgl7M/BF+2bTWcic5n648P9O
# y/hr24jUDpK8kVRvsxlScyPX59drz9f+wDu1nC3oGTFRu2Cs4SG2KGAJoXt0NWLc
# oWZ4PskH9YxCK1bjHqSOgVC1+mUqrCASgp7bS1Y4Xd6mUPVN5A3nkq4AUaAq5NJP
# 3VNLKJLNEgusjFxZKYQX4f7I6f5PPYaEONxXje+mGYduGOjV7kePa6cyzZDWxger
# ZKLyvG/FIDDIIi6wd0x0aOTR2318HfDkz4xfNaw58II61XukSRrZ1PoO+4Jo6l26
# aAbY4Cdv0QhCvmI4AqRGZcSTrNFZoroAwHbUjzjkX5DEMF0UoqqKJb8QFQB/HtC5
# fKzXMyRcztB2kFldOQgZszHzHzwkzvJuSIQgBNYkQ6Kj2yvnydsDUKSJJIY4NNz/
# Ii3q4lflFAYmJUNfzM7lofMXAAiwXKumnTsUZ1AYbWKfciJveX+QO2mqFmDM0Vdr
# PdyoO5X7iZkDF0B+GKScUryStI3mBnqCk6XVBIsN+ucobus2EdDVxCsNObEel7v9
# nNRqU16+0OhWP9MNyg6sL64Kwb1VrNoUOaspL7cn01v+Iw18i3qiXblNdwpWHvO3
# Y0HNwdPIltaPj5qubkAoS6L2DFNzfa7oVgFZafNbLq80YWeQqPQ=
# =i2jc
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 23 Mar 2025 06:23:17 ACDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal]
# gpg: gregkh@kernel.org: Verified 13 signatures in the past 8 weeks. Encrypted
# 0 messages.
# gpg: Warning: you have yet to encrypt a message to this key!
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

show more ...

nvme: only allow entering LIVE from CONNECTING state

[ Upstream commit d2fe192348f93fe3a0cb1e33e4aba58e646397f4 ]

The fabric transports and also the PCI transport are not entering the
LIVE state fr

nvme: only allow entering LIVE from CONNECTING state

[ Upstream commit d2fe192348f93fe3a0cb1e33e4aba58e646397f4 ]

The fabric transports and also the PCI transport are not entering the
LIVE state from NEW or RESETTING. This makes the state machine more
restrictive and allows to catch not supported state transitions, e.g.
directly switching from RESETTING to LIVE.

Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Daniel Wagner <wagi@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.78' into for/openbmc/dev-6.6

This is the 6.6.78 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmey9hUACgkQONu9yGCS
# aT7Ecw//Ts3+DVy

Merge tag 'v6.6.78' into for/openbmc/dev-6.6

This is the 6.6.78 stable release

# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmey9hUACgkQONu9yGCS
# aT7Ecw//Ts3+DVyM1iMAUj6zZHQ7+UVqRxvVQ0yJwe1gzECrasxhu+ack0MDuRXb
# RTOHzrVkpHrOZ58T0kkkp4DVea4bq8kpq9wnnOxpta4SzQYuwxuypxw9ZML2u8kR
# A77akcb4MPBpeTwlLUTEX1K2CrF+Wfz9ZGauJRTmrnWogJe1hZWTxr3tc9TqGeMA
# tk93g9kWy7hxxubPJpAUbNVmWbpm/TfZuMAEyktpNf8E0DLukHjr0If85t3BC0KZ
# kxLSCN05ZmWoZVQjmaerS8pXFvwj08OeRbUtW+b4oaraUV7vsrwxW/WcOqb6vIBn
# AEohV3w7CpFj0moRPXJO+UuxmP5TrSCIGUaEGjnrMCPJfjxwnmFYaf+9DYi3bR4H
# U8UyU55PhGTWlWg238Qp64KsDn41M/rlNKOiPEGq08+1Qnhoj4LWfFFHzLhO8y4R
# xLfsOzu6cHgEUnMKPTV6TnkWSCEL9t51wgzsqa7iKdO7kyAL1YCb4+LkskJAqUzW
# t3i8Sw8nygE7cKQ5eHzG6CClKEfgxtMGiR63gan9npEUgcFbzoVP0uz9RYz7+0Vz
# 5oE2ZSGXSoiJNWhdjJVrr1gqg/TwrzmVjsmUEnf4uTDABh9GXL+g+UZHGSMvvvYi
# T8gUY4aFwXO5fGKN1RW8RXJSbJr4nKYde2s/h4ZT1EwRVdj5Zcc=
# =+i1A
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 17 Feb 2025 19:10:53 ACDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Good signature from "Greg Kroah-Hartman <gregkh@kernel.org>" [marginal]
# gpg: gregkh@kernel.org: Verified 7 signatures in the past 3 weeks. Encrypted
# 0 messages.
# gpg: Warning: you have yet to encrypt a message to this key!
# gpg: Warning: if you think you've seen more signatures by this key and user
# id, then this key might be a forgery! Carefully examine the email address
# for small variations. If the key is suspect, then use
# gpg --tofu-policy bad 647F28654894E3BD457199BE38DBBDC86092693E
# to mark it as being bad.
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

show more ...

nvme: handle connectivity loss in nvme_set_queue_count

[ Upstream commit 294b2b7516fd06a8dd82e4a6118f318ec521e706 ]

When the set feature attempts fails with any NVME status code set in
nvme_set_que

nvme: handle connectivity loss in nvme_set_queue_count

[ Upstream commit 294b2b7516fd06a8dd82e4a6118f318ec521e706 ]

When the set feature attempts fails with any NVME status code set in
nvme_set_queue_count, the function still report success. Though the
numbers of queues set to 0. This is done to support controllers in
degraded state (the admin queue is still up and running but no IO
queues).

Though there is an exception. When nvme_set_features reports an host
path error, nvme_set_queue_count should propagate this error as the
connectivity is lost, which means also the admin queue is not working
anymore.

Fixes: 9a0be7abb62f ("nvme: refactor set_queue_count")
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Daniel Wagner <wagi@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.76' into for/openbmc/dev-6.6

This is the 6.6.76 stable release

Conflicts:
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts

Conflicts were resolved in favour of our side a

Merge tag 'v6.6.76' into for/openbmc/dev-6.6

This is the 6.6.76 stable release

Conflicts:
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts

Conflicts were resolved in favour of our side as the upstream stable
branches cherry-picked a small number of changes out of a much large
series, which has already been backported.

show more ...

nvme: fix bogus kzalloc() return check in nvme_init_effects_log()

[ Upstream commit 170e086ad3997f816d1f551f178a03a626a130b7 ]

nvme_init_effects_log() returns failure when kzalloc() is successful,

nvme: fix bogus kzalloc() return check in nvme_init_effects_log()

[ Upstream commit 170e086ad3997f816d1f551f178a03a626a130b7 ]

nvme_init_effects_log() returns failure when kzalloc() is successful,
which is obviously wrong and causes failures to boot. Correct the
check.

Fixes: d4a95adeabc6 ("nvme: Add error path for xa_store in nvme_init_effects")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

nvme: Add error path for xa_store in nvme_init_effects

[ Upstream commit d4a95adeabc6b5a39405e49c6d5ed14dd83682c4 ]

The xa_store() may fail due to memory allocation failure because there
is no guar

nvme: Add error path for xa_store in nvme_init_effects

[ Upstream commit d4a95adeabc6b5a39405e49c6d5ed14dd83682c4 ]

The xa_store() may fail due to memory allocation failure because there
is no guarantee that the index NVME_CSI_NVM is already used. This fix
introduces a new function to handle the error path.

Fixes: cc115cbe12d9 ("nvme: always initialize known command effects")
Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr>
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 ...

nvme: Add error check for xa_store in nvme_get_effects_log

[ Upstream commit ac32057acc7f3d7a238dafaa9b2aa2bc9750080e ]

The xa_store() may fail due to memory allocation failure because there
is no

nvme: Add error check for xa_store in nvme_get_effects_log

[ Upstream commit ac32057acc7f3d7a238dafaa9b2aa2bc9750080e ]

The xa_store() may fail due to memory allocation failure because there
is no guarantee that the index csi is already used. This fix adds an
error check of the return value of xa_store() in nvme_get_effects_log().

Fixes: 1cf7a12e09aa ("nvme: use an xarray to lookup the Commands Supported and Effects log")
Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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 ...

Merge tag 'v6.6.70' into for/openbmc/dev-6.6

This is the 6.6.70 stable release

Conflicts:
include/linux/usb/chipidea.h

Conflict was a trivial addition.

Signed-off-by: Andrew Jeffery <andrew@c

Merge tag 'v6.6.70' into for/openbmc/dev-6.6

This is the 6.6.70 stable release

Conflicts:
include/linux/usb/chipidea.h

Conflict was a trivial addition.

Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

Revert "nvme: make keep-alive synchronous operation"

[ Upstream commit 84488282166de6b6760ada8030e87aaa08bce3aa ]

This reverts commit d06923670b5a5f609603d4a9fee4dec02d38de9c.

It was realized that

Revert "nvme: make keep-alive synchronous operation"

[ Upstream commit 84488282166de6b6760ada8030e87aaa08bce3aa ]

This reverts commit d06923670b5a5f609603d4a9fee4dec02d38de9c.

It was realized that the fix implemented to contain the race condition
among the keep alive task and the fabric shutdown code path in the commit
d06923670b5ia ("nvme: make keep-alive synchronous operation") is not
optimal. The reason being keep-alive runs under the workqueue and making
it synchronous would waste a workqueue context.
Furthermore, we later found that the above race condition is a regression
caused due to the changes implemented in commit a54a93d0e359 ("nvme: move
stopping keep-alive into nvme_uninit_ctrl()"). So we decided to revert the
commit d06923670b5a ("nvme: make keep-alive synchronous operation") and
then fix the regression.

Link: https://lore.kernel.org/all/196f4013-3bbf-43ff-98b4-9cb2a96c20c2@grimberg.me/
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

nvme: use helper nvme_ctrl_state in nvme_keep_alive_finish function

[ Upstream commit 599d9f3a10eec69ef28a90161763e4bd7c9c02bf ]

We no more need acquiring ctrl->lock before accessing the
NVMe contr

nvme: use helper nvme_ctrl_state in nvme_keep_alive_finish function

[ Upstream commit 599d9f3a10eec69ef28a90161763e4bd7c9c02bf ]

We no more need acquiring ctrl->lock before accessing the
NVMe controller state and instead we can now use the helper
nvme_ctrl_state. So replace the use of ctrl->lock from
nvme_keep_alive_finish function with nvme_ctrl_state call.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Stable-dep-of: 84488282166d ("Revert "nvme: make keep-alive synchronous operation"")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.64' into for/openbmc/dev-6.6

This is the 6.6.64 stable release

nvme-multipath: implement "queue-depth" iopolicy

[ Upstream commit f227345f0a70f011647ae7ae12778bf258ff71f2 ]

The round-robin path selector is inefficient in cases where there is a
difference in la

nvme-multipath: implement "queue-depth" iopolicy

[ Upstream commit f227345f0a70f011647ae7ae12778bf258ff71f2 ]

The round-robin path selector is inefficient in cases where there is a
difference in latency between paths. In the presence of one or more
high latency paths the round-robin selector continues to use the high
latency path equally. This results in a bias towards the highest latency
path and can cause a significant decrease in overall performance as IOs
pile on the highest latency path. This problem is acute with NVMe-oF
controllers.

The queue-depth path selector sends I/O down the path with the lowest
number of requests in its request queue. Paths with lower latency will
clear requests more quickly and have less requests queued compared to
higher latency paths. The goal of this path selector is to make more use
of lower latency paths which will bring down overall IO latency and
increase throughput and performance.

Signed-off-by: Thomas Song <tsong@purestorage.com>
[emilne: commandeered patch developed by Thomas Song @ Pure Storage]
Co-developed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Co-developed-by: John Meneghini <jmeneghi@redhat.com>
Signed-off-by: John Meneghini <jmeneghi@redhat.com>
Link: https://lore.kernel.org/linux-nvme/20240509202929.831680-1-jmeneghi@redhat.com/
Tested-by: Marco Patalano <mpatalan@redhat.com>
Tested-by: Jyoti Rani <jrani@purestorage.com>
Tested-by: John Meneghini <jmeneghi@redhat.com>
Reviewed-by: Randy Jennings <randyj@purestorage.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
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>
Stable-dep-of: 5dd18f09ce73 ("nvme/multipath: Fix RCU list traversal to use SRCU primitive")
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.62' into for/openbmc/dev-6.6

This is the 6.6.62 stable release

nvme/host: Fix RCU list traversal to use SRCU primitive

[ Upstream commit 6d1c69945ce63a9fba22a4abf646cf960d878782 ]

The code currently uses list_for_each_entry_rcu() while holding an SRCU
lock, tr

nvme/host: Fix RCU list traversal to use SRCU primitive

[ Upstream commit 6d1c69945ce63a9fba22a4abf646cf960d878782 ]

The code currently uses list_for_each_entry_rcu() while holding an SRCU
lock, triggering false positive warnings with CONFIG_PROVE_RCU=y
enabled:

drivers/nvme/host/core.c:3770 RCU-list traversed in non-reader section!!

While the list is properly protected by SRCU lock, the code uses the wrong
list traversal primitive. Replace list_for_each_entry_rcu() with
list_for_each_entry_srcu() to correctly indicate SRCU-based protection
and eliminate the false warning.

Fixes: be647e2c76b2 ("nvme: use srcu for iterating namespace list")
Signed-off-by: Breno Leitao <leitao@debian.org>
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 ...

nvme: make keep-alive synchronous operation

[ Upstream commit d06923670b5a5f609603d4a9fee4dec02d38de9c ]

The nvme keep-alive operation, which executes at a periodic interval,
could potentially snea

nvme: make keep-alive synchronous operation

[ Upstream commit d06923670b5a5f609603d4a9fee4dec02d38de9c ]

The nvme keep-alive operation, which executes at a periodic interval,
could potentially sneak in while shutting down a fabric controller.
This may lead to a race between the fabric controller admin queue
destroy code path (invoked while shutting down controller) and hw/hctx
queue dispatcher called from the nvme keep-alive async request queuing
operation. This race could lead to the kernel crash shown below:

Call Trace:
autoremove_wake_function+0x0/0xbc (unreliable)
__blk_mq_sched_dispatch_requests+0x114/0x24c
blk_mq_sched_dispatch_requests+0x44/0x84
blk_mq_run_hw_queue+0x140/0x220
nvme_keep_alive_work+0xc8/0x19c [nvme_core]
process_one_work+0x200/0x4e0
worker_thread+0x340/0x504
kthread+0x138/0x140
start_kernel_thread+0x14/0x18

While shutting down fabric controller, if nvme keep-alive request sneaks
in then it would be flushed off. The nvme_keep_alive_end_io function is
then invoked to handle the end of the keep-alive operation which
decrements the admin->q_usage_counter and assuming this is the last/only
request in the admin queue then the admin->q_usage_counter becomes zero.
If that happens then blk-mq destroy queue operation (blk_mq_destroy_
queue()) which could be potentially running simultaneously on another
cpu (as this is the controller shutdown code path) would forward
progress and deletes the admin queue. So, now from this point onward
we are not supposed to access the admin queue resources. However the
issue here's that the nvme keep-alive thread running hw/hctx queue
dispatch operation hasn't yet finished its work and so it could still
potentially access the admin queue resource while the admin queue had
been already deleted and that causes the above crash.

This fix helps avoid the observed crash by implementing keep-alive as a
synchronous operation so that we decrement admin->q_usage_counter only
after keep-alive command finished its execution and returns the command
status back up to its caller (blk_execute_rq()). This would ensure that
fabric shutdown code path doesn't destroy the fabric admin queue until
keep-alive request finished execution and also keep-alive thread is not
running hw/hctx queue dispatch operation.

Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

nvme: disable CC.CRIME (NVME_CC_CRIME)

[ Upstream commit 0ce96a6708f34280a536263ee5c67e20c433dcce ]

Disable NVME_CC_CRIME so that CSTS.RDY indicates that the media
is ready and able to handle comma

nvme: disable CC.CRIME (NVME_CC_CRIME)

[ Upstream commit 0ce96a6708f34280a536263ee5c67e20c433dcce ]

Disable NVME_CC_CRIME so that CSTS.RDY indicates that the media
is ready and able to handle commands without returning
NVME_SC_ADMIN_COMMAND_MEDIA_NOT_READY.

Signed-off-by: Greg Joyce <gjoyce@linux.ibm.com>
Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
Tested-by: Nilay Shroff <nilay@linux.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.48' into for/openbmc/dev-6.6

This is the 6.6.48 stable release

nvme: fix namespace removal list

[ Upstream commit ff0ffe5b7c3c12c6e0cca16652905963ae817b44 ]

This function wants to move a subset of a list from one element to the
tail into another list. It also

nvme: fix namespace removal list

[ Upstream commit ff0ffe5b7c3c12c6e0cca16652905963ae817b44 ]

This function wants to move a subset of a list from one element to the
tail into another list. It also needs to use the srcu synchronize
instead of the regular rcu version. Do this one element at a time
because that's the only to do it.

Fixes: be647e2c76b27f4 ("nvme: use srcu for iterating namespace list")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

nvme: use srcu for iterating namespace list

[ Upstream commit be647e2c76b27f409cdd520f66c95be888b553a3 ]

The nvme pci driver synchronizes with all the namespace queues during a
reset to ensure that

nvme: use srcu for iterating namespace list

[ Upstream commit be647e2c76b27f409cdd520f66c95be888b553a3 ]

The nvme pci driver synchronizes with all the namespace queues during a
reset to ensure that there's no pending timeout work.

Meanwhile the timeout work potentially iterates those same namespaces to
freeze their queues.

Each of those namespace iterations use the same read lock. If a write
lock should somehow get between the synchronize and freeze steps, then
forward progress is deadlocked.

We had been relying on the nvme controller state machine to ensure the
reset work wouldn't conflict with timeout work. That guarantee may be a
bit fragile to rely on, so iterate the namespace lists without taking
potentially circular locks, as reported by lockdep.

Link: https://lore.kernel.org/all/20220930001943.zdbvolc3gkekfmcv@shindev/
Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Tested-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.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 ...

nvme: clear caller pointer on identify failure

[ Upstream commit 7e80eb792bd7377a20f204943ac31c77d859be89 ]

The memory allocated for the identification is freed on failure. Set
it to NULL so the ca

nvme: clear caller pointer on identify failure

[ Upstream commit 7e80eb792bd7377a20f204943ac31c77d859be89 ]

The memory allocated for the identification is freed on failure. Set
it to NULL so the caller doesn't have a pointer to that freed address.

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 ...

Merge tag 'v6.6.42' into dev-6.6

This is the 6.6.42 stable release

nvme: avoid double free special payload

[ Upstream commit e5d574ab37f5f2e7937405613d9b1a724811e5ad ]

If a discard request needs to be retried, and that retry may fail before
a new special payload i

nvme: avoid double free special payload

[ Upstream commit e5d574ab37f5f2e7937405613d9b1a724811e5ad ]

If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned.

Signed-off-by: Chunguang Xu <chunguang.xu@shopee.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

Merge tag 'v6.6.33' into dev-6.6

This is the 6.6.33 stable release

nvme-multipath: fix io accounting on failover

[ Upstream commit a2e4c5f5f68dbd206f132bc709b98dea64afc3b8 ]

There are io stats accounting that needs to be handled, so don't call
blk_mq_end_request()

nvme-multipath: fix io accounting on failover

[ Upstream commit a2e4c5f5f68dbd206f132bc709b98dea64afc3b8 ]

There are io stats accounting that needs to be handled, so don't call
blk_mq_end_request() directly. Use the existing nvme_end_req() helper
that already handles everything.

Fixes: d4d957b53d91ee ("nvme-multipath: support io stats on the mpath device")
Reviewed-by: Christoph Hellwig <hch@lst.de>
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 ...