linux-kernel - Re: [PATCH 0/1] SIGWINCH problem with terminal apps still alive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1Kof4h-0005Q3-Ns@be1.7eggert.dyndns.org>
Date:	Sat, 11 Oct 2008 16:04:07 +0200
From:	Bodo Eggert <7eggert@....de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>, Adam Tla?ka <atlka@...gda.pl>,
	linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH 0/1] SIGWINCH problem with terminal apps still alive

Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> Adam Tla?ka <atlka@...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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/