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 A4B9DC63797 for ; Tue, 17 Jan 2023 11:11:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 296416B0073; Tue, 17 Jan 2023 06:11:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 246106B0075; Tue, 17 Jan 2023 06:11:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 135D26B0078; Tue, 17 Jan 2023 06:11:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 047E56B0073 for ; Tue, 17 Jan 2023 06:11:50 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B8978120A96 for ; Tue, 17 Jan 2023 11:11:49 +0000 (UTC) X-FDA: 80364025938.02.D190AAB Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf04.hostedemail.com (Postfix) with ESMTP id 4013140005 for ; Tue, 17 Jan 2023 11:11:46 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; dmarc=none; spf=none (imf04.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673953908; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qytGHu82VK3CUqFmu7D++WVNpN/DYUsBjfwHEG80AhA=; b=gdCdW4UiI17seoroOzRnsXzMVeozAQx1MoSnYFFKXR6PGeZt6blmmQBD4+kYQGmrK7JnC8 It3Szi2fKi1uuAMi4reP6pZACbuduzcmj0Izr3Sfm25mc5mu9k05iz+2KZScE8oLkDXCcN yF/WEKekh4uQ/lCOdBq9mTFw6urC8Js= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; dmarc=none; spf=none (imf04.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673953908; a=rsa-sha256; cv=none; b=5btrkApqcU1RNXKMGqPtvcKCblnNQdqwnHVkOoGTGThEcXeJg8bj4hPUnnFlKrBtJcafjJ XJCT2Hh79d4IYSkyNLX3KyQm5GU2rlBJX0zs7zHTa2gbbFgWey5S108Fc4ugzwVAol30Ur 2saRx9qny1OKsHjgMbioWdBBUdu0fPY= Received: from fsav118.sakura.ne.jp (fsav118.sakura.ne.jp [27.133.134.245]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 30HBBeeB053962; Tue, 17 Jan 2023 20:11:40 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav118.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav118.sakura.ne.jp); Tue, 17 Jan 2023 20:11:40 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav118.sakura.ne.jp) Received: from [192.168.1.20] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 30HBBe92053959 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Jan 2023 20:11:40 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <518d5b42-be63-28ad-f28e-0f1d5d992230@I-love.SAKURA.ne.jp> Date: Tue, 17 Jan 2023 20:11:38 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH] fs/ntfs3: Use __GFP_NOWARN allocation at ntfs_load_attr_list() Content-Language: en-US To: Konstantin Komarov Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev, syzbot , syzkaller-bugs@googlegroups.com, linux-mm , Michal Hocko References: <00000000000027524405f1452ea8@google.com> <7b10c1aa-0b3a-da0d-ea0e-b135cffc3491@I-love.SAKURA.ne.jp> <38352801-b4ae-0cdc-17ba-06b363da3aa6@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4013140005 X-Stat-Signature: r9x1jnfghu1sk6gc5f78qm6gm3p9a571 X-HE-Tag: 1673953906-778736 X-HE-Meta: U2FsdGVkX19PD5s36+SFjP6XZ3yd0+nwKATXVo4rklpHLmjKG0GIS+XghzNYNOcm5yeZD1rbWMZJHvtEoGx/7Q4aHlLsu6QhPMvU59HM9tyF2Zo0ZtCl0f87gBCkclrKda7QrociahMdgtKqnRZQCqMWIMmQnWnAfMzPqTVPOe/2CnNljuxLbuRPyM+bUyZW6PGu6v/SRihvFLvbH18+QB92e1gdiyGknhwEeTteaJanxMteJl0+8JFMz5shB/XTmJWa9CEU+AjBFDznn1KoxQYUkZ+qyl/opAIAcH4oAnIsPDZICzZi4vcOlULhDrybEeqMOzmd8joPKqBtQdCQOUcVN0TnAkx4rkJN6DAttHm5z075wpXQ0rpMmazQAwkBTW274JgVHZS/hJc/r1m7OY28FjS39nXvEg46bpF2PuXQ+PmUktGFuUdQRwAQkdtFJ3yeo9kDlXTyTfTkRunHy47bp03NF7m6f52ub5T736HeWCeMwCnWudTpobMO9LBXdt0OkvdW75nAL1YAU5LD2KT8vel38WqAWu0JlH+X6vtPVOKU4/QSMm63YwPI1WTeExXGXkTJjm5GCGO/omn+HSJfIaRa7oSh9TuqZVcfQ4LDDuU1L7xMaar4cj9WYpSC3kqON5GctPS2jMAkXxMH5D7EcUyIPiG4O42AcIxYuLf3mmwnK2OXrouomcJ50Fs+zAPcxvaz9INrCdtW6p28nOdpZCqFPEQg2ntVSIuc+zpoBHxf5nD+4PI4nIo0J5/atu+7NiBnQzV7EXnkhHrYpbKLtkW+Z00vc30YG8fLgqTv2d7DmFM7lSoFVjW/O9Hg2jUEQ2i8o2fpT2Mfm96DUwL/GCq3pVVvd+J7WyaGjJdPPd9Q+KSbUIGExW7aoVEtMx+iwKvp/lwD4wY+Rrp0Skj5sJXGU6C+99KUSfBShNAd5AA/ZaGjU1BYbWXODUYD4f4dJKYTKsm9B6RBgQL I8TKY5LB yg+j/Fb+yZCRZLmM0YMbZJ/jsg8YUfml34nwZ 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: Konstantin, what is the expected max size? Can this allocation for legitimate filesystem become large enough to try vmalloc() ? On 2023/01/03 17:13, Michal Hocko wrote: > 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. >