From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from SN4PR2101CU001.outbound.protection.outlook.com (mail-southcentralusazon11012018.outbound.protection.outlook.com [40.93.195.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41C924446F6; Mon, 17 Aug 2026 14:37:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.195.18 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786977460; cv=fail; b=MPGDg3OGs7DqTJMM2CrfmMefQ5hMu/zp2vjPl0sNNBmrJA/0r9ox4BYkxAwdECBJ5SeuzDorl9/nkinetcuZxx2yytp9MKB53h6mcJk/aRrHWCv5DcQpQiGrAvHg4JHFWtaUj+JPuUQ7muMC5pyRfMlxlvmpn5m4297LgVEjjX8= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786977460; c=relaxed/simple; bh=uSZnPH7Mc3qmTrIeLctD+y2ZTMbjjAcUYrLv0GtfCUE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=GDAHFMN68VTGlk3/WWvJDnJN8YnaX3nv7pQcZW//9fTEnCth+4a7gVOoTRwofkpzLvCo254wDhziYRF3zR+Y+tsc0L87WfwuyOGAo3KtspsADIssPlBYxg1hAAnxH2ISm5UnqQCDnMKlUAwx/sI2JpLjJ3Zga4JWwdB8ZvsVX9U= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=aZFI3kfl; arc=fail smtp.client-ip=40.93.195.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="aZFI3kfl" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=VeLj0ZDZAXjLRNGXHi83dIw/Ik/gX5yLr4CvWEr7Ng8hMVOPQUwadrrPLC+1wEUhtBSfmbXbMDKB8iq6geIkhXGqXNTEDUhCVQQW70LAVTIZtJtjPOnCxHwVpdiVCrVoMvO6pwKKzXvra+lutdljHGlgcYIHxSvG0GWQMlGcQ+LqY3sx6TRwzsW8FRucZfCs2gTF7+WA7Dsj1sR2UV6l9H+7ZFE2aGGNf0hmRSapM9co2PznuoLC4clQd1sugNZXqov2gegoo33ZgcO1kfm3ia/attqgXRuuRd9L+gxFsaxwF+H3iAvSsGFE5W/rYmra650rf9w0tTXUkC4jRCgIWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Hr9KVv+OxwTYFtiVUzC6gwTabvWBj/QNp1qmEFGuKhI=; b=JWphi66rK2TNosDdEns7I09K/+jzHHcamVqedRDPx4Nb9GXmQGg7MCC0pbBm0A0niQFI8/dnkOvXSWhRUtx35zhu8Fgl/5SIF0uUe5w7j/2Mo0orHw5wWUT5z1UtnoOCDM1f3HN7P3phaBsYGO/Hx+d/O3LotWcRR5PCrwddMeUFtQ47wCThZTbV1XHJfsAGavVXxLja2QNfXTYfJGqQmlsDJMlGvX2zXGNBnIo81Idd8eK7ACEn1haUAVscJYPSovLUCudeYiEQ+C6SsgVULxOmWdx7rJJ0yhru2kn1KLUAN3eEBucoWZHxG1h3mNy9WwlLXfEe++q+++qzaGy95g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Hr9KVv+OxwTYFtiVUzC6gwTabvWBj/QNp1qmEFGuKhI=; b=aZFI3kflEwq7ON4FXM9IWTYRDhSlLdvTZtsy9luY6Ud5/MXiIX/T8Gnv/L6VKYiG43W6LsF5CF+vIYlohtc/kRJMqnrPRu7CGE8QqujrsGAuv180OEt/p8jdO2MZLdBXIdduqkTDyOjAuSJpY0hnUrijwt9/RK60d3ho+T5364pWaPY2AsEBIsvRwwknRVUFlaWdf0x7+vYOB0mRlBjS+ovSmUdBA8CvdoVGYCgbrvq7NivXFkl4AiFSkmTsdvry4Q2T8NqNBDIMze233XDJn3Sf5/U7CKRnV/6f7UIsAMa5HEOHJMkAx4MhZ/H31FgrvYp/cyaTgsTYJNGqRzvr9g== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by IA0PR12MB7775.namprd12.prod.outlook.com (2603:10b6:208:431::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.315.17; Mon, 17 Aug 2026 14:37:31 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0315.016; Mon, 17 Aug 2026 14:37:31 +0000 From: Zi Yan To: Alan Stern Cc: Andrew Morton , syzbot , apopple@nvidia.com, byungchul@sk.com, david@kernel.org, gourry@gourry.net, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, matthew.brost@intel.com, rakie.kim@sk.com, syzkaller-bugs@googlegroups.com, ying.huang@linux.alibaba.com, Greg Kroah-Hartman , linux-usb@vger.kernel.org, Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner Subject: Re: [syzbot] [mm?] WARNING in ep_write_iter Date: Mon, 17 Aug 2026 10:37:29 -0400 X-Mailer: MailMate (3.0r7024) Message-ID: In-Reply-To: References: <6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com> <20260816135201.98590b17b526dda8c4ec9105@linux-foundation.org> <02c2e5c7-0d78-4763-90ff-75fa87105fcb@rowland.harvard.edu> <9787b33b-b30e-4c5e-a0ee-7f14515c7166@rowland.harvard.edu> <20260816194213.0e813ed338144ebc81ed4050@linux-foundation.org> <472add4b-f16a-4b87-bbc3-98c8aa385cf5@rowland.harvard.edu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-MS-Reactions: disallow X-ClientProxiedBy: LV3P220CA0003.NAMP220.PROD.OUTLOOK.COM (2603:10b6:408:234::22) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|IA0PR12MB7775:EE_ X-MS-Office365-Filtering-Correlation-Id: be8b0e4c-a499-40f1-596d-08defc6d11c3 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|7416014|23010399003|376014|366016|6133799003|10067099003|4143699003|11063799006|5023799004|56012099006|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: E4/obcH0YgN7nPeORpjs5QBGdAMtCDS+KC+PxNLDlshSRdL7ocmhiZzgeoKwrZmZ0O1zocTuRSxRokTWzI6LJnJk3Adiq491HbMtcASDc+FbtJ8J+fohg+jOACGQ2vsCcnJ7cHw6e3rXndlKHvOiy5PcGwoCPtyM9orj0j6sjab4Zd5jsH2vL26TpFDNzLM6hjnCa2/ClFUp7eZsiUVQG5fLYE3jnf7oKwyM4l2t3olyrEugQI8DwZhBFTqVsuV1L0qodea92+89AQaVWgv7FEAekiZpel/RXkR5XZHKkZ36T5Zz0EW3OC5WWpXCDsSEiKH9ncRaUksBKQzC+NjqCbbIovJ5+d/00Op8QqlD6p7Xm0eDmcP+EHJkRK8PjX27sFpBpaxEC76bzgEOQ39PczwNgIIuq1MMH3+obVVOPmLgVWrARXsCEllDQ3kswMBGj8JFi9pCEW2NMYuLyFBUWcBtqB5k/9al/fY81JiMOOTDFbYuWOoclL6eAmY9N+FT3W7IQwuMvEnKiwgqmLfPif0MXxSZVh5rnM8x6ClH7fDFv9/hZHVcuUhha1XW+rGuII61loa/vdpuaFBYO4M+z0PPms5mOuRLV0l1Es2rPS78CobaenNEIszxhUDSKezfG8S076zRXjchbcMIYd5DzbRFhi3Zt8om0YOK41Wql5c= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(23010399003)(376014)(366016)(6133799003)(10067099003)(4143699003)(11063799006)(5023799004)(56012099006)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RWMvRjkvd2RZQ0VNQTdDK3BHc2J6SS9MV1kwK3JhUmZqazU0bnpvOTVidm9l?= =?utf-8?B?NUU4WXRjbW13UmFDT1lNdDRWU21TUGFmM0RodnFON1ZhZks5bFpKSmFTamp4?= =?utf-8?B?OXNlU2NxSFpwOWhjSStzVElRNEtkd1pPQS95bUw0Z2JiNDlpZnRYTFM0ZWRK?= =?utf-8?B?REZYWXgvVFZIK1JtVHdaS0ExSVR0K3pML1Q3SENRZW1oYjk4OVJUVlFhUS84?= =?utf-8?B?bUpMeVJ6dUErSTdNendDRlU2aVRmeVd5cG9lQk9pMzUrL2NRQVZqeVYvV0tN?= =?utf-8?B?UzEwRlNHZ3J0dURCbnRXeGFBMWtMWnA5cXpuTUYrblQvbTZyVUR2OXFDeVJk?= =?utf-8?B?emxadldoMG5WZkhSVUpNTS9sTDJxMS94NjFESFdsaldnOUJaeFNySXZORzRX?= =?utf-8?B?SVVDOHhuYk1yZnpCbUQrOEFoWlB0aDdnR201eVVDM1B5VHgyQkIvQVJTMTRC?= =?utf-8?B?c2dmS29Bdys2ZTZjc2gwUXJqVmNZbVBoZjBDMFM5VnNOdWROSE5HTVNGSUtI?= =?utf-8?B?dGtDOHlwSTAwSU9uNUJ1dFpscU50emY0cUJldEczMlpMUVNiZzByOUgwWG5J?= =?utf-8?B?Qmt6QkRZdkV5RkZlSFZPbk1MVTdHZjQ2YmpyQ3lUMmJxRTlqak1ZT2NJb0Zn?= =?utf-8?B?YnBQOVB5SGVkUVUxRkJvMHN2UFZDNGJWRC82ZmQ1QWs5Yy95QzV4U2MrKzVw?= =?utf-8?B?Q2pxZFB5U09UOGk0RDJYZFJGQzlLRkxtSG5JQ3hYNVcxdi9vNmIxWFV6THd5?= =?utf-8?B?cWVBRUluYXMwL1VlcWNiNzZkbm0vUkdIYzBoc1k5Zlg2enFid0dNSVN1Ykx2?= =?utf-8?B?dURybFpjTFQwMDRMTkprTE9SNU1lUXphNmpIUmczZmpBZlozS09tMzFxRk5i?= =?utf-8?B?S2YwMkpvdUd6eTBJZ2dpbmRsb3haQjFoTHIvZzB5RTlYQTZIU1EyZ01vdytt?= =?utf-8?B?TU9DWHJydkJMM1ArMldHR29MangwVUJPWGVCdU5oVXVjZmVabnZROTE0KzBk?= =?utf-8?B?c1VHOXJSQ3d2bDBDK2ZyU3FPTUlSSzJmSmVGaUNOb0lSTUg5YkVkVzJVUkQz?= =?utf-8?B?c0h6ZjJpWHpDakZQc2pZUjRzdXdmU1hFbEs1bHpZdFdCZmNmcEV4MmlnVlF3?= =?utf-8?B?UmQ2MDQ4MlFKenJVWC9lcEtIa2FoYVJYMnFicUJLVjlZUUNpd2Z6NG9BbktZ?= =?utf-8?B?K0lGdkFEbUM3RkJ3c2Q2c1BSOWZoeUFUaHYyb0NnaHFsY1RQeWtNUi9LUnBj?= =?utf-8?B?VWtrS09DbEZqai9ha1RlRnNCR3ZaOUdPWTBmSVNHT2hsazNDOXY1UzVXQ2Zt?= =?utf-8?B?bTBabWJjWnd5WmpmTTUxMXVDWjJOR1JsSWRLQ2FaRTFON3ZWcktDZmlsa241?= =?utf-8?B?RzJEMHpkNVByS21URSthQkRXNG1lRytUVFRDTEdpZDh5bkNTN0NPUjJmRnAw?= =?utf-8?B?d2dENlVoNzIxcnRRWmpndFZDbTlrSVppcWwrR3c3ZFlVdU1KRkMzcDB1MmI3?= =?utf-8?B?czdpYmp0MHNvWWhDNGVnSU90ZTVweVNOaWRMck5FcU44eVFMTGlrNmZhK1Z3?= =?utf-8?B?RFNJVzdadWFvRktLTHpZdVBvbjdObHF4MDREMFJzcUJyYXBsTXhtVWVkT25F?= =?utf-8?B?NWxUbTkrdllSZm1JaUs5SWRqN1F3djEzOXpaVkpvU0pvWW1jSnJZTlFCMEpN?= =?utf-8?B?VHZ6T2pwbFdCN1lNdVRtNktDVEU4QW1kNFdxQk1pTWx4TTJOQndDL1k1cUZ1?= =?utf-8?B?cFpPVFBVZ0hMem5zU1BEYkxjNVBQdC9wRXNOL3BxZnZXSWgvNHRJYTYyd1E4?= =?utf-8?B?c2Uzc1hXeEdoOTFyT2hIaUZGVHd3cVVoMDZ6MGU1dUMwWHNUWU5IU1V4VFgv?= =?utf-8?B?VWp1VjdvYUc4NmdrcU9SMXJvcmdwYit6T3YrdDNGYXkzTEgrL0pDWmh6Z1Ev?= =?utf-8?B?ZlZzOEpjV05FSG1TN2o4alJ5Sk8remJSR0V5SWZYUzd4Yi9kVmRtRy9mdmMz?= =?utf-8?B?Wi9xRmpVUEZ1WU8zZmtGLzBHd00yY0oxMTl5QjR1QTlCTHNMUnVxY3J0cVhK?= =?utf-8?B?SWFaaThjcUNvcTNYNkg5SE11bTBnS3ViaTdtdnJDMkd1QmtJOHdoZEZDNThF?= =?utf-8?B?d3pqVk84d2RPdklaQWp6UWVxTFBYZTJaZmw0YytqZ2xFR2YyQnNyY0VjWWRu?= =?utf-8?B?M3RWWmZNWHJMSFFMVnFmZUlzZDJKa3ltSU02dFdVUTJaWEg1MlZzRkcxU014?= =?utf-8?B?WWUxYkZPYU1jSWdKeFRpOWdEWDU2UWcyWEpjUDBsT3lXUVZLN3d3NDVFY0F0?= =?utf-8?Q?lxxzf9yvQPwe7SNdra?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: be8b0e4c-a499-40f1-596d-08defc6d11c3 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2026 14:37:31.3940 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: o7eDOPtuh12VE1jJ8cA/uVSKWdDaLAEUpfHN/XLwDdKhvINHkhlGksji+oTzx+eN X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR12MB7775 On 17 Aug 2026, at 10:34, Zi Yan wrote: > On 17 Aug 2026, at 9:55, Alan Stern wrote: > >> On Sun, Aug 16, 2026 at 07:42:13PM -0700, Andrew Morton wrote: >>> On Sun, 16 Aug 2026 21:47:58 -0400 "Zi Yan" wrote: >>> >>>>> >>>>>>> I prefer Andrew's first suggestion. If the user asks the kernel to copy >>>>>>> too much data, just fail -- with no warning. >>>>>> >>>>>> __GFP_WARN gets rid of all other warnings, even if user asks for a >>>>>> reasonable size. Why use such a big hammer? >>>>> >>>>> Because on many systems, WARN causes the kernel to crash. You don't >>>>> want the entire system to crash just because the user asked for more >>>>> memory than was available. >>>> >>>> User asking for more memory that what is available is pretty common and >>>> should not trigger a WARN or crash, unless you have panic_on_oom set. >>> >>> I assume Alan is referring to panic_on_warn. >> >> Yes. > > Right. That is why I said “unless you have panic_on_oom set”. So panic_on_warn > will not crash the kernel if user asks for more memory than what is available. > >> >>> Heaven knows how common panic_on_warn usage is. Gemini tells me "There >>> is no exact global headcount or precise user metric for how many people >>> use panic_on_warn. However, the setting is widely enabled across a few >>> billion Android devices and many cloud/server provider host kernels >>> where automated failover makes a full reboot preferable to running with >>> an unknown warning state". >>> >>> So I do think that WARNs are more serious than we (mm developers) tend >>> to assume. >> >> I do know that Greg KH has pretty strong feelings about this issue. > > But the warning here is when kernel user wants buddy allocator to give > what it cannot allocate, a page order > MAX_PAGE_ORDER. The warning > tells that kernel user please ask for a reasonably sized memory. > >> >>> So we just shouldn't permit userspace to trivially trigger a >>> page-allocation WARN. Especially if the caller is perfectly capable of >>> handling an ENOMEM allocation failure, as appears to be the case with >>> usb-gadget. >>> >>> (Does usb-gadget actually get used by Android? Surely not by cloud >>> providers!) >>> >>> (Can this WARN be triggered by unprivileged userspace? I didn't look, >>> this matters a lot). >> >> I don't think it can. Regardless, even privileged userspace shouldn't >> be able to crash the whole system by doing something that ought to >> return a harmless error. > > The issue here is that the inode.c code passes the user input len without > checking to page allocator code. Capping that is a minimal requirement > to prevent untrusted userspace input getting into trusted kernel space code > easily. > >> >>>> You can mmap a virtual address range bigger than your physical memory >>>> size plus your swap space and try to fault all pages in. That would >>>> cause OOM and the system should not crash. >>> >>> Right. As long as it doesn't trigger a WARN! >>> >>> >>> >>> >>> Perhaps we should revisit this. >>> >>> Why are we emitting a WARN if an allocation fails, given that this will >>> often panic the kernel? Should we on the core MM side dial that back >>> to a pr_warn() and a helpful backtrace? >> >> I think that would be a very good idea. Only the caller knows whether >> an allocation failure will leave the system in an unstable state; the >> library routine shouldn't try to make this decision on its own. > > In this case, the WARN is emitted not because of an allocation failure, > but an invalid input to buddy allocator (order > MAX_PAGE_ORDER). The > WARN is for kernel developers, telling them their code is asking too much > free memory and core MM cannot handle it. Suppressing that means > code outside MM can abuse page allocator. Code like doing > alloc_pages(MAX_PAGE_ORDER + 1, __GFP_NOFAIL | __GFP_NOWARN) should not > exist, instead of just getting pr_warn() and failures. +other page allocator people In case I am wrong. Best Regards, Yan, Zi