<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/nvme/target, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2019-06-25T03:34:51Z</updated>
<entry>
<title>nvmet: fix data_len to 0 for bdev-backed write_zeroes</title>
<updated>2019-06-25T03:34:51Z</updated>
<author>
<name>Minwoo Im</name>
<email>minwoo.im.dev@gmail.com</email>
</author>
<published>2019-06-02T03:43:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e3d4c4a7a0900daf246cfb713101f4044e9b97fa'/>
<id>urn:sha1:e3d4c4a7a0900daf246cfb713101f4044e9b97fa</id>
<content type='text'>
[ Upstream commit 3562f5d9f21e7779ae442a45197fed6cb247fd22 ]

The WRITE ZEROES command has no data transfer so that we need to
initialize the struct (nvmet_req *req)-&gt;data_len to 0x0.  While
(nvmet_req *req)-&gt;transfer_len is initialized in nvmet_req_init(),
data_len will be initialized by nowhere which might cause the failure
with status code NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR randomly.  It's
because nvmet_req_execute() checks like:

	if (unlikely(req-&gt;data_len != req-&gt;transfer_len)) {
		req-&gt;error_loc = offsetof(struct nvme_common_command, dptr);
		nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR);
	} else
		req-&gt;execute(req);

This patch fixes req-&gt;data_len not to be a randomly assigned by
initializing it to 0x0 when preparing the command in
nvmet_bdev_parse_io_cmd().

nvmet_file_parse_io_cmd() which is for file-backed I/O has already
initialized the data_len field to 0x0, though.

Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Chaitanya Kulkarni &lt;Chaitanya.Kulkarni@wdc.com&gt;
Signed-off-by: Minwoo Im &lt;minwoo.im.dev@gmail.com&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nvmet: fix discover log page when offsets are used</title>
<updated>2019-04-11T15:28:30Z</updated>
<author>
<name>Keith Busch</name>
<email>keith.busch@intel.com</email>
</author>
<published>2019-04-09T16:03:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d808b7f759b50acf0784ce6230ffa63e12ef465d'/>
<id>urn:sha1:d808b7f759b50acf0784ce6230ffa63e12ef465d</id>
<content type='text'>
The nvme target hadn't been taking the Get Log Page offset parameter
into consideration, and so has been returning corrupted log pages when
offsets are used. Since many tools, including nvme-cli, split the log
request to 4k, we've been breaking discovery log responses when more
than 3 subsystems exist.

Fix the returned data by internally generating the entire discovery
log page and copying only the requested bytes into the user buffer. The
command log page offset type has been modified to a native __le64 to
make it easier to extract the value from a command.

Signed-off-by: Keith Busch &lt;keith.busch@intel.com&gt;
Tested-by: Minwoo Im &lt;minwoo.im@samsung.com&gt;
Reviewed-by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: James Smart &lt;james.smart@broadcom.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: fix error flow during ns enable</title>
<updated>2019-03-28T17:15:03Z</updated>
<author>
<name>Max Gurtovoy</name>
<email>maxg@mellanox.com</email>
</author>
<published>2019-03-28T10:54:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a536b49785759bf99465fdf6e248d34322123fcd'/>
<id>urn:sha1:a536b49785759bf99465fdf6e248d34322123fcd</id>
<content type='text'>
In case we fail to enable p2pmem on the current namespace, disable the
backing store device before exiting.

Cc: Stephen Bates &lt;sbates@raithlin.com&gt;
Signed-off-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: fix building bvec from sg list</title>
<updated>2019-03-28T17:15:02Z</updated>
<author>
<name>Ming Lei</name>
<email>ming.lei@redhat.com</email>
</author>
<published>2019-03-27T09:07:22Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=02db99548d3608a625cf481cff2bb7b626829b3f'/>
<id>urn:sha1:02db99548d3608a625cf481cff2bb7b626829b3f</id>
<content type='text'>
There are two mistakes for building bvec from sg list for file
backed ns:

- use request data length to compute number of io vector, this way
doesn't consider sg-&gt;offset, and the result may be smaller than required
io vectors

- bvec-&gt;bv_len isn't capped by sg-&gt;length

This patch fixes this issue by building bvec from sg directly, given
the whole IO stack is ready for multi-page bvec.

Reported-by: Yi Zhang &lt;yi.zhang@redhat.com&gt;
Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver")

Signed-off-by: Ming Lei &lt;ming.lei@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
</content>
</entry>
<entry>
<title>nvmet: ignore EOPNOTSUPP for discard</title>
<updated>2019-03-13T18:57:34Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-03-13T17:55:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=005c674f705ee308e23b8e4e7047419d12122fde'/>
<id>urn:sha1:005c674f705ee308e23b8e4e7047419d12122fde</id>
<content type='text'>
NVMe DSM is a pure hint, so if the underlying device / file system
does not support discard-like operations we should not fail the
operation but rather return success.

