mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tobias Herzog <t-herzog@gmx.de>
To: Oliver Neukum <oneukum@suse.com>
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: Fri, 24 Mar 2017 22:50:12 +0100	[thread overview]
Message-ID: <1490392212.2779.33.camel@gmx.de> (raw)
In-Reply-To: <1490022179.25734.5.camel@suse.com>

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
"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?
> 
> > 
> > +			acm->nb_size = expected_size;
> > +		}
> 	Regards
> 		Oliver
> 

  reply	other threads:[~2017-03-24 21:50 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 " 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 [this message]
2017-03-28  8:04         ` Oliver Neukum
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=1490392212.2779.33.camel@gmx.de \
    --to=t-herzog@gmx.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome