Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751439AbcLDUw0 (ORCPT ); Sun, 4 Dec 2016 15:52:26 -0500 Received: from b.ns.miles-group.at ([95.130.255.144]:44723 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751038AbcLDUwY (ORCPT ); Sun, 4 Dec 2016 15:52:24 -0500 Subject: Re: [PATCH 1/1] mtd: ubi: fix improper return value To: Joe Perches , Marek Vasut , Pan Bian , Artem Bityutskiy , 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: Richard Weinberger Message-ID: <0446c91c-ac84-3601-203a-9c2e7057f1f9@nod.at> Date: Sun, 4 Dec 2016 21:52:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 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: 956 Lines: 25 On 04.12.2016 21:33, Joe Perches wrote: >>> 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. We should better think about how to get ubi_self_check_all_ff() fixed. When enabled on a modern NAND, vmalloc() is likely to fail now and then since len is the erase block size and can be up to a few mega bytes. Thanks, //richard