Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1431126AbdDYN2X (ORCPT ); Tue, 25 Apr 2017 09:28:23 -0400 Received: from mga04.intel.com ([192.55.52.120]:40339 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S945940AbdDYN2M (ORCPT ); Tue, 25 Apr 2017 09:28:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,249,1488873600"; d="scan'208";a="93919743" From: Felipe Balbi To: Greg Kroah-Hartman , Maksim Salau Cc: Florian Fainelli , linux-kernel@vger.kernel.org, arnd@arndb.de, Alan Stern , Mathias Nyman , Peter Chen , Roger Quadros , Baoyou Xie , Sekhar Nori , Chris Bainbridge , Wolfram Sang , "open list\:USB SUBSYSTEM" Subject: Re: [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack In-Reply-To: <20170425113752.GC7191@kroah.com> References: <20170424012939.29929-1-f.fainelli@gmail.com> <20170425133533.52ba1cb6@gmail.com> <20170425113752.GC7191@kroah.com> Date: Tue, 25 Apr 2017 16:27:30 +0300 Message-ID: <87bmrklirh.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1480 Lines: 38 Hi, Greg Kroah-Hartman writes: > 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 :) We should probably have a similar patch on drivers/usb/gadget/udc/core.c::usb_gadget_map_request_by_dev() -- balbi