From: Qinglang Miao <miaoqinglang@huawei.com>
To: Eric Sandeen <sandeen@sandeen.net>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
<linux-xfs@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xfs: check the return value of krealloc() in xfs_uuid_mount
Date: Thu, 26 Nov 2020 09:21:11 +0800 [thread overview]
Message-ID: <9f998a9d-0684-6b45-009e-acf2e0ac4c85@huawei.com> (raw)
In-Reply-To: <365b952c-7fea-3bc2-55ea-3f6b1c9f9142@sandeen.net>
在 2020/11/25 23:55, Eric Sandeen 写道:
> 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 <hulkci@huawei.com>
>> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
>> ---
>> 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
Hi Eric,
Sorry for neglecting __GFP_NOFAIL symbol, and I would add a WARN in
memory failure next time.
Thanks for your advice!
>
>> + xfs_uuid_table = if_xfs_uuid_table;
>> hole = xfs_uuid_table_size++;
>> }
>> xfs_uuid_table[hole] = *uuid;
>>
> .
>
next prev parent reply other threads:[~2020-11-26 1:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 6:50 Qinglang Miao
2020-11-25 15:55 ` Eric Sandeen
2020-11-26 1:21 ` Qinglang Miao [this message]
2020-11-26 2:16 ` Gao Xiang
2020-11-26 3:05 ` Qinglang Miao
2020-11-26 3:13 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f998a9d-0684-6b45-009e-acf2e0ac4c85@huawei.com \
--to=miaoqinglang@huawei.com \
--cc=darrick.wong@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®