<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/nvme/target, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-08-15T10:17:03Z</updated>
<entry>
<title>nvmet: exit debugfs after discovery subsystem exits</title>
<updated>2025-08-15T10:17:03Z</updated>
<author>
<name>Mohamed Khalfella</name>
</author>
<published>2025-08-07T05:35:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6be5de28158990e934081a1770a5a4ee6aa40cff'/>
<id>urn:sha1:6be5de28158990e934081a1770a5a4ee6aa40cff</id>
<content type='text'>
[ Upstream commit 80f21806b8e34ae1e24c0fc6a0f0dfd9b055e130 ]

Commit 528589947c180 ("nvmet: initialize discovery subsys after debugfs
is initialized") changed nvmet_init() to initialize nvme discovery after
"nvmet" debugfs directory is initialized. The change broke nvmet_exit()
because discovery subsystem now depends on debugfs. Debugfs should be
destroyed after discovery subsystem. Fix nvmet_exit() to do that.

Reported-by: Yi Zhang &lt;yi.zhang@redhat.com&gt;
Closes: https://lore.kernel.org/all/CAHj4cs96AfFQpyDKF_MdfJsnOEo=2V7dQgqjFv+k3t7H-=yGhA@mail.gmail.com/
Fixes: 528589947c180 ("nvmet: initialize discovery subsys after debugfs is initialized")
Signed-off-by: Mohamed Khalfella &lt;mkhalfella@purestorage.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Link: https://lore.kernel.org/r/20250807053507.2794335-1-mkhalfella@purestorage.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: initialize discovery subsys after debugfs is initialized</title>
<updated>2025-08-15T10:16:58Z</updated>
<author>
<name>Mohamed Khalfella</name>
</author>
<published>2025-07-25T20:50:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b2577ac44b76476249dc8e641941a4879912167d'/>
<id>urn:sha1:b2577ac44b76476249dc8e641941a4879912167d</id>
<content type='text'>
[ Upstream commit 528589947c1802b9357c2a9b96d88cc4a11cd88b ]

During nvme target initialization discovery subsystem is initialized
before "nvmet" debugfs directory is created. This results in discovery
subsystem debugfs directory to be created in debugfs root directory.

nvmet_init() -&gt;
  nvmet_init_discovery() -&gt;
    nvmet_subsys_alloc() -&gt;
      nvmet_debugfs_subsys_setup()

In other words, the codepath above is exeucted before nvmet_debugfs is
created. We get /sys/kernel/debug/nqn.2014-08.org.nvmexpress.discovery
instead of /sys/kernel/debug/nvmet/nqn.2014-08.org.nvmexpress.discovery.
Move nvmet_init_discovery() call after nvmet_init_debugfs() to fix it.

Fixes: 649fd41420a8 ("nvmet: add debugfs support")
Signed-off-by: Mohamed Khalfella &lt;mkhalfella@purestorage.com&gt;
Reviewed-by: Chaitanya Kulkarni &lt;kch@nvidia.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@kernel.org&gt;
Reviewed-by: Daniel Wagner &lt;dwagner@suse.de&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet-tcp: fix callback lock for TLS handshake</title>
<updated>2025-07-24T06:58:35Z</updated>
<author>
<name>Maurizio Lombardi</name>
</author>
<published>2025-07-04T14:44:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6cbd9f5ad8f2b67eba7093acbc7d924b0aa9dfc2'/>
<id>urn:sha1:6cbd9f5ad8f2b67eba7093acbc7d924b0aa9dfc2</id>
<content type='text'>
[ Upstream commit 0523c6cc87e558c50ff4489c87c54c55068b1169 ]

When restoring the default socket callbacks during a TLS handshake, we
need to acquire a write lock on sk_callback_lock.  Previously, a read
lock was used, which is insufficient for modifying sk_user_data and
sk_data_ready.

Fixes: 675b453e0241 ("nvmet-tcp: enable TLS handshake upcall")
Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: fix memory leak of bio integrity</title>
<updated>2025-07-10T14:08:40Z</updated>
<author>
<name>Dmitry Bogdanov</name>
</author>
<published>2025-06-25T11:45:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e2028fcf924d1c6df017033c8d6e28b735a0508'/>
<id>urn:sha1:2e2028fcf924d1c6df017033c8d6e28b735a0508</id>
<content type='text'>
[ Upstream commit 190f4c2c863af7cc5bb354b70e0805f06419c038 ]

If nvmet receives commands with metadata there is a continuous memory
leak of kmalloc-128 slab or more precisely bio-&gt;bi_integrity.

Since commit bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")
each user of bio_init has to use bio_uninit as well. Otherwise the bio
integrity is not getting free. Nvmet uses bio_init for inline bios.

Uninit the inline bio to complete deallocation of integrity in bio.

Fixes: bf4c89fc8797 ("block: don't call bio_uninit from bio_endio")
Signed-off-by: Dmitry Bogdanov &lt;d.bogdanov@yadro.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet-fcloop: access fcpreq only when holding reqlock</title>
<updated>2025-06-19T13:41:01Z</updated>
<author>
<name>Daniel Wagner</name>
</author>
<published>2025-05-07T12:23:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=87457ff0c4f198ab6db3f225b4be8963497ffaae'/>
<id>urn:sha1:87457ff0c4f198ab6db3f225b4be8963497ffaae</id>
<content type='text'>
[ Upstream commit 47a827cd7929d0550c3496d70b417fcb5649b27b ]

The abort handling logic expects that the state and the fcpreq are only
accessed when holding the reqlock lock.

While at it, only handle the aborts in the abort handler.

Signed-off-by: Daniel Wagner &lt;wagi@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvme: fix command limits status code</title>
<updated>2025-06-19T13:40:42Z</updated>
<author>
<name>Keith Busch</name>
</author>
<published>2025-05-20T20:20:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=75141d56b6268fd5c801c0035a1d4adfd24cfe69'/>
<id>urn:sha1:75141d56b6268fd5c801c0035a1d4adfd24cfe69</id>
<content type='text'>
[ Upstream commit 10f4a7cd724e34b7a6ff96e57ac49dc0cadececc ]

The command specific status code, 0x183, was introduced in the NVMe 2.0
specification defined to "Command Size Limits Exceeded" and only ever
applied to DSM and Copy commands.  Fix the name and, remove the
incorrect translation to error codes and special treatment in the
target code for it.

Fixes: 3b7c33b28a44d4 ("nvme.h: add Write Zeroes definitions")
Cc: Chaitanya Kulkarni &lt;chaitanyak@nvidia.com&gt;
Reviewed-by: Chaitanya Kulkarni &lt;kch@nvidia.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: pci-epf: remove NVMET_PCI_EPF_Q_IS_SQ</title>
<updated>2025-05-13T05:57:12Z</updated>
<author>
<name>Damien Le Moal</name>
</author>
<published>2025-05-08T23:25:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8113d610a79885db5d53b5e01138ed4159e05ce9'/>
<id>urn:sha1:8113d610a79885db5d53b5e01138ed4159e05ce9</id>
<content type='text'>
The flag NVMET_PCI_EPF_Q_IS_SQ is set but never used. Remove it.

Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: pci-epf: improve debug message</title>
<updated>2025-05-13T05:57:11Z</updated>
<author>
<name>Damien Le Moal</name>
</author>
<published>2025-05-08T23:25:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4f6f3f4fe31695cd69874457573a2236c05fef02'/>
<id>urn:sha1:4f6f3f4fe31695cd69874457573a2236c05fef02</id>
<content type='text'>
Improve the debug message of nvmet_pci_epf_create_cq() to indicate if a
completion queue IRQ is disabled.

Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: pci-epf: cleanup nvmet_pci_epf_raise_irq()</title>
<updated>2025-05-13T05:57:11Z</updated>
<author>
<name>Damien Le Moal</name>
</author>
<published>2025-05-08T23:25:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4236e600bf902202214aa6277e84c4738c56f762'/>
<id>urn:sha1:4236e600bf902202214aa6277e84c4738c56f762</id>
<content type='text'>
There is no point in taking the controller irq_lock and calling
nvmet_pci_epf_should_raise_irq() for a completion queue which does not
have IRQ enabled (NVMET_PCI_EPF_Q_IRQ_ENABLED flag is not set).
Move the test for the NVMET_PCI_EPF_Q_IRQ_ENABLED flag out of
nvmet_pci_epf_should_raise_irq() to the top of nvmet_pci_epf_raise_irq()
to return early when no IRQ should be raised.

Also, use dev_err_ratelimited() to avoid a message storm under load when
raising IRQs is failing.

Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Reviewed-by: Niklas Cassel &lt;cassel@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: pci-epf: do not fall back to using INTX if not supported</title>
<updated>2025-05-13T05:57:11Z</updated>
<author>
<name>Damien Le Moal</name>
</author>
<published>2025-05-08T23:25:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2c3a6f6a28051f323baf19b48af86e48b812831d'/>
<id>urn:sha1:2c3a6f6a28051f323baf19b48af86e48b812831d</id>
<content type='text'>
Some endpoint PCIe controllers do not support raising legacy INTX
interrupts. This support is indicated by the intx_capable field of
struct pci_epc_features. Modify nvmet_pci_epf_raise_irq() to not
automatically fallback to trying raising an INTX interrupt after an MSI
or MSI-X error if the controller does not support INTX.

Signed-off-by: Damien Le Moal &lt;dlemoal@kernel.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
</feed>
