Return-Path: Received: from cantor2.suse.de ([195.135.220.15]:60020 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753066AbbFFVco (ORCPT ); Sat, 6 Jun 2015 17:32:44 -0400 Date: Sat, 6 Jun 2015 23:32:40 +0200 (CEST) From: Jiri Kosina To: Oleg Nesterov cc: Petr Mladek , Andrew Morton , 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 , Borislav Petkov , Michal Hocko , live-patching@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API In-Reply-To: <20150606211648.GA15591@redhat.com> Message-ID: References: <1433516477-5153-1-git-send-email-pmladek@suse.cz> <1433516477-5153-12-git-send-email-pmladek@suse.cz> <20150606211648.GA15591@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-nfs-owner@vger.kernel.org List-ID: On Sat, 6 Jun 2015, Oleg Nesterov wrote: > Still I personally dislike the new kthread_sigaction() API. I agree, > a couple if signal helpers for kthreads make sense. Say, > > void kthread_do_signal_stop(void) > { > spin_lock_irq(&curtent->sighand->siglock); > if (current->jobctl & JOBCTL_STOP_DEQUEUED) > __set_current_state(TASK_STOPPED); > spin_unlock_irq(¤t->sighand->siglock); > > schedule(); > } ... not to mention the fact that 'STOP' keyword in relation to kthreads has completely different meaning today, which just contributes to overall confusion; but that's an independent story. > > and probably even "int kthread_signal_deque(void)". > > But personally I do not think kthread_do_signal() makes a lot of sense... Would it be possible for you to elaborate a little bit more why you think so ... ? I personally don't see a huge principal difference between "kthread_signal_dequeue() + kthread_do_signal_{stop,...}" vs. generic "kthread_do_signal()" that's just basically completely general and takes care of 'everything necessary'. That being said, my relationship to signal handling code is of course much less intimate compared to yours, so I am really curious what particular objections to that interface have. Thanks a lot, -- Jiri Kosina SUSE Labs