lkml.org 
[lkml]   [2008]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 0/1] SIGWINCH problem with terminal apps still alive
    Date
    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?



    \
     
     \ /
      Last update: 2008-10-11 15:55    [W:0.023 / U:31.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site