All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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
Date: Tue, 25 Apr 2017 16:27:30 +0300	[thread overview]
Message-ID: <87bmrklirh.fsf@linux.intel.com> (raw)
In-Reply-To: <20170425113752.GC7191@kroah.com>


Hi,

Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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

      reply	other threads:[~2017-04-25 13:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  1:29 [PATCH v2] usb: core: Warn if an URB's transfer_buffer is on stack Florian Fainelli
2017-04-24  7:15 ` Clemens Ladisch
2017-04-24 13:27 ` Alan Stern
2017-04-25 10:35 ` Maksim Salau
2017-04-25 11:37   ` Greg Kroah-Hartman
2017-04-25 13:27     ` Felipe Balbi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bmrklirh.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=baoyou.xie@linaro.org \
    --cc=chris.bainbridge@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maksim.salau@gmail.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=nsekhar@ti.com \
    --cc=peter.chen@nxp.com \
    --cc=rogerq@ti.com \
    --cc=stern@rowland.harvard.edu \
    --cc=wsa-dev@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.