On Fri, 2019-08-09 at 18:31 -0500, Goldwyn Rodrigues wrote: > We should not deadlock the kernel, or wait infinitely in case the > user users incorrect mount options. One example is when > indirect mount and mount offsets are bind mounts which are not > private, and automount waits to complete a mount propagation. > Use the expire timeout as the limit to wait for automount > to complete, or return -EWOULDBLOCK/-EAGAIN. I like the idea of using a timeout. But I'm wondering if there could be adverse side effects. Can you talk a little about cases that lead to this please. One purpose of this blocking is to prevent path walkers from walking into an under construction mount point directory. I guess this will end up returning an error to user space so it won't allow this to happen ... and if the user space caller ignores the error return and continues ... the app could get very sick, very quick ... At least when a process blocks on this it's a clear sign of some other problem that really needs to be fixed and crash dumps allow inspecting the blocked processes to work out (hopefully, but not always) where it started. Hence a little more discussion about expected behaviour is in order even if it's decided to accept a bit less information in order to prevent processes from blocking for a "long" time. > > Signed-off-by: Goldwyn Rodrigues <rgoldwyn@xxxxxxxx> > > diff --git a/fs/autofs/waitq.c b/fs/autofs/waitq.c > index b04c528b19d3..da1f01a73ffb 100644 > --- a/fs/autofs/waitq.c > +++ b/fs/autofs/waitq.c > @@ -476,8 +476,11 @@ int autofs_wait(struct autofs_sb_info *sbi, > * wq->name.name is NULL iff the lock is already released > * or the mount has been made catatonic. > */ > - wait_event_killable(wq->queue, wq->name.name == NULL); > - status = wq->status; > + status = wait_event_killable_timeout(wq->queue, wq->name.name > == NULL, sbi->exp_timeout); > + if (status > 0) > + status = wq->status; > + else if (status == 0) > + status = -EAGAIN; > > /* > * For direct and offset mounts we need to track the > requester's >
