7

I have written a small driver to read some data and give it to the user. My driver can be used by more than one application, i.e. it's a reentrant driver, hence the use of a spin lock. But I discovered that copy_to_user should not be called with a spin lock held. char_device_buf in the following code is shared data; I have to protect it. Is there any mechanism apart from mutex to use spin lock and use copy_to_user?

static ssize_t char_dev_read(struct file *file,
                                char *buf,
                                size_t lbuf,
                                loff_t *ppos)
    {
            int maxbytes; /* number of bytes from ppos to MAX_LENGTH */
            int bytes_to_do; /* number of bytes to read */
            int nbytes; /* number of bytes actually read */

            maxbytes = MAX_LENGTH - *ppos;

            if( maxbytes > lbuf ) bytes_to_do = lbuf;
            else bytes_to_do = maxbytes;

            if( bytes_to_do == 0 ) {
                    printk("Reached end of device\n");
                    return -ENOSPC; /* Causes read() to return EOF */
            }

       /* Tesing for accidental release */
    //              accidental_release(); 

            printk(KERN_DEBUG "READER: trying for critical region lock \n");

            spin_lock(&myspin);/*begin of critical region */

                    printk(KERN_DEBUG "READER : acquired lock: executing critical code\n");
                    nbytes = bytes_to_do -
                             copy_to_user( buf, /* to */
                                           char_device_buf + *ppos, /* from */
                                           bytes_to_do ); /* how many bytes */


            spin_unlock(&myspin); /* end of critical region */
            *ppos += nbytes;
            return nbytes;
    }
Marco Bonelli
  • 63,369
  • 21
  • 118
  • 128
Suri
  • 3,287
  • 9
  • 45
  • 75

1 Answers1

8

The reason why copy_{to,from}_user should not be used inside a spin lock, is that these functions can sleep. Imagine this scenario (on a uni-processor machine):

  1. Process A mmap()ed a file
  2. The process calls your driver providing an address into that mmap()ed area
  3. Your code runs, locks, then copy_to_user causes a page fault on that address - the memory is not present so that process goes to sleep until the data comes from the disk.
  4. The kernel schedules to process B, it calls your the driver the same way.
  5. Deadlock - Process A is waiting for the IO to return inside a lock but won't be scheduled because B is holding the CPU waiting for the same lock to be unlocked.

Unless there is a 100% guarantee that copy_{to,from}_user won't cause a segfault, you cannot use spin locks, but must use a sleep lock instead, such as 'mutex_lock'. Sleep locks yield control to the scheduler while spin locks do not.

Dan Aloni
  • 3,968
  • 22
  • 30
  • In multi-processor, the process B will get a chance to execute on other processor. Thus, the system will not halt. Once the page table is loaded correctly, it will come out from sleep and the code will be executed fine. I don't see any problem on multiprocessor here. Anyway, the spin lock is not useful in uniprocessor as we all know that. I don't understand the sleep() drawback here with your example on multiprocessor. Can you please throw up the issue on multi-processor environment? – dexterous Apr 29 '14 at 15:29
  • 1
    On a multiprocessor you can bump into the same problem. Suppose process A is scheduled out while holding the spinlock. Now, the scheduler can put any task it wants on any CPU. Suppose it innocently schedules all CPUs to run some code that happens to lock that spinlock, then you get a deadlock, because the original thread will never wake up to release it. No scheduling can happen on a CPU that waits on a spinlock. The `copy_to_user` example is just one example of a situation that requires scheduler sleep. For any other case where you hold a spinlock and then schedule out - you risk a deadlock. – Dan Aloni Apr 30 '14 at 14:49
  • So the general assumption is that any process holding `spinlock` cannot be descheduled from the CPU it is running on unless the code inside the critical section may sleep which will allow the kernel to deschedule it while holding `spinlock`. – St.Antario Nov 14 '19 at 05:33