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
--nextPart3205480.12Vt4fEPCI Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 ma= kes=20 no sense to lock just paths that exhibit the race. Indeed a new lock for t= ty=20 would make sense, but be warned that you will have to use this lock in a=20 dozen places that are now rightfully protected with the proctree lock. So= =20 instead of one locking operation you now have to do two. The only benefit= =20 you get is reduced lock contention. I am against pushing in the heavy handed patch as well, but I rather have t= he=20 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. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart3205480.12Vt4fEPCI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQBEn+unXyyEoT62BG0RAidUAJ9EgIX8uUfQOQqCaOlR21w8S/zgUwCfQ3jk s114ageSM0TTisEA/ZP/Mw8= =CrO/ -----END PGP SIGNATURE----- --nextPart3205480.12Vt4fEPCI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606261613.59057.max>