All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Vladis Dronov <vdronov@redhat.com>
Cc: Jaroslav Kysela <perex@perex.cz>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	linux-sound@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: Fix double-free in snd_usb_add_audio_stream()
Date: Thu, 31 Mar 2016 16:20:20 +0200	[thread overview]
Message-ID: <s5hh9fmenkr.wl-tiwai@suse.de> (raw)
In-Reply-To: <805340847.43676741.1459433035733.JavaMail.zimbra@redhat.com>

On Thu, 31 Mar 2016 16:03:55 +0200,
Vladis Dronov wrote:
> 
> Hello, Takashi, all,
> 
> > No, it has nothing to do with the double-free bug itself.  Such an
> > optimization shouldn't be put in a fix patch
> 
> This piece of code move alone fixes the double-free bug in
> create_fixed_stream_quirk(), so I believe it is related.

The merits you pointed are irrelevant from the double-free bug.

> Besides, a lot of stuff
> is created and initialized in snd_usb_add_audio_stream() and while I do not see
> another use-after-free bug, it could be there. By moving this code we avoid
> these potential bugs we have not hit yet.

It's a different issue.  The only judgment now is which one is clearer
to understand.  The code efficiency isn't a question for this bug,
since the error condition is very rare, and it's no hot path, after
all.

> But anyway. If you still believe this code should not be moved, please, confirm,
> I'll suggest the next patch version without it.

Right, I don't want to move it.


> > Vladis, if you take someone's patch as the base, you have to carry the
> > original authorship somewhere...
> 
> Yes, I was thinking about it, I was just not sure how should I do it. Will the
> following form be fine? Or somehow else?
> 
> Based on a patch by Takashi Iwai" <tiwai@suse.de>

Yes, usually such a line should be enough.


> > > + * if not, create a new pcm stream. the caller must remove fp from
> > > + * the substream fmt_list in the error path to avoid double-free.
> >
> > This comment isn't true.  The caller may leave it as is, too, like my
> > first version.  It just depends on the code.
> 
> Yes. Is the following rewrite acceptable for the next patch version?
> 
>  * if not, create a new pcm stream. Note, fp is added to the substream fmt_list
>  * and will be freed on the chip instance release. Do not free fp or do remove
>  * it from the substream fmt_list to avoid double-free.

Yes, that looks more correct.


thanks,

Takashi

WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Vladis Dronov <vdronov@redhat.com>
Cc: Jaroslav Kysela <perex@perex.cz>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	linux-sound@vger.kernel.org
Subject: Re: [PATCH] ALSA: usb-audio: Fix double-free in snd_usb_add_audio_stream()
Date: Thu, 31 Mar 2016 14:20:20 +0000	[thread overview]
Message-ID: <s5hh9fmenkr.wl-tiwai@suse.de> (raw)
In-Reply-To: <805340847.43676741.1459433035733.JavaMail.zimbra@redhat.com>

On Thu, 31 Mar 2016 16:03:55 +0200,
Vladis Dronov wrote:
> 
> Hello, Takashi, all,
> 
> > No, it has nothing to do with the double-free bug itself.  Such an
> > optimization shouldn't be put in a fix patch
> 
> This piece of code move alone fixes the double-free bug in
> create_fixed_stream_quirk(), so I believe it is related.

The merits you pointed are irrelevant from the double-free bug.

> Besides, a lot of stuff
> is created and initialized in snd_usb_add_audio_stream() and while I do not see
> another use-after-free bug, it could be there. By moving this code we avoid
> these potential bugs we have not hit yet.

It's a different issue.  The only judgment now is which one is clearer
to understand.  The code efficiency isn't a question for this bug,
since the error condition is very rare, and it's no hot path, after
all.

> But anyway. If you still believe this code should not be moved, please, confirm,
> I'll suggest the next patch version without it.

Right, I don't want to move it.


> > Vladis, if you take someone's patch as the base, you have to carry the
> > original authorship somewhere...
> 
> Yes, I was thinking about it, I was just not sure how should I do it. Will the
> following form be fine? Or somehow else?
> 
> Based on a patch by Takashi Iwai" <tiwai@suse.de>

Yes, usually such a line should be enough.


> > > + * if not, create a new pcm stream. the caller must remove fp from
> > > + * the substream fmt_list in the error path to avoid double-free.
> >
> > This comment isn't true.  The caller may leave it as is, too, like my
> > first version.  It just depends on the code.
> 
> Yes. Is the following rewrite acceptable for the next patch version?
> 
>  * if not, create a new pcm stream. Note, fp is added to the substream fmt_list
>  * and will be freed on the chip instance release. Do not free fp or do remove
>  * it from the substream fmt_list to avoid double-free.

Yes, that looks more correct.


thanks,

Takashi

  reply	other threads:[~2016-03-31 14:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 19:03 [PATCH] ALSA: usb-audio: Fix double-free in snd_usb_add_audio_stream() Vladis Dronov
2016-03-30 19:03 ` Vladis Dronov
2016-03-30 19:03 ` Vladis Dronov
2016-03-30 19:03   ` Vladis Dronov
2016-03-30 19:38   ` kbuild test robot
2016-03-30 19:38     ` kbuild test robot
2016-03-30 19:38     ` kbuild test robot
2016-03-30 20:31   ` Takashi Iwai
2016-03-30 20:31     ` Takashi Iwai
2016-03-30 20:31     ` Takashi Iwai
2016-03-31  9:50     ` Takashi Iwai
2016-03-31  9:50       ` Takashi Iwai
2016-03-31  9:50       ` Takashi Iwai
2016-03-31 12:36       ` Vladis Dronov
2016-03-31 12:36         ` Vladis Dronov
2016-03-31 12:57         ` Takashi Iwai
2016-03-31 12:57           ` Takashi Iwai
2016-03-31 14:03           ` Vladis Dronov
2016-03-31 14:03             ` Vladis Dronov
2016-03-31 14:20             ` Takashi Iwai [this message]
2016-03-31 14:20               ` Takashi Iwai
2016-03-31 16:05               ` Vladis Dronov
2016-03-31 16:05                 ` Vladis Dronov
2016-03-31 16:13                 ` Takashi Iwai
2016-03-31 16:13                   ` Takashi Iwai

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=s5hh9fmenkr.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=vdronov@redhat.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.