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.
