Do you think that this is actually happening in your case?  The most likely time would be a signalled process to which some application level program is directing ioctls.

At 01:24 PM 5/14/2004, Eugene LiS User wrote:

Dave Grothe <[EMAIL PROTECTED]> wrote:
>Good point about clearing the IOCWAIT flag before destoying the
>semaphore.

I started to think that even that may not be enough.

Shouldn't we use spinlocks to protect the pairs like these: ?

spinlock(smth for hd->sd_flag )
if (F_ISSET(hd->sd_flag,IOCWAIT))
        lis_wake_up_wiocing(hd);
spinunlock(smth for hd->sd_flag )

This particular technique would not work because holding a spin lock across a call to the schedule() routine in the kernel is verboten.


spinlock(smth for hd->sd_flag )
CLR_SD_FLAG(hd,IOCWAIT);
SEM_DESTROY(&hd->sd_wiocing) ;
spinunlock(smth for hd->sd_flag )


Say, if in lis_strdoioctl()

1. The IOCWAIT flag is set.

2. The lis_wait_for_wiocing()
   is called and immediately exited due to error.

3. Flag is cleared
4. SEM_DESTROY is about to be executed

Meanwhile, in lis_strrput() (running on another CPU)

1. Flag is checked and confirmed
  (right at the time between steps (2) and (3) of lis_strdoioctl)

2. The lis_wake_up_wiocing(hd) is started on the semaphore
   that is being destroyed.

Looks like this is possible.

Am I missing something?

No.  It looks like a possible case.


--
Eugene

Do we really need to call SEM_DESTROY(&hd->sd_wiocing) ?

No.  But the case that you cite above would lead to over-incrementing of the semaphore counter.  That would have to be corrected for by calling lis_sem_init() at the beginning of each ioctl operation.  I don't like doing that for portability reasons.  Perhaps not all OSs will allow re-initialization of the semaphore without first de-initializing it.

Perhaps some state flag that would allow lis_strdoioctl() to do the SEM_DESTROY at the beginning of the "next" ioctl and a final one when the stdata structure is deallocated....

Anyway, I will be away for the next week and will think about something else during that time.

-- Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.663 / Virus Database: 426 - Release Date: 4/20/2004

Reply via email to