All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	rjw-KKrjLPT3xs0@public.gmane.org,
	linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: [PATCH UPDATED AGAIN 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
Date: Sat, 10 Dec 2011 00:42:53 +0100	[thread overview]
Message-ID: <20111209234246.GC27173@somewhere> (raw)
In-Reply-To: <20111208205055.GB12108-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

On Thu, Dec 08, 2011 at 12:50:55PM -0800, Tejun Heo wrote:
> (Note for Linus at the bottom)
> 
> threadgroup_lock() protected only protected against new addition to
> the threadgroup, which was inherently somewhat incomplete and
> problematic for its only user cgroup.  On-going migration could race
> against exec and exit leading to interesting problems - the symmetry
> between various attach methods, task exiting during method execution,
> ->exit() racing against attach methods, migrating task switching basic
> properties during exec and so on.
> 
> This patch extends threadgroup_lock() such that it protects against
> all three threadgroup altering operations - fork, exit and exec.  For
> exit, threadgroup_change_begin/end() calls are added to exit_signals
> around assertion of PF_EXITING.  For exec, threadgroup_[un]lock() are
> updated to also grab and release cred_guard_mutex.
> 
> With this change, threadgroup_lock() guarantees that the target
> threadgroup will remain stable - no new task will be added, no new
> PF_EXITING will be set and exec won't happen.
> 
> The next patch will update cgroup so that it can take full advantage
> of this change.
> 
> -v2: beefed up comment as suggested by Frederic.
> 
> -v3: narrowed scope of protection in exit path as suggested by
>      Frederic.
> 
> Signed-off-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> Acked-by: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>
> Cc: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
> ---
> Okay, narrowed exit path protection down to setting of PF_EXITING
> itself.  ->exit() on dangling tasks is a bit weird but I don't think
> it's too bad.  Frederic, are you okay with this version?

Yeah that new scheme that only protects PF_EXITING may look a bit
strange. But I think we are fine. With rcu list traversal, it should
be safe even if a group member is concurrently dropped from the list (in that
case all we check if its PF_EXITING then we give up). And we may
have a concurrent ->exit() but that should be fine too.

Thanks!

Acked-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

> 
> Linus, if Frederic is okay with it, I'm gonna rebase the series on top
> of freezer changes in pm tree to avoid conflicts in cgroup_freezer,
> which sits between cgroup and freezer, both of which are going through
> non-trivial changes, push the branch to linux-next and put pending
> cgroup patches on top.  Please scream if you're mighty unhappy with it
> or have a better idea.
> 
> Thank you.

WARNING: multiple messages have this Message-ID (diff)
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	paul@paulmenage.org, rjw@sisk.pl, lizf@cn.fujitsu.com,
	linux-pm@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	containers@lists.linux-foundation.org, matthltc@us.ibm.com,
	akpm@linux-foundation.org, oleg@redhat.com,
	kamezawa.hiroyu@Jp.fujitsu.com
Subject: Re: [PATCH UPDATED AGAIN 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
Date: Sat, 10 Dec 2011 00:42:53 +0100	[thread overview]
Message-ID: <20111209234246.GC27173@somewhere> (raw)
In-Reply-To: <20111208205055.GB12108@google.com>

On Thu, Dec 08, 2011 at 12:50:55PM -0800, Tejun Heo wrote:
> (Note for Linus at the bottom)
> 
> threadgroup_lock() protected only protected against new addition to
> the threadgroup, which was inherently somewhat incomplete and
> problematic for its only user cgroup.  On-going migration could race
> against exec and exit leading to interesting problems - the symmetry
> between various attach methods, task exiting during method execution,
> ->exit() racing against attach methods, migrating task switching basic
> properties during exec and so on.
> 
> This patch extends threadgroup_lock() such that it protects against
> all three threadgroup altering operations - fork, exit and exec.  For
> exit, threadgroup_change_begin/end() calls are added to exit_signals
> around assertion of PF_EXITING.  For exec, threadgroup_[un]lock() are
> updated to also grab and release cred_guard_mutex.
> 
> With this change, threadgroup_lock() guarantees that the target
> threadgroup will remain stable - no new task will be added, no new
> PF_EXITING will be set and exec won't happen.
> 
> The next patch will update cgroup so that it can take full advantage
> of this change.
> 
> -v2: beefed up comment as suggested by Frederic.
> 
> -v3: narrowed scope of protection in exit path as suggested by
>      Frederic.
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Acked-by: Li Zefan <lizf@cn.fujitsu.com>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Paul Menage <paul@paulmenage.org>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> ---
> Okay, narrowed exit path protection down to setting of PF_EXITING
> itself.  ->exit() on dangling tasks is a bit weird but I don't think
> it's too bad.  Frederic, are you okay with this version?

Yeah that new scheme that only protects PF_EXITING may look a bit
strange. But I think we are fine. With rcu list traversal, it should
be safe even if a group member is concurrently dropped from the list (in that
case all we check if its PF_EXITING then we give up). And we may
have a concurrent ->exit() but that should be fine too.

Thanks!

Acked-by: Frederic Weisbecker <fweisbec@gmail.com>

> 
> Linus, if Frederic is okay with it, I'm gonna rebase the series on top
> of freezer changes in pm tree to avoid conflicts in cgroup_freezer,
> which sits between cgroup and freezer, both of which are going through
> non-trivial changes, push the branch to linux-next and put pending
> cgroup patches on top.  Please scream if you're mighty unhappy with it
> or have a better idea.
> 
> Thank you.

  parent reply	other threads:[~2011-12-09 23:42 UTC|newest]

Thread overview: 167+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-01 23:46 [PATCHSET] cgroup: stable threadgroup during attach & subsys methods consolidation Tejun Heo
2011-11-01 23:46 ` Tejun Heo
2011-11-01 23:46 ` [PATCH 01/10] cgroup: add cgroup_root_mutex Tejun Heo
2011-11-01 23:46   ` Tejun Heo
     [not found]   ` <1320191193-8110-2-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  8:38     ` KAMEZAWA Hiroyuki
2011-11-04  8:38   ` KAMEZAWA Hiroyuki
2011-11-04  8:38   ` KAMEZAWA Hiroyuki
2011-11-01 23:46 ` [PATCH 02/10] threadgroup: rename signal->threadgroup_fork_lock to ->group_rwsem Tejun Heo
2011-11-01 23:46 ` [PATCH 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec Tejun Heo
2011-11-01 23:46 ` Tejun Heo
2011-11-04  8:45   ` KAMEZAWA Hiroyuki
2011-11-04  8:45   ` KAMEZAWA Hiroyuki
2011-11-13 16:44   ` Frederic Weisbecker
2011-11-13 18:20   ` Frederic Weisbecker
2011-11-13 18:20     ` Frederic Weisbecker
     [not found]   ` <1320191193-8110-4-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  8:45     ` KAMEZAWA Hiroyuki
2011-11-13 16:44     ` Frederic Weisbecker
2011-11-13 16:44       ` Frederic Weisbecker
2011-11-14 13:54       ` Frederic Weisbecker
2011-11-14 13:54         ` Frederic Weisbecker
2011-11-21 22:03         ` Tejun Heo
2011-11-21 22:03         ` Tejun Heo
2011-11-21 22:03           ` Tejun Heo
2011-11-23 14:34           ` Frederic Weisbecker
     [not found]           ` <20111121220326.GM25776-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-11-23 14:34             ` Frederic Weisbecker
2011-11-23 14:34               ` Frederic Weisbecker
2011-11-14 13:54       ` Frederic Weisbecker
2011-11-21 21:58       ` Tejun Heo
2011-11-21 21:58         ` Tejun Heo
2011-11-23 14:02         ` Frederic Weisbecker
     [not found]         ` <20111121215839.GL25776-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-11-23 14:02           ` Frederic Weisbecker
2011-11-23 14:02             ` Frederic Weisbecker
     [not found]             ` <20111123140139.GB10669-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
2011-11-24 21:22               ` Tejun Heo
2011-11-24 21:22             ` Tejun Heo
2011-11-24 21:22               ` Tejun Heo
2011-11-21 21:58       ` Tejun Heo
2011-11-13 18:20     ` Frederic Weisbecker
2011-11-24 22:50     ` [PATCH UPDATED " Tejun Heo
2011-11-24 22:50   ` Tejun Heo
2011-11-24 22:50     ` Tejun Heo
2011-11-25  4:02     ` Linus Torvalds
2011-11-25  4:02       ` Linus Torvalds
     [not found]       ` <CA+55aFxq1wztMzYhKaY5RHazLBDz4pSXUgiGzTj2wA6EJcDbAw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-11-27 19:21         ` Tejun Heo
2011-11-27 19:21           ` Tejun Heo
     [not found]           ` <20111127192155.GB4266-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-11-27 21:25             ` Tejun Heo
2011-11-27 21:25               ` Tejun Heo
2011-12-01 19:29               ` Tejun Heo
2011-12-01 19:29                 ` Tejun Heo
     [not found]               ` <20111127212558.GE4266-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-01 19:29                 ` Tejun Heo
2011-11-27 21:25           ` Tejun Heo
2011-11-27 19:21       ` Tejun Heo
2011-11-25 14:01     ` Frederic Weisbecker
2011-11-25 14:01       ` Frederic Weisbecker
     [not found]       ` <20111125140136.GC23307-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
2011-11-27 19:30         ` Tejun Heo
2011-11-27 19:30           ` Tejun Heo
     [not found]           ` <20111127193001.GC4266-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-02 16:28             ` Frederic Weisbecker
2011-12-02 16:28           ` Frederic Weisbecker
2011-12-02 16:28             ` Frederic Weisbecker
     [not found]             ` <20111202162753.GA19752-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
2011-12-05 18:43               ` Tejun Heo
2011-12-05 18:43                 ` Tejun Heo
     [not found]                 ` <20111205184315.GJ627-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-07 15:30                   ` Frederic Weisbecker
2011-12-07 15:30                 ` Frederic Weisbecker
2011-12-07 15:30                   ` Frederic Weisbecker
     [not found]                   ` <20111207153046.GC13252-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org>
2011-12-07 18:22                     ` Tejun Heo
2011-12-07 18:22                   ` Tejun Heo
2011-12-07 18:22                     ` Tejun Heo
     [not found]                     ` <20111207182214.GA7610-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-08 20:50                       ` [PATCH UPDATED AGAIN " Tejun Heo
2011-12-08 20:50                     ` Tejun Heo
2011-12-08 20:50                       ` Tejun Heo
2011-12-09 23:42                       ` Frederic Weisbecker
     [not found]                       ` <20111208205055.GB12108-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-09 23:42                         ` Frederic Weisbecker [this message]
2011-12-09 23:42                           ` Frederic Weisbecker
2011-12-13  1:33                           ` Tejun Heo
2011-12-13  2:17                             ` Tejun Heo
     [not found]                             ` <20111213013334.GC25802-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-12-13  2:17                               ` Tejun Heo
2011-12-13  2:17                                 ` Tejun Heo
2011-12-13  1:33                           ` Tejun Heo
2011-12-13  1:33                           ` Tejun Heo
2011-12-05 18:43             ` [PATCH UPDATED " Tejun Heo
2011-11-27 19:30       ` Tejun Heo
     [not found]     ` <20111124225054.GA14828-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-11-25  4:02       ` Linus Torvalds
2011-11-25 14:01       ` Frederic Weisbecker
     [not found] ` <1320191193-8110-1-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-01 23:46   ` [PATCH 01/10] cgroup: add cgroup_root_mutex Tejun Heo
2011-11-01 23:46   ` [PATCH 02/10] threadgroup: rename signal->threadgroup_fork_lock to ->group_rwsem Tejun Heo
2011-11-01 23:46     ` Tejun Heo
2011-11-04  8:40     ` KAMEZAWA Hiroyuki
     [not found]     ` <1320191193-8110-3-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  8:40       ` KAMEZAWA Hiroyuki
2011-11-04  8:40     ` KAMEZAWA Hiroyuki
2011-11-04 15:16       ` Tejun Heo
2011-11-04 15:16         ` Tejun Heo
     [not found]       ` <20111104174032.e0c4fc11.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-11-04 15:16         ` Tejun Heo
2011-11-01 23:46   ` [PATCH 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec Tejun Heo
2011-11-01 23:46   ` [PATCH 04/10] cgroup: always lock threadgroup during migration Tejun Heo
2011-11-01 23:46   ` [PATCH 05/10] cgroup: subsys->attach_task() should be called after migration Tejun Heo
2011-11-01 23:46   ` [PATCH 06/10] cgroup: improve old cgroup handling in cgroup_attach_proc() Tejun Heo
2011-11-01 23:46     ` Tejun Heo
     [not found]     ` <1320191193-8110-7-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-14 20:37       ` Frederic Weisbecker
2011-11-14 20:37         ` Frederic Weisbecker
2011-11-14 20:37     ` Frederic Weisbecker
2011-11-01 23:46   ` [PATCH 07/10] cgroup: introduce cgroup_taskset and use it in subsys->can_attach(), cancel_attach() and attach() Tejun Heo
2011-11-01 23:46     ` Tejun Heo
     [not found]     ` <1320191193-8110-8-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-14 21:16       ` Frederic Weisbecker
2011-11-14 21:16         ` Frederic Weisbecker
2011-11-14 21:16     ` Frederic Weisbecker
2011-11-01 23:46   ` [PATCH 08/10] cgroup: don't use subsys->can_attach_task() or ->attach_task() Tejun Heo
2011-11-01 23:46   ` [PATCH 09/10] cgroup, cpuset: don't use ss->pre_attach() Tejun Heo
2011-11-01 23:46     ` Tejun Heo
     [not found]     ` <1320191193-8110-10-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-15  0:51       ` Frederic Weisbecker
2011-11-15  0:51         ` Frederic Weisbecker
2011-11-15  0:51     ` Frederic Weisbecker
2011-11-01 23:46   ` [PATCH 10/10] cgroup: kill subsys->can_attach_task(), pre_attach() and attach_task() Tejun Heo
2011-11-01 23:46     ` Tejun Heo
2011-11-04  9:10     ` KAMEZAWA Hiroyuki
2011-11-04  9:10     ` KAMEZAWA Hiroyuki
2011-11-15  0:54     ` Frederic Weisbecker
     [not found]     ` <1320191193-8110-11-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  9:10       ` KAMEZAWA Hiroyuki
2011-11-15  0:54       ` Frederic Weisbecker
2011-11-15  0:54         ` Frederic Weisbecker
2011-11-21 22:07   ` [PATCHSET] cgroup: stable threadgroup during attach & subsys methods consolidation Tejun Heo
2011-11-21 22:07     ` Tejun Heo
     [not found]     ` <20111121220719.GP25776-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2011-11-22  2:27       ` Li Zefan
2011-11-22  2:27         ` Li Zefan
     [not found]         ` <4ECB089C.3080208-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2011-11-22 16:20           ` Tejun Heo
2011-11-22 16:20             ` Tejun Heo
2011-11-22 16:20         ` Tejun Heo
2011-11-22  2:27     ` Li Zefan
2011-11-24 22:51   ` Tejun Heo
2011-11-01 23:46 ` [PATCH 04/10] cgroup: always lock threadgroup during migration Tejun Heo
2011-11-01 23:46   ` Tejun Heo
2011-11-04  8:54   ` KAMEZAWA Hiroyuki
2011-11-04  8:54   ` KAMEZAWA Hiroyuki
     [not found]     ` <20111104175413.30afaf8e.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2011-11-04 15:21       ` Tejun Heo
2011-11-04 15:21         ` Tejun Heo
2011-11-04 15:21     ` Tejun Heo
2011-11-14 18:46   ` Frederic Weisbecker
     [not found]   ` <1320191193-8110-5-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  8:54     ` KAMEZAWA Hiroyuki
2011-11-14 18:46     ` Frederic Weisbecker
2011-11-14 18:46       ` Frederic Weisbecker
2011-11-14 18:52       ` Frederic Weisbecker
2011-11-14 18:52       ` Frederic Weisbecker
2011-11-14 18:52         ` Frederic Weisbecker
2011-11-21 22:05         ` Tejun Heo
2011-11-21 22:05         ` Tejun Heo
2011-11-21 22:05           ` Tejun Heo
2011-11-01 23:46 ` [PATCH 05/10] cgroup: subsys->attach_task() should be called after migration Tejun Heo
2011-11-14 20:06   ` Frederic Weisbecker
2011-11-14 20:06     ` Frederic Weisbecker
2011-11-21 22:04     ` Tejun Heo
2011-11-21 22:04     ` Tejun Heo
2011-11-21 22:04       ` Tejun Heo
     [not found]   ` <1320191193-8110-6-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-14 20:06     ` Frederic Weisbecker
2011-11-01 23:46 ` Tejun Heo
2011-11-01 23:46 ` [PATCH 06/10] cgroup: improve old cgroup handling in cgroup_attach_proc() Tejun Heo
2011-11-01 23:46 ` [PATCH 07/10] cgroup: introduce cgroup_taskset and use it in subsys->can_attach(), cancel_attach() and attach() Tejun Heo
2011-11-01 23:46 ` [PATCH 08/10] cgroup: don't use subsys->can_attach_task() or ->attach_task() Tejun Heo
2011-11-01 23:46   ` Tejun Heo
2011-11-04  9:08   ` KAMEZAWA Hiroyuki
2011-11-04  9:08   ` KAMEZAWA Hiroyuki
2011-11-14 23:54   ` Frederic Weisbecker
     [not found]   ` <1320191193-8110-9-git-send-email-tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2011-11-04  9:08     ` KAMEZAWA Hiroyuki
2011-11-14 23:54     ` Frederic Weisbecker
2011-11-14 23:54       ` Frederic Weisbecker
2011-11-01 23:46 ` [PATCH 09/10] cgroup, cpuset: don't use ss->pre_attach() Tejun Heo
2011-11-01 23:46 ` [PATCH 10/10] cgroup: kill subsys->can_attach_task(), pre_attach() and attach_task() Tejun Heo
2011-11-21 22:07 ` [PATCHSET] cgroup: stable threadgroup during attach & subsys methods consolidation Tejun Heo
2011-11-24 22:51 ` Tejun Heo
2011-11-24 22:51   ` Tejun Heo

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=20111209234246.GC27173@somewhere \
    --to=fweisbec-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-pm-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org \
    --cc=rjw-KKrjLPT3xs0@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    /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.