Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752192AbeACQDZ (ORCPT + 1 other); Wed, 3 Jan 2018 11:03:25 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:39600 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394AbeACQDX (ORCPT ); Wed, 3 Jan 2018 11:03:23 -0500 X-Google-Smtp-Source: ACJfBov+I0rea2rqMOC7okx8rBthc7vJM+cTJ5OK/czrdG8bCNLZUG6ZbtPJeyfPoLK/G2bVyAiR4g== Date: Wed, 3 Jan 2018 09:03:16 -0700 From: Jason Gunthorpe To: Tariq Toukan Cc: Julia Lawall , SF Markus Elfring , linux-rdma@vger.kernel.org, netdev@vger.kernel.org, LKML , kernel-janitors@vger.kernel.org Subject: Re: [PATCH] ethernet: mlx4: Delete an error message for a failed memory allocation in five functions Message-ID: <20180103160316.GB11348@ziepe.ca> References: <30191db0-4d99-0349-b66a-c7354ef90d50@users.sourceforge.net> <0fea8f2f-f8fc-ce2e-3d33-44227de3637a@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 03, 2018 at 01:24:59PM +0200, Tariq Toukan wrote: > >Strings take up space. Since there is a backtrace on an out of memory > >problem, if the string does not provide any more information than the > >position of the call, then there is not much added value. I don't know > >what was the string in this case. If it provides some additional > >information, then it would be reasonable to keep it. > > I don't really accept this claim... The standard we are moving to is to rely on the backtrace print for debugging. It is so huge it is unlikely a single print from the driver will make much difference to the user's view. Most users think backtrace == oops == bug report. > In addition, some out-of-memory errors are recoverable, even though their > backtrace is also printed. For example, in function mlx4_en_create_cq > (appears in patch) we have a first allocation attempt (kzalloc_node) and a > fallback (kzalloc). Please send a patch fixing this as other have suggested, it is clearly a bug. Jason