LinuxQuestions.org - No simultaneous ioctl commands in latest kernels (slow cdrecord)

- Linux - Kernel (https://www.linuxquestions.org/questions/linux-kernel-70/)

- - No simultaneous ioctl commands in latest kernels (slow cdrecord) (https://www.linuxquestions.org/questions/linux-kernel-70/no-simultaneous-ioctl-commands-in-latest-kernels-slow-cdrecord-907105/)

No simultaneous ioctl commands in latest kernels (slow cdrecord)

If I need to burn many CDs, I sometimes use multiple burners simultaneously with multiple instances of cdrecord.

Previously I could burn at full speed, but with the latest kernel versions (2.6.38, 2.6.39, 3.0) the speed is greatly reduced. A separate burner burns for example at 24x speed while simultaneously they do not burn faster than 12x speed.

After some research it appears that the ioctl commands wait for each other. Does this possibly have anything to do with the BKL?

An easy way to reproduce this issue:
Run the following command on an older kernel (eg 2.6.26) and a new kernel (eg 6.2.39)
$ eject /dev/sr0 & eject /dev/sr1

On an old kernel the trays will open simultaneously while on a new kernel they open sequentially.

My question is, is there a possibility to make the new kernels run the ioctl commands simultaneously?

Do you think this is related to commit 2a48fc0ab242417 ?
http://comments.gmane.org/gmane.linux.kernel/1113910

I tried to build a kernel without the libata for my new dvd duplicator (the deprecated IDE driver is still present in 3.0.4 kernel) thinking the problem could comes from this driver, but was unable to boot debian wheezy with this. Cannot say more.

I finaly decided to install debian lenny on this machine, with 2.6.26, and learned how to use HAL for the scripting part :/
Works fine, and will stay like this untill I need USB3...

After some research, I believe this problem has possibly something to do with BKL.
I found the following patch, applied during the BKL removal campaign, here : http://git390.marist.edu/cgi-bin/git...a48fc0ab242417

Code:

diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c

index ba9c3e0..e148341 100644

--- a/drivers/scsi/sr.c

+++ b/drivers/scsi/sr.c

@@ -44,7 +44,6 @@

 #include <linux/init.h>

 #include <linux/blkdev.h>

 #include <linux/mutex.h>

-#include <linux/smp_lock.h>

 #include <linux/slab.h>

 #include <asm/uaccess.h>

 

@@ -76,6 +75,7 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);

          CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \

          CDC_MRW|CDC_MRW_W|CDC_RAM)

 

+static DEFINE_MUTEX(sr_mutex);

 static int sr_probe(struct device *);

 static int sr_remove(struct device *);

 static int sr_done(struct scsi_cmnd *);

@@ -470,24 +470,24 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)

        struct scsi_cd *cd;

        int ret = -ENXIO;

 

-        lock_kernel();

+        mutex_lock(&sr_mutex);

        cd = scsi_cd_get(bdev->bd_disk);

        if (cd) {

                ret = cdrom_open(&cd->cdi, bdev, mode);

                if (ret)

                        scsi_cd_put(cd);

        }

-        unlock_kernel();

+        mutex_unlock(&sr_mutex);

        return ret;

 }

 

 static int sr_block_release(struct gendisk *disk, fmode_t mode)

 {

        struct scsi_cd *cd = scsi_cd(disk);

-        lock_kernel();

+        mutex_lock(&sr_mutex);

        cdrom_release(&cd->cdi, mode);

        scsi_cd_put(cd);

-        unlock_kernel();

+        mutex_unlock(&sr_mutex);

        return 0;

 }

 

@@ -499,7 +499,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,

        void __user *argp = (void __user *)arg;

        int ret;

 

-        lock_kernel();

+        mutex_lock(&sr_mutex);

 

        /*

          * Send SCSI addressing ioctls directly to mid level, send other

@@ -529,7 +529,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,

        ret = scsi_ioctl(sdev, cmd, argp);

 

 out:

-        unlock_kernel();

+        mutex_unlock(&sr_mutex);

        return ret;

 }

It simply replaced calls to the BKL with the use of a private mutex. As far as I understand, BKL was preemtible, allowing to send concurent ioctls. This mutex doesn't allow this. I think we need a per device locking.

I did not found other complaints about this problem, and then I tried to get help from kernel devs :

https://lkml.org/lkml/2011/10/29/117

edada, did you find a solution for this, or indeed a clear cause of the problem?