From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Richard Weinberger <richard@nod.at>,
Steven Rostedt <rostedt@goodmis.org>,
David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org,
Trond Myklebust <trond.myklebust@primarydata.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
linux-nfs@vger.kernel.org, Chris Mason <clm@fb.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Borislav Petkov <bp@suse.de>, Michal Hocko <mhocko@suse.cz>,
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
Date: Sun, 7 Jun 2015 00:58:54 +0200 [thread overview]
Message-ID: <20150606225854.GA20352@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1506070034100.12753@pobox.suse.cz>
On 06/07, Jiri Kosina wrote:
>
> On Sun, 7 Jun 2015, Oleg Nesterov wrote:
>
> > > 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'.
> >
> > Then why do we need the new API ?
>
> Well, in a nutshell, because of the "it's general and takes care of
> everything" part.
...
> Signal handling is just
> one of the piggy-backers on top of this general cleanup.
And to avoid the confusion: so far I only argued with the signal
handling part of this API. Namely with kthread_do_signal(), especially
with the SIG_DFL logic.
If we want somthing like kthread_iterant agree it should probably help to
handle the signals too. But afaics kthread_do_signal() doesn't really help
and certainly it is not strictly necessary.
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>
Cc: Petr Mladek <pmladek-AlSwsSmVLrQ@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,
Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Trond Myklebust
<trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>,
Anna Schumaker
<anna.schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chris Mason <clm-b10kYP2dOMg@public.gmane.org>,
"Paul E. McKenney"
<paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>,
Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>,
live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API
Date: Sun, 7 Jun 2015 00:58:54 +0200 [thread overview]
Message-ID: <20150606225854.GA20352@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1506070034100.12753-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
On 06/07, Jiri Kosina wrote:
>
> On Sun, 7 Jun 2015, Oleg Nesterov wrote:
>
> > > 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'.
> >
> > Then why do we need the new API ?
>
> Well, in a nutshell, because of the "it's general and takes care of
> everything" part.
...
> Signal handling is just
> one of the piggy-backers on top of this general cleanup.
And to avoid the confusion: so far I only argued with the signal
handling part of this API. Namely with kthread_do_signal(), especially
with the SIG_DFL logic.
If we want somthing like kthread_iterant agree it should probably help to
handle the signals too. But afaics kthread_do_signal() doesn't really help
and certainly it is not strictly necessary.
Oleg.
WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: linux-nfs@vger.kernel.org, Borislav Petkov <bp@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
linux-api@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Richard Weinberger <richard@nod.at>,
Trond Myklebust <trond.myklebust@primarydata.com>,
linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.cz>,
Michal Hocko <mhocko@suse.cz>, Chris Mason <clm@fb.com>,
Ingo Molnar <mingo@redhat.com>,
linux-mtd@lists.infradead.org,
Steven Rostedt <rostedt@goodmis.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Tejun Heo <tj@kernel.org>,
live-patching@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
David Woodhouse <dwmw2@infradead.org>,
Anna Schumaker <anna.schumaker@netapp.com>
Subject: Re: [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API
Date: Sun, 7 Jun 2015 00:58:54 +0200 [thread overview]
Message-ID: <20150606225854.GA20352@redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1506070034100.12753@pobox.suse.cz>
On 06/07, Jiri Kosina wrote:
>
> On Sun, 7 Jun 2015, Oleg Nesterov wrote:
>
> > > 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'.
> >
> > Then why do we need the new API ?
>
> Well, in a nutshell, because of the "it's general and takes care of
> everything" part.
...
> Signal handling is just
> one of the piggy-backers on top of this general cleanup.
And to avoid the confusion: so far I only argued with the signal
handling part of this API. Namely with kthread_do_signal(), especially
with the SIG_DFL logic.
If we want somthing like kthread_iterant agree it should probably help to
handle the signals too. But afaics kthread_do_signal() doesn't really help
and certainly it is not strictly necessary.
Oleg.
next prev parent reply other threads:[~2015-06-06 23:00 UTC|newest]
Thread overview: 175+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 15:00 [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Petr Mladek
2015-06-05 15:00 ` Petr Mladek
2015-06-05 15:00 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 01/18] kthread: Allow to call __kthread_create_on_node() with va_list args Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 02/18] kthread: Add API for iterant kthreads Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-09 6:23 ` Tejun Heo
2015-06-09 6:23 ` Tejun Heo
2015-06-09 6:23 ` Tejun Heo
2015-06-15 12:46 ` Petr Mladek
2015-06-15 12:46 ` Petr Mladek
2015-06-15 12:46 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 03/18] kthread: Add kthread_stop_current() Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 04/18] signal: Rename kernel_sigaction() to kthread_sigaction() and clean it up Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 05/18] freezer/scheduler: Add freezable_cond_resched() Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 06/18] signal/kthread: Initial implementation of kthread signal handling Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-06 21:58 ` Oleg Nesterov
2015-06-06 21:58 ` Oleg Nesterov
2015-06-06 21:58 ` Oleg Nesterov
2015-06-08 13:51 ` Petr Mladek
2015-06-08 13:51 ` Petr Mladek
2015-06-08 13:51 ` Petr Mladek
2015-06-08 21:13 ` Oleg Nesterov
2015-06-08 21:13 ` Oleg Nesterov
2015-06-08 21:13 ` Oleg Nesterov
2015-06-15 13:13 ` Petr Mladek
2015-06-15 13:13 ` Petr Mladek
2015-06-15 13:13 ` Petr Mladek
2015-06-15 19:14 ` Oleg Nesterov
2015-06-15 19:14 ` Oleg Nesterov
2015-06-15 19:14 ` Oleg Nesterov
2015-06-16 7:54 ` Petr Mladek
2015-06-16 7:54 ` Petr Mladek
2015-06-16 7:54 ` Petr Mladek
2015-06-09 7:10 ` Tejun Heo
2015-06-09 7:10 ` Tejun Heo
2015-06-09 7:10 ` Tejun Heo
2015-06-09 12:15 ` Jiri Kosina
2015-06-09 12:15 ` Jiri Kosina
2015-06-09 12:15 ` Jiri Kosina
2015-06-10 3:13 ` Tejun Heo
2015-06-10 3:13 ` Tejun Heo
2015-06-10 3:13 ` Tejun Heo
2015-06-05 15:01 ` [RFC PATCH 07/18] kthread: Make iterant kthreads freezable by default Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-09 7:20 ` Tejun Heo
2015-06-09 7:20 ` Tejun Heo
2015-06-09 7:20 ` Tejun Heo
2015-06-09 15:53 ` Petr Mladek
2015-06-09 15:53 ` Petr Mladek
2015-06-09 15:53 ` Petr Mladek
2015-06-10 4:31 ` Tejun Heo
2015-06-10 4:31 ` Tejun Heo
2015-06-10 4:31 ` Tejun Heo
2015-06-12 13:24 ` Petr Mladek
2015-06-12 13:24 ` Petr Mladek
2015-06-12 13:24 ` Petr Mladek
2015-06-13 23:22 ` Tejun Heo
2015-06-13 23:22 ` Tejun Heo
2015-06-13 23:22 ` Tejun Heo
2015-06-15 9:28 ` Petr Mladek
2015-06-15 9:28 ` Petr Mladek
2015-06-15 9:28 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 08/18] kthread: Allow to get struct kthread_iterant from task_struct Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 16:10 ` Peter Zijlstra
2015-06-05 16:10 ` Peter Zijlstra
2015-06-05 16:10 ` Peter Zijlstra
2015-06-08 10:01 ` Petr Mladek
2015-06-08 10:01 ` Petr Mladek
2015-06-08 10:01 ` Petr Mladek
2015-06-08 11:39 ` Peter Zijlstra
2015-06-08 11:39 ` Peter Zijlstra
2015-06-09 15:25 ` Petr Mladek
2015-06-09 15:25 ` Petr Mladek
2015-06-09 15:25 ` Petr Mladek
2015-06-10 9:05 ` Peter Zijlstra
2015-06-10 9:05 ` Peter Zijlstra
2015-06-10 9:05 ` Peter Zijlstra
2015-06-09 7:32 ` Tejun Heo
2015-06-09 7:32 ` Tejun Heo
2015-06-09 7:32 ` Tejun Heo
2015-06-08 17:48 ` Steven Rostedt
2015-06-08 17:48 ` Steven Rostedt
2015-06-08 17:48 ` Steven Rostedt
2015-06-10 9:07 ` Peter Zijlstra
2015-06-10 9:07 ` Peter Zijlstra
2015-06-10 9:07 ` Peter Zijlstra
2015-06-10 14:07 ` Steven Rostedt
2015-06-10 14:07 ` Steven Rostedt
2015-06-11 4:28 ` Jiri Kosina
2015-06-11 4:28 ` Jiri Kosina
2015-06-11 4:28 ` Jiri Kosina
2015-06-05 15:01 ` [RFC PATCH 10/18] jffs2: Remove forward definition of jffs2_garbage_collect_thread() Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 11/18] jffs2: Convert jffs2_gcd_mtd kthread into the iterant API Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-06 21:16 ` Oleg Nesterov
2015-06-06 21:16 ` Oleg Nesterov
2015-06-06 21:16 ` Oleg Nesterov
2015-06-06 21:32 ` Jiri Kosina
2015-06-06 21:32 ` Jiri Kosina
2015-06-06 21:32 ` Jiri Kosina
2015-06-06 22:30 ` Oleg Nesterov
2015-06-06 22:30 ` Oleg Nesterov
2015-06-06 22:30 ` Oleg Nesterov
2015-06-06 22:44 ` Jiri Kosina
2015-06-06 22:44 ` Jiri Kosina
2015-06-06 22:44 ` Jiri Kosina
2015-06-06 22:58 ` Oleg Nesterov [this message]
2015-06-06 22:58 ` Oleg Nesterov
2015-06-06 22:58 ` Oleg Nesterov
2015-06-05 15:01 ` [RFC PATCH 12/18] lockd: Convert the central lockd service to kthread_iterant API Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 13/18] ring_buffer: Use iterant kthreads API in the ring buffer benchmark Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 14/18] ring_buffer: Allow to cleanly freeze the ring buffer benchmark kthreads Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 15/18] ring_buffer: Allow to exit the ring buffer benchmark immediately Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-08 17:44 ` Steven Rostedt
2015-06-08 17:44 ` Steven Rostedt
2015-06-08 17:44 ` Steven Rostedt
2015-06-15 15:23 ` Petr Mladek
2015-06-15 15:23 ` Petr Mladek
2015-06-15 15:23 ` Petr Mladek
2015-06-15 15:23 ` Petr Mladek
2015-06-15 15:33 ` Steven Rostedt
2015-06-15 15:33 ` Steven Rostedt
2015-06-15 15:33 ` Steven Rostedt
2015-06-15 15:54 ` Petr Mladek
2015-06-15 15:54 ` Petr Mladek
2015-06-15 15:54 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 16/18] kthread: Support interruptible sleep with a timeout by iterant kthreads Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 17/18] ring_buffer: Use the new API for a sleep with a timeout in the benchmark Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 15:01 ` [RFC PATCH 18/18] jffs2: Use the new API for a sleep with a timeout Petr Mladek
2015-06-05 15:01 ` Petr Mladek
2015-06-05 16:22 ` [RFC PATCH 00/18] kthreads/signal: Safer kthread API and signal handling Peter Zijlstra
2015-06-05 16:22 ` Peter Zijlstra
2015-06-09 6:14 ` Tejun Heo
2015-06-09 6:14 ` Tejun Heo
2015-06-09 6:14 ` Tejun Heo
2015-06-10 10:40 ` Peter Zijlstra
2015-06-10 10:40 ` Peter Zijlstra
2015-06-10 10:40 ` Peter Zijlstra
2015-06-11 22:02 ` Tejun Heo
2015-06-11 22:02 ` Tejun Heo
2015-06-11 22:02 ` Tejun Heo
2015-06-09 6:10 ` Tejun Heo
2015-06-09 6:10 ` Tejun Heo
2015-06-09 6:10 ` Tejun Heo
2015-06-09 7:58 ` Tejun Heo
2015-06-09 7:58 ` Tejun Heo
2015-06-09 7:58 ` Tejun Heo
2015-06-17 11:34 ` Christoph Hellwig
2015-06-17 11:34 ` Christoph Hellwig
2015-06-17 11:34 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150606225854.GA20352@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=anna.schumaker@netapp.com \
--cc=bp@suse.de \
--cc=clm@fb.com \
--cc=dwmw2@infradead.org \
--cc=jkosina@suse.cz \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nfs@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pmladek@suse.cz \
--cc=richard@nod.at \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trond.myklebust@primarydata.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.