From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from smtprelay0247.hostedemail.com ([216.40.44.247]:34372 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755321AbbCFUV6 (ORCPT ); Fri, 6 Mar 2015 15:21:58 -0500 Message-ID: <1425673313.12017.47.camel@perches.com> (sfid-20150306_212204_829181_D6E538D5) Subject: Re: [PATCH 1/1] staging: rtl8723au: Remove unnecessary OOM message From: Joe Perches To: Jes Sorensen Cc: Julia Lawall , Quentin Lambert , Larry Finger , Greg Kroah-Hartman , kernel-janitors@vger.kernel.org, linux-wireless@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Date: Fri, 06 Mar 2015 12:21:53 -0800 In-Reply-To: References: <20150306082140.GA9740@sloth> <1425663302.12017.32.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, 2015-03-06 at 14:43 -0500, Jes Sorensen wrote: > Joe Perches writes: > > On Fri, 2015-03-06 at 11:08 -0500, Jes Sorensen wrote: > >> Julia Lawall writes: > >> > On Fri, 6 Mar 2015, Jes Sorensen wrote: > >> >> Quentin Lambert writes: > >> >> > This patch reduces the kernel size by removing error messages > >> >> > that duplicate > >> >> > the normal OOM message. > >> >> > A simplified version of the semantic patch that finds this problem is as > >> >> > follows: (http://coccinelle.lip6.fr) > >> >> This patch removes useful warnings about what allocation failed. The > >> >> messages removed are NOT duplicate! > >> > Is it really the case that the information can't be reconstructed from the > >> > information generated by kmalloc on failure? To my understanding there is > >> > a stack trace, and from scanning through the changes I see only one change > >> > per function, so perhaps the stack trace already makes it clear where the > >> > problem occurred? > >> It may be possible to backtrack, but this change just makes it harder. > >> There are tons of real issues to fix in this driver, this patch just > >> increases the risk of patch conflicts for no real gain. > > > > Making the allocation less likely to fail for > > low memory systems is a gain. > > > > The allocation failures themselves are low > > likelihood events. Determining which specific > > memory allocation failure occurred has near > > nil value. > > Joe, Jes, > That is bologna, We disagree, and I rather like minced meat sausages. > knowing which allocation failed has a lot of value, it > allows the developer to go back and look at the allocation sizes, > parameters applied etc. Likely enough of this is emitted by the generic OOM message and stack dump. > This is a classic case of blindly applied script 'fixes' causing more > harm than good. cheesy tomato/tomahto. Goes well with baloney. cheers, Joe