Date: Mon, 26 Jun 2006 16:13:50 +0200 From: Max Laier <max@love2party.net> To: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> Cc: freebsd-stable@freebsd.org, "Wojciech A. Koszek" <wkoszek@freebsd.org>, csjp@freebsd.org, Martin Blapp <mb@imp.ch>, Robert Watson <rwatson@freebsd.org>, Patrick Guelat <patg@imp.ch> Subject: Re: Crash with FreeBSD 6.1 STABLE of today Message-ID: <200606261613.59057.max@love2party.net> In-Reply-To: <1151328755.80434.17.camel@buffy.york.ac.uk> References: <20060621202508.S17514@godot.imp.ch> <20060626151138.C14714@godot.imp.ch> <1151328755.80434.17.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Monday 26 June 2006 15:32, Gavin Atkinson wrote: > On Mon, 2006-06-26 at 15:15 +0200, Martin Blapp wrote: > > A remote stress testing of a tty session over serial cable > > with a patched kernel worked fine. > > > > How to proceed now ? The patch also applies to CURRENT > > as there where no big changes since the repo has been > > branched. > > > > Should I commit it to CURRENT ? > > > > > http://mx.imp.ch/patch-tty.t_pgrp.diff > > I'm still not convinced that the proctree lock is the correct lock to > use - maybe a new lock for the tty subsystem? Also, some of the locking > in the patch appears to be unnecessary. I can't help feeling that this > patch is the heavy-handed solution to the problem, and given how > heavyweight locks can be, maybe it's not a good solution. > > Is the problem actually understood? Do we know what's racing with what? I found kern_proc.c:461 to be a likely candidate for a race. > Given there only ever seems to be a single backtrace involved, as far as > I can tell, it's ttymodem racing with tty_close - can those two > functions alone be locked? When locking something you have to lock every access to do it right. It makes no sense to lock just paths that exhibit the race. Indeed a new lock for tty would make sense, but be warned that you will have to use this lock in a dozen places that are now rightfully protected with the proctree lock. So instead of one locking operation you now have to do two. The only benefit you get is reduced lock contention. I am against pushing in the heavy handed patch as well, but I rather have the heavy handed version in than a nasty race. > Alas, I can't recreate the problem on-demand so can't really find a > better solution. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEn+unXyyEoT62BG0RAidUAJ9EgIX8uUfQOQqCaOlR21w8S/zgUwCfQ3jk s114ageSM0TTisEA/ZP/Mw8= =CrO/ -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606261613.59057.max>