From owner-freebsd-current@FreeBSD.ORG Mon Nov 21 16:58:41 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2730B106564A; Mon, 21 Nov 2011 16:58:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 376468FC15; Mon, 21 Nov 2011 16:58:39 +0000 (UTC) Received: by eyd10 with SMTP id 10so7909395eyd.13 for ; Mon, 21 Nov 2011 08:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HCbgJp85wGhdGddljVa0oLXogJkaCt5+bRCcx6EsCoM=; b=kCKnHW7pgL6iJfsF5pKYBYvD9pY2VIYVMc/jl1zdZ31612n1qziCrOClUDPTo0AtTj 5593fOhxTk7YswPRL+uU67Yw50dLSraXSHrXuUT2w8Cdcu0M1j8aL4b/xriy/SzBioI7 t1Ngpw723LPMrizO7b7cxOtuekPe0wUvsXYBE= MIME-Version: 1.0 Received: by 10.180.109.106 with SMTP id hr10mr19251735wib.9.1321894719140; Mon, 21 Nov 2011 08:58:39 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.85.8 with HTTP; Mon, 21 Nov 2011 08:58:38 -0800 (PST) In-Reply-To: <201111211132.42119.jhb@freebsd.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171638.03208.jhb@freebsd.org> <4EC6D544.5040803@FreeBSD.org> <201111211132.42119.jhb@freebsd.org> Date: Mon, 21 Nov 2011 17:58:38 +0100 X-Google-Sender-Auth: 1T2BYcoWjY82HBAV2gNj5UcSLJk Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Alexander Motin , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: Stop scheduler on panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 16:58:41 -0000 2011/11/21 John Baldwin : > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: >> on 17/11/2011 23:38 John Baldwin said the following: >> > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: >> >> Hmmm, you could also make critical_exit() not perform deferred preemp= tions >> >> if SCHEDULER_STOPPED? =C2=A0That would fix the recursion and still le= t the >> >> preemption "work" when resuming from the debugger? >> >> Yes, that's a good solution, I think. =C2=A0I just didn't want to touch = such a "low >> level" code, but I guess there is no rational reason for that. >> >> > Or you could let the debugger run in a permament critical section (tho= ugh >> > perhaps that breaks too many other things like debugger routines that = try >> > to use locks like the 'kill' command (which is useful!)). =C2=A0Effect= ively what you >> > are trying to do is having the debugger run in a critical section unti= l the >> > debugger is exited. =C2=A0It would be cleanest to let it run that way = explicitly >> > if possible since then you don't have to catch as many edge cases. >> >> I like this idea, but likely it would take some effort to get done. > > Yes, it would take some effort, so checking SCHEDULER_STOPPED in > critical_exit() is probably good for the short term. =C2=A0Would be nice = to fix > it properly some day. > >> Related to this is something that I attempted to discuss before. =C2=A0I= think that >> because the debugger acts on a frozen system image (the debugger is a so= le actor >> and observer), the debugger should try to minimize its interaction with = the >> debugged system. =C2=A0In this vein I think that the debugger should als= o bypass any >> locks just like with SCHEDULER_STOPPED. =C2=A0The debugger should also b= e careful to >> note a state of any subsystems that it uses (e.g. the keyboard) and retu= rn them >> to the initial state if it had to be changed. =C2=A0But that's a bit dif= ferent story. >> =C2=A0And I really get beyond my knowledge zone when I try to think abou= t things like >> handling 'call func_xxxx' in the debugger where func_xxxx may want to ac= quire >> some locks or noticeably change some state within a system. > > I think to some extent, I think if a user calls a function from the debug= ger > they better know what they are doing. =C2=A0However, I think it can also = be useful > to have the debugger modify the system in some cases if it can safely do = so > (e.g. the 'kill' command from DDB can be very useful, and IIRC, it is car= eful > to only use try locks and just fail if it can't acquire the needed locks)= . I would be very in favor about having a 'thread trampoline for KDB', thus that it can use locks. The only downside is that it assume an healthy state of the switching infrastructure, so maybe it would be fine to wrapper this under a proper compile-time option (KDB_LITE -> it will run in interrupt context and the users will better know what they do). Attilio --=20 Peace can only be achieved by understanding - A. Einstein