<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/nvme, branch v6.7</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.7</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.7'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-12-19T20:41:05Z</updated>
<entry>
<title>nvme-pci: fix sleeping function called from interrupt context</title>
<updated>2023-12-19T20:41:05Z</updated>
<author>
<name>Maurizio Lombardi</name>
<email>mlombard@redhat.com</email>
</author>
<published>2023-12-19T16:48:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f6fe0b2d35457c10ec37acc209d19726bdc16dbd'/>
<id>urn:sha1:f6fe0b2d35457c10ec37acc209d19726bdc16dbd</id>
<content type='text'>
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:
     &lt;IRQ&gt;
      __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 &lt;mlombard@redhat.com&gt;
Reviewed-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "nvme-fc: fix race between error recovery and creating association"</title>
<updated>2023-12-19T16:58:46Z</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2023-12-18T16:19:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d3e8b1858734bf46cda495be4165787b9a3981a6'/>
<id>urn:sha1:d3e8b1858734bf46cda495be4165787b9a3981a6</id>
<content type='text'>
The commit was identified to might sleep in invalid context and is
blocking regression testing.

This reverts commit ee6fdc5055e916b1dd497f11260d4901c4c1e55e.

Link: https://lore.kernel.org/linux-nvme/hkhl56n665uvc6t5d6h3wtx7utkcorw4xlwi7d2t2bnonavhe6@xaan6pu43ap6/
Link: https://lists.infradead.org/pipermail/linux-nvme/2023-December/043756.html
Reported-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Reported-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Cc: Michael Liang &lt;mliang@purestorage.com&gt;
Tested-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Reviewed-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-pci: Add sleep quirk for Kingston drives</title>
<updated>2023-12-07T16:53:20Z</updated>
<author>
<name>Georg Gottleuber</name>
<email>ggo@tuxedocomputers.com</email>
</author>
<published>2023-09-20T08:52:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=107b4e063d78c300b21e2d5291b1aa94c514ea5b'/>
<id>urn:sha1:107b4e063d78c300b21e2d5291b1aa94c514ea5b</id>
<content type='text'>
Some Kingston NV1 and A2000 are wasting a lot of power on specific TUXEDO
platforms in s2idle sleep if 'Simple Suspend' is used.

This patch applies a new quirk 'Force No Simple Suspend' to achieve a
low power sleep without 'Simple Suspend'.

Signed-off-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Signed-off-by: Georg Gottleuber &lt;ggo@tuxedocomputers.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: fix deadlock between reset and scan</title>
<updated>2023-12-04T16:39:04Z</updated>
<author>
<name>Bitao Hu</name>
<email>yaoma@linux.alibaba.com</email>
</author>
<published>2023-11-30T02:13:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=839a40d1e730977d4448d141fa653517c2959a88'/>
<id>urn:sha1:839a40d1e730977d4448d141fa653517c2959a88</id>
<content type='text'>
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&lt;=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 &gt; /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 &gt; /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 &gt; /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-&gt;namespaces
list after nvme_reset_work frozen all ns-&gt;q in ctrl-&gt;namespaces list.
The newly added ns is not frozen, so nvme_wait_freeze will wait forever.
Unfortunately, ctrl-&gt;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 &lt;yaoma@linux.alibaba.com&gt;
Reviewed-by: Guixin Liu &lt;kanie@linux.alibaba.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: prevent potential spectre v1 gadget</title>
<updated>2023-12-04T16:39:04Z</updated>
<author>
<name>Nitesh Shetty</name>
<email>nj.shetty@samsung.com</email>
</author>
<published>2023-11-28T12:29:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=20dc66f2d76b4a410df14e4675e373b718babc34'/>
<id>urn:sha1:20dc66f2d76b4a410df14e4675e373b718babc34</id>
<content type='text'>
This patch fixes the smatch warning, "nvmet_ns_ana_grpid_store() warn:
potential spectre issue 'nvmet_ana_group_enabled' [w] (local cap)"
Prevent the contents of kernel memory from being leaked to  user space
via speculative execution by using array_index_nospec.

Signed-off-by: Nitesh Shetty &lt;nj.shetty@samsung.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: improve NVME_HOST_AUTH and NVME_TARGET_AUTH config descriptions</title>
<updated>2023-12-04T16:39:03Z</updated>
<author>
<name>Shin'ichiro Kawasaki</name>
<email>shinichiro.kawasaki@wdc.com</email>
</author>
<published>2023-11-29T04:49:51Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=29ac4b2f9263f52ba12fa35832cc6506ce3b4793'/>
<id>urn:sha1:29ac4b2f9263f52ba12fa35832cc6506ce3b4793</id>
<content type='text'>
Currently two similar config options NVME_HOST_AUTH and NVME_TARGET_AUTH
have almost same descriptions. It is confusing to choose them in
menuconfig. Improve the descriptions to distinguish them.

Signed-off-by: Shin'ichiro Kawasaki &lt;shinichiro.kawasaki@wdc.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-ioctl: move capable() admin check to the end</title>
<updated>2023-12-04T16:39:03Z</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2023-05-02T18:43:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=7be866b1cf0bf1dfa74480fe8097daeceda68622'/>
<id>urn:sha1:7be866b1cf0bf1dfa74480fe8097daeceda68622</id>
<content type='text'>
This can be an expensive call on some kernel configs. Move it to the end
after checking the cheaper ways to determine if the command is allowed.

Reviewed-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: ensure reset state check ordering</title>
<updated>2023-12-04T16:39:03Z</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2023-10-27T17:58:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e6e7f7ac03e40795346f1b2994a05f507ad8d345'/>
<id>urn:sha1:e6e7f7ac03e40795346f1b2994a05f507ad8d345</id>
<content type='text'>
A different CPU may be setting the ctrl-&gt;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 &lt;mh2022@meta.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
</content>
</entry>
<entry>
<title>nvme: introduce helper function to get ctrl state</title>
<updated>2023-12-04T16:39:03Z</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2023-10-30T15:13:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5c687c287c46fadb14644091823298875a5216aa'/>
<id>urn:sha1:5c687c287c46fadb14644091823298875a5216aa</id>
<content type='text'>
The controller state is typically written by another CPU, so reading it
should ensure no optimizations are taken. This is a repeated pattern in
the driver, so start with adding a convenience function that returns the
controller state with READ_ONCE().

Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme-core: check for too small lba shift</title>
<updated>2023-12-01T15:49:50Z</updated>
<author>
<name>Keith Busch</name>
<email>kbusch@kernel.org</email>
</author>
<published>2023-11-28T17:36:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=74fbc88e161424b3b96a22b23a8e3e1edab9d05c'/>
<id>urn:sha1:74fbc88e161424b3b96a22b23a8e3e1edab9d05c</id>
<content type='text'>
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 &lt;axboe@kernel.dk&gt;
Signed-off-by: Keith Busch &lt;kbusch@kernel.org&gt;
</content>
</entry>
</feed>
