All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregKH@linuxfoundation.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: Himadri Pandya <himadrispandya@gmail.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-usb@vger.kernel.org
Subject: Re: usb_control_msg_send() and usb_control_msg_recv() are highly problematic
Date: Wed, 23 Sep 2020 13:07:24 +0200	[thread overview]
Message-ID: <20200923110724.GA3692555@kroah.com> (raw)
In-Reply-To: <1600858740.26851.16.camel@suse.com>

On Wed, Sep 23, 2020 at 12:59:00PM +0200, Oliver Neukum wrote:
> Hi,
> 
> you probably do not want to hear this. I was out of comission
> for the last week weeks and I should have looked at this more closely.
> 
> You may notice that usb_control_msg() for times immemorial has been
> using GFP_NOIO internally. This is because control messages are needed
> in a lot of contexts such as SCSI error handling and runtime PM
> that require GFP_NOIO. IIRC at that time we found ourselves unable to
> go through all those call chains, so we pulled the nuclear option
> and slapped a blanket GFP_NOIO on the function.
> 
> Today I got a patch that outright deleted a memory allocation with
> GFP_NOIO, so I looked into this. We are making the same mistake
> we couldn't fix in the past.
> I am afraid the API has to be changed to include memory flags.
> And we should do this now while the damage is still within limits.
> I am preparing patches.

How about we always use GPF_NOIO for the calls?  That should be fine and
make it easier, right?

thanks,

greg k-h

  reply	other threads:[~2020-09-23 11:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 10:59 usb_control_msg_send() and usb_control_msg_recv() are highly problematic Oliver Neukum
2020-09-23 11:07 ` Greg KH [this message]
2020-09-23 11:28   ` Oliver Neukum

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=20200923110724.GA3692555@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=himadrispandya@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=stern@rowland.harvard.edu \
    /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.