From owner-freebsd-current@freebsd.org Tue Aug 4 16:27:49 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE5B99B2BCB for ; Tue, 4 Aug 2015 16:27:48 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 7BEDD137 for ; Tue, 4 Aug 2015 16:27:48 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: by labow3 with SMTP id ow3so11089864lab.1 for ; Tue, 04 Aug 2015 09:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2pqvq5eiwiIIg1FD77ES0jFmNGYhRNd+seYgLqvFFUo=; b=pFLovuVu2cwsuD8wUN0lfdj1YG3b2JCLNq7qfIgbLSSC6qVvJ1THZtzVwnkdRdvct7 xm/eUe6+S/gwZLSsFxVs50lJnxenYiEirXQtgHiMBQ1RWBMz6wfJxL9WKcgWjjz0SxSy D7KI1NdRN56yIzVFAmYrGlLzQrZbBJ0dlc8Tj6hU199LK5UWt//wLV9GMIj3RzQloeF5 Z3e+CyCDolKMqJJHBZA/Qnfz5pp5Pqj/94xVTa8LaU9sD7h1jJs3enWAOsofukMxbPV5 LFxtp9x6wBgWWSpjs3tIRTyY654KT1Jo3kxZSZ8YyE66BF1DkUOjqgyoUW2HuM0NHHeN HVBQ== MIME-Version: 1.0 X-Received: by 10.112.163.226 with SMTP id yl2mr4517316lbb.100.1438705666269; Tue, 04 Aug 2015 09:27:46 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.80.133 with HTTP; Tue, 4 Aug 2015 09:27:46 -0700 (PDT) In-Reply-To: <20150804160211.GO2072@kib.kiev.ua> References: <20150804145311.GN2072@kib.kiev.ua> <20150804160211.GO2072@kib.kiev.ua> Date: Tue, 4 Aug 2015 18:27:46 +0200 X-Google-Sender-Auth: iLzlBoMAxkUPCnNOe8yACXdO6SM Message-ID: Subject: Re: proper way to terminate a kthread when the parent process dies ? From: Luigi Rizzo To: Konstantin Belousov Cc: freebsd-current , Stefano Garzarella , Giuseppe Lettieri Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 04 Aug 2015 16:27:49 -0000 On Tue, Aug 4, 2015 at 6:02 PM, Konstantin Belousov wrote: > On Tue, Aug 04, 2015 at 05:32:28PM +0200, Luigi Rizzo wrote: >> On Tue, Aug 4, 2015 at 4:53 PM, Konstantin Belousov wrote: >> > If this is a thread of the normal user process, then it is not a kernel >> > thread, even if it never leaves the kernel mode. >> >> thanks for the answer. >> >> i do not really know what is the difference between a "kernel thread" >> and a "thread". >> Could you clarify what is the distinctive feature between the two ? >> Perhaps being owned by pid 0 ? > No. I probably having troubles answering this exact question. TDP_KTHREAD > is used as a shortcut in several places, mostly to avoid some specific > actions that are useless for the real kernel process. E.g. the amd64 > context switch code avoids setting some CPU registers when switching to > the kernel thread. Hacks to not switch address spaces when switching > to the kthread were already removed. > > Overall, claiming that a thread of the normal user process (i.e. process > which executes in userspace) is kernel thread is fragile and, if not > breaking in your tests, could break later. >> >> This specific thread is created within a system call by invoking kthread_add() >> and associated with the user process. > Did you tried the other approach, by creating the thread from userspace, > and then executing the syscall which would loop ? This is how things are > done by e.g. nfsd. ok will look at the alternative you suggest. Specifically, our two threads implement the host part of a virtualized network interface and operate in a way that is very similar to an interrupt handler, or vhost-net in KVM. In principle, the user process that issues the system call could be unaware of the existence and number of those threads; that is why we went for a "kernel thread" created within the kernel. thanks again for the explanation cheers luigi > > Still, if you looping in the kernel, you must call thread_suspend_check() > periodically. >> >> > >> > You must call thread_suspend_check() in any in-kernel loop to allow the >> > stops and process exit to work. >> >> so does it mean that the kthread_suspend_check() is incorrect and we should >> use thread_suspend_check() instead ? > Most likely yes. -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------