Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp2991434pxy; Mon, 3 May 2021 12:28:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFFKJ4PXlhPFhr4tGF+2zTDD7nGgc1U29vZonrncbYJQTbAzaM+wzDKMk9TS1waMjxf8/s X-Received: by 2002:aa7:c918:: with SMTP id b24mr21731105edt.58.1620070112384; Mon, 03 May 2021 12:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620070112; cv=none; d=google.com; s=arc-20160816; b=ofdPntxqnrH5IZ6Q/ZwuhISTttsWW/5FCXmqqK23YIVOyUGsMXSXHXpJN1D6LTTtkU lW9zAAxGdk5eeW86v1l3JfbiI56tPl8qZByGRCjZHJx0VbyPYFFl8pltR7T9X2ydN5Wo BqTqMoNl1GC6323C7cfMvBomqeSJlNCq5meiE/s7eLyZUTla1NGg0d+sdOOnqUzggYjQ pnBBYCggbLSl6HFe04PKYdAh6sEQWgvXL8ObS5WD9IKZ5+YU7A/sduPJHuBNW0PSTymM R0WIcWxcYLUVIoDL/rY1drX08PkjmaNe1zVyuTp1VaRcgRDG7O6YCnyqJgaheX8w2Gvn mq1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=tqCH2OjhBeB81TLTB3bOi0VbMLAgCTBaOhoHDRVrszE=; b=g99r9bb/tzoNw5Zl9QuRCCw1g+lkfC0uOK+Ylif6gjV9flruo8qZjqz0YY5HUgR5a1 /v4ZjuBU9I/JJYhv8UasLfbynNpLzuT5xdN19k1/ufg+8GRPJpxvSCtjb/oY3JSitsbG I1LM7vG5LpVLVcL4OvGFGcssNckm+yrJb4mBru5XjrxRkeo5ricH8ge+if8WTjuAZFjK 8mJa3y3rAiIH2b916Hk/c1C6io/ZNPswOOBeeFER6woGecBUJoWYLHzQMTd6+G8XcTe5 xjELbK0DzkSOvsbdZQKJ0YQWyt5/41a+RThhklCofSZBli55I3/oaIE4ivBfBl6O2h3I tzHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=cd81Nwdk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay17si702628ejb.340.2021.05.03.12.28.02; Mon, 03 May 2021 12:28:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=cd81Nwdk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229604AbhECTZY (ORCPT + 99 others); Mon, 3 May 2021 15:25:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:46272 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbhECTZX (ORCPT ); Mon, 3 May 2021 15:25:23 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 43D7A6115C; Mon, 3 May 2021 19:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1620069869; bh=OKudAjjnl8svSwq1luMmalScMJ7m6qMNbFwp6vBMip8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cd81NwdkpRHRTtCT75jMGyMD1Fa74ZxaMVdbcHmBYWmNY3U/LCgxE5B26f2x/rlud firEqe/4nvLpncdLC2xkfFkrsjdIp05sL8p+8oXih/N/T57iB6G+aQMC7YYvEmT3hn yiiqK1ZTGOgVl+DC4qkHHFejB/UYc/p7NqnUr7I8= Date: Mon, 3 May 2021 12:24:28 -0700 From: Andrew Morton To: Alan Stern Cc: syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, Greg Kroah-Hartman , linux-usb@vger.kernel.org Subject: Re: [syzbot] WARNING in do_proc_bulk Message-Id: <20210503122428.30ebfddbaf8f5184dc73e1a7@linux-foundation.org> In-Reply-To: <20210503185614.GA628313@rowland.harvard.edu> References: <000000000000b47bc805c15e4b11@google.com> <00000000000000186405c16a6156@google.com> <20210503105351.0966275d0d9e001ed794de2c@linux-foundation.org> <20210503185614.GA628313@rowland.harvard.edu> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 May 2021 14:56:14 -0400 Alan Stern wrote: > > > > do_proc_bulk() is asking kmalloc for more than MAX_ORDER bytes, in > > > > tbuf = kmalloc(len1, GFP_KERNEL); > > This doesn't seem to be a bug. do_proc_bulk is simply trying to > allocate a kernel buffer for data passed to/from userspace. If a user > wants too much space all at once, that's their problem. > > As far as I know, the kmalloc API doesn't require the caller to filter > out requests for more the MAX_ORDER bytes. Only to be prepared to > handle failures -- which do_proc_bulk is all set for. > > Am I wrong about this? Should we add __GFP_NOWARN to the gfp flags? Yes, if the oversized request is a can-happen and the resulting error is handled appropriately, __GFP_NOWARN is the way to go.