From: Markus Elfring <[email protected]>
Date: Tue, 25 Apr 2017 22:20:02 +0200
Three update suggestions were taken into account
from static source code analysis.
Markus Elfring (3):
Use devm_kcalloc() in ufshcd_memory_alloc()
Delete an error message for a failed memory allocation in ufshcd_memory_alloc()
Delete an unnecessary return statement in ufshcd_exception_event_handler()
drivers/scsi/ufs/ufshcd.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--
2.12.2
From: Markus Elfring <[email protected]>
Date: Tue, 25 Apr 2017 21:45:25 +0200
* A multiplication for the size determination of a memory allocation
indicated that an array data structure should be processed.
Thus use the corresponding function "devm_kcalloc".
* Replace the specification of a data structure by a pointer dereference
to make the corresponding size determination a bit safer according to
the Linux coding style convention.
Signed-off-by: Markus Elfring <[email protected]>
---
drivers/scsi/ufs/ufshcd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 9ef8ce7f01a2..ce385911a20e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3270,8 +3270,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
}
/* Allocate memory for local reference block */
- hba->lrb = devm_kzalloc(hba->dev,
- hba->nutrs * sizeof(struct ufshcd_lrb),
+ hba->lrb = devm_kcalloc(hba->dev, hba->nutrs, sizeof(*hba->lrb),
GFP_KERNEL);
if (!hba->lrb) {
dev_err(hba->dev, "LRB Memory allocation failed\n");
--
2.12.2
From: Markus Elfring <[email protected]>
Date: Tue, 25 Apr 2017 21:50:43 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: Possible unnecessary 'out of memory' message
Thus remove such a statement here.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <[email protected]>
---
drivers/scsi/ufs/ufshcd.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ce385911a20e..5216e33e61a3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3274,8 +3274,7 @@ static int ufshcd_memory_alloc(struct ufs_hba *hba)
GFP_KERNEL);
- if (!hba->lrb) {
- dev_err(hba->dev, "LRB Memory allocation failed\n");
+ if (!hba->lrb)
goto out;
- }
+
return 0;
out:
return -ENOMEM;
--
2.12.2
From: Markus Elfring <[email protected]>
Date: Tue, 25 Apr 2017 22:00:05 +0200
The script "checkpatch.pl" pointed information out like the following.
WARNING: void function return statements are not generally useful
Thus remove such a statement here.
Signed-off-by: Markus Elfring <[email protected]>
---
drivers/scsi/ufs/ufshcd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5216e33e61a3..9018f26a5667 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4966,7 +4966,6 @@ static void ufshcd_exception_event_handler(struct work_struct *work)
out:
pm_runtime_put_sync(hba->dev);
- return;
}
/* Complete requests that have door-bell cleared */
--
2.12.2
On 2017-04-25 13:26, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
> Date: Tue, 25 Apr 2017 21:45:25 +0200
>
> * A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "devm_kcalloc".
>
> * Replace the specification of a data structure by a pointer
> dereference
> to make the corresponding size determination a bit safer according to
> the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <[email protected]>
> ---
> drivers/scsi/ufs/ufshcd.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 9ef8ce7f01a2..ce385911a20e 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3270,8 +3270,7 @@ static int ufshcd_memory_alloc(struct ufs_hba
> *hba)
> }
>
> /* Allocate memory for local reference block */
> - hba->lrb = devm_kzalloc(hba->dev,
> - hba->nutrs * sizeof(struct ufshcd_lrb),
> + hba->lrb = devm_kcalloc(hba->dev, hba->nutrs, sizeof(*hba->lrb),
> GFP_KERNEL);
> if (!hba->lrb) {
> dev_err(hba->dev, "LRB Memory allocation failed\n");
Looks good to me.
Reviewed-by: Subhash Jadavani <[email protected]>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On 2017-04-25 13:28, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
> Date: Tue, 25 Apr 2017 21:50:43 +0200
>
> The script "checkpatch.pl" pointed information out like the following.
>
> WARNING: Possible unnecessary 'out of memory' message
>
> Thus remove such a statement here.
>
> Link:
> http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring <[email protected]>
> ---
> drivers/scsi/ufs/ufshcd.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index ce385911a20e..5216e33e61a3 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3274,8 +3274,7 @@ static int ufshcd_memory_alloc(struct ufs_hba
> *hba)
> GFP_KERNEL);
> - if (!hba->lrb) {
> - dev_err(hba->dev, "LRB Memory allocation failed\n");
> + if (!hba->lrb)
> goto out;
> - }
> +
> return 0;
> out:
> return -ENOMEM;
Looks good to me.
Reviewed-by: Subhash Jadavani <[email protected]>
PS: ufshcd_memory_alloc() also does some DMA coherent memory allocation
(via dmam_alloc_coherent() APIs) and tries to print out the message on
allocation failure. Although i don't know "out of memory" messages will
be printed out by dmam_alloc_coherent() APIs or not. If it does print it
out then we might want to remove our local memory allocation failure log
messages.
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On 2017-04-25 13:30, SF Markus Elfring wrote:
> From: Markus Elfring <[email protected]>
> Date: Tue, 25 Apr 2017 22:00:05 +0200
>
> The script "checkpatch.pl" pointed information out like the following.
>
> WARNING: void function return statements are not generally useful
>
> Thus remove such a statement here.
>
> Signed-off-by: Markus Elfring <[email protected]>
> ---
> drivers/scsi/ufs/ufshcd.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 5216e33e61a3..9018f26a5667 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -4966,7 +4966,6 @@ static void
> ufshcd_exception_event_handler(struct work_struct *work)
>
> out:
> pm_runtime_put_sync(hba->dev);
> - return;
> }
>
> /* Complete requests that have door-bell cleared */
Looks good to me.
Reviewed-by: Subhash Jadavani <[email protected]>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
> Although i don't know "out of memory" messages will be printed out by dmam_alloc_coherent() APIs
> or not.
Would such information belong to the programming interface documentation?
Are there any related tags or source code annotations needed?
Regards,
Markus
On Wed, 2017-04-26 at 10:57 -0700, Subhash Jadavani wrote:
> PS: ufshcd_memory_alloc() also does some DMA coherent memory allocation
> (via dmam_alloc_coherent() APIs) and tries to print out the message on
> allocation failure. Although i don't know "out of memory" messages will
> be printed out by dmam_alloc_coherent() APIs or not. If it does print it
> out then we might want to remove our local memory allocation failure log
> messages.
Basically most everything that has a gfp_t argument does a
dump_stack() on OOM unless __GFP_NOWARN is specified by that gfp_t.
> Basically most everything that has a gfp_t argument does a
> dump_stack() on OOM unless __GFP_NOWARN is specified by that gfp_t.
How do you think about to improve any programming interface documentation
around such a function property?
Are there any special checks needed for function implementations
which can pass the flag “__GFP_NOWARN”?
Regards,
Markus
On Wed, 2017-04-26 at 20:50 +0200, SF Markus Elfring wrote:
> > Basically most everything that has a gfp_t argument does a
> > dump_stack() on OOM unless __GFP_NOWARN is specified by that gfp_t.
>
> How do you think about to improve any programming interface documentation
> around such a function property?
Feel free to submit documentation patches.
> Are there any special checks needed for function implementations
> which can pass the flag “__GFP_NOWARN”?
No.
> Feel free to submit documentation patches.
Do involved software developers agree on the functionality for
stack dumps because of out of memory situations?
Regards,
Markus
>> PS: ufshcd_memory_alloc() also does some DMA coherent memory allocation
>> (via dmam_alloc_coherent() APIs) and tries to print out the message on
>> allocation failure. Although i don't know "out of memory" messages will
>> be printed out by dmam_alloc_coherent() APIs or not. If it does print it
>> out then we might want to remove our local memory allocation failure log
>> messages.
>
> Basically most everything that has a gfp_t argument does a
> dump_stack() on OOM unless __GFP_NOWARN is specified by that gfp_t.
How do you think about to continue the clarification for this aspect
of the involved programming interfaces?
Regards,
Markus