Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1947113AbdDYL7w (ORCPT <rfc822;w@1wt.eu>);
        Tue, 25 Apr 2017 07:59:52 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:56470 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1428795AbdDYL7m (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 25 Apr 2017 07:59:42 -0400
Date: Tue, 25 Apr 2017 12:37:52 +0100
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Maksim Salau <maksim.salau@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>, linux-kernel@vger.kernel.org,
        arnd@arndb.de, Alan Stern <stern@rowland.harvard.edu>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Peter Chen <peter.chen@nxp.com>, Roger Quadros <rogerq@ti.com>,
        Baoyou Xie <baoyou.xie@linaro.org>, Sekhar Nori <nsekhar@ti.com>,
        Chris Bainbridge <chris.bainbridge@gmail.com>,
        Wolfram Sang <wsa-dev@sang-engineering.com>,
        "open list:USB SUBSYSTEM" <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on
 stack
Message-ID: <20170425113752.GC7191@kroah.com>
References: <20170424012939.29929-1-f.fainelli@gmail.com>
 <20170425133533.52ba1cb6@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170425133533.52ba1cb6@gmail.com>
User-Agent: Mutt/1.8.2 (2017-04-18)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1287
Lines: 32

On Tue, Apr 25, 2017 at 01:35:33PM +0300, Maksim Salau wrote:
> > +			} else if (object_is_on_stack(urb->transfer_buffer)) {
> > +				WARN_ONCE(1, "transfer buffer is on stack\n");
> > +				ret = -EAGAIN;
> >  			} else {
> 
> Hi,
> 
> Has anyone considered a fail-safe mode? I.e.: if a buffer is on stack,
> kmemdup it and continue with a warning. This will give us both: functional
> drivers (with possibly decreased efficiency in speed and memory footprint)
> and warnings for developers that a particular driver requires attention.

No, I do not want that, let's fix the drivers.

> This mode will not affect drivers which obey the rules, but will make
> offenders at least functional. My main concern is that not every user is able
> to detect and report a problem, which prevents drivers from functioning.
> Especially this is a problem for not wide spread devices.
> Due to this users a seeing unusable equipment, but developers are not
> aware of those, even if fixes are trivial.
> 
> Such mode has a also a negative effect: if a developer has a device
> with an offending driver, he can miss the warning message, since the driver
> just works.

Exactly, let's fix the bugs.  These have been bugs for 10+ years now,
they should get fixed, it's not complex :)

thanks,

greg k-h