minor bugs around fork_init

I found 4 minor problems in the thread creation code:

* 2.2 reserved 4 threads for root, and 2.4 still has the define (MIN_THREADS_LEFT_FOR_ROOT), but the code is missing :-(

* get_pid causes a deadlock when all pid numbers are in use. In the worst case, only 10900 threads are required to exhaust the 15 bit pid space.

* in theory, fork_init() might give 2 tasks the same pid, although this can only happen when all but 1 or 2 pids are in use:

<<
fork_init() runs with the BKL acquired.
It first calls get_pid(), and get_pid() internally scans
the task queue and returns a pid number that is not used by a thread on the task queue. But it doesn't add the thread to the task queue.

copy_xy() can sleep, thus the BKL is released.

At the end of fork_init(), the new task is added to the task queue.

--> if 2 thread are within fork_init(), then both might get the same pid!

* the spinlock within get_pid is bogus: get_pid isn't SMP safe.

I've attached a patch (tested with 2.4.0-test12).

--
Manfred

// $Header$
// Kernel Version:

//  VERSION = 2
//  PATCHLEVEL = 4
//  SUBLEVEL = 0
//  EXTRAVERSION = -test12

@@ -45,6 +45,7 @@
 extern int bdf_prm[], bdflush_min[], bdflush_max[];
 extern int sysctl_overcommit_memory;
 extern int max_threads;
+extern int threads_high, threads_low;
 extern int nr_queued_signals, max_queued_signals;
 extern int sysrq_enabled;
 

@@ -222,7 +223,8 @@
 	 0644, NULL, &proc_dointvec},
 #endif	 
 	{KERN_MAX_THREADS, "threads-max", &max_threads, sizeof(int),
-	 0644, NULL, &proc_dointvec},
+	 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL,
+	&threads_low, &threads_high},
 	{KERN_RANDOM, "random", NULL, 0, 0555, random_table},
 	{KERN_OVERFLOWUID, "overflowuid", &overflowuid, sizeof(int), 0644, NULL,
 	 &proc_dointvec_minmax, &sysctl_intvec, NULL,

ld: cannot open drivers/ieee1394/ieee1394.a: No such file or directory
make: *** [vmlinux] Error 1

::::: Gene Imes http://www.ozob.net :::::

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I sent the following patch to Linus already. It should fix the problem.

--Kai

diff -ur linux-2.4.0-test13-pre3/drivers/ieee1394/Makefile linux-2.4.0-test13-pre3.1/drivers/ieee1394/Makefile
@@ -23,7 +23,8 @@
 obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o
 obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o
 
+include $(TOPDIR)/Rules.make
+
 ieee1394.o: $(ieee1394-objs)
 	$(LD) -r -o $@ $(ieee1394-objs)
 
-include $(TOPDIR)/Rules.make

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Yes. I posted a patch for 31-bit pids once or twice. There is no great hurry, but on the other hand, it is always better to make these changes long before it is really urgent.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi!

On 2Gig machine, you should be able to overflow 16 bits. So it is quite urgent.
Pavel

I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

That's another problem!
31 bit uid would be a nice feature for 2.4, but the last time I asked Linus he answered that the high bits are still reserved.

My patch fixes bugs in the current, 15 bit implementation:
* we don't reserve any threads for root as 2.2 did
* if a user limit allows for > 10900 threads, then that user can cause a deadlock by using all pid values (one thread can block 3 pid values). get_pid() will loop forever.
* in theory, 2 threads could get the same pid.

--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/