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 C3AEEE7718B for ; Mon, 30 Dec 2024 02:55:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6A5F6B007B; Sun, 29 Dec 2024 21:55:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D195F6B0083; Sun, 29 Dec 2024 21:55:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C07D66B0085; Sun, 29 Dec 2024 21:55:42 -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 A40596B007B for ; Sun, 29 Dec 2024 21:55:42 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4E389B133A for ; Mon, 30 Dec 2024 02:55:42 +0000 (UTC) X-FDA: 82950108696.10.AE47457 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf01.hostedemail.com (Postfix) with ESMTP id 4086B40003 for ; Mon, 30 Dec 2024 02:55:03 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp designates 202.181.97.72 as permitted sender) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735527297; a=rsa-sha256; cv=none; b=ayazihef0SJaeOpl7CmtdHHfVfoVWBFc/zMajb8qBBv+PaSqxsa3jHJpw01OKikZi3h99A 6mes5q2K69Z3Iq4I+i404cKIIdu9W7S6SSDzkLEPvUiC7NibaqjdPZ+V4I1HTWJe8Cq/Vb xobGZNwu+x1jo8b0WcmwiMmYp9vFeFk= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp designates 202.181.97.72 as permitted sender) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735527297; 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=1e1sr23V6FmdWk9x845QSJiKxkwPoLKZ5uVyyWp8R/U=; b=GVFr0k1Wg7S0jt9J3lIZxtIsGa/v1Uw576Raw8xV2+r9jLw58130PivEPIptr41CK12K10 ajx0KAcmIe+/zM/Qp2tvK32Yli506Kah61QIECR1ewZNqsqJfYV/5MytNf0I2ZXi74tRyy D2jVuAvd138G9QyNlNfH9yG+a4mJO1w= Received: from www262.sakura.ne.jp (localhost [127.0.0.1]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 4BU2t7cm099861; Mon, 30 Dec 2024 11:55:07 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from [192.168.1.6] (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 4BU2t687099858 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Dec 2024 11:55:06 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <6ac4cb00-4841-4deb-a3f9-7948a1ba5389@I-love.SAKURA.ne.jp> Date: Mon, 30 Dec 2024 11:55:07 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/util: make memdup_user_nul() similar to memdup_user() To: Andrew Morton Cc: linux-mm , LKML , Al Viro , Denis Efremov , Julia Lawall , Michal Hocko , Kees Cook , Vlastimil Babka References: <014cd694-cc27-4a07-a34a-2ae95d744515@I-love.SAKURA.ne.jp> <20241223172552.133f4e293f1dfbb6aa86b5ef@linux-foundation.org> Content-Language: en-US From: Tetsuo Handa In-Reply-To: <20241223172552.133f4e293f1dfbb6aa86b5ef@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Anti-Virus-Server: fsav204.rs.sakura.ne.jp X-Virus-Status: clean X-Rspamd-Queue-Id: 4086B40003 X-Stat-Signature: 48t7gjszwfuoderah8hjxtcqxfw4h4fw X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1735527303-132150 X-HE-Meta: U2FsdGVkX1+2hBklLlQ57QVlpKRpFTtWzR0ZXYJvPXXZQF0zQQeIvUM0SDnDDJRReY6tYswSfm92lKKENWPj9P+23AtDVbX3YEwfrnMNZrkD30UDexMgR/1w8ai/1JFEKlTZxSkuvBiGP2vKTBlpSk1SDyTM2HgqktncMoXrqOAe2+CGJkBRxpQI+XshnIYAuTRbmlXBwET1rfD5ZPm+mvQE31VOwKmQqxqeOhGN+VEb6z3/V6jht3Ba5QQ6VXyYL0BjiHbcpoGb49TSrfbwYnxuchyPLHzT2F8wCaMmu8N6D7BV8QVXprAFKMmJxnfA1Tb71OJbyB1zX0btKPbS2l3E0CnUmoriRvNHXl0ks3XjsU9LcKT/Kfu0r6FGgN/aUPxjStlI4rhG2IBoI21NFbv9HO6aEQ23pKL84klpcU70VT3yniNH33xLwD4/8l8P1bbqKjH5eOgKWl1x3JHzsFOc9/TPjEnXzv+I9q4jvIO1IA2sAbJ3vzM6KOPvJdY2d+5LUZwRLdqarhYH9c8GLiC2JXxCEf988ZYx+elJSyOYKvWHsevpz+lWBtR4tmPf2VaOEX0X+2XbHplqpAtl/PkasRfnKXsdmAx1lRYrcopE+fCw6pjxFi5dRJ7fFBzOeoxDHWPiBMpamocYh6p0sgjxGT2bVDiwn1E7saoyYkLohMHI2SIUM/8EcSc6vViKljrStLF+2GZHQw+tPcjv0FLmqTJnTOY10ix+WCiDdbsv1V6s+tbFs5yEv9ZO6WtFKZ9Ifbp4dyhnxG7i2zhydXeg2P2LZ/OZnFa+YKs4ag/Y0aJAxIRoFNWxvtx4jCIpPJ11CC2ibQb3IBJwwv42InqN2cD9pNu/iBHvkEX7rwLxEsl/97hg6yFQzml7XmAtyAQIbd8TkIrJj0ze1LrX6RQf+7jMIXJCHmGQV5P1wyr6NE+b9JCvle6X9+6kuiyAPUJ3x0z6II9XQChSgXb N1x89z7N XaJdKcmn7MAyrX1Pjm1C1//QfVMm5ktqax+xYVeSD463LQhU3MWusLFCvKdcZAARzyI7/ES8n2aDTHoxOO2iEZNRbGiodTp1b+R02/G9omW1VF2CqU7bf877WLfUKvwMYCWXTFvrb9/J7uRiBjreJeyJWRKrFMl4D+E2fruFGQpjDb8ZBuQv3iDRnK91Oad00ZMmz0WIr+uCKQwlLhc5ilw2MFkHibO/9d3Zs4L7cixje9EmITvoKSAj/euPzeLNef8Uc4oczj9jnAEdQsBG5u6e1O9H3VK5j6c+RaY6nMlfggxSDeN+9jTvCYpvz/LOgS4J03yDrMafKPEE2VyqIN+pYdPye0vIBgjCBmd8pRLpI/CKUEolPam60ZoS1PF8vIpU/jgMAwY5f2BXqB+Dxt5XdjTYqx5l4PymEp9FypGLvJATjWyRiQpuXESUAf0pUKl3gf+0t5AJAQvGG9nq1yGtfpqzlxiljI69c6XIDAzc4JIT9fHpavoRQpZoy596irii5Hxd3OZT1w0a3Vb9gyFKUwbBUa/xgPhhNPc6eLxObITk= 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: List-Subscribe: List-Unsubscribe: On 2024/12/24 10:25, Andrew Morton wrote: > > tl;dr: patch does three different things, some of which appear to be > needed in -stable kernels. > > > On Sat, 21 Dec 2024 16:47:29 +0900 Tetsuo Handa wrote: > >> Since the string data to copy from userspace is likely less than PAGE_SIZE >> bytes, replace GFP_KERNEL with GFP_USER like commit 6c2c97a24f09 >> ("memdup_user(): switch to GFP_USER") does > > Please provide a reason for this change. Does it have user-visible > effects? If so, what are they? I think it is hardly user-visible, for GFP_USER allocations up to 8 * PAGE_SIZE bytes unlikely fails. Also, if there are memdup_user_nul() callers that need larger than 8 * PAGE_SIZE bytes, such user would ask for addition of vmemdup_user_nul(). > >> and add __GFP_NOWARN like commit >> 6c8fcc096be9 ("mm: don't let userspace spam allocations warnings") does. > > Ditto. > >> Also, use dedicated slab buckets like commit d73778e4b867 ("mm/util: Use >> dedicated slab buckets for memdup_user()") does. > > Ditto. > >> Reported-by: syzbot+7e12e97b36154c54414b@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=7e12e97b36154c54414b > > That's a userspace-triggered WARN, so we'll want to backport the fix > into -stable kernels. But we won't necessarly want to backport the > other two changes, depending upon what their effects are. I don't think we need to backport the fix. This problem was found by fuzz testing, and the effect of not backporting is nothing but "too large memory allocation attempt warning" message is printed. > > > In other words, it would be better to present this as a series of three > (fully changelogged!) patches, with one or more of them cc:stable. Maybe commit 547ade42ced0 ("coccinelle: api: extend memdup_user transformation with GFP_USER") provided better description than commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER"). commit 547ade42ced037db77a82e67d70b55c0eecc49e0: coccinelle: api: extend memdup_user transformation with GFP_USER Match GFP_USER and optional __GFP_NOWARN allocations with memdup_user.cocci rule. Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched memdup_user() from GFP_KERNEL to GFP_USER. In almost all cases it is still a good idea to recommend memdup_user() for GFP_KERNEL allocations. The motivation behind altering memdup_user() to GFP_USER: https://lkml.org/lkml/2018/1/6/333 commit 6c8fcc096be9d02f478c508052a41a4430506ab3: mm: don't let userspace spam allocations warnings memdump_user usually gets fed unchecked userspace input. Blasting a full backtrace into dmesg every time is a bit excessive - I'm not sure on the kernel rule in general, but at least in drm we're trying not to let unpriviledge userspace spam the logs freely. Definitely not entire warning backtraces. It also means more filtering for our CI, because our testsuite exercises these corner cases and so hits these a lot. > > If we really do want to roll all three changes into a single patch and > backport that then please let's justify all three backports within the > changelog. >