Messages in this thread | | | Date | Tue, 4 May 2004 09:00:15 +0800 (WST) | From | Ian Kent <> | Subject | Re: 2.6.6-rc3-mm1 |
| |
On Mon, 3 May 2004, Jeff Moyer wrote:
> ==> Regarding Re: 2.6.6-rc3-mm1; raven@themaw.net adds: > > raven> The case where two process similtaneously trigger a mount in autofs4 > raven> can cause multiple requests to the daemon for the same mount. The > raven> daemon handles this OK but it's possible an incorrect error to be > raven> returned. For this reason I believe it is better to change the spin > raven> lock to a semaphore in waitq.c. This makes the second and subsequent > raven> request wait on the q as ther supposed to. > > This looks good to me. Do you also need to take the semaphore in > autofs4_catatonic_mode(), around the hijacking of the queue? > > void autofs4_catatonic_mode(struct autofs_sb_info *sbi) > { > struct autofs_wait_queue *wq, *nwq; > > DPRINTK(("autofs: entering catatonic mode\n")); > > sbi->catatonic = 1; > wq = sbi->queues; > sbi->queues = NULL; /* Erase all wait queues */ > ... >
Once sbi->catatonic is 1 then the mount is "catatonic". No more mount request can be made (ever). The q is quesient.
Interestingly, once done you can't return. Like jumping of a cliff and then deciding you don't want to hit the bottom.
The point of the may umount ioctl was to allow a decision to be made before jumping.
Ian
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |