From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Michal Hocko <mhocko@suse.com>
Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev,
syzbot <syzbot+89dbb3a789a5b9711793@syzkaller.appspotmail.com>,
syzkaller-bugs@googlegroups.com, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_load_attr_list()
Date: Tue, 3 Jan 2023 09:49:22 +0900 [thread overview]
Message-ID: <38352801-b4ae-0cdc-17ba-06b363da3aa6@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <Y7M8bwYAzyuYbmP3@dhcp22.suse.cz>
On 2023/01/03 5:19, Michal Hocko wrote:
>> @@ -52,7 +52,7 @@ int ntfs_load_attr_list(struct ntfs_inode *ni, struct ATTRIB *attr)
>>
>> if (!attr->non_res) {
>> lsize = le32_to_cpu(attr->res.data_size);
>> - le = kmalloc(al_aligned(lsize), GFP_NOFS);
>> + le = kmalloc(al_aligned(lsize), GFP_NOFS | __GFP_NOWARN);
>
> This looks like a bad idea in general. The allocator merely says that
> something is wrong and you are silencing that. The calling code should
> check the size for reasonable range and if larger size. Moreover, if
> lsize can be really more than PAGE_SIZE this should be kvmalloc instead.
There are already similar commits.
commit 0d0f659bf713 ("fs/ntfs3: Use __GFP_NOWARN allocation at wnd_init()")
commit 59bfd7a483da ("fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_fill_super()")
Is KMALLOC_MAX_SIZE intended to be used by callers like
https://linux.googlesource.com/linux/kernel/git/torvalds/linux/+/a5a1e1f249db4e0a35d3deca0b9916b11cc1f02b%5E!
? I think that, unless there is a known upper limit defined by specification,
checking for overflow and silence like
https://lkml.kernel.org/r/6d878e01-6c2f-8766-2578-c95030442369@I-love.SAKURA.ne.jp
is fine. These input are random values which do not need to succeed by using kvmalloc().
next parent reply other threads:[~2023-01-03 0:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <00000000000027524405f1452ea8@google.com>
[not found] ` <7b10c1aa-0b3a-da0d-ea0e-b135cffc3491@I-love.SAKURA.ne.jp>
[not found] ` <Y7M8bwYAzyuYbmP3@dhcp22.suse.cz>
2023-01-03 0:49 ` Tetsuo Handa [this message]
2023-01-03 8:01 ` Michal Hocko
2023-01-03 8:13 ` Michal Hocko
2023-01-17 11:11 ` Tetsuo Handa
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=38352801-b4ae-0cdc-17ba-06b363da3aa6@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=ntfs3@lists.linux.dev \
--cc=syzbot+89dbb3a789a5b9711793@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/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