All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: netdev <netdev@vger.kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	David Miller <davem@davemloft.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Himadri Pandya <himadrispandya@gmail.com>
Subject: Re: [Linux-kernel-mentees] [PATCH] net: usb: Fix uninit-was-stored issue in asix_read_cmd()
Date: Tue, 25 Aug 2020 16:44:37 +0200	[thread overview]
Message-ID: <20200825144437.GA1484901@kroah.com> (raw)
In-Reply-To: <20200825143946.GA365901@rowland.harvard.edu>

On Tue, Aug 25, 2020 at 10:39:46AM -0400, Alan Stern wrote:
> On Tue, Aug 25, 2020 at 08:51:35AM +0200, Greg Kroah-Hartman wrote:
> > At first glance, I think this can all be cleaned up, but it will take a
> > bit of tree-wide work.  I agree, we need a "read this message and error
> > if the whole thing is not there", as well as a "send this message and
> > error if the whole thing was not sent", and also a way to handle
> > stack-provided data, which seems to be the primary reason subsystems
> > wrap this call (they want to make it easier on their drivers to use it.)
> > 
> > Let me think about this in more detail, but maybe something like:
> > 	usb_control_msg_read()
> > 	usb_control_msg_send()
> > is a good first step (as the caller knows this) and stack provided data
> > would be allowed, and it would return an error if the whole message was
> > not read/sent properly.  That way we can start converting everything
> > over to a sane, and checkable, api and remove a bunch of wrapper
> > functions as well.
> 
> Suggestion: _read and _send are not a natural pair.  Consider instead
> _read and _write.  _recv and _send don't feel right either, because it
> both cases the host sends the control message -- the difference lies
> in who sends the data.

Yes, naming is hard :)

	usb_control_read_msg()
	usb_control_write_msg()

feels good to me, let me try this out and see if it actually makes sense
to do this on a few in-usb-core files and various drivers...

thanks,

greg k-h
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Himadri Pandya <himadrispandya@gmail.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	USB list <linux-usb@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] net: usb: Fix uninit-was-stored issue in asix_read_cmd()
Date: Tue, 25 Aug 2020 16:44:37 +0200	[thread overview]
Message-ID: <20200825144437.GA1484901@kroah.com> (raw)
In-Reply-To: <20200825143946.GA365901@rowland.harvard.edu>

On Tue, Aug 25, 2020 at 10:39:46AM -0400, Alan Stern wrote:
> On Tue, Aug 25, 2020 at 08:51:35AM +0200, Greg Kroah-Hartman wrote:
> > At first glance, I think this can all be cleaned up, but it will take a
> > bit of tree-wide work.  I agree, we need a "read this message and error
> > if the whole thing is not there", as well as a "send this message and
> > error if the whole thing was not sent", and also a way to handle
> > stack-provided data, which seems to be the primary reason subsystems
> > wrap this call (they want to make it easier on their drivers to use it.)
> > 
> > Let me think about this in more detail, but maybe something like:
> > 	usb_control_msg_read()
> > 	usb_control_msg_send()
> > is a good first step (as the caller knows this) and stack provided data
> > would be allowed, and it would return an error if the whole message was
> > not read/sent properly.  That way we can start converting everything
> > over to a sane, and checkable, api and remove a bunch of wrapper
> > functions as well.
> 
> Suggestion: _read and _send are not a natural pair.  Consider instead
> _read and _write.  _recv and _send don't feel right either, because it
> both cases the host sends the control message -- the difference lies
> in who sends the data.

Yes, naming is hard :)

	usb_control_read_msg()
	usb_control_write_msg()

feels good to me, let me try this out and see if it actually makes sense
to do this on a few in-usb-core files and various drivers...

thanks,

greg k-h

  reply	other threads:[~2020-08-25 14:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-23  8:20 [Linux-kernel-mentees] [PATCH] net: usb: Fix uninit-was-stored issue in asix_read_cmd() Himadri Pandya
2020-08-23  8:20 ` Himadri Pandya
2020-08-23  9:26 ` [Linux-kernel-mentees] " Dmitry Vyukov via Linux-kernel-mentees
2020-08-23  9:26   ` Dmitry Vyukov
2020-08-23 10:19   ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-23 10:19     ` Greg Kroah-Hartman
2020-08-23 10:31     ` [Linux-kernel-mentees] " Dmitry Vyukov via Linux-kernel-mentees
2020-08-23 10:31       ` Dmitry Vyukov
2020-08-23 10:56       ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-23 10:56         ` Greg Kroah-Hartman
2020-08-23 10:58       ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-23 10:58         ` Greg Kroah-Hartman
2020-08-23 12:38         ` [Linux-kernel-mentees] " Himadri Pandya
2020-08-24  8:55         ` Dmitry Vyukov via Linux-kernel-mentees
2020-08-24  8:55           ` Dmitry Vyukov
2020-08-25  6:51           ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-25  6:51             ` Greg Kroah-Hartman
2020-08-25  6:54             ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-25  6:54               ` Greg Kroah-Hartman
2020-08-25 14:39             ` [Linux-kernel-mentees] " Alan Stern
2020-08-25 14:39               ` Alan Stern
2020-08-25 14:44               ` Greg Kroah-Hartman [this message]
2020-08-25 14:44                 ` Greg Kroah-Hartman
2020-08-25 15:44                 ` [Linux-kernel-mentees] " Greg Kroah-Hartman
2020-08-25 15:44                   ` Greg Kroah-Hartman
2020-08-24 18:16 ` [Linux-kernel-mentees] " Jakub Kicinski
2020-08-24 18:16   ` Jakub Kicinski
2020-08-25  6:36   ` [Linux-kernel-mentees] " Himadri Pandya
2020-08-25  6:36     ` Himadri Pandya

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=20200825144437.GA1484901@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=himadrispandya@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=syzkaller-bugs@googlegroups.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.