Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: [PATCH 0/1] SIGWINCH problem with terminal apps still alive | Date | Sat, 11 Oct 2008 16:04:07 +0200 |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > Adam Tla?ka <atlka@pg.gda.pl> wrote:
>> now we have 2.6.26.6 kernel and still terminal resize leads to >> undesired effects. It is very inconvenient to wait for 2.6.27 for >> corrections.
You'll have to wait some longer, since it still has this bug.
>> As Alan Cox previously said mutexes generally work but as we can >> observe in case of kill_pgrp() call inside mutex lock we got >> race because of rescheduling so lock is not working here. >> Rearanging code so the variable change is placed before kill_pgrp() >> call removes mentioned race situaction.
> NAK again > > Moving the copies around simply moves the race, it might be that it fixes > your box and unfixes other peoples.
This patch does not move around any race, but it works around a locking issue by making sure you are the hedgehog racing the rabbit.
However, you are right in spotting that there must be something wrong with the resulting code. It does (still) modify both tty and the real_tty while only holding one lock. Besides that, it depends on tty->mutex to prevent reading the old values because real_tty->mutex is held.
Adam, since you are working on this issue, I'd suggest you modify the source to take both locks, one at a time, while setting the new values (lock tty->mutex, compare tty->ws, possibly set ws, unlock, lock real_tty, ...).
Alan, do you agree? Or is it required to take both locks at the same time? If it is, in which order?
| |