linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Janani Venkataraman <jananive@in.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: amwang@redhat.com, rdunlap@xenotime.net, andi@firstfloor.org,
	aravinda@linux.vnet.ibm.com, hch@lst.de, mhiramat@redhat.com,
	jeremy.fitzhardinge@citrix.com, xemul@parallels.com,
	suzuki@linux.vnet.ibm.com, kosaki.motohiro@jp.fujitsu.com,
	adobriyan@gmail.com, tarundsk@linux.vnet.ibm.com,
	vapier@gentoo.org, roland@hack.frob.com, tj@kernel.org,
	ananth@linux.vnet.ibm.com, gorcunov@openvz.org,
	avagin@openvz.org, oleg@redhat.com, eparis@redhat.com,
	d.hatayama@jp.fujitsu.com, james.hogan@imgtec.com,
	akpm@linux-foundation.org, torvalds@linux-foundation.org
Subject: [PATCH 12/19] Hold the threads using task_work_add
Date: Fri, 04 Oct 2013 16:02:03 +0530	[thread overview]
Message-ID: <20131004103203.1612.49165.stgit@f19-x64> (raw)
In-Reply-To: <20131004102532.1612.24185.stgit@f19-x64>

From:Janani Venkataraman <janani@in.ibm.com>

Hold the threads in a killable state, for collection of register set.
This was implemented in the past using the freezer system. The freezer functions in
kernel essentially help start and stop sets of tasks and this approach
exploited the existing freezer subsystem kernel interface effectively to
quiesce all the threads of the application before triggering the core dump.
This approach was not accepted due to the potential Dos attack. Also the
community discussed that "freeze" is a bit dangerous because an application
which is frozen cannot be ended and while it's frozen and there is no
information "its frozen" via usual user commands as 'ps' or 'top'.

In this method we assign work to the threads of the task, which will make
them wait in a killable state until the operation is complete, using
'completion'. Once the dump is complete we release the threads.

The following are yet to be implemented:

1) A check to ensure all the threads have entered the work that was queued
2) Handling of threads blocked in kernel.These will not reach the work
   queued and hence the dump may be delayed. If the process is in a non
   running state we can probably take the dump as it would not lead to
   inconsistency. We would like to community views on the same.

Signed-off-by: Janani Venkataraman <jananive@in.ibm.com >
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
---
 fs/proc/gencore.c |   42 +++++++++++++++++++++++++++++++++++++++---
 fs/proc/gencore.h |    4 ++++
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/fs/proc/gencore.c b/fs/proc/gencore.c
index 5f56910..d741f18 100644
--- a/fs/proc/gencore.c
+++ b/fs/proc/gencore.c
@@ -20,8 +20,10 @@
  * Authors:
  *      Ananth N.Mavinakayanahalli <ananth@in.ibm.com>
  *      Suzuki K. Poulose <suzuki@in.ibm.com>
+ *      Janani Venkataraman <jananive@in.ibm.com>
  */
 
+#include <linux/task_work.h>
 #include <linux/elf.h>
 #include <linux/seq_file.h>
 #include <linux/slab.h>
@@ -67,22 +69,45 @@ out:
 	return ret;
 }
 
+static void gencore_work(struct callback_head *open_work)
+{
+	/* TODO A method to know when all the threads have reached here */ 
+	struct core_proc *cp = container_of(open_work, struct core_proc, twork);
+	/* If a thread is exiting we could let it go */
+	if (current->flags & PF_EXITING)
+		return;
+	wait_for_completion_killable(&cp->hold);
+}
+ 
 static int release_gencore(struct inode *inode, struct file *file)
 {
 	struct task_struct *task = get_proc_task(file->f_dentry->d_inode);
 	struct core_proc *cp;
+	struct task_struct *t;
 
 	if (!task)
 		return -EIO;
 
 	mutex_lock(&core_mutex);
 	cp = get_core_proc(task);
-	if (cp) {
+	if (cp) 
 		list_del(&cp->list);
-		kfree(cp);
-	}
+	else
+		return -ENOENT;
+	
+	complete_all(&cp->hold);
 	mutex_unlock(&core_mutex);
+	/* Cancelling the work added */
+	t = task;
+	read_lock(&tasklist_lock);
+	do {
+		if (t != current)
+			task_work_cancel(t, gencore_work);
+	} while_each_thread(cp->task, t);
+
+	read_unlock(&tasklist_lock);   
 	put_task_struct(task);
+	kfree(cp);
 	return 0;
 }
 
