LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response
@ 2019-05-21  8:24 ` Avri Altman
  2019-05-28  4:07   ` Alim Akhtar
                     ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Avri Altman @ 2019-05-21  8:24 UTC (permalink / raw)
  To: James E.J. Bottomley, Martin K. Petersen, linux-scsi,
	linux-kernel, Evan Green, Bean Huo, Pedro Sousa, Alim Akhtar
  Cc: Avi Shchislowski, Alex Lemberg, Avri Altman

struct ufs_dev_cmd is the main container that supports device management
commands. In the case of a read descriptor request, we assume that the
proper space was allocated in dev_cmd to hold the returning descriptor.

This is no longer true, as there are flows that doesn't use dev_cmd
for device management requests, and was wrong in the first place.

fixes: d44a5f98bb49 (ufs: query descriptor API)

Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/scsi/ufs/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 8c1c551..3fe3029 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1917,7 +1917,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	memcpy(&query_res->upiu_res, &lrbp->ucd_rsp_ptr->qr, QUERY_OSF_SIZE);
 
 	/* Get the descriptor */
-	if (lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
+	if (hba->dev_cmd.query.descriptor &&
+	    lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
 		u8 *descp = (u8 *)lrbp->ucd_rsp_ptr +
 				GENERAL_UPIU_REQUEST_SIZE;
 		u16 resp_len;
-- 
1.9.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response
  2019-05-21  8:24 ` [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response Avri Altman
@ 2019-05-28  4:07   ` Alim Akhtar
  2019-06-03  8:37     ` Avri Altman
  2019-05-28  7:51   ` [EXT] " Bean Huo (beanhuo)
  2019-06-05  2:11   ` Martin K. Petersen
  2 siblings, 1 reply; 5+ messages in thread
From: Alim Akhtar @ 2019-05-28  4:07 UTC (permalink / raw)
  To: Avri Altman, James E.J. Bottomley, Martin K. Petersen,
	linux-scsi, linux-kernel, Evan Green, Bean Huo, Pedro Sousa
  Cc: Avi Shchislowski, Alex Lemberg

Hi Avri

On 5/21/19 1:54 PM, Avri Altman wrote:
> struct ufs_dev_cmd is the main container that supports device management
> commands. In the case of a read descriptor request, we assume that the
> proper space was allocated in dev_cmd to hold the returning descriptor.
> 
> This is no longer true, as there are flows that doesn't use dev_cmd
> for device management requests, and was wrong in the first place.
> 
Can you please put some light on those flows? Are those platform 
specific? Just curious.
> fixes: d44a5f98bb49 (ufs: query descriptor API)
> 
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>   drivers/scsi/ufs/ufshcd.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 8c1c551..3fe3029 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1917,7 +1917,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
>   	memcpy(&query_res->upiu_res, &lrbp->ucd_rsp_ptr->qr, QUERY_OSF_SIZE);
>   
>   	/* Get the descriptor */
> -	if (lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
> +	if (hba->dev_cmd.query.descriptor &&
> +	    lrbp->ucd_rsp_ptr->qr.opcode == UPIU_QUERY_OPCODE_READ_DESC) {
>   		u8 *descp = (u8 *)lrbp->ucd_rsp_ptr +
>   				GENERAL_UPIU_REQUEST_SIZE;
>   		u16 resp_len;
> 
This change looks ok to me. I hope you have tested this patch.
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [EXT] [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response
  2019-05-21  8:24 ` [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response Avri Altman
  2019-05-28  4:07   ` Alim Akhtar
@ 2019-05-28  7:51   ` Bean Huo (beanhuo)
  2019-06-05  2:11   ` Martin K. Petersen
  2 siblings, 0 replies; 5+ messages in thread
From: Bean Huo (beanhuo) @ 2019-05-28  7:51 UTC (permalink / raw)
  To: Avri Altman, James E.J. Bottomley, Martin K. Petersen,
	linux-scsi, linux-kernel, Evan Green, Pedro Sousa, Alim Akhtar
  Cc: Avi Shchislowski, Alex Lemberg

Hi, Avri
>
>Signed-off-by: Avri Altman <avri.altman@wdc.com>
Acked-by: Bean Huo <beanhuo@micron.com>

Thanks,
//Bean

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response
  2019-05-28  4:07   ` Alim Akhtar
@ 2019-06-03  8:37     ` Avri Altman
  0 siblings, 0 replies; 5+ messages in thread
From: Avri Altman @ 2019-06-03  8:37 UTC (permalink / raw)
  To: Alim Akhtar, James E.J. Bottomley, Martin K. Petersen,
	linux-scsi, linux-kernel, Evan Green, Bean Huo, Pedro Sousa
  Cc: Avi Shchislowski, Alex Lemberg

Hi Alim,
Thank you for your review.
Sorry for the late response - I was away for a couple of weeks.

Thanks,
Avri

> Subject: Re: [PATCH] scsi: ufs: Check that space was properly alloced in
> copy_query_response
> 
> Hi Avri
> 
> On 5/21/19 1:54 PM, Avri Altman wrote:
> > struct ufs_dev_cmd is the main container that supports device management
> > commands. In the case of a read descriptor request, we assume that the
> > proper space was allocated in dev_cmd to hold the returning descriptor.
> >
> > This is no longer true, as there are flows that doesn't use dev_cmd
> > for device management requests, and was wrong in the first place.
> >
> Can you please put some light on those flows? Are those platform
> specific? Just curious.
No, actually its quite simplistic.
__ufshcd_query_descriptor set dev_cmd.query.descriptor 
to point to its designated space before sending the read descriptor query,
and to null once it's done.
But it doesn't check it in ufshcd_copy_query_response when the query
returns from the device, which it should, as I indicated in the commit log.


> This change looks ok to me. I hope you have tested this patch.
Yes I did.

> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response
  2019-05-21  8:24 ` [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response Avri Altman
  2019-05-28  4:07   ` Alim Akhtar
  2019-05-28  7:51   ` [EXT] " Bean Huo (beanhuo)
@ 2019-06-05  2:11   ` Martin K. Petersen
  2 siblings, 0 replies; 5+ messages in thread
From: Martin K. Petersen @ 2019-06-05  2:11 UTC (permalink / raw)
  To: Avri Altman
  Cc: James E.J. Bottomley, Martin K. Petersen, linux-scsi,
	linux-kernel, Evan Green, Bean Huo, Pedro Sousa, Alim Akhtar,
	Avi Shchislowski, Alex Lemberg


Avri,

> struct ufs_dev_cmd is the main container that supports device management
> commands. In the case of a read descriptor request, we assume that the
> proper space was allocated in dev_cmd to hold the returning descriptor.
>
> This is no longer true, as there are flows that doesn't use dev_cmd
> for device management requests, and was wrong in the first place.

Applied to 5.2/scsi-fixes, thanks!

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2019-06-05  2:14 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20190521082527epcas1p44fe0c4659549ae265c9d59ef7844e57e@epcas1p4.samsung.com>
2019-05-21  8:24 ` [PATCH] scsi: ufs: Check that space was properly alloced in copy_query_response Avri Altman
2019-05-28  4:07   ` Alim Akhtar
2019-06-03  8:37     ` Avri Altman
2019-05-28  7:51   ` [EXT] " Bean Huo (beanhuo)
2019-06-05  2:11   ` Martin K. Petersen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).