[alsa-devel] [PATCH 1/9] ALSA: Compress - dont use lock for all ioctls

Takashi Iwai tiwai at suse.de
Tue Aug 27 13:00:48 CEST 2013


At Tue, 27 Aug 2013 15:14:15 +0530,
Vinod Koul wrote:
> 
> On Tue, Aug 27, 2013 at 12:22:31PM +0200, Takashi Iwai wrote:
> > At Tue, 27 Aug 2013 12:10:31 +0530,
> > Vinod Koul wrote:
> > > 
> > > Some simple ioctls like timsetamp query, capabities query can be done anytime
> > > and should not be under the stream lock. Move these to
> > > snd_compress_simple_iotcls() which is invoked without lock held
> > > 
> > > While at it, improve readblity a bit by sprinkling some empty lines
> > > 
> > > Signed-off-by: Vinod Koul <vinod.koul at intel.com>
> > > Cc: <stable at vger.kernel.org>
> > 
> > Why it's needed for stable?  Fixing any real bugs?
> yup, users are complaining that while streams are draining they can't read
> timstamps. Also one case where a user hit pause didnt go thru as lock preveted
> the pause to be executed..

Then write the problems more clearly.  I saw no such information in
the changelog.

> Since 3.10 is next LTS kernel, I forsee lots of folks using taht for a while so
> makes sense to fix there as well

Depends on the fix and the problem.  The fact that this can't be
tested only with 3.10 kernel (no real driver exists), I doubt it's
worth.  Stable kernels aren't for out-of-tree drivers.

And, if you really target to the stable tree, don't put any
unnecessary changes like white space fixes.  Read
stable_kernel_rules.txt once more.


thanks,

Takashi

> > > +	default:
> > > +		mutex_unlock(&stream->device->lock);
> > > +		return snd_compress_simple_ioctls(f, stream, cmd, arg);
> > 
> > In this code, it still locks/unlocks shortly unnecessarily.
> > It should be rather like:
> > 	switch (_IOC_NR(cmd)) {
> >  	case _IOC_NR(SNDRV_COMPRESS_IOCTL_VERSION):
> > 		...
> >  	case _IOC_NR(SNDRV_COMPRESS_GET_CAPS):
> > 		....	
> > 	default:
> > 		retval = snd_compress_locked_ioctls(f, stream, cmd, arg);
> > 	}
> Hmmm, okay no point in blocking. I will reverse the flow
> 
> ~Vinod
> 
> -- 
> 


More information about the Alsa-devel mailing list