linux-kernel - Re: [PATCH] vt: fix vcs* sysfs file creation race [v2]

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-prev] [day] [month] [year] [list]

Date:	Fri, 23 May 2008 20:04:40 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Aristeu Sergio Rozanski Filho <aris@...vo.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vt: fix vcs* sysfs file creation race [v2]

> But this isn't the only problem.  Currently release_dev() checks for
> tty->count without holding any locks but BKL that is acquired on tty_release()
> and several tty drivers also check tty->count and some of them without even

Yes - the old stable branches were fixed to used atomic_t but for some
reason this never ended up in 2.5/2.6.

> 1) We get rid of tty->count usage on drivers by implementing internal
>    counters.  This solution would allow us to fix each driver before
>    converting tty->count into a kref and only be used by tty layer.  This
>    proposed patch does eliminate tty->count usage on vt.

We need to do this anyway because of the race between an interrupt on one
processor and a hangup/close on another. So tty needs a kref and if tty
has a kref count it might as well be the tty->count replacement. It's on
my todo list but feel free to beat me to it.

> 2) We kill the current one open/close for each tty_open, only calling
>    driver's open and close on the first open and last close.  By looking on
>    the tty drivers, none of them do anything important with multiple opens
>    anyway (but I might be wrong on this).

Several use it to track things like board use counters. I'd prefer to
avoid that change, especially as it isn't needed long term. Also long
term tty->open is moving towards standardised library code - thats where
having tty_port leads.

kref the tty not the vty would be my suggestion.

Alan
--
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/