[PATCH 0/3] SCSI-UFSHCD: Fine-tuning for two function implementations

[PATCH 0/3] SCSI-UFSHCD: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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

[PATCH 0/3] SCSI-UFSHCD: Fine-tuning for two function implementations

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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

[PATCH 1/3] scsi: ufs: Use devm_kcalloc() in ufshcd_memory_alloc()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

[PATCH 1/3] scsi: ufs: Use devm_kcalloc() in ufshcd_memory_alloc()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

[PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

[PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

[PATCH 3/3] scsi: ufs: Delete an unnecessary return statement in ufshcd_exception_event_handler()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

[PATCH 3/3] scsi: ufs: Delete an unnecessary return statement in ufshcd_exception_event_handler()

[SF Markus Elfring]

From: Markus Elfring <elfring@users.sourceforge.net>
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 <elfring@users.sourceforge.net>
---
 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

Re: [PATCH 1/3] scsi: ufs: Use devm_kcalloc() in ufshcd_memory_alloc()

[Subhash Jadavani]

On 2017-04-25 13:26, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/3] scsi: ufs: Use devm_kcalloc() in ufshcd_memory_alloc()

[Subhash Jadavani]

On 2017-04-25 13:26, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[Subhash Jadavani]

On 2017-04-25 13:28, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

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

Re: [PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_a

[Subhash Jadavani]

On 2017-04-25 13:28, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

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

Re: [PATCH 3/3] scsi: ufs: Delete an unnecessary return statement in ufshcd_exception_event_handler()

[Subhash Jadavani]

On 2017-04-25 13:30, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/3] scsi: ufs: Delete an unnecessary return statement in ufshcd_exception_event_handler(

[Subhash Jadavani]

On 2017-04-25 13:30, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> 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 <elfring@users.sourceforge.net>
> ---
>  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 <subhashj@codeaurora.org>

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[SF Markus Elfring]

> 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

Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[SF Markus Elfring]

> 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

Re: [PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[Joe Perches]

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.

Re: [PATCH 2/3] scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_a

[Joe Perches]

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.

Re: Checking error messages for failed memory allocations

[SF Markus Elfring]

> 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

Re: Checking error messages for failed memory allocations

[SF Markus Elfring]

> 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

Re: Checking error messages for failed memory allocations

[Joe Perches]

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.

Re: Checking error messages for failed memory allocations

[Joe Perches]

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.

Re: Checking error messages for failed memory allocations

[SF Markus Elfring]

> 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

Re: Checking error messages for failed memory allocations

[SF Markus Elfring]

> 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

Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[SF Markus Elfring]

>> 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

Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc()

[SF Markus Elfring]

>> 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