From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Date: Wed, 17 Jun 2015 04:34:50 -0700 Message-ID: <20150617113450.GA28508@infradead.org> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1433516477-5153-1-git-send-email-pmladek-AlSwsSmVLrQ@public.gmane.org> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Petr Mladek Cc: Andrew Morton , Oleg Nesterov , Tejun Heo , Ingo Molnar , Peter Zijlstra , Richard Weinberger , Steven Rostedt , David Woodhouse , linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Trond Myklebust , Anna Schumaker , linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chris Mason , "Paul E. McKenney" , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org On Fri, Jun 05, 2015 at 05:00:59PM +0200, Petr Mladek wrote: > Kthreads are implemented as an infinite loop. They include check points > for termination, freezer, parking, and even signal handling. > > We need to touch all kthreads every time we want to add or > modify the behavior of such checkpoints. It is not easy because > there are several hundreds of kthreads and each of them is > implemented in a slightly different way. > > This anarchy brings potentially broken or non-standard behavior. > For example, few kthreads already handle signals a strange way. > > > This patchset is a _proof-of-concept_ how to improve the situation. Maybe it might be a better idea to audit the existing callers of signals for kthreads and first check if we can get rid of them. Then as a second step if any are left convert them to signalfd-style operation where signals aren't checked synchronously but as something the threads can consume on a as needed basis. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 17 Jun 2015 04:34:50 -0700 From: Christoph Hellwig To: Petr Mladek Subject: Re: [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Message-ID: <20150617113450.GA28508@infradead.org> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433516477-5153-1-git-send-email-pmladek@suse.cz> Cc: Peter Zijlstra , Trond Myklebust , linux-kernel@vger.kernel.org, Michal Hocko , Chris Mason , linux-mtd@lists.infradead.org, live-patching@vger.kernel.org, Richard Weinberger , Ingo Molnar , Borislav Petkov , David Woodhouse , Steven Rostedt , Thomas Gleixner , linux-nfs@vger.kernel.org, "Paul E. McKenney" , Jiri Kosina , Oleg Nesterov , linux-api@vger.kernel.org, Tejun Heo , Andrew Morton , Linus Torvalds , Anna Schumaker List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jun 05, 2015 at 05:00:59PM +0200, Petr Mladek wrote: > Kthreads are implemented as an infinite loop. They include check points > for termination, freezer, parking, and even signal handling. > > We need to touch all kthreads every time we want to add or > modify the behavior of such checkpoints. It is not easy because > there are several hundreds of kthreads and each of them is > implemented in a slightly different way. > > This anarchy brings potentially broken or non-standard behavior. > For example, few kthreads already handle signals a strange way. > > > This patchset is a _proof-of-concept_ how to improve the situation. Maybe it might be a better idea to audit the existing callers of signals for kthreads and first check if we can get rid of them. Then as a second step if any are left convert them to signalfd-style operation where signals aren't checked synchronously but as something the threads can consume on a as needed basis. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:57362 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752948AbbFQLfH (ORCPT ); Wed, 17 Jun 2015 07:35:07 -0400 Date: Wed, 17 Jun 2015 04:34:50 -0700 From: Christoph Hellwig To: Petr Mladek Cc: Andrew Morton , Oleg Nesterov , Tejun Heo , Ingo Molnar , Peter Zijlstra , Richard Weinberger , Steven Rostedt , David Woodhouse , linux-mtd@lists.infradead.org, Trond Myklebust , Anna Schumaker , linux-nfs@vger.kernel.org, Chris Mason , "Paul E. McKenney" , Thomas Gleixner , Linus Torvalds , Jiri Kosina , Borislav Petkov , Michal Hocko , live-patching@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Message-ID: <20150617113450.GA28508@infradead.org> References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1433516477-5153-1-git-send-email-pmladek@suse.cz> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Fri, Jun 05, 2015 at 05:00:59PM +0200, Petr Mladek wrote: > Kthreads are implemented as an infinite loop. They include check points > for termination, freezer, parking, and even signal handling. > > We need to touch all kthreads every time we want to add or > modify the behavior of such checkpoints. It is not easy because > there are several hundreds of kthreads and each of them is > implemented in a slightly different way. > > This anarchy brings potentially broken or non-standard behavior. > For example, few kthreads already handle signals a strange way. > > > This patchset is a _proof-of-concept_ how to improve the situation. Maybe it might be a better idea to audit the existing callers of signals for kthreads and first check if we can get rid of them. Then as a second step if any are left convert them to signalfd-style operation where signals aren't checked synchronously but as something the threads can consume on a as needed basis.