On 9/13/17 7:24 PM, Brown, Aaron F wrote: >> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@xxxxxxxxxx] On Behalf >> Of Christophe JAILLET >> Sent: Monday, August 28, 2017 10:13 AM >> To: Waskiewicz Jr, Peter <peter.waskiewicz.jr@xxxxxxxxx>; Kirsher, Jeffrey T >> <jeffrey.t.kirsher@xxxxxxxxx> >> Cc: netdev@xxxxxxxxxxxxxxx; kernel-janitors@xxxxxxxxxxxxxxx; intel-wired- >> lan@xxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx >> Subject: Re: [Intel-wired-lan] [PATCH] igb: check memory allocation failure >> >> Le 28/08/2017 à 01:09, Waskiewicz Jr, Peter a écrit : >>> On 8/27/17 2:42 AM, Christophe JAILLET wrote: >>>> Check memory allocation failures and return -ENOMEM in such cases, as >>>> already done for other memory allocations in this function. >>>> >>>> This avoids NULL pointers dereference. >>>> >>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx> >>>> --- >>>> drivers/net/ethernet/intel/igb/igb_main.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> > > This seems to be fine from a "it does not break in testing" perspective, so... > > Tested-by: Aaron Brown <aaron.f.brown@xxxxxxxxx > >>> -PJ >>> >> Hi, >> >> in fact, there is no leak because the only caller of 'igb_sw_init()' >> (i.e. 'igb_probe()'), already frees these resources in case of error, >> see [1] >> >> These resources are also freed in 'igb_remove()'. >> >> Best reagrds, >> CJ >> >> [1]: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux- >> next.git/tree/drivers/net/ethernet/intel/igb/igb_main.c#n2775 > > But is PJ's comment saying that it is not really necessary? If so I tend to lean towards the don't touch it if it's not broken perspective. I guess I didn't respond after Christophe replied, sorry about that. The patch is good to me. It's definitely catching an issue where we're not checking for a memory failure, then just follows the same de-allocation path on unwind. If you want it: Acked-by: PJ Waskiewicz <peter.waskiewicz.jr@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
