Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751261AbcLDVhA (ORCPT ); Sun, 4 Dec 2016 16:37:00 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:36332 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbcLDVg6 (ORCPT ); Sun, 4 Dec 2016 16:36:58 -0500 Subject: Re: [PATCH 1/1] mtd: ubi: fix improper return value To: Joe Perches , Pan Bian , Artem Bityutskiy , Richard Weinberger , David Woodhouse , Brian Norris , Boris Brezillon , Cyrille Pitchen , linux-mtd@lists.infradead.org References: <1480831930-5449-1-git-send-email-bianpan201604@163.com> <1480883619.4534.6.camel@perches.com> Cc: linux-kernel@vger.kernel.org, Pan Bian From: Marek Vasut Message-ID: <85f33a89-f349-eac0-a072-d99867b796fb@gmail.com> Date: Sun, 4 Dec 2016 22:36:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480883619.4534.6.camel@perches.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1338 Lines: 39 On 12/04/2016 09:33 PM, Joe Perches wrote: > On Sun, 2016-12-04 at 13:48 +0100, Marek Vasut wrote: >> On 12/04/2016 07:12 AM, Pan Bian wrote: >>> From: Pan Bian >>> >>> When __vmalloc() returns a NULL pointer, the region is not checked, and >>> we cannot make sure that only 0xFF bytes are present at offset. Thus, >>> returning 0 seems improper. >>> >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189081 >>> >>> Signed-off-by: Pan Bian >>> --- >>> drivers/mtd/ubi/io.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c > [] >>> @@ -1413,7 +1413,7 @@ int ubi_self_check_all_ff(struct ubi_device *ubi, int pnum, int offset, int len) >>> buf = __vmalloc(len, GFP_NOFS, PAGE_KERNEL); >>> if (!buf) { >>> ubi_err(ubi, "cannot allocate memory to check for 0xFFs"); >>> - return 0; >>> + return -ENOMEM; >> >> I wonder if you shouldn't also nuke the ubi_err() , because when you run >> out of memory, printk() will likely also fail. > > No, not really. printk doesn't allocate memory. > > But the ubi_err should be removed because all memory > allocations that fail without a specific GFP_NOWARN > flag already have a dump_stack() call. Ah, thanks for the correction :-) -- Best regards, Marek Vasut