linux-next: manual merge of the rr tree with the sound tree

linux-next: manual merge of the rr tree with the sound tree

[Stephen Rothwell]

Hi Rusty,

Today's linux-next merge of the rr tree got a conflict in
arch/um/drivers/hostaudio_kern.c between commit
90dc763fef4c869e60b2a7ad92e1a7dab68575ea ("sound: push BKL into open
functions") from the sound tree and commit
6aad4054c113f2d8a8bbdee64e7167950dd06c92 ("param:lock-charp-simple") from
the rr tree.

Overlapping additions.  I fixed it up (see below) and carry the fix as necessary.

I was not sure if the kparam_(un)block_sysfs_write() calls needed to be
surrounded by the (un)lock_kernel() calls or vice verse.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/um/drivers/hostaudio_kern.c
index 68142df,162855c..0000000
--- a/arch/um/drivers/hostaudio_kern.c
+++ b/arch/um/drivers/hostaudio_kern.c
@@@ -199,10 -200,9 +201,12 @@@ static int hostaudio_open(struct inode 
  	if (file->f_mode & FMODE_WRITE)
  		w = 1;
  
 +	lock_kernel();
+ 	kparam_block_sysfs_write(dsp);
  	ret = os_open_file(dsp, of_set_rw(OPENFLAGS(), r, w), 0);
+ 	kparam_unblock_sysfs_write(dsp);
 +	unlock_kernel();
 +
  	if (ret < 0) {
  		kfree(state);
  		return ret;
@@@ -258,13 -258,15 +262,17 @@@ static int hostmixer_open_mixdev(struc
  	if (file->f_mode & FMODE_WRITE)
  		w = 1;
  
 +	lock_kernel();
+ 	kparam_block_sysfs_write(mixer);
  	ret = os_open_file(mixer, of_set_rw(OPENFLAGS(), r, w), 0);
+ 	kparam_unblock_sysfs_write(mixer);
 +	unlock_kernel();
  
  	if (ret < 0) {
+ 		kparam_block_sysfs_write(dsp);
  		printk(KERN_ERR "hostaudio_open_mixdev failed to open '%s', "
  		       "err = %d\n", dsp, -ret);
+ 		kparam_unblock_sysfs_write(dsp);
  		kfree(state);
  		return ret;
  	}

Re: linux-next: manual merge of the rr tree with the sound tree

[Arnd Bergmann]

On Tuesday 13 July 2010, Stephen Rothwell wrote:
> Overlapping additions.  I fixed it up (see below) and carry the fix as necessary.
> 
> I was not sure if the kparam_(un)block_sysfs_write() calls needed to be
> surrounded by the (un)lock_kernel() calls or vice verse.

Either way should be fine, since the BKL does not suffer from AB-BA deadlocks
with mutexes. I would generally recommend making the BKL the outermost
lock to make it easier to conver to a mutex. That is how you did it too.

Thanks,

	Arnd