From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 27 19:49:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE12B5A6; Fri, 27 Mar 2015 19:49:25 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67967C5E; Fri, 27 Mar 2015 19:49:25 +0000 (UTC) Received: by wgbdm7 with SMTP id dm7so4145673wgb.1; Fri, 27 Mar 2015 12:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=k/fJN1V0AD/WTksuybNU9Z5V6kNTBiwPb1v+IyYPVFE=; b=slqzHjGSOBs8QjTwaQMqJRRm7YY58569e0rM9LDMDmdn9tUzVKWPg/fikHEt+tg+pP GkQ6KuTj8GxAuVfBS0q2TmYbsaQpLU2Ee0HIpv7+5PUsjV8FkwkyrzTl+ypDOnLmttZs LAB5QLKI4MV3xJSoAiQCPS1xmVKL0LaTTmT1KdBOG3SgdS/aAmrERAXPmFUJpfmzBepw cwYSURq0pcsCJoBmyiee3hm/fyrxvNYTMjs3Uul67SkaUGBZmaDSTtU4zMJkSmIst63Y BZiodiOa5HwAkFX+gtkvSL09g8Vv+5Ceejho5WBp4RJGB3/PBsedbJAuqEQlC4znawA5 4ZQA== X-Received: by 10.180.85.103 with SMTP id g7mr708737wiz.19.1427485763892; Fri, 27 Mar 2015 12:49:23 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id m9sm4764532wiz.24.2015.03.27.12.49.22 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 27 Mar 2015 12:49:22 -0700 (PDT) Date: Fri, 27 Mar 2015 20:49:20 +0100 From: Mateusz Guzik To: Yue Chen Subject: Re: How to traverse kernel threads? Message-ID: <20150327194920.GB18158@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Yue Chen , "freebsd-hackers@freebsd.org" , Benjamin Kaduk , Oliver Pinter References: <20150321220246.GE14650@dft-labs.eu> <20150321232622.GF14650@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-hackers@freebsd.org" , Oliver Pinter , Benjamin Kaduk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 19:49:26 -0000 On Fri, Mar 27, 2015 at 02:35:55PM -0400, Yue Chen wrote: > When using the following code on kernel module loading: > ------------------------------------------------------------------------------------------ > struct thread *td = kdb_thr_first(); > td = kdb_thr_next(td); > ------------------------------------------------------------------------------------------ > The kernel panics. > Panics how? Also you can easily see these functions don't lock anything, so it would be assumed you took appropriate locks. Except it seems there routines are supposed to be only used when execution is 'frozen' (e.g. when escaped to the debugger). > > And when printing all threads in proc0 (all kernel threads?): > ------------------------------------------------------------------------------------------ > struct proc *p = pfind(0); > FOREACH_THREAD_IN_PROC(p, td) { > uprintf("td: %x\n", td); > } > proc0 is an exported symbol, no need to pfind. > td = curthread; > uprintf("cur td: %x\n", td); > ------------------------------------------------------------------------------------------ > The ``curthread'' (from this kernel module running the above code) is not > in the 0 process group. > There is no 'curthread from kernel module'. My guess is you do this work from module initializator, and in that case curthread is the thread which loads the module, and such a thread is definitely not linked into proc0. Still nobody knows what you are trying to do. -- Mateusz Guzik