On 2011-09-14, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> In my mind, a port was only open after my open() handler returns
>> success. I guess that's wrong, and I should increment my use counter
>> unconditionally each time my open() handler is called.
>
> Probably - and remember to allow for hangup.
Thanks. I was just looking at the way that is handled in the tty_port
helpers.
>> customers are running kernels recent enough to have those helpers. I
>> suppose I could look into writing compatibility versions compatible
>> with the range of kernels I have to support.
>
> It's actually pretty independant of the underlying tty code so may well
> backport quite easily although it does touch on the refcounting stuff a
> bit I guess.
>
>> The problem is how to make a driver written that way work for
>> somebody running a 2.4 kernel (or even a not-very-recent 2.6 kernel).
>> Yes, I have a few customers running 2.4 kernels, and lots of
>> customers running older 2.6 kernels. I _might_ be able to convince
>> management it's time to drop support for 2.4, but there's no way I
>> can abandon customers using 2.6 kernels.
>
> For 2.4 I think you are on your own, but there are also no 2.4
> kernels without security holes so I tend to think of 2.4 as mostly
> dead.
I think a good argument can be made for that, but I AFAIK my 2.4
customers are running isolated, semi-embedded boxes where security
isn't a concern. (I know... famous last words.)
> In the 2.6 case the tty_port code depends upon the tty layer
> refcounting, and the tty layer refcounting fixes exploitable races in
> tty hangup.
>
> At a certainly point you may actually be best supporting both setups
> as two driver variants. One for the kernels with old style
> lock_kernel assumptions and the like, one for those where tty_port
> appears and we relax the rest of the rules dramatically.
That's certainly worth considering. Once done, it looks like it would
reduce future maintenance effort.
--
Grant Edwards grant.b.edwards Yow! One FISHWICH coming
at up!!
gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
