From owner-freebsd-current@FreeBSD.ORG Tue Dec 6 15:26:31 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 1AE00106566B; Tue, 6 Dec 2011 15:26:31 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38B138FC08; Tue, 6 Dec 2011 15:26:29 +0000 (UTC) Received: by bkat2 with SMTP id t2so10532049bka.13 for ; Tue, 06 Dec 2011 07:26:29 -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=/ez1W1oBbxSPUGwoGFPnAa6V4YvM0c2Zz5Moaf1Flsw=; b=M10rq5FfDku+eigZZ1JYsif0+Gdl60Jn80whhUIH40TCsdNnz5a0p4o2juWsn+4r9X kkHzF/57MFJg8rh3/rSkzUt550a9AOuMS5YhccC3Q/OmqTLjQIeHHZoGTQxI8/JyXbIR fvk+P1sow7A0PmBG1A8IKKnqtl0XQyqD+VxdQ= MIME-Version: 1.0 Received: by 10.180.74.211 with SMTP id w19mr7667899wiv.7.1323185188858; Tue, 06 Dec 2011 07:26:28 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.47.211 with HTTP; Tue, 6 Dec 2011 07:26:28 -0800 (PST) In-Reply-To: <4EDBF11D.6030401@FreeBSD.org> References: <20111113083215.GV50300@deviant.kiev.zoral.com.ua> <201111171638.03208.jhb@freebsd.org> <4EC6D544.5040803@FreeBSD.org> <201111211132.42119.jhb@freebsd.org> <4EDBF11D.6030401@FreeBSD.org> Date: Tue, 6 Dec 2011 16:26:28 +0100 X-Google-Sender-Auth: OzYaNYzDIvAiSV43HfP7oqQ_2VI Message-ID: From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-current@freebsd.org 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: Tue, 06 Dec 2011 15:26:31 -0000 2011/12/4 Andriy Gapon : > on 21/11/2011 18:58 Attilio Rao said the following: >> I would be very in favor about having a 'thread trampoline for KDB', >> thus that it can use locks. > > I keep hearing the suggestion to add this trampoline, but I admit that I = do not > understand its technical meaning in this context. =C2=A0And also how it h= elps with > the locking. =C2=A0So I will appreciate an explanation! =C2=A0Thanks! kdb_trap() now runs in interrupt context, my suggestion was to just to give KDB its own context (a new kernel thread) and yield its execution when KDB needs to be entered, this way it is possible to use locking and avoid functions duplications. In theory, this avoids constructing complicate algorithms to be lockless when implementing primitives KDB should use. However, I now realize a problem: if we want to stop CPUs we don't really want to acquire locks anyway because of CPU restart. Likely, the KDB trampoline is not a good option for this reason and we should work instead on getting KDB functions to be totally lockless. Another thing I'm considering is, however, the entrypoint for KDB. When I looked into it months ago I thought there is a mismatch between kdb_enter() (which should disable CPUs) and other ways to enter KDB (maybe some paths calling directly kdb_trap()?). We must offer an unified policy and entrypoint, being likely to disable CPUs when entering it. Attilio --=20 Peace can only be achieved by understanding - A. Einstein