From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933830AbcLNQS3 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 14 Dec 2016 11:18:29 -0500
Received: from mail-wj0-f195.google.com ([209.85.210.195]:33791 "EHLO
        mail-wj0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932411AbcLNQS0 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 14 Dec 2016 11:18:26 -0500
Date: Wed, 14 Dec 2016 17:18:23 +0100
From: Michal Hocko <mhocko@kernel.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrey Konovalov <andreyknvl@google.com>,
        Felipe Balbi <balbi@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Deepa Dinamani <deepa.kernel@gmail.com>,
        Mathieu Laurendeau <mat.lau@laposte.net>, Bin Liu <b-liu@ti.com>,
        USB list <linux-usb@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller <syzkaller@googlegroups.com>,
        Dmitry Vyukov <dvyukov@google.com>, Kostya Serebryany <kcc@google.com>,
        Cristopher Lameter <cl@linux.com>
Subject: Re: usb/gadget: warning in ep_write_iter/__alloc_pages_nodemask
Message-ID: <20161214161823.GQ25573@dhcp22.suse.cz>
References: <20161214091005.GD25573@dhcp22.suse.cz>
 <Pine.LNX.4.44L0.1612141100280.2114-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44L0.1612141100280.2114-100000@iolanthe.rowland.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed 14-12-16 11:13:11, Alan Stern wrote:
> On Wed, 14 Dec 2016, Michal Hocko wrote:
> 
> > On Tue 13-12-16 08:33:34, Alan Stern wrote:
> > > On Tue, 13 Dec 2016, Michal Hocko wrote:
[...]
> > > > Well, my point was that it is not really hard to imagine to deplete
> > > > larger contiguous memory blocks (say PAGE_ALLOC_COSTLY_ORDER). Those are
> > > > still causing the OOM killer and chances are that a controlled flood of
> > > > these requests could completely DoS the system.
> > > 
> > > Putting a limit on the total size of a single transfer would prevent 
> > > this.
> > 
> > Dunno, putting a limit to the user visible interface sounds wrong to me.
> 
> In practice, I think the data transfer sizes tend to be not very large.  
> But I could be wrong about that.

That is one part the other is whether a malicious user can abuse this to
DoS the kernel which is the point I am trying to make here. Depleting
non-costly high orders can be quite dangerious so allowing a free ticket
to them to arbitrary user in an arbitrary amount is definitely not good.
-- 
Michal Hocko
SUSE Labs