From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03BEAC3DA7D for ; Tue, 3 Jan 2023 08:13:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 827098E0002; Tue, 3 Jan 2023 03:13:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B0268E0001; Tue, 3 Jan 2023 03:13:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 677BE8E0002; Tue, 3 Jan 2023 03:13:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 545098E0001 for ; Tue, 3 Jan 2023 03:13:08 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 24B15A52CB for ; Tue, 3 Jan 2023 08:13:08 +0000 (UTC) X-FDA: 80312772456.17.9C8536E Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 66B88140002 for ; Tue, 3 Jan 2023 08:13:06 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VZI6wB8m; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672733586; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rMHQUOAHmTg3wO8jl3EtVLVU5btU1+IUye1p3QH4BgY=; b=ijYzneU35QdwY5pTO7tip714/qT7r3nEy5LhgmZxFmDylypSRNP4R46TZnbAGMjiZUWets GYy5t/meVc+douH3gNnVfZCkOkrrR1A3CiKiHOT3t3J8UXd71ssb4wAD+BbX5hpS+5lSsS 9x81BdSuAI7WQkfeOPefH8ryfhcWA14= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VZI6wB8m; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672733586; a=rsa-sha256; cv=none; b=EfbiPmOUGxlclu94Aux4nFx7ZqykqHQUVWxvYkOvs+avjlKG+doSCcVyf4uazwODTq11W6 7tjjIO3kLvcRq+jERImih6BG4b4SY63wIKw8gi9Y7q6xcGZOpHhQhfP4YmPWg4gDdGbTc2 2NYfK7WO7Bd80gXgeE1C5MfQqsgBIbk= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0B41F60B03; Tue, 3 Jan 2023 08:13:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1672733585; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rMHQUOAHmTg3wO8jl3EtVLVU5btU1+IUye1p3QH4BgY=; b=VZI6wB8m0hSplwKxNnwO4QnNP833alU3sEYqyVwgzpugy2N5daS5PT2JCwi4ydw3JOMC/L 50aQGmjI7pAbvUm9gxjQEz9g4aTnp0RhR7L6tT5JJyM/h1tilicFecw1GWQbik+VQA3aeb BgmLpiqWvxnUhYUX/n78pz+U/oUz9fA= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id DDE82139F1; Tue, 3 Jan 2023 08:13:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id OGFQM5Djs2NwfgAAMHmgww (envelope-from ); Tue, 03 Jan 2023 08:13:04 +0000 Date: Tue, 3 Jan 2023 09:13:04 +0100 From: Michal Hocko To: Tetsuo Handa Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev, syzbot , syzkaller-bugs@googlegroups.com, linux-mm Subject: Re: [PATCH] fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_load_attr_list() Message-ID: References: <00000000000027524405f1452ea8@google.com> <7b10c1aa-0b3a-da0d-ea0e-b135cffc3491@I-love.SAKURA.ne.jp> <38352801-b4ae-0cdc-17ba-06b363da3aa6@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 66B88140002 X-Rspam-User: X-Stat-Signature: jcegbb5knurdpuuukyk6zbw1qpf6mboz X-HE-Tag: 1672733586-835335 X-HE-Meta: U2FsdGVkX1/wRJ9t0NoScmLS0AaBS6s/N+pGvKT/CWT1tnVnrN4Ff9on5qoXK7pAAT0lFLy4Jw8my+xxnOYR+ROVbJvRnnBwpzpyMfN0E21sWtAPLxDPtmHvt1Xa7sjnAfU6gOg5NizyYwRMh8M718OlhEUZ227PEi+TJ8iG8mxy6LuYoHJsroY649RjiEiwgkMAYBN1/SiRjXP24COknBFExaRSy2BQuAfGa8BbUIGvlpbSc+66C0YENb9KshdnJN4o4g38tvNA4hfwrYdX2AheFgc4XbOO44P/2H3tn7YVGIhugMfkjYvhG0UFgrShnvoXYkzYl9hUk0EXV/eg2X4y+rKBiRQRDQsfVQ0D+ZOptGGS2xORAFT93HMFui9hhYi30QKkawz0JoLLVr9y54Ck6+iueiubKXSadwkC2tp7nD7JtGeVZCAr6/GxsrshDz1OUI0kqwhWJNtNOPF9Rigz/aixG5FfeKnDhvBhU2dc4D/Sq0GHc3OICOWKBh/HlEU4lHjJinVyxLmhQ7sZeVevvTpDzOOSKprwIC6OzCv97M/hk0xJw56BPqiSgrSubhH1xjQ1cfA3iQzLe52tekh6QCFlw3YaEIqb5yEwK+Klye05/EwYI67hqEGv/ygeIAKvpSR13r9E4r8PMFfeXfNC7IaZM98QgSqjaOSTKMXhsWip1Tnlm4YN8duh9LJZ3NvMAjT1WMUy5v85HkTuL//7FGOz1Ijv+ZYMU+Mh3jGMGvbO5OhfVx562LWcXBNVgsGV9cTvZoCV4VlAB7XkfPDn1wQQlqLf7y6XaeKPbxN8sLGgfRyMEB3V1rvHCX0BbS/FIyUB3fbkt4R7e70eU//rYrgNcPceEQh37RAbMxxjWEvhNrbkFJQag+gY6sqjHJVaAzy+oIXpSW3LjrVXd4jEFxzO9MU3kdrX6sczlSqoxuXWDPeXEzf4TYBs/W9uKCbVP3v5/eADGqx3c/V MppaYv+Y A8lVSm75nSyqOrmzbChMebMCQMO2FzB0wzP// X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 03-01-23 09:01:34, Michal Hocko wrote: > On Tue 03-01-23 09:49:22, Tetsuo Handa wrote: > > 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()") > > Bad examples to follow. > > > Is KMALLOC_MAX_SIZE intended to be used by callers like > > > > https://linux.googlesource.com/linux/kernel/git/torvalds/linux/+/a5a1e1f249db4e0a35d3deca0b9916b11cc1f02b%5E! > > > > ? > > Nope, this doesn't look right either. This all is about inhibiting the > warning much more than actually fixing the underlying problem which > would be either check against a _specification_ based or _reasonable_ > expectation based range or using kvmalloc instead if the range is not > well defined. Let me clarify some more because there are two things happening here. kvmalloc (or its variants) should be used whenever there is a risk the allocation request size is large (>>PAGE_SIZE) sounds like reasonable rule of thumb because those allocations shouldn't put an additional pressure on a fragmented system. Any user input, and that applies to potentially crafted fs images, should be checked for runaway values. If there is specification in place then this is no brainer. If the value is not well specified then there should be reasonable defensive checking done. KMALLOC_MAX_SIZE doesn't sound like a good fit for the check as that is an internal implementation specific constant for a particular memory allocator. vmalloc allows much larger allocations and sometime that is a reasonable thing to allow. So those checks should be domain specific. -- Michal Hocko SUSE Labs