Alan Cox wrote:
> Add an 'owner' field to the objects we are using. Then we can lock the tty
> and the ldisc from the tyy_io code rather than in serial.c and friends. This
> removes the unload during open/close races we currently have in serial.c
>
> Take a look at videodev.c for a fairly clear e
> - implements tty->ldisc_sem to plug race between do_tty_hangup()
> and tty_set_ldisc(). Is this the ldisc race to which you refer?
Actually I'd missed that one. I was referring to the module race on the ldisc
> +#ifdef CONFIG_MODULES
> + struct module *owner;
> +#endif
I'd rather the f
> Where is an example of the "other locking fix styles" that you and Ted want
> to apply to the serial drivers?
> I would be interested to try to figure this out and fix it--can you give
> me more of an idea of what the problem is?
Add an 'owner' field to the objects we are using. Then we can loc
Alan Cox wrote:
>
> > > drivers and fix their open/close routines to work with this patch? Peter
> > > and I can take some time to do that--if that would help.
> >
> > That would be one big help. Having done that I'd like to go over it all with
> > Ted first (if he has time) before I push it to
Alan Cox wrote:
> So I stuck my justify this change to Ted hat on. And failed.
>
> For one the cleanest way to handle all the locking is to propogate the other
> locking fix styles into both the ldisc and serial drivers. At least for 2.4
If I understand you right, the plan is to leave tty_open u
> > drivers and fix their open/close routines to work with this patch? Peter
> > and I can take some time to do that--if that would help.
>
> That would be one big help. Having done that I'd like to go over it all with
> Ted first (if he has time) before I push it to Linus
So I stuck my justify
> Alan Cox wrote:
> > It has to be changed, the race is basically unfixable any other way. I didn't
> > lightly make that change
>
> I agree. The patch seems like the correct solution. What will it take to
> get the patch in the 2.4.x kernels? Do we need someone to go through the serial
> driv
Alan Cox wrote:
> It has to be changed, the race is basically unfixable any other way. I didn't
> lightly make that change
I agree. The patch seems like the correct solution. What will it take to
get the patch in the 2.4.x kernels? Do we need someone to go through the serial
drivers and fix th
> Ted can you get this patch in the kernel or ban it as interface breaking
> heresy? It would be much nicer for us device driver writers to have just
> one interface to support.
It has to be changed, the race is basically unfixable any other way. I didn't
lightly make that change
-
To unsubscri
Maciej, Ted --
Maciej's patch to tty_io.c from lkml 2/22/01
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0101.2/1049.html
has been incorporated in RH 7.1's kernel (for example) but not in the
main 2.4.x kernels.
This presents two different interfaces for serial drivers, and it is
awkwa
Hello,
There is a problem with handling of TTYs, which manifests itself for
modular backends. I've been able to observe it with the serial.c backend.
The symptoms are if open() fails for some reason (e.g. due to an inactive
DSR line), the module count for the responsible backend decrements
mul
11 matches
Mail list logo
