Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp480939pxu; Wed, 25 Nov 2020 07:59:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJxwr2typwwuO81E/iz++VMAFqjjv4lds4yT9hEZBH1aKTiLTz2OHZDTO/3G7b8p7Y07ePGk X-Received: by 2002:a05:6402:17d9:: with SMTP id s25mr4052208edy.132.1606319944949; Wed, 25 Nov 2020 07:59:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606319944; cv=none; d=google.com; s=arc-20160816; b=IKryKuSE3Sd2R8SRnQrLyTZoNo23yev9mc3IIXww4BAQgh5N/JWrp2sYRU55hU7O3Q 2qe87tWFBbjE8226fiHEwmYDc0f20+bs9MwCdfVcQnAnCmj8OkccQa4ym3D2EHxf1WOW 47U9jb4Fq/SlGmH6H8NV2L4h5Ejb+v1eMj/gZsVsvWDfZbFv5IVbUWdNaMoyyGYvv/3w mNeE8228sqM7cYlIQaXaaoi/872NsgmgJUF3+G0xep+NYwCZx7Bq0ow15S3sF42H31WW ugk7IwEMbv14K5A/Be7Q905fIkRWF0Xm4oBeRgMfsyF5r6YzifNJAJ7IKPKZBf3plojx rzBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=sIvBbJbXtxcNQIA+E6pAsIk5lka/bwxJVvCwsK/Lof0=; b=dbfnVKdGXosow49ImzJ5YGxm6u8zOjgVQiJTESs2kcZdRBZDC4ej8cEAexTsu6QLbt Uy/5PbYOJbd/D9F5o8TkofKqD9hqrMuLk7moGDE+rXt3wljhB6w5jC+DBu5v0+I8tINR wazSSsN0mKI46XJtgSmldOBnzYPooss5zIWZuKkc3Cd8p2K8dXQMX2kIaLof5x4vKKzB 51BujX+zGAU5yGJgvR1OZJs8roEy1M0FmhN337lS1x8K1IUp+FRRtOf9BcVo8wmElACq utoswiJb36r0OYlHAmwjH9Q4776evZ8myxvKnfp3oF7JJ1n5lCLUdvoveZQDJY7Zowyv 2eXw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lr24si1320363ejb.482.2020.11.25.07.58.41; Wed, 25 Nov 2020 07:59:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730660AbgKYPz3 (ORCPT + 99 others); Wed, 25 Nov 2020 10:55:29 -0500 Received: from sandeen.net ([63.231.237.45]:49388 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730591AbgKYPz3 (ORCPT ); Wed, 25 Nov 2020 10:55:29 -0500 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id DBFEA323C1C; Wed, 25 Nov 2020 09:55:21 -0600 (CST) To: Qinglang Miao , "Darrick J. Wong" , linux-xfs@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20201125065036.154312-1-miaoqinglang@huawei.com> From: Eric Sandeen Subject: Re: [PATCH] xfs: check the return value of krealloc() in xfs_uuid_mount Message-ID: <365b952c-7fea-3bc2-55ea-3f6b1c9f9142@sandeen.net> Date: Wed, 25 Nov 2020 09:55:27 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201125065036.154312-1-miaoqinglang@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/25/20 12:50 AM, Qinglang Miao wrote: > krealloc() may fail to expand the memory space. Even with __GFP_NOFAIL? * ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior and all allocation requests will loop endlessly until they succeed. This might be really dangerous especially for larger orders. > Add sanity checks to it, > and WARN() if that really happened. As aside, there is no WARN added in this patch for a memory failure. > Fixes: 771915c4f688 ("xfs: remove kmem_realloc()") > Reported-by: Hulk Robot > Signed-off-by: Qinglang Miao > --- > fs/xfs/xfs_mount.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 150ee5cb8..c07f48c32 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -80,9 +80,13 @@ xfs_uuid_mount( > } > > if (hole < 0) { > - xfs_uuid_table = krealloc(xfs_uuid_table, > + uuid_t *if_xfs_uuid_table; > + if_xfs_uuid_table = krealloc(xfs_uuid_table, > (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), > GFP_KERNEL | __GFP_NOFAIL); > + if (!if_xfs_uuid_table) > + goto out_duplicate; And this would emit "Filesystem has duplicate UUID" which is not correct. But anyway, the __GFP_NOFAIL in the call makes this all moot AFAICT. -Eric > + xfs_uuid_table = if_xfs_uuid_table; > hole = xfs_uuid_table_size++; > } > xfs_uuid_table[hole] = *uuid; >