From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754312AbdHZLRV (ORCPT ); Sat, 26 Aug 2017 07:17:21 -0400 Received: from mout.web.de ([217.72.192.78]:58024 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752126AbdHZLRU (ORCPT ); Sat, 26 Aug 2017 07:17:20 -0400 Subject: Re: scsi: ufs: Delete an error message for a failed memory allocation in ufshcd_memory_alloc() 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 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> From: SF Markus Elfring Message-ID: Date: Sat, 26 Aug 2017 13:17:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1493231242.18659.28.camel@perches.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:SL7hKGHNJ629eCnK1cZaPtXIBQfWzrj9X9mCZ1UX8ByOwvwxmUy SinXrMBaVEjmB5LRkMJsWGx5Dtp7wFVGHLZ/WAJUkT+XtRsTXyEezlVM2msdVXvO5EeqmYP AOX1LDO1xPJPz0zp3W34ALgl/A8Mn5sGDdtIZvbdcaRBvjcFdaNRmfLkpWrDF/Bhb6gexgT jKKYBwudwe/HBPPmt0G1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:47hSZRLhwho=:oN9BfGH/X/pKslerJ6mbym pTetKg6+zI837FCqm7lQTPm7Hw/OVvTsRs8BFR7HkxLg3ZRFbhvISpsSWhJH8D8ZPelEXxHZS NSgLgzC6iYIZCMklG505PYqTZxwlQhukn85nxXI9x8en0AjM8SLPlrB8UZEUy4gPKOyaVQXzb CXAe58Ji0Kr6JSHGLsl6aE3QMovqtyLJfoUElpT5cZwkJEnz6g9/Ew7qlplGTMgq4w208JQIg m4OGEx0V3WgNqUlYnwOn/RPWQ/ngvEkUlighl3ft/fDylpexpUZL/W+Y1f5EIp8LhW312ei11 ZDHK4o6uDqB1a5IY6ZR/lC2LEZ0t8a/JwMZOrFdu93tCSj4PTB8pEYSeLyJ8wM84cLpk9xXZC TWr5Sk3HRys9NS7411JZihsOTE7bbgjbufzl+Rk/cjskBushngH/6fPWro2pI7YsGU7XHNczT BhkHzzhFLRJN5H/il+v20CN6r8vU8wLVDTsRgToztd8aCP3kgp8uPj3BrqKSioU2h57tUr6T1 FzUfoA4D/susSkVgqO0xg/mycVuZ0s1WUkQWegyATDVTfohfIrzSp2WbK2gRf86cFS9dbMMV8 JIq3pZznydE/CJkZoOFXk/cIJPP4iDJ/lM3gi9A/JX9IJG1qqguwLYcd2YdBMOzJSQUX5fnXa uQMfV5lmUPDm76xowJEubd9E1P9N6flS7eVK5g7/N3SWs7dri8PenemRQQeOF5x/te6VQzB2R CGsuFH8Jfd1QFyHkLy/+CEZ9Qbm5QI6UO/ardJoexOORrjDSo0n8V7N812TyXtC0SLGrPCAu4 jL4kNKIZuxssPAA/Klhe4vhukPdeHSIat1JE0u0d4Y8Nq593LQ= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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 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