| Message ID | 3d355c13-159a-2570-9ead-af93ad95c210@users.sourceforge.net (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
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.
> 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
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;