Date: Mon, 26 Jun 2006 14:32:35 +0100 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: Martin Blapp <mb@imp.ch> Cc: freebsd-stable@freebsd.org, "Wojciech A. Koszek" <wkoszek@freebsd.org>, csjp@freebsd.org, Robert Watson <rwatson@freebsd.org>, Max Laier <max@love2party.net>, Patrick Guelat <patg@imp.ch> Subject: Re: Crash with FreeBSD 6.1 STABLE of today Message-ID: <1151328755.80434.17.camel@buffy.york.ac.uk> In-Reply-To: <20060626151138.C14714@godot.imp.ch> References: <20060621202508.S17514@godot.imp.ch> <20060623133915.S14714@godot.imp.ch> <1151078632.62769.30.camel@buffy.york.ac.uk> <200606231928.58063.max@love2party.net> <20060626115110.O14714@godot.imp.ch> <20060626133540.G14714@godot.imp.ch> <20060626151138.C14714@godot.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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? Alas, I can't recreate the problem on-demand so can't really find a better solution. Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1151328755.80434.17.camel>