Dereferencing semaphores and atomic_t's

drivers/scsi/scsi_error.c:

        SCSI_LOG_ERROR_RECOVERY(3, printk("Wake up parent %d\n",
                                          shost->eh_notify->count.counter));

        up(shost->eh_notify);

drivers/scsi/hosts.c:

                up(shost->eh_wait);
                SCSI_LOG_ERROR_RECOVERY(5, printk("Waking error handler"
                                          "thread (%d)\n",
                                          atomic_read(&shost->eh_wait->count)));


                up(shost->eh_wait);
                SCSI_LOG_ERROR_RECOVERY(5, printk("Waking error handler"
                                          "thread (%d)\n",
                                          atomic_read(&shost->eh_wait->count)));

Do we really allow this type of layering violation?

(There appear to be some circumstances when obtaining the semaphore count is useful, but shouldn't we provide an architecture helper function to do that since a semaphore structure _is_ an architecture-defined opaque structure.)

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

From: Russell King <[email protected]>
Date: Wed, 2 Oct 2002 11:16:26 +0100

Do we really allow this type of layering violation?

No, it should be killed :-)

(There appear to be some circumstances when obtaining the semaphore count is useful, but shouldn't we provide an architecture helper function to do that since a semaphore structure _is_ an architecture-defined opaque structure.)

Feel free to make one.

This is already fixed in 2.4 - just forward port the fixes

I added sem_getcount to my scsi_error.c update and my scsi_hosts update patch. I should have these out soon.

Sorry Russell that it has taken longer than I said to get the updated scsi_error patch out. I am still investigating an issue with getting door lock to work post fault insertion.

-andmike
--
Michael Anderson
[email protected]