linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paolo 'Blaisorblade' Giarrusso" <blaisorblade@yahoo.it>
To: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Cc: Jeff Dike <jdike@addtoit.com>,
	user-mode-linux-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: [PATCH 01/10] uml: don't remove umid files in conflict case
Date: Wed, 21 Sep 2005 19:27:38 +0200	[thread overview]
Message-ID: <20050921172737.10219.71614.stgit@zion.home.lan> (raw)
In-Reply-To: <200509211923.21861.blaisorblade@yahoo.it>

From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

Only remove the UML pidfile and management socket if we created them.
Currently in case two UMLs are started with the same umid, the second will
remove the first's ones.

Probably we should also panic() at that point, not sure however.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 arch/um/kernel/umid.c |   30 +++++++++++++++++++-----------
 1 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/arch/um/kernel/umid.c b/arch/um/kernel/umid.c
--- a/arch/um/kernel/umid.c
+++ b/arch/um/kernel/umid.c
@@ -31,6 +31,8 @@ static char *uml_dir = UML_DIR;
 /* Changed by set_umid */
 static int umid_is_random = 1;
 static int umid_inited = 0;
+/* Have we created the files? Should we remove them? */
+static int umid_owned = 0;
 
 static int make_umid(int (*printer)(const char *fmt, ...));
 
@@ -82,20 +84,21 @@ int __init umid_file_name(char *name, ch
 
 extern int tracing_pid;
 
-static int __init create_pid_file(void)
+static void __init create_pid_file(void)
 {
 	char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
 	char pid[sizeof("nnnnn\0")];
 	int fd, n;
 
-	if(umid_file_name("pid", file, sizeof(file))) return 0;
+	if(umid_file_name("pid", file, sizeof(file)))
+		return;
 
 	fd = os_open_file(file, of_create(of_excl(of_rdwr(OPENFLAGS()))), 
 			  0644);
 	if(fd < 0){
 		printf("Open of machine pid file \"%s\" failed: %s\n",
 		       file, strerror(-fd));
-		return 0;
+		return;
 	}
 
 	sprintf(pid, "%d\n", os_getpid());
@@ -103,7 +106,6 @@ static int __init create_pid_file(void)
 	if(n != strlen(pid))
 		printf("Write of pid file failed - err = %d\n", -n);
 	os_close_file(fd);
-	return 0;
 }
 
 static int actually_do_remove(char *dir)
@@ -147,7 +149,8 @@ static int actually_do_remove(char *dir)
 void remove_umid_dir(void)
 {
 	char dir[strlen(uml_dir) + UMID_LEN + 1];
-	if(!umid_inited) return;
+	if (!umid_owned)
+		return;
 
 	sprintf(dir, "%s%s", uml_dir, umid);
 	actually_do_remove(dir);
@@ -155,11 +158,12 @@ void remove_umid_dir(void)
 
 char *get_umid(int only_if_set)
 {
-	if(only_if_set && umid_is_random) return(NULL);
-	return(umid);
+	if(only_if_set && umid_is_random)
+		return NULL;
+	return umid;
 }
 
-int not_dead_yet(char *dir)
+static int not_dead_yet(char *dir)
 {
 	char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
 	char pid[sizeof("nnnnn\0")], *end;
@@ -193,7 +197,8 @@ int not_dead_yet(char *dir)
 		   (p == CHOOSE_MODE(tracing_pid, os_getpid())))
 			dead = 1;
 	}
-	if(!dead) return(1);
+	if(!dead)
+		return(1);
 	return(actually_do_remove(dir));
 }
 
@@ -286,6 +291,7 @@ static int __init make_umid(int (*printe
 		if(errno == EEXIST){
 			if(not_dead_yet(tmp)){
 				(*printer)("umid '%s' is in use\n", umid);
+				umid_owned = 0;
 				return(-1);
 			}
 			err = mkdir(tmp, 0777);
@@ -296,7 +302,8 @@ static int __init make_umid(int (*printe
 		return(-1);
 	}
 
-	return(0);
+	umid_owned = 1;
+	return 0;
 }
 
 __uml_setup("uml_dir=", set_uml_dir,
@@ -309,7 +316,8 @@ static int __init make_umid_setup(void)
 	/* one function with the ordering we need ... */
 	make_uml_dir();
 	make_umid(printf);
-	return create_pid_file();
+	create_pid_file();
+	return 0;
 }
 __uml_postsetup(make_umid_setup);
 


  reply	other threads:[~2005-09-21 17:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 17:23 [PATCH 0/10] "Bigger" UML fixes for 2.6.14 Blaisorblade
2005-09-21 17:27 ` Paolo 'Blaisorblade' Giarrusso [this message]
2005-09-21 17:28 ` [PATCH 02/10] strlcat: use for uml umid.c Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 03/10] uml: don't redundantly mark pte as newpage in pte_modify Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 04/10] uml: fix hang in TT mode on fault Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 05/10] uml: fix condition in tlb flush Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:28 ` [PATCH 06/10] uml: run mconsole "sysrq" in process context Paolo 'Blaisorblade' Giarrusso
2005-09-21 20:50   ` [uml-devel] " Jeff Dike
2005-09-22 19:20     ` Blaisorblade
2005-09-22 20:37       ` Jeff Dike
2005-09-22 20:48         ` Blaisorblade
2005-09-23  7:40         ` Andrew Morton
2005-09-23 13:33           ` Jeff Dike
2005-09-25 21:34             ` Paul Jackson
2005-09-21 17:29 ` [PATCH 07/10] uml: avoid fixing faults while atomic Paolo 'Blaisorblade' Giarrusso
2005-09-21 19:49   ` Andrew Morton
2005-09-21 20:22     ` [uml-devel] " Blaisorblade
2005-09-21 20:47       ` Andrew Morton
2005-09-22 19:37         ` Blaisorblade
2005-09-22 19:58           ` Andrew Morton
2005-09-22 20:54           ` Linus Torvalds
2005-09-21 20:29     ` Linus Torvalds
2005-09-21 17:29 ` [PATCH 08/10] uml: Fix GFP_ flags usage Paolo 'Blaisorblade' Giarrusso
2005-09-21 19:19   ` Bill Davidsen
2005-09-21 20:52   ` [uml-devel] " Jeff Dike
2005-09-21 17:29 ` [PATCH 09/10] Uml: use GFP_ATOMIC for allocations under spinlocks Paolo 'Blaisorblade' Giarrusso
2005-09-21 17:29 ` [PATCH 10/10] uml: replace printk with "stack-friendly" printf - to report console failure Paolo 'Blaisorblade' Giarrusso

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=20050921172737.10219.71614.stgit@zion.home.lan \
    --to=blaisorblade@yahoo.it \
    --cc=akpm@osdl.org \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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).