Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41. In upstream issue is fixed with commit b716e6889c95f64b. For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Thanks, Dakshaja.
Hi all,
Gentle reminder.
Thanks, Dakshaja
On Thursday, May 05/21/20, 2020 at 19:36:42 +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41. In upstream issue is fixed with commit b716e6889c95f64b. For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Thanks, Dakshaja.
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c index 57a4062cb..47bee01d3 100644 --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -931,16 +931,35 @@ void nvmet_req_uninit(struct nvmet_req *req) } EXPORT_SYMBOL_GPL(nvmet_req_uninit); -void nvmet_req_execute(struct nvmet_req *req) +bool nvmet_check_data_len(struct nvmet_req *req, size_t data_len) {
- if (unlikely(req->data_len != req->transfer_len)) {
- if (unlikely(data_len != req->transfer_len)) { req->error_loc = offsetof(struct nvme_common_command, dptr); nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR);
- } else
req->execute(req);
return false;- }
- return true;
+} +EXPORT_SYMBOL_GPL(nvmet_check_data_len);
+void nvmet_req_execute(struct nvmet_req *req) +{
- req->execute(req);
} EXPORT_SYMBOL_GPL(nvmet_req_execute); +bool nvmet_check_data_len_lte(struct nvmet_req *req, size_t data_len) +{
if (unlikely(data_len > req->transfer_len)) {req->error_loc = offsetof(struct nvme_common_command, dptr);nvmet_req_complete(req, NVME_SC_SGL_INVALID_DATA | NVME_SC_DNR);return false;}return true;+}
int nvmet_req_alloc_sgl(struct nvmet_req *req) { struct pci_dev *p2p_dev = NULL; diff --git a/drivers/nvme/target/io-cmd-bdev.c b/drivers/nvme/target/io-cmd-bdev.c index 32008d851..498efb062 100644 --- a/drivers/nvme/target/io-cmd-bdev.c +++ b/drivers/nvme/target/io-cmd-bdev.c @@ -150,6 +150,10 @@ static void nvmet_bdev_execute_rw(struct nvmet_req *req) sector_t sector; int op, op_flags = 0, i;
- if (!nvmet_check_data_len(req, nvmet_rw_len(req)))
return;- if (!req->sg_cnt) { nvmet_req_complete(req, 0); return;
@@ -207,6 +211,8 @@ static void nvmet_bdev_execute_flush(struct nvmet_req *req) { struct bio *bio = &req->b.inline_bio;
- if (!nvmet_check_data_len(req, 0))
return;@@ -274,6 +280,9 @@ static void nvmet_bdev_execute_discard(struct nvmet_req *req) static void nvmet_bdev_execute_dsm(struct nvmet_req *req) {
- if (!nvmet_check_data_len_lte(req, nvmet_dsm_len(req)))
return;- switch (le32_to_cpu(req->cmd->dsm.attributes)) { case NVME_DSMGMT_AD: nvmet_bdev_execute_discard(req);
@@ -295,6 +304,8 @@ static void nvmet_bdev_execute_write_zeroes(struct nvmet_req *req) sector_t nr_sector; int ret;
- if (!nvmet_check_data_len(req, 0))
return;@@ -319,20 +330,15 @@ u16 nvmet_bdev_parse_io_cmd(struct nvmet_req *req) case nvme_cmd_read: case nvme_cmd_write: req->execute = nvmet_bdev_execute_rw;
req->data_len = nvmet_rw_len(req);req->data_len = 0;req->data_len = (le32_to_cpu(cmd->dsm.nr) + 1) *sizeof(struct nvme_dsm_range);req->data_len = 0;diff --git a/drivers/nvme/target/io-cmd-file.c b/drivers/nvme/target/io-cmd-file.c index 05453f5d1..34fc0c04d 100644 --- a/drivers/nvme/target/io-cmd-file.c +++ b/drivers/nvme/target/io-cmd-file.c @@ -232,6 +232,9 @@ static void nvmet_file_execute_rw(struct nvmet_req *req) { ssize_t nr_bvec = req->sg_cnt;
- if (!nvmet_check_data_len(req, nvmet_rw_len(req)))
return;- if (!req->sg_cnt || !nr_bvec) { nvmet_req_complete(req, 0); return;
@@ -273,6 +276,8 @@ static void nvmet_file_flush_work(struct work_struct *w) static void nvmet_file_execute_flush(struct nvmet_req *req) {
- if (!nvmet_check_data_len(req, 0))
return;} @@ -331,6 +336,9 @@ static void nvmet_file_dsm_work(struct work_struct *w) static void nvmet_file_execute_dsm(struct nvmet_req *req) {
- if (!nvmet_check_data_len_lte(req, nvmet_dsm_len(req)))
return;- INIT_WORK(&req->f.work, nvmet_file_dsm_work); schedule_work(&req->f.work);
} @@ -359,6 +367,8 @@ static void nvmet_file_write_zeroes_work(struct work_struct *w) static void nvmet_file_execute_write_zeroes(struct nvmet_req *req) {
- if (!nvmet_check_data_len(req, 0))
return;} @@ -371,20 +381,15 @@ u16 nvmet_file_parse_io_cmd(struct nvmet_req *req) case nvme_cmd_read: case nvme_cmd_write: req->execute = nvmet_file_execute_rw;
req->data_len = nvmet_rw_len(req);req->data_len = 0;req->data_len = (le32_to_cpu(cmd->dsm.nr) + 1) *sizeof(struct nvme_dsm_range);req->data_len = 0;diff --git a/drivers/nvme/target/nvmet.h b/drivers/nvme/target/nvmet.h index c51f8dd01..a8a7744d8 100644 --- a/drivers/nvme/target/nvmet.h +++ b/drivers/nvme/target/nvmet.h @@ -375,7 +375,9 @@ u16 nvmet_parse_fabrics_cmd(struct nvmet_req *req); bool nvmet_req_init(struct nvmet_req *req, struct nvmet_cq *cq, struct nvmet_sq *sq, const struct nvmet_fabrics_ops *ops); void nvmet_req_uninit(struct nvmet_req *req); +bool nvmet_check_data_len(struct nvmet_req *req, size_t data_len); void nvmet_req_execute(struct nvmet_req *req); +bool nvmet_check_data_len_lte(struct nvmet_req *req, size_t data_len); void nvmet_req_complete(struct nvmet_req *req, u16 status); int nvmet_req_alloc_sgl(struct nvmet_req *req); void nvmet_req_free_sgl(struct nvmet_req *req); @@ -495,6 +497,12 @@ static inline u32 nvmet_rw_len(struct nvmet_req *req) req->ns->blksize_shift; } +static inline u32 nvmet_dsm_len(struct nvmet_req *req) +{
return (le32_to_cpu(req->cmd->dsm.nr) + 1) *sizeof(struct nvme_dsm_range);+}
u16 errno_to_nvme_status(struct nvmet_req *req, int errno); /* Convert a 32-bit number to a 16-bit 0's based number */
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
A: No. Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Tue, May 26, 2020 at 01:05:04PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Gentle reminder.
From a patch you sent out 4 days ago? Covering a long holiday weekend
for most "western" countries? odd...
greg k-h
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Do all of the above patches apply cleanly? Do they need to be backported? Have you tested that? Do you have such a series of patches so we can compare them?
The patch below is not in any format that I can take it in. ALso, 95% of the times we take a patch that is different from what is upstream will have bugs and problems over time because of that. So I always want to take the original upstream patches instead if at all possible.
So I need a lot more information here in order to try to determine this, sorry.
thanks,
greg k-h
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Do all of the above patches apply cleanly? Do they need to be backported? Have you tested that? Do you have such a series of patches so we can compare them?
Yes I have tested, all the patches applied cleanly and attached all the patches for your reference. They all can be pulled into 5.4 stable without any issues.
530436c4 -- culprit commit 2cb6963a -- dependent commit 6f86f2c9 -- dependent commit 59ef0eaa -- dependent commit e9061c39 -- dependent commit be3f3114 -- dependent commit b716e688 -- fix commit
The patch below is not in any format that I can take it in. ALso, 95% of the times we take a patch that is different from what is upstream will have bugs and problems over time because of that. So I always want to take the original upstream patches instead if at all possible.
So I need a lot more information here in order to try to determine this, sorry.
Thanks Dakshaja
On Thu, May 28, 2020 at 01:14:31PM +0530, Dakshaja Uppalapati wrote:
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
So why don't we just revert 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") from the stable trees? Will that fix the issue for you instead of the much-larger set of backports you are proposing?
Also, is this an issue for you in the 4.19 releases? The above mentioned patch showed up in 4.19.92 and 5.4.7.
For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Do all of the above patches apply cleanly? Do they need to be backported? Have you tested that? Do you have such a series of patches so we can compare them?
Yes I have tested, all the patches applied cleanly and attached all the patches for your reference. They all can be pulled into 5.4 stable without any issues.
530436c4 -- culprit commit 2cb6963a -- dependent commit 6f86f2c9 -- dependent commit 59ef0eaa -- dependent commit e9061c39 -- dependent commit be3f3114 -- dependent commit b716e688 -- fix commit
The patch below is not in any format that I can take it in. ALso, 95% of the times we take a patch that is different from what is upstream will have bugs and problems over time because of that. So I always want to take the original upstream patches instead if at all possible.
So I need a lot more information here in order to try to determine this, sorry.
Thanks Dakshaja
diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c index 831a062d27cb..3665b45d6515 100644 --- a/drivers/nvme/target/admin-cmd.c +++ b/drivers/nvme/target/admin-cmd.c
<snip>
I still don't understand what the patch here is, as you don't really provide any information about it in a format I am used to seeing. Can you redo it in the documented style of submitting a normal patch to the kernel tree so that might help explain things?
thanks,
greg k-h
On Thursday, May 05/28/20, 2020 at 10:34:03 +0200, Greg KH wrote:
On Thu, May 28, 2020 at 01:14:31PM +0530, Dakshaja Uppalapati wrote:
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
So why don't we just revert 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") from the stable trees? Will that fix the issue for you instead of the much-larger set of backports you are proposing?
Also, is this an issue for you in the 4.19 releases? The above mentioned patch showed up in 4.19.92 and 5.4.7.
Yes, on 4.19 stable kernel too issue is seen. By reverting 530436c45ef2 issue is not seen on both 4.19 and 5.4 stable kernels. Do you want me to send the reverted patch?
For stable 5.4 kernel it doesn’t apply clean and needs pulling in the following commits.
commit 2cb6963a16e9e114486decf591af7cb2d69cb154 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:41 2019 -0600
commit 6f86f2c9d94d55c4d3a6f1ffbc2e1115b5cb38a8 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:42 2019 -0600
commit 59ef0eaa7741c3543f98220cc132c61bf0230bce Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:43 2019 -0600
commit e9061c397839eea34207668bfedce0a6c18c5015 Author: Christoph Hellwig hch@lst.de Date: Wed Oct 23 10:35:44 2019 -0600
commit b716e6889c95f64ba32af492461f6cc9341f3f05 Author: Sagi Grimberg sagi@grimberg.me Date: Sun Jan 26 23:23:28 2020 -0800
I tried a patch by including only necessary parts of the commits e9061c397839, 59ef0eaa7741 and b716e6889c95. PFA.
With the attached patch, issue is not seen.
Please let me know on how to fix it in stable, can all above 5 changes be cleanly pushed or if attached shorter version can be pushed?
Do all of the above patches apply cleanly? Do they need to be backported? Have you tested that? Do you have such a series of patches so we can compare them?
Yes I have tested, all the patches applied cleanly and attached all the patches for your reference. They all can be pulled into 5.4 stable without any issues.
530436c4 -- culprit commit 2cb6963a -- dependent commit 6f86f2c9 -- dependent commit 59ef0eaa -- dependent commit e9061c39 -- dependent commit be3f3114 -- dependent commit b716e688 -- fix commit
The patch below is not in any format that I can take it in. ALso, 95% of the times we take a patch that is different from what is upstream will have bugs and problems over time because of that. So I always want to take the original upstream patches instead if at all possible.
So I need a lot more information here in order to try to determine this, sorry.
Thanks Dakshaja
diff --git a/drivers/nvme/target/admin-cmd.c b/drivers/nvme/target/admin-cmd.c index 831a062d27cb..3665b45d6515 100644 --- a/drivers/nvme/target/admin-cmd.c +++ b/drivers/nvme/target/admin-cmd.c
<snip>
I still don't understand what the patch here is, as you don't really provide any information about it in a format I am used to seeing. Can you redo it in the documented style of submitting a normal patch to the kernel tree so that might help explain things?
thanks,
greg k-h
On Mon, Jun 01, 2020 at 09:51:44PM +0530, Dakshaja Uppalapati wrote:
On Thursday, May 05/28/20, 2020 at 10:34:03 +0200, Greg KH wrote:
On Thu, May 28, 2020 at 01:14:31PM +0530, Dakshaja Uppalapati wrote:
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
So why don't we just revert 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") from the stable trees? Will that fix the issue for you instead of the much-larger set of backports you are proposing?
Also, is this an issue for you in the 4.19 releases? The above mentioned patch showed up in 4.19.92 and 5.4.7.
Yes, on 4.19 stable kernel too issue is seen. By reverting 530436c45ef2 issue is not seen on both 4.19 and 5.4 stable kernels. Do you want me to send the reverted patch?
Yes please.
thanks,
greg k-h
On Monday, June 06/01/20, 2020 at 18:27:50 +0200, Greg KH wrote:
On Mon, Jun 01, 2020 at 09:51:44PM +0530, Dakshaja Uppalapati wrote:
On Thursday, May 05/28/20, 2020 at 10:34:03 +0200, Greg KH wrote:
On Thu, May 28, 2020 at 01:14:31PM +0530, Dakshaja Uppalapati wrote:
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote:
Hi all,
Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
So why don't we just revert 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") from the stable trees? Will that fix the issue for you instead of the much-larger set of backports you are proposing?
Also, is this an issue for you in the 4.19 releases? The above mentioned patch showed up in 4.19.92 and 5.4.7.
Yes, on 4.19 stable kernel too issue is seen. By reverting 530436c45ef2 issue is not seen on both 4.19 and 5.4 stable kernels. Do you want me to send the reverted patch?
Yes please.
Attached the reverted patch.PFA.
Thanks, Dakshaja
On Monday, June 06/01/20, 2020 at 22:15:20 +0530, Dakshaja Uppalapati wrote:
On Monday, June 06/01/20, 2020 at 18:27:50 +0200, Greg KH wrote:
On Mon, Jun 01, 2020 at 09:51:44PM +0530, Dakshaja Uppalapati wrote:
On Thursday, May 05/28/20, 2020 at 10:34:03 +0200, Greg KH wrote:
On Thu, May 28, 2020 at 01:14:31PM +0530, Dakshaja Uppalapati wrote:
On Tuesday, May 05/26/20, 2020 at 12:25:42 +0200, Greg KH wrote:
On Thu, May 21, 2020 at 07:36:43PM +0530, Dakshaja Uppalapati wrote: > Hi all, > > Issue which is reported in https://lore.kernel.org/linux-nvme/CH2PR12MB40050ACF > 2C0DC7439355ED3FDD270@CH2PR12MB4005.namprd12.prod.outlook.com/T/#r8cfc80b26f0cd > 1cde41879a68fd6a71186e9594c is also seen on stable kernel 5.4.41.
What issue is that? Your url is wrapped and can not work here :(
Sorry for that, when I tried to format the disk discovered from target machine the below error is seen in dmesg.
dmesg: [ 1844.868480] blk_update_request: I/O error, dev nvme0c0n1, sector 0 op 0x3:(DISCARD) flags 0x4000800 phys_seg 1 prio class 0
The above issue is seen from kernel-5.5-rc1 onwards.
> In upstream issue is fixed with commit b716e6889c95f64b.
Is this a regression or support for something new that has never worked before?
This is a regression, bisects points to the commit 530436c4 and fixed with commit b716e688 in upstream.
Now same issue is seen with stable kernel-5.4.41, 530436c4 is part of it.
So why don't we just revert 530436c45ef2 ("nvme: Discard workaround for non-conformant devices") from the stable trees? Will that fix the issue for you instead of the much-larger set of backports you are proposing?
Also, is this an issue for you in the 4.19 releases? The above mentioned patch showed up in 4.19.92 and 5.4.7.
Yes, on 4.19 stable kernel too issue is seen. By reverting 530436c45ef2 issue is not seen on both 4.19 and 5.4 stable kernels. Do you want me to send the reverted patch?
Yes please.
Attached the reverted patch.PFA.
Sorry, was hurry in replying. will send out as a kernel patch.
Thanks, Dakshaja
linux-stable-mirror@lists.linaro.org
-
Dakshaja Uppalapati -
Greg KH