On Wed, Jul 12, 2017 at 07:20:28PM +0100, Alan Cox wrote: > > > When opening from kernel, we don't use file pointer. The count mismatch > > is between tty->count and #fd's. So opening from kernel leads to #fd's > > being less than tty->count. I thought this difference is relevant to > > user-space opening of tty, and not to kernel opening of tty. Can you > > suggest how to address this mismatch? > > Your kernel reference is the same as having a file open reference so I > think this actually needs addressing in the maths. In other words count > the number of kernel references and also add that into the test for > check_tty_count (kernel references + #fds == count). > > I'd really like to keep this right because that check has a long history > of catching really nasty race conditions in the tty code. The > open/close/hangup code is really fragile so worth the debugability. I see. Okay based this, check_tty_count can be easily updated to take into account kernel references. > > > Ah may be I didn't notice the active bit. Is it one of the #defines in > > tty.h? Can usage count and active bit be used to differentiate between > > whether the tty was opened by kernel or user? > > It only tells you whether the port is currently active for some purpose, > not which. If you still want to implement exclusivity between kernel and > user then it needs another flag, but I think that flag should be in > port->flags as it is a property of the physical interface. > > (Take a look at tty_port_open for example) Okay I can add TTY_PORT_KOPENED to port->flags and that should work too. However, can you please help me understand this: Our use case requires kernel access to tty_struct and accordingly tty_kopen returns tty_struct. The exclusivity between user and kernel space is also meant to prevent one side from opening tty_struct while another has it opened. In all this, it is tty_struct and not tty_port which is the key resource we are concerned with. So shouldn't the exclusivity flag belong to tty_struct? Adding a the flag to port->flags but controlling it from code for opening and closing tty will also mean we have tty_port_kopened, tty_port_set_kopen etc inside tty open/close code. Am I viewing this problem incorrectly? Thanks, Okash _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
