[lkml]   [2008]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/1] SIGWINCH problem with terminal apps still alive
Alan Cox <> wrote:
> Adam Tla?ka <> wrote:

>> now we have 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?

 \ /
  Last update: 2008-10-11 15:55    [W:0.071 / U:5.928 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site