@@ -117,6 +142,7 @@ static int open_gencore(struct inode *inode, struct file *filp)
 {
 	struct task_struct *task = get_proc_task(inode);
 	struct core_proc *cp;
+	struct task_struct *t;
 	int elf_class;
 	int ret = 0;
 	if (!task)
@@ -145,6 +171,16 @@ static int open_gencore(struct inode *inode, struct file *filp)
 	mutex_lock(&core_mutex);
 	list_add(&cp->list, &core_list);
 	mutex_unlock(&core_mutex);
+	init_completion(&cp->hold);
+	/* Adding the work for all the threads except current */
+	t = cp->task;
+	init_task_work(&cp->twork, gencore_work);
+	read_lock(&tasklist_lock);
+	do {
+		if (t != current)
+			task_work_add(t, &cp->twork, true);
+	} while_each_thread(cp->task, t);
+	read_unlock(&tasklist_lock); 
 
 out:
 	put_task_struct(task);
diff --git a/fs/proc/gencore.h b/fs/proc/gencore.h
index c98fddf..1a88e24 100644
--- a/fs/proc/gencore.h
+++ b/fs/proc/gencore.h
@@ -1,12 +1,16 @@
 #ifndef __GEN_CORE_H
 #define __GEN_CORE_H
 
+#include <linux/types.h>
 #include <linux/list.h>
 #include <linux/sched.h>
+#include <linux/completion.h>
 
 struct core_proc {
 	struct list_head list;
 	struct task_struct *task;
+	struct completion hold;
+	struct callback_head twork;
 };
 
 #endif


  parent reply	other threads:[~2013-10-04 10:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 10:30 [RFC] [PATCH 00/19] Non disruptive application core dump infrastructure using task_work_add() Janani Venkataraman
2013-10-04 10:30 ` [PATCH 01/19] Create elfcore-common.c for ELF class independent core generation helpers Janani Venkataraman
2013-10-04 10:30 ` [PATCH 02/19] Make vma_dump_size() generic Janani Venkataraman
2013-10-08  0:23   ` Ryan Mallon
2013-10-08  3:52     ` Janani Venkataraman1
2013-10-04 10:31 ` [PATCH 03/19] Make fill_psinfo generic Janani Venkataraman
2013-10-04 10:31 ` [PATCH 04/19] Rename compat versions of the reusable core generation routines Janani Venkataraman
2013-10-04 10:31 ` [PATCH 05/19] Export the reusable ELF " Janani Venkataraman
2013-10-04 10:31 ` [PATCH 06/19] Define API for reading arch specif Program Headers for Core Janani Venkataraman
2013-10-04 10:31 ` [PATCH 07/19] ia64 impelementation for elf_core_copy_extra_phdrs() Janani Venkataraman
2013-10-04 10:31 ` [PATCH 08/19] elf_core_copy_extra_phdrs() for UML Janani Venkataraman
2013-10-04 10:31 ` [PATCH 09/19] Create /proc/pid/core entry Janani Venkataraman
2013-10-04 10:31 ` [PATCH 10/19] Track the core generation requests Janani Venkataraman
2013-10-04 10:31 ` [PATCH 11/19] Check if the process is an ELF executable Janani Venkataraman
2013-10-04 10:32 ` Janani Venkataraman [this message]
2013-10-04 10:32 ` [PATCH 13/19] Create ELF Header Janani Venkataraman
2013-10-04 10:32 ` [PATCH 14/19] Create ELF Core notes Data Janani Venkataraman
2013-10-04 10:32 ` [PATCH 15/19] Calculate the size of the core file Janani Venkataraman
2013-10-04 10:32 ` [PATCH 16/19] Generate the data sections for ELF Core Janani Venkataraman
2013-10-04 10:32 ` [PATCH 17/19] Identify the ELF class of the process Janani Venkataraman
2013-10-04 10:33 ` [PATCH 18/19] Adding support for compat ELF class data structures Janani Venkataraman
2013-10-04 10:33 ` [PATCH 19/19] Compat ELF class core generation support Janani Venkataraman
2013-10-04 10:38 ` [RFC] [PATCH 00/19] Non disruptive application core dump infrastructure using task_work_add() Pavel Emelyanov
2013-10-07 18:57   ` Tejun Heo
2013-10-08 10:14     ` Janani Venkataraman1
2013-10-08 10:12   ` Janani Venkataraman1
2013-10-09  8:57     ` Pavel Emelyanov
2013-10-04 13:44 ` Andi Kleen
2013-10-07  6:07   ` Suzuki K. Poulose
2013-10-07 13:58     ` Oleg Nesterov
2013-10-07 18:10     ` Andi Kleen

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=20131004103203.1612.49165.stgit@f19-x64 \
    --to=jananive@in.ibm.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=amwang@redhat.com \
    --cc=ananth@linux.vnet.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=aravinda@linux.vnet.ibm.com \
    --cc=avagin@openvz.org \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=eparis@redhat.com \
    --cc=gorcunov@openvz.org \
    --cc=hch@lst.de \
    --cc=james.hogan@imgtec.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=oleg@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=roland@hack.frob.com \
    --cc=suzuki@linux.vnet.ibm.com \
    --cc=tarundsk@linux.vnet.ibm.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vapier@gentoo.org \
    --cc=xemul@parallels.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).