Interesting. It's probably worth looking at what Plan 9 did in this situation; as I recall, devmnt was responsible for cleaning up when a process exited.
I don't see any useful reason for blocking indefinitely. On Wed, Jul 20, 2016 at 5:14 PM, Barret Rhoden <[email protected]> wrote: > Hi - > > Kyle et al. stumbled on a bug with devmnt and exit-without-close. > > If you open a file across a 9p mount, then exit without calling > close, the kernel will eventually run out of RPC tags in devmnt. > > The issue is that syscalls get aborted when the process is dying. > these syscalls are ones in which the wait time is outside of the > kernel's control. qlocks, for instance, are okay. A kthread will > eventually get the lock and complete. rendez's get aborted. > > This doesn't play nicely with devmnt, which keeps retrying on abort. > but all syscalls abort for a DYING process, so it'll retry til we run > out of tags. > > I'm not a huge fan of the infinite retry process. This is the "flush > the flush of the flush of the original op" deal, I think. Why does 9p > need so many flushes? Is one flush sufficient? Maybe, maybe not. > > I'm willing to change the syscall aborting, if needs be. Though we > should have a clear set of rules about what to do with outstanding > syscalls when processes die. e.g., I listen on a socket (open a > Qlisten file). open itself is blocked on a rendez_sleep in devip.c, so > it's not in an FD table. Then we kill the process. When does that > conversation/port/etc get freed? Never? > > Are there other cases where we want a rendez to close a file? (any > close can happen at exit time). > > Are we ever in a situation where the rendez *must* succeed? (if so, > perhaps the rendez is the wrong tool there?). Maybe we should have > some sort of rule where you never use *must* and *rendez* in the same > sentence. (i.e., anything calling rendez must be able to fail, and > that must be okay). Considering most rendezes are related to network > ops, that seems reasonable (since the remote end can disappear at any > time). > > Barret > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
