linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Neukum <oneukum@suse.com>
To: Tobias Herzog <t-herzog@gmx.de>
Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 1/4] cdc-acm: reassemble fragmented notifications
Date: Tue, 28 Mar 2017 10:04:43 +0200	[thread overview]
Message-ID: <1490688283.29898.2.camel@suse.com> (raw)
In-Reply-To: <1490392212.2779.33.camel@gmx.de>

Am Freitag, den 24.03.2017, 22:50 +0100 schrieb Tobias Herzog:
> Hi Oliver,
> 
> thank you for your patience... :) I have a question to one of your
> comments (see below).
> 
> Best regards,
> Tobias
> 
> > 
> > Am Samstag, den 18.03.2017, 19:52 +0100 schrieb Tobias Herzog:
> > > 
> > > 
> > > USB devices may have very limitited endpoint packet sizes, so that
> > > notifications can not be transferred within one single usb packet.
> > > Reassembling of multiple packages may be necessary.
> > Hi,
> > 
> > almost perfect.
> > A few new issue. Comments inline.
> > 
> > > 
> > > 
> > > 
> > > +	struct usb_cdc_notification *dr = (struct
> > > usb_cdc_notification *)buf;
> > > +	unsigned char *data = (unsigned char *)(dr + 1);
> > This is border line incorrect. It depends on the compiler not
> > adding padding. Please make it
> > 
> > buf + sizeof(struct usb_cdc_notification)
> > 
> > > 
> > > 
> > > -	usb_mark_last_busy(acm->dev);
> > > -
> > > -	data = (unsigned char *)(dr + 1);
> > >  	switch (dr->bNotificationType) {
> > >  	case USB_CDC_NOTIFY_NETWORK_CONNECTION:
> > >  		dev_dbg(&acm->control->dev,
> > > @@ -363,8 +337,77 @@ static void acm_ctrl_irq(struct urb *urb)
> > >  			__func__,
> > >  			dr->bNotificationType, dr->wIndex,
> > >  			dr->wLength, data[0], data[1]);
> > > +	}
> > > +}
> > > +
> > > +/* control interface reports status changes with "interrupt"
> > > transfers */
> > > +static void acm_ctrl_irq(struct urb *urb)
> > > +{
> > > +	struct acm *acm = urb->context;
> > > +	struct usb_cdc_notification *dr = urb->transfer_buffer;
> > > +	unsigned int current_size = urb->actual_length;
> > > +	unsigned int expected_size, copy_size;
> > > +	int retval;
> > > +	int status = urb->status;
> > > +
> > > +	switch (status) {
> > > +	case 0:
> > > +		/* success */
> > >  		break;
> > > +	case -ECONNRESET:
> > > +	case -ENOENT:
> > > +	case -ESHUTDOWN:
> > > +		/* this urb is terminated, clean up */
> > > +		acm->nb_index = 0;
> > > +		dev_dbg(&acm->control->dev,
> > > +			"%s - urb shutting down with status:
> > > %d\n",
> > > +			__func__, status);
> > > +		return;
> > > +	default:
> > > +		dev_dbg(&acm->control->dev,
> > > +			"%s - nonzero urb status received: %d\n",
> > > +			__func__, status);
> > > +		goto exit;
> > >  	}
> > > +
> > > +	usb_mark_last_busy(acm->dev);
> > > +
> > > +	if (acm->nb_index)
> > > +		dr = (struct usb_cdc_notification *)acm-
> > > > 
> > > > notification_buffer;
> > > +
> > > +	/* size = notification-header + (optional) data */
> > > +	expected_size = sizeof(struct usb_cdc_notification) +
> > > +					le16_to_cpu(dr->wLength);
> > > +
> > > +	if (current_size < expected_size) {
> > > +		/* notification is transmitted fragmented,
> > > reassemble */
> > > +		if (acm->nb_size < expected_size) {
> > > +			if (acm->nb_size) {
> > > +				kfree(acm->notification_buffer);
> > > +				acm->nb_size = 0;
> > > +			}
> > > +			acm->notification_buffer =
> > > +					kmalloc(expected_size,
> > > GFP_ATOMIC);
> > Given how kmalloc works you'd better round this up to a power of two.
> > 
> > > 
> > > 
> > > +			if (!acm->notification_buffer)
> > > +				goto exit;
> > This is most subtle. Please add a comment that this prevents a double
> > free if we get a disconnect()
> I'm unsure if I got this right: Are you talking about the fact, that
> the use of 'kmalloc' will make 'acm->notification_buffer' valid again
> (i.e. NULL or pointing to a correctly allocated block), after it was

yes

> "invalidated" by 'kfree' (in case the previously allocated buffer was
> too small)?
> The 'goto exit'-thing for me is just not to use the buffer if
> allocation fails. Or am I missing anything here?

You need to consider the hot unplug case.

	Regards
		Oliver

  reply	other threads:[~2017-03-28  8:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1479118868.21146.4.camel@suse.com>
2017-03-14 20:14 ` [PATCH 1/4] cdc-acm: reassemble fragmented notifications Tobias Herzog
2017-03-14 20:14   ` [PATCH 2/4] cdc-acm: fix possible invalid access when processing notification Tobias Herzog
2017-03-15  9:26     ` Oliver Neukum
2017-03-14 20:14   ` [PATCH 3/4] cdc-acm: log message for serial state notification Tobias Herzog
2017-03-14 20:14   ` [PATCH 4/4] cdc-acm: remove unused element of struct acm Tobias Herzog
2017-03-15  9:26   ` [PATCH 1/4] cdc-acm: reassemble fragmented notifications Oliver Neukum
2017-03-18 18:52     ` Tobias Herzog
2017-03-18 18:52 ` [PATCH v2 0/4] " Tobias Herzog
2017-03-18 18:52   ` [PATCH v2 1/4] " Tobias Herzog
2017-03-20 15:02     ` Oliver Neukum
2017-03-24 21:50       ` Tobias Herzog
2017-03-28  8:04         ` Oliver Neukum [this message]
2017-03-18 18:52   ` [PATCH v2 2/4] cdc-acm: fix possible invalid access when processing notification Tobias Herzog
2017-03-19  9:50     ` Sergei Shtylyov
2017-03-20 15:04     ` Oliver Neukum
2017-03-18 18:52   ` [PATCH v2 3/4] cdc-acm: log message for serial state notification Tobias Herzog
2017-03-18 18:52   ` [PATCH v2 4/4] cdc-acm: remove unused element of struct acm Tobias Herzog
2017-03-30 20:15 ` [PATCH v3 0/4] cdc-acm: reassemble fragmented notifications Tobias Herzog
2017-03-30 20:15   ` [PATCH v3 1/4] cdc-acm: fix possible invalid access when processing notification Tobias Herzog
2017-03-31  9:31     ` Oliver Neukum
2017-03-30 20:15   ` [PATCH v3 2/4] cdc-acm: reassemble fragmented notifications Tobias Herzog
2017-03-31  9:33     ` Oliver Neukum
2017-03-30 20:15   ` [PATCH v3 3/4] cdc-acm: log message for serial state notification Tobias Herzog
2017-03-31  9:34     ` Oliver Neukum
2017-03-30 20:15   ` [PATCH v3 4/4] cdc-acm: remove unused element of struct acm Tobias Herzog
2017-03-31  9:35     ` 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=1490688283.29898.2.camel@suse.com \
    --to=oneukum@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=t-herzog@gmx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).