All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>, <akpm@linux-foundation.org>
Cc: <penguin-kernel@I-love.SAKURA.ne.jp>,
	<linux-kernel@vger.kernel.org>, <mhocko@kernel.org>,
	<linux-mm@kvack.org>, <hpa@zytor.com>, <chris@chris-wilson.co.uk>,
	<hch@lst.de>, <mingo@elte.hu>, <jszhang@marvell.com>,
	<joelaf@google.com>, <joaodias@google.com>, <willy@infradead.org>,
	<tglx@linutronix.de>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context
Date: Thu, 30 Mar 2017 14:00:48 +0200	[thread overview]
Message-ID: <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> (raw)
In-Reply-To: <20170330102719.13119-1-aryabinin@virtuozzo.com>

On 03/30/2017 12:27 PM, Andrey Ryabinin wrote:
> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem
> as potentially sleeping") added might_sleep() to remove_vm_area() from
> vfree(), and commit 763b218ddfaf ("mm: add preempt points into
> __purge_vmap_area_lazy()") actually made vfree() potentially sleeping.
>
> This broke vmwgfx driver which calls vfree() under spin_lock().
>
>     BUG: sleeping function called from invalid context at mm/vmalloc.c:1480
>     in_atomic(): 1, irqs_disabled(): 0, pid: 341, name: plymouthd
>     2 locks held by plymouthd/341:
>      #0:  (drm_global_mutex){+.+.+.}, at: [<ffffffffc01c274b>] drm_release+0x3b/0x3b0 [drm]
>      #1:  (&(&tfile->lock)->rlock){+.+...}, at: [<ffffffffc0173038>] ttm_object_file_release+0x28/0x90 [ttm]
>
>     Call Trace:
>      dump_stack+0x86/0xc3
>      ___might_sleep+0x17d/0x250
>      __might_sleep+0x4a/0x80
>      remove_vm_area+0x22/0x90
>      __vunmap+0x2e/0x110
>      vfree+0x42/0x90
>      kvfree+0x2c/0x40
>      drm_ht_remove+0x1a/0x30 [drm]
>      ttm_object_file_release+0x50/0x90 [ttm]
>      vmw_postclose+0x47/0x60 [vmwgfx]
>      drm_release+0x290/0x3b0 [drm]
>      __fput+0xf8/0x210
>      ____fput+0xe/0x10
>      task_work_run+0x85/0xc0
>      exit_to_usermode_loop+0xb4/0xc0
>      do_syscall_64+0x185/0x1f0
>      entry_SYSCALL64_slow_path+0x25/0x25
>
> This can be fixed in vmgfx, but it would be better to make vfree()
> non-sleeping again because we may have other bugs like this one.
>
> __purge_vmap_area_lazy() is the only function in the vfree() path that
> wants to be able to sleep. So it make sense to schedule
> __purge_vmap_area_lazy() via schedule_work() so it runs only in sleepable
> context. This will have a minimal effect on the regular vfree() path.
> since __purge_vmap_area_lazy() is rarely called.
>
> Fixes: 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem as
>                       potentially sleeping")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org>
>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> ---
>  mm/vmalloc.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 68eb002..ea1b4ab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -701,7 +701,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>   * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
>   * is already purging.
>   */
> -static void try_purge_vmap_area_lazy(void)
> +static void try_purge_vmap_area_lazy(struct work_struct *work)
>  {
>  	if (mutex_trylock(&vmap_purge_lock)) {
>  		__purge_vmap_area_lazy(ULONG_MAX, 0);
> @@ -720,6 +720,8 @@ static void purge_vmap_area_lazy(void)
>  	mutex_unlock(&vmap_purge_lock);
>  }
>  
> +static DECLARE_WORK(purge_vmap_work, try_purge_vmap_area_lazy);
> +
>  /*
>   * Free a vmap area, caller ensuring that the area has been unmapped
>   * and flush_cache_vunmap had been called for the correct range
> @@ -736,7 +738,7 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>  	llist_add(&va->purge_list, &vmap_purge_list);
>  
>  	if (unlikely(nr_lazy > lazy_max_pages()))
> -		try_purge_vmap_area_lazy();

Perhaps a slight optimization would be to schedule work iff
!mutex_locked(&vmap_purge_lock) below?

/Thomas


> +		schedule_work(&purge_vmap_work);
>  }
>  
>  /*
> @@ -1125,7 +1127,6 @@ void vm_unmap_ram(const void *mem, unsigned int count)
>  	unsigned long addr = (unsigned long)mem;
>  	struct vmap_area *va;
>  
> -	might_sleep();
>  	BUG_ON(!addr);
>  	BUG_ON(addr < VMALLOC_START);
>  	BUG_ON(addr > VMALLOC_END);
> @@ -1477,8 +1478,6 @@ struct vm_struct *remove_vm_area(const void *addr)
>  {
>  	struct vmap_area *va;
>  
> -	might_sleep();
> -
>  	va = find_vmap_area((unsigned long)addr);
>  	if (va && va->flags & VM_VM_AREA) {
>  		struct vm_struct *vm = va->vm;

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>, <akpm@linux-foundation.org>
Cc: <penguin-kernel@I-love.SAKURA.ne.jp>,
	<linux-kernel@vger.kernel.org>, <mhocko@kernel.org>,
	<linux-mm@kvack.org>, <hpa@zytor.com>, <chris@chris-wilson.co.uk>,
	<hch@lst.de>, <mingo@elte.hu>, <jszhang@marvell.com>,
	<joelaf@google.com>, <joaodias@google.com>, <willy@infradead.org>,
	<tglx@linutronix.de>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context
Date: Thu, 30 Mar 2017 14:00:48 +0200	[thread overview]
Message-ID: <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> (raw)
In-Reply-To: <20170330102719.13119-1-aryabinin@virtuozzo.com>

On 03/30/2017 12:27 PM, Andrey Ryabinin wrote:
> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem
> as potentially sleeping") added might_sleep() to remove_vm_area() from
> vfree(), and commit 763b218ddfaf ("mm: add preempt points into
> __purge_vmap_area_lazy()") actually made vfree() potentially sleeping.
>
> This broke vmwgfx driver which calls vfree() under spin_lock().
>
>     BUG: sleeping function called from invalid context at mm/vmalloc.c:1480
>     in_atomic(): 1, irqs_disabled(): 0, pid: 341, name: plymouthd
>     2 locks held by plymouthd/341:
>      #0:  (drm_global_mutex){+.+.+.}, at: [<ffffffffc01c274b>] drm_release+0x3b/0x3b0 [drm]
>      #1:  (&(&tfile->lock)->rlock){+.+...}, at: [<ffffffffc0173038>] ttm_object_file_release+0x28/0x90 [ttm]
>
>     Call Trace:
>      dump_stack+0x86/0xc3
>      ___might_sleep+0x17d/0x250
>      __might_sleep+0x4a/0x80
>      remove_vm_area+0x22/0x90
>      __vunmap+0x2e/0x110
>      vfree+0x42/0x90
>      kvfree+0x2c/0x40
>      drm_ht_remove+0x1a/0x30 [drm]
>      ttm_object_file_release+0x50/0x90 [ttm]
>      vmw_postclose+0x47/0x60 [vmwgfx]
>      drm_release+0x290/0x3b0 [drm]
>      __fput+0xf8/0x210
>      ____fput+0xe/0x10
>      task_work_run+0x85/0xc0
>      exit_to_usermode_loop+0xb4/0xc0
>      do_syscall_64+0x185/0x1f0
>      entry_SYSCALL64_slow_path+0x25/0x25
>
> This can be fixed in vmgfx, but it would be better to make vfree()
> non-sleeping again because we may have other bugs like this one.
>
> __purge_vmap_area_lazy() is the only function in the vfree() path that
> wants to be able to sleep. So it make sense to schedule
> __purge_vmap_area_lazy() via schedule_work() so it runs only in sleepable
> context. This will have a minimal effect on the regular vfree() path.
> since __purge_vmap_area_lazy() is rarely called.
>
> Fixes: 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem as
>                       potentially sleeping")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org>
>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> ---
>  mm/vmalloc.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 68eb002..ea1b4ab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -701,7 +701,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>   * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
>   * is already purging.
>   */
> -static void try_purge_vmap_area_lazy(void)
> +static void try_purge_vmap_area_lazy(struct work_struct *work)
>  {
>  	if (mutex_trylock(&vmap_purge_lock)) {
>  		__purge_vmap_area_lazy(ULONG_MAX, 0);
> @@ -720,6 +720,8 @@ static void purge_vmap_area_lazy(void)
>  	mutex_unlock(&vmap_purge_lock);
>  }
>  
> +static DECLARE_WORK(purge_vmap_work, try_purge_vmap_area_lazy);
> +
>  /*
>   * Free a vmap area, caller ensuring that the area has been unmapped
>   * and flush_cache_vunmap had been called for the correct range
> @@ -736,7 +738,7 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>  	llist_add(&va->purge_list, &vmap_purge_list);
>  
>  	if (unlikely(nr_lazy > lazy_max_pages()))
> -		try_purge_vmap_area_lazy();

Perhaps a slight optimization would be to schedule work iff
!mutex_locked(&vmap_purge_lock) below?

/Thomas


> +		schedule_work(&purge_vmap_work);
>  }
>  
>  /*
> @@ -1125,7 +1127,6 @@ void vm_unmap_ram(const void *mem, unsigned int count)
>  	unsigned long addr = (unsigned long)mem;
>  	struct vmap_area *va;
>  
> -	might_sleep();
>  	BUG_ON(!addr);
>  	BUG_ON(addr < VMALLOC_START);
>  	BUG_ON(addr > VMALLOC_END);
> @@ -1477,8 +1478,6 @@ struct vm_struct *remove_vm_area(const void *addr)
>  {
>  	struct vmap_area *va;
>  
> -	might_sleep();
> -
>  	va = find_vmap_area((unsigned long)addr);
>  	if (va && va->flags & VM_VM_AREA) {
>  		struct vm_struct *vm = va->vm;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Hellstrom <thellstrom@vmware.com>
To: Andrey Ryabinin <aryabinin@virtuozzo.com>, akpm@linux-foundation.org
Cc: penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org,
	mhocko@kernel.org, linux-mm@kvack.org, hpa@zytor.com,
	chris@chris-wilson.co.uk, hch@lst.de, mingo@elte.hu,
	jszhang@marvell.com, joelaf@google.com, joaodias@google.com,
	willy@infradead.org, tglx@linutronix.de, stable@vger.kernel.org
Subject: Re: [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context
Date: Thu, 30 Mar 2017 14:00:48 +0200	[thread overview]
Message-ID: <2cfc601e-3093-143e-b93d-402f330a748a@vmware.com> (raw)
In-Reply-To: <20170330102719.13119-1-aryabinin@virtuozzo.com>

On 03/30/2017 12:27 PM, Andrey Ryabinin wrote:
> Commit 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem
> as potentially sleeping") added might_sleep() to remove_vm_area() from
> vfree(), and commit 763b218ddfaf ("mm: add preempt points into
> __purge_vmap_area_lazy()") actually made vfree() potentially sleeping.
>
> This broke vmwgfx driver which calls vfree() under spin_lock().
>
>     BUG: sleeping function called from invalid context at mm/vmalloc.c:1480
>     in_atomic(): 1, irqs_disabled(): 0, pid: 341, name: plymouthd
>     2 locks held by plymouthd/341:
>      #0:  (drm_global_mutex){+.+.+.}, at: [<ffffffffc01c274b>] drm_release+0x3b/0x3b0 [drm]
>      #1:  (&(&tfile->lock)->rlock){+.+...}, at: [<ffffffffc0173038>] ttm_object_file_release+0x28/0x90 [ttm]
>
>     Call Trace:
>      dump_stack+0x86/0xc3
>      ___might_sleep+0x17d/0x250
>      __might_sleep+0x4a/0x80
>      remove_vm_area+0x22/0x90
>      __vunmap+0x2e/0x110
>      vfree+0x42/0x90
>      kvfree+0x2c/0x40
>      drm_ht_remove+0x1a/0x30 [drm]
>      ttm_object_file_release+0x50/0x90 [ttm]
>      vmw_postclose+0x47/0x60 [vmwgfx]
>      drm_release+0x290/0x3b0 [drm]
>      __fput+0xf8/0x210
>      ____fput+0xe/0x10
>      task_work_run+0x85/0xc0
>      exit_to_usermode_loop+0xb4/0xc0
>      do_syscall_64+0x185/0x1f0
>      entry_SYSCALL64_slow_path+0x25/0x25
>
> This can be fixed in vmgfx, but it would be better to make vfree()
> non-sleeping again because we may have other bugs like this one.
>
> __purge_vmap_area_lazy() is the only function in the vfree() path that
> wants to be able to sleep. So it make sense to schedule
> __purge_vmap_area_lazy() via schedule_work() so it runs only in sleepable
> context. This will have a minimal effect on the regular vfree() path.
> since __purge_vmap_area_lazy() is rarely called.
>
> Fixes: 5803ed292e63 ("mm: mark all calls into the vmalloc subsystem as
>                       potentially sleeping")
> Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: <stable@vger.kernel.org>
>
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> ---
>  mm/vmalloc.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 68eb002..ea1b4ab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -701,7 +701,7 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>   * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
>   * is already purging.
>   */
> -static void try_purge_vmap_area_lazy(void)
> +static void try_purge_vmap_area_lazy(struct work_struct *work)
>  {
>  	if (mutex_trylock(&vmap_purge_lock)) {
>  		__purge_vmap_area_lazy(ULONG_MAX, 0);
> @@ -720,6 +720,8 @@ static void purge_vmap_area_lazy(void)
>  	mutex_unlock(&vmap_purge_lock);
>  }
>  
> +static DECLARE_WORK(purge_vmap_work, try_purge_vmap_area_lazy);
> +
>  /*
>   * Free a vmap area, caller ensuring that the area has been unmapped
>   * and flush_cache_vunmap had been called for the correct range
> @@ -736,7 +738,7 @@ static void free_vmap_area_noflush(struct vmap_area *va)
>  	llist_add(&va->purge_list, &vmap_purge_list);
>  
>  	if (unlikely(nr_lazy > lazy_max_pages()))
> -		try_purge_vmap_area_lazy();

Perhaps a slight optimization would be to schedule work iff
!mutex_locked(&vmap_purge_lock) below?

/Thomas


> +		schedule_work(&purge_vmap_work);
>  }
>  
>  /*
> @@ -1125,7 +1127,6 @@ void vm_unmap_ram(const void *mem, unsigned int count)
>  	unsigned long addr = (unsigned long)mem;
>  	struct vmap_area *va;
>  
> -	might_sleep();
>  	BUG_ON(!addr);
>  	BUG_ON(addr < VMALLOC_START);
>  	BUG_ON(addr > VMALLOC_END);
> @@ -1477,8 +1478,6 @@ struct vm_struct *remove_vm_area(const void *addr)
>  {
>  	struct vmap_area *va;
>  
> -	might_sleep();
> -
>  	va = find_vmap_area((unsigned long)addr);
>  	if (va && va->flags & VM_VM_AREA) {
>  		struct vm_struct *vm = va->vm;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-03-30 12:01 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 10:27 [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context Andrey Ryabinin
2017-03-30 10:27 ` Andrey Ryabinin
2017-03-30 10:27 ` Andrey Ryabinin
2017-03-30 10:27 ` [PATCH 2/4] x86/ldt: use vfree() instead of vfree_atomic() Andrey Ryabinin
2017-03-30 10:27   ` Andrey Ryabinin
2017-03-31  8:05   ` Thomas Gleixner
2017-03-31  8:05     ` Thomas Gleixner
2017-03-30 10:27 ` [PATCH 3/4] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack Andrey Ryabinin
2017-03-30 10:27   ` Andrey Ryabinin
2017-03-30 10:27 ` [PATCH 4/4] mm/vmalloc: remove vfree_atomic() Andrey Ryabinin
2017-03-30 10:27   ` Andrey Ryabinin
2017-03-30 17:18   ` Matthew Wilcox
2017-03-30 17:18     ` Matthew Wilcox
2017-03-30 15:27     ` Andrey Ryabinin
2017-03-30 15:27       ` Andrey Ryabinin
2017-04-04  9:40   ` Michal Hocko
2017-04-04  9:40     ` Michal Hocko
2017-03-30 12:00 ` Thomas Hellstrom [this message]
2017-03-30 12:00   ` [PATCH 1/4] mm/vmalloc: allow to call vfree() in atomic context Thomas Hellstrom
2017-03-30 12:00   ` Thomas Hellstrom
2017-03-30 14:48   ` Andrey Ryabinin
2017-03-30 14:48     ` Andrey Ryabinin
2017-03-30 14:48     ` Andrey Ryabinin
2017-03-30 15:04     ` Thomas Hellstrom
2017-03-30 15:04       ` Thomas Hellstrom
2017-03-30 15:04       ` Thomas Hellstrom
2017-04-04  9:41     ` Michal Hocko
2017-04-04  9:41       ` Michal Hocko
2017-04-04  9:49       ` Thomas Hellstrom
2017-04-04  9:49         ` Thomas Hellstrom
2017-04-04  9:49         ` Thomas Hellstrom
2017-04-05 10:31       ` Andrey Ryabinin
2017-04-05 10:31         ` Andrey Ryabinin
2017-04-05 10:31         ` Andrey Ryabinin
2017-04-05 10:42         ` Michal Hocko
2017-04-05 10:42           ` Michal Hocko
2017-04-05 11:42     ` Vlastimil Babka
2017-04-05 11:42       ` Vlastimil Babka
2017-04-05 12:14       ` Michal Hocko
2017-04-05 12:14         ` Michal Hocko
2017-03-30 22:22 ` Andrew Morton
2017-03-30 22:22   ` Andrew Morton
2017-03-30 22:22   ` Andrew Morton
2017-03-31  7:12   ` Joel Fernandes
2017-03-31  7:12     ` Joel Fernandes
2017-03-31  9:26   ` Andrey Ryabinin
2017-03-31  9:26     ` Andrey Ryabinin
2017-03-31  9:26     ` Andrey Ryabinin
2017-04-04  9:36   ` Michal Hocko
2017-04-04  9:36     ` Michal Hocko
2017-04-04  9:38 ` Michal Hocko
2017-04-04  9:38   ` Michal Hocko
2017-04-12 12:49 ` [PATCH v2 0/5] " Andrey Ryabinin
2017-04-12 12:49   ` Andrey Ryabinin
2017-04-12 12:49   ` [PATCH v2 1/5] mm/vmalloc: " Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin
2017-04-12 12:49   ` [PATCH v2 2/5] x86/ldt: use vfree() instead of vfree_atomic() Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin
2017-04-12 12:49   ` [PATCH v2 3/5] kernel/fork: use vfree() instead of vfree_atomic() to free thread stack Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin
2017-04-12 12:49   ` [PATCH v2 4/5] mm/vmalloc: remove vfree_atomic() Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin
2017-04-12 12:49   ` [PATCH v2 5/5] mm/vmalloc: Don't spawn workers if somebody already purging Andrey Ryabinin
2017-04-12 12:49     ` Andrey Ryabinin

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=2cfc601e-3093-143e-b93d-402f330a748a@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=hch@lst.de \
    --cc=hpa@zytor.com \
    --cc=joaodias@google.com \
    --cc=joelaf@google.com \
    --cc=jszhang@marvell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@elte.hu \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.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.