From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Perches Date: Tue, 09 May 2017 15:18:27 +0000 Subject: Re: [PATCH] net: dsa: loop: Check for memory allocation failure Message-Id: <1494343107.20782.2.camel@perches.com> List-Id: References: <20170506052945.2639-1-christophe.jaillet@wanadoo.fr> <063D6719AE5E284EB5DD2968C1650D6DCFFE715E@AcuExch.aculab.com> <1494265443.31950.62.camel@perches.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Florian Fainelli , Julia Lawall Cc: David Laight , 'Christophe JAILLET' , "andrew@lunn.ch" , "vivien.didelot@savoirfairelinux.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kernel-janitors@vger.kernel.org" On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote: > On 05/08/2017 04:46 PM, Julia Lawall wrote: > > On Mon, 8 May 2017, Joe Perches wrote: > > > Each time -EPROBE_DEFER occurs, another set of calls to > > > dsa_switch_alloc and dev_kzalloc also occurs. > > > > > > Perhaps it'd be better to do: > > > > > > if (ps->netdev) { > > > devm_kfree(&devmdev->dev, ps); > > > devm_kfree(&mdiodev->dev, ds); > > > return -EPROBE_DEFER; > > > } > > > > Is EPROBE_DEFER handled differently than other kinds of errors? > > In the core device driver model, yes, EPROBE_DEFER is treated > differently than other errors because it puts the driver on a retry queue. > > EPROBE_DEFER is already a slow and exceptional path, and this is a > mock-up driver, so I am not sure what value there is in trying to > balance devm_kzalloc() with corresponding devm_kfree()... Example code should be as correct as possible.