From mboxrd@z Thu Jan 1 00:00:00 1970 From: SF Markus Elfring Date: Sat, 26 Aug 2017 11:17:00 +0000 Subject: Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc() Message-Id: List-Id: References: <75622f45-f46c-e52f-2b9e-6ff5ce32184a@users.sourceforge.net> <3d355c13-159a-2570-9ead-af93ad95c210@users.sourceforge.net> <019b6365c15b0764c156d6453648f7a2@codeaurora.org> <1493231242.18659.28.camel@perches.com> In-Reply-To: <1493231242.18659.28.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Joe Perches , Subhash Jadavani , linux-scsi@vger.kernel.org, linux-scsi-owner@vger.kernel.org Cc: "James E. J. Bottomley" , "Martin K. Petersen" , Vinayak Holikatti , LKML , kernel-janitors@vger.kernel.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. > > 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