Fixes: 3b031d15995f ("nvmet: add error log support for bdev backend")
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed by: Chaitanya Kulkarni &lt;chaitanya.kulkarni@wdc.com&gt;
Tested-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>nvmet-fc: bring Disconnect into compliance with FC-NVME spec</title>
<updated>2019-03-13T18:57:34Z</updated>
<author>
<name>James Smart</name>
<email>jsmart2021@gmail.com</email>
</author>
<published>2019-03-13T17:55:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=404ec31df434fdae515202952b5e230c1b983ee1'/>
<id>urn:sha1:404ec31df434fdae515202952b5e230c1b983ee1</id>
<content type='text'>
The FC-NVME spec, when finally approved, modified the disconnect LS
such that the only scope available is the association.

Rework the Disconnect LS processing to be in accordance with the
change.

Signed-off-by: Nigel Kirkland &lt;nigel.kirkland@broadcom.com&gt;
Signed-off-by: James Smart &lt;jsmart2021@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>nvmet-fc: fix issues with targetport assoc_list list walking</title>
<updated>2019-03-13T18:57:30Z</updated>
<author>
<name>James Smart</name>
<email>jsmart2021@gmail.com</email>
</author>
<published>2019-03-13T17:55:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0191e7405b687339a5540c1562acdecefd70eb3f'/>
<id>urn:sha1:0191e7405b687339a5540c1562acdecefd70eb3f</id>
<content type='text'>
There are two changes:

1) The logic in the __nvmet_fc_free_assoc() routine is bad. It uses
"safe" routines assuming pointers will come back valid.  However, the
intervening next structure being linked can be removed from the list and
the resulting safe pointers are bad, resulting in NULL ptrs being hit.

Correct by scheduling a work element to perform the association delete,
which can be done while under lock.

2) Prior patch that added the work element scheduling left a possible
reference on the object if the work element couldn't be scheduled.

Correct by doing the put on a failing schedule_work() call.

Signed-off-by: Nigel Kirkland &lt;nigel.kirkland@broadcom.com&gt;
Signed-off-by: James Smart &lt;jsmart2021@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>nvme-loop: init nvmet_ctrl fatal_err_work when allocate</title>
<updated>2019-03-13T18:05:39Z</updated>
<author>
<name>Yufen Yu</name>
<email>yuyufen@huawei.com</email>
</author>
<published>2019-03-13T17:54:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d11de63f2b519f0a162b834013b6d3a46dbf3886'/>
<id>urn:sha1:d11de63f2b519f0a162b834013b6d3a46dbf3886</id>
<content type='text'>
After commit 4d43d395fe (workqueue: Try to catch flush_work() without
INIT_WORK()), it can cause warning when delete nvme-loop device, trace
like:

[   76.601272] Call Trace:
[   76.601646]  ? del_timer+0x72/0xa0
[   76.602156]  __cancel_work_timer+0x1ae/0x270
[   76.602791]  cancel_work_sync+0x14/0x20
[   76.603407]  nvmet_ctrl_free+0x1b7/0x2f0 [nvmet]
[   76.604091]  ? free_percpu+0x168/0x300
[   76.604652]  nvmet_sq_destroy+0x106/0x240 [nvmet]
[   76.605346]  nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop]
[   76.606220]  nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop]
[   76.607026]  nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop]
[   76.607871]  nvme_do_delete_ctrl+0x75/0xb0
[   76.608477]  nvme_sysfs_delete+0x7d/0xc0
[   76.609057]  dev_attr_store+0x24/0x40
[   76.609603]  sysfs_kf_write+0x4c/0x60
[   76.610144]  kernfs_fop_write+0x19a/0x260
[   76.610742]  __vfs_write+0x1c/0x60
[   76.611246]  vfs_write+0xfa/0x280
[   76.611739]  ksys_write+0x6e/0x120
[   76.612238]  __x64_sys_write+0x1e/0x30
[   76.612787]  do_syscall_64+0xbf/0x3a0
[   76.613329]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may
more reasonable.

Signed-off-by: Yufen Yu &lt;yuyufen@huawei.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>nvmet: convert to SPDX identifiers</title>
<updated>2019-02-20T14:22:42Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-02-18T10:36:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=77141dc6ceffdbf4dd3470911c838309e23cd55c'/>
<id>urn:sha1:77141dc6ceffdbf4dd3470911c838309e23cd55c</id>
<content type='text'>
Update license to use SPDX-License-Identifier instead of verbose license
text.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
</content>
</entry>
<entry>
<title>nvmet-rdma: convert to SPDX identifiers</title>
<updated>2019-02-20T14:22:39Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2019-02-18T10:35:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3641bd323fb145710b3ee4c522670c77410984a7'/>
<id>urn:sha1:3641bd323fb145710b3ee4c522670c77410984a7</id>
<content type='text'>
Update license to use SPDX-License-Identifier instead of verbose license
text.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
</content>
</entry>
</feed>
