| 2017-05-08 17:39:33 |
bugproxy |
bug |
|
|
added bug |
| 2017-05-08 17:39:36 |
bugproxy |
tags |
|
architecture-ppc64le bugnameltc-154092 severity-high targetmilestone-inin1610 |
|
| 2017-05-08 17:39:37 |
bugproxy |
ubuntu: assignee |
|
Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) |
|
| 2017-05-08 17:39:40 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2017-05-08 18:04:44 |
Manoj Iyer |
bug task added |
|
ubuntu-power-systems |
|
| 2017-05-09 18:14:38 |
Manoj Iyer |
linux (Ubuntu): assignee |
Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) |
Manoj Iyer (manjo) |
|
| 2017-05-09 21:40:48 |
Manoj Iyer |
linux (Ubuntu): importance |
Undecided |
High |
|
| 2017-05-09 21:40:48 |
Manoj Iyer |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2017-05-09 21:41:35 |
Manoj Iyer |
ubuntu-power-systems: status |
New |
Incomplete |
|
| 2017-05-10 18:59:20 |
bugproxy |
attachment added |
|
ibmvscsis: Clear left-over abort_cmd pointers https://bugs.launchpad.net/bugs/1689365/+attachment/4874794/+files/0001-ibmvscsis-Clear-left-over-abort_cmd-pointers.patch |
|
| 2017-05-10 20:19:35 |
bugproxy |
attachment added |
|
ibmvscsis: Fix the incorrect req_lim_delta https://bugs.launchpad.net/bugs/1689365/+attachment/4874835/+files/0001-ibmvscsis-Fix-the-incorrect-req_lim_delta.patch |
|
| 2017-05-10 20:49:27 |
bugproxy |
tags |
architecture-ppc64le bugnameltc-154092 severity-high targetmilestone-inin1610 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 |
|
| 2017-06-01 16:09:16 |
Manoj Iyer |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 ubuntu-17.04 |
|
| 2017-06-05 14:42:33 |
Manoj Iyer |
description |
---Problem Description---
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[PATCH v3] ibmvscsis: Do not send aborted task response
https://www.spinics.net/lists/stable/msg170418.html
This patch also requires a patch that was accepted upstream which is:
target: Fix unknown fabric callback queue-full errors
https://patchwork.kernel.org/patch/9405013/
---uname output---
Latest Yakkety master branch
Machine Type = P8
---Steps to Reproduce---
Send abort ops over and over and you will hit it. |
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential] |
|
| 2017-06-05 14:52:05 |
Manoj Iyer |
description |
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential] |
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential]
Patches are confined to ibmvscsi driver and target driver. |
|
| 2017-06-05 16:21:45 |
Manoj Iyer |
description |
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential]
Patches are confined to ibmvscsi driver and target driver. |
[Impact]
ibmvscsis: Do not send aborted task response
The driver is sending a response to the actual scsi op that was
aborted by an abort task TM, while LIO is sending a response to
the abort task TM.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for that command, but we're still using the tag until the
command is released at release_cmd time, so we chose to delay
sending the response until then. That then caused this issue, because
release_cmd is always called, even if queue_status is not.
SCSI spec says that the initiator that sends the abort task
TM NEVER gets a response to the aborted op and with the current
code it will send a response. Thus this fix will remove that response
if the CMD_T_ABORTED && !CMD_T_TAS.
Another case with a small timing window is the case where if LIO sends a
TMR_DOES_NOT_EXIST, and the release_cmd callback is called for the TMR Abort
cmd before the release_cmd for the (attemped) aborted cmd, then we need to
ensure that we send the response for the (attempted) abort cmd to the client
before we send the response for the TMR Abort cmd.
[Test Case]
As per comment #11, this requires sending manual abort signals to trigger the bug.
[Fix]
ibmvscsis: Fix the incorrect req_lim_delta
ibmvscsis: Clear left-over abort_cmd pointers
ibmvscsis: Do not send aborted task response
target: Fix unknown fabric callback queue-full errors
[Regression Potential]
Patches are confined to ibmvscsi driver and target driver. |
|
| 2017-07-19 16:33:01 |
Manoj Iyer |
ubuntu-power-systems: importance |
Undecided |
High |
|
| 2017-07-31 14:25:02 |
Manoj Iyer |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 ubuntu-17.04 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 |
|
| 2017-08-03 13:16:09 |
Stefan Bader |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-08-03 13:16:09 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Zesty) |
|
| 2017-08-08 10:17:43 |
Kleber Sacilotto de Souza |
linux (Ubuntu Zesty): status |
New |
Fix Committed |
|
| 2017-08-14 14:12:59 |
Manoj Iyer |
ubuntu-power-systems: status |
Incomplete |
Fix Committed |
|
| 2017-08-16 16:34:05 |
Kleber Sacilotto de Souza |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 verification-needed-zesty |
|
| 2017-08-16 20:19:36 |
bugproxy |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 verification-needed-zesty |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 verification-done-zesty |
|
| 2017-08-21 13:53:13 |
Andrew Cloke |
ubuntu-power-systems: assignee |
|
Manoj Iyer (manjo) |
|
| 2017-08-21 13:53:35 |
Manoj Iyer |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-a ubuntu-17.04 verification-done-zesty |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-g ubuntu-17.04 verification-done-zesty |
|
| 2017-08-28 10:14:27 |
Launchpad Janitor |
linux (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
| 2017-08-28 10:14:27 |
Launchpad Janitor |
cve linked |
|
2017-1000111 |
|
| 2017-08-28 10:14:27 |
Launchpad Janitor |
cve linked |
|
2017-1000112 |
|
| 2017-08-28 10:14:27 |
Launchpad Janitor |
cve linked |
|
2017-7487 |
|
| 2017-08-28 21:09:44 |
bugproxy |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 triage-g ubuntu-17.04 verification-done-zesty |
architecture-ppc64 targetmilestone-inin1610 |
|
| 2017-08-30 19:59:35 |
bugproxy |
tags |
architecture-ppc64 targetmilestone-inin1610 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 |
|
| 2017-08-30 20:39:51 |
bugproxy |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 verification-done-zesty |
|
| 2017-09-04 13:47:20 |
Andrew Cloke |
ubuntu-power-systems: status |
Fix Committed |
Fix Released |
|
| 2019-05-03 01:50:03 |
bugproxy |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1610 verification-done-zesty |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1704 verification-done-zesty |
|
| 2019-07-24 20:20:07 |
Brad Figg |
tags |
architecture-ppc64 bugnameltc-154092 severity-high targetmilestone-inin1704 verification-done-zesty |
architecture-ppc64 bugnameltc-154092 cscc severity-high targetmilestone-inin1704 verification-done-zesty |
|
