Re: [PATCH 1/4] module: add syscall to load module from fd
H. Peter Anvin zytor.com> writes: > > It is a bit more indirect, but also in practice it's a bit trickier than > > that. We need to ensure the memory doesn't change underneath us and > > stays attached to that fd. I can easily see that code slipping and > > ending in an exploit. > > > > But that may be my irrational fear of the mm :) > > You have to do the same thing with a file/file descriptor, I would think. > > However, I keep wondering about the use case for this, as opposed to > signatures. Two things: 1. finit_module() lets LSMs make decisions based on full information on the module to be loaded 2. On some systems (such as Chromium OS) we have a trusted root OS (e.g. the entire root filesystem is protected using dm-verity); requiring signatures on top of this is a waste of resources -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] module: add syscall to load module from fd
H. Peter Anvin hpa at zytor.com writes: It is a bit more indirect, but also in practice it's a bit trickier than that. We need to ensure the memory doesn't change underneath us and stays attached to that fd. I can easily see that code slipping and ending in an exploit. But that may be my irrational fear of the mm :) You have to do the same thing with a file/file descriptor, I would think. However, I keep wondering about the use case for this, as opposed to signatures. Two things: 1. finit_module() lets LSMs make decisions based on full information on the module to be loaded 2. On some systems (such as Chromium OS) we have a trusted root OS (e.g. the entire root filesystem is protected using dm-verity); requiring signatures on top of this is a waste of resources -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Try harder to probe some finicky mice
From: Alon Ziv <[EMAIL PROTECTED]> Some rodents appear to be extra-finicky, and require both a PSMOUSE_RESET_DIS and a PSMOUSE_RESET_BAT before they are unconfused enough to be probed. Signed-off-by: Alon Ziv <[EMAIL PROTECTED]> --- drivers/input/mouse/psmouse-base.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index b9f0fb2..ca039a5 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -651,6 +651,7 @@ static int psmouse_extensions(struct psmouse *psmouse, * protocol probes. Note that we do full reset becuase some mice * put themselves to sleep when see PSMOUSE_RESET_DIS. */ + ps2_command(>ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); psmouse_reset(psmouse); if (max_proto >= PSMOUSE_IMEX && im_explorer_detect(psmouse, set_properties) == 0) -- 1.5.2.146.gb75c6 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Try harder to probe some finicky mice
From: Alon Ziv [EMAIL PROTECTED] Some rodents appear to be extra-finicky, and require both a PSMOUSE_RESET_DIS and a PSMOUSE_RESET_BAT before they are unconfused enough to be probed. Signed-off-by: Alon Ziv [EMAIL PROTECTED] --- drivers/input/mouse/psmouse-base.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index b9f0fb2..ca039a5 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -651,6 +651,7 @@ static int psmouse_extensions(struct psmouse *psmouse, * protocol probes. Note that we do full reset becuase some mice * put themselves to sleep when see PSMOUSE_RESET_DIS. */ + ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); psmouse_reset(psmouse); if (max_proto = PSMOUSE_IMEX im_explorer_detect(psmouse, set_properties) == 0) -- 1.5.2.146.gb75c6 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
From: "David Howells" <[EMAIL PROTECTED]> > David Woodhouse <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] said: > > > [BTW, another solution is to truly support opaque "handles" to kernel > > > objects; I believe David Howells is already working on something like > > > this for Wine? > > Yes. However, it uses a different system call set to use them. They translate > to small object structures internally. > Obviously... since they're handles, not FDs... [BTW, are you using Windows' idea of storing the objects in process space, in a page that's inaccessible to the app itself, and passing pointers into this page as the handles?] > > > The poll interface can be trivially extended to support > > > waiting on those...] > > No, they aren't files. I did not want to use "files" because this would incur > a fairly major penalty for each object: > So what if they aren't files? If you look at (e.g.) AIX's poll(), it allows you to put SysV semaphore IDs in pollfd structures. (Actually they do even more--- they have an extended pollfd struct; but even without it, just putting a handle instead of FD and a special event code in a normal pollfd should suffice...) > struct file + struct dentry + struct inode > > Which would mean that Win32 File objects would require two of each, one set to > hold the extra Win32 attributes and one set for the actual Linux file. > I'm afraid I'm not following your logic in this; I believe most Win32 attrs can be mapped to more generic abstractions which should be able to exist at 'struct file' level. (And even if not, a Win32 file handle could just hold two pointers--- one to the 'struct file', and one to the extra attrs...) > The way I've chosen uses somewhat less memory and should be faster. > And breaks _completely_ with the existing scheme :-/ > > ISTR it wasn't quite trivial to do it that way - it would require the > > addition of an extra argument to the fops->poll() method. > > Yes, the PulseEvent operation demands that all processes currently waiting on > the event should be woken, but that no processes attaching immediately > afterward get triggered. > Huh? Where did you get this? Looking at my copy of MSDN (July '00), the PulseEvent remarks more-or-less suggest an implementation like SetEvent(e) ResetEvent(e) I don't see any mention of 'currently waiting' vs 'new' waiters. (Besides, I doubt MS tries to solve this in the SMP case...) > Oh... and WaitForMultipleObjects also has a "wait for all" option. Yes, this is a valid point... I wonder if it's possible to add _just_ this to poll()... -az - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
From: David Howells [EMAIL PROTECTED] David Woodhouse [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] said: [BTW, another solution is to truly support opaque handles to kernel objects; I believe David Howells is already working on something like this for Wine? Yes. However, it uses a different system call set to use them. They translate to small object structures internally. Obviously... since they're handles, not FDs... [BTW, are you using Windows' idea of storing the objects in process space, in a page that's inaccessible to the app itself, and passing pointers into this page as the handles?] The poll interface can be trivially extended to support waiting on those...] No, they aren't files. I did not want to use files because this would incur a fairly major penalty for each object: So what if they aren't files? If you look at (e.g.) AIX's poll(), it allows you to put SysV semaphore IDs in pollfd structures. (Actually they do even more--- they have an extended pollfd struct; but even without it, just putting a handle instead of FD and a special event code in a normal pollfd should suffice...) struct file + struct dentry + struct inode Which would mean that Win32 File objects would require two of each, one set to hold the extra Win32 attributes and one set for the actual Linux file. I'm afraid I'm not following your logic in this; I believe most Win32 attrs can be mapped to more generic abstractions which should be able to exist at 'struct file' level. (And even if not, a Win32 file handle could just hold two pointers--- one to the 'struct file', and one to the extra attrs...) The way I've chosen uses somewhat less memory and should be faster. And breaks _completely_ with the existing scheme :-/ ISTR it wasn't quite trivial to do it that way - it would require the addition of an extra argument to the fops-poll() method. Yes, the PulseEvent operation demands that all processes currently waiting on the event should be woken, but that no processes attaching immediately afterward get triggered. Huh? Where did you get this? Looking at my copy of MSDN (July '00), the PulseEvent remarks more-or-less suggest an implementation like SetEvent(e) ResetEvent(e) I don't see any mention of 'currently waiting' vs 'new' waiters. (Besides, I doubt MS tries to solve this in the SMP case...) Oh... and WaitForMultipleObjects also has a wait for all option. Yes, this is a valid point... I wonder if it's possible to add _just_ this to poll()... -az - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Oh, I don't argue about that. (Well, almost--- see below...) It's just that we need _some_ method for getting over the silly POSIX FD-handling restrictions... And the negative-FDs may be the solution. (Note I said we 'can' declare other semantics; not 'should'. So these FDs can still be normal ones, just at the other end of the numbering range...) My misgivings are: * There's no way to integrate other signalling mechanisms; e.g., we may wish for a 'wake-all-waiters' signaller, or for a 'timed-wait' that arrives via an FD and not as a signal * a pipe is a more-or-less good semaphore; it may be too heavyweight, as it's forced to pass useless [in this case] info, and we can't control its wakeup order [although POSIX doesn't seem to require this] [ Actually, I once had an idea of binding signals into an FD, so they can be 'read' out of it... with that, an alarm() is a 'timed-wait' waitable by poll() :-) ] -az - Original Message - From: "Alexander Viro" <[EMAIL PROTECTED]> To: "Alon Ziv" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Alan Cox" <[EMAIL PROTECTED]> Sent: Sunday, April 22, 2001 16:31 Subject: Re: light weight user level semaphores > > > On Sun, 22 Apr 2001, Alon Ziv wrote: > > > Well, that's the reason for my small-negative-integer semaphore-FD idea... > > (It won't support select() easily, but poll() is prob'ly good enough) > > Still, there is the problem of read()/write()/etc. semantics; sure, we can > > declare that 'negative FDs' have their own semantics which just happen to > > include poll(), but it sure looks like a kludge... > > You _still_ don't get it. The question is not "how to add magic kernel > objects that would look like descriptors and support a binch of > ioctls, allowing to do semaphores", it's "do we need semaphores > to be kernel-level objects". Implementation with pipes allows to avoid > the magic crap - they are real, normal pipes - nothing special from > the kernel POV. read(), write(), etc. are nothing but reading and writing > for pipes. > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Well, that's the reason for my small-negative-integer semaphore-FD idea... (It won't support select() easily, but poll() is prob'ly good enough) Still, there is the problem of read()/write()/etc. semantics; sure, we can declare that 'negative FDs' have their own semantics which just happen to include poll(), but it sure looks like a kludge... -az - Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: "Alon Ziv" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, April 22, 2001 14:44 Subject: Re: light weight user level semaphores > > All of this FD allocation stuff is truly distrurbing. > > This appears to be the one place where Win32 got it (almost) right--- > > quite about every kernel object looks to userland just like an opaque > > handle, and the same operations apply to all of them. > > Unix got this right, then AT broke it in System III. One very good reason > for pipe based semaphore stuff is precisely that it works in poll/select/SIGIO > > Alan > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Well, that's the reason for my small-negative-integer semaphore-FD idea... (It won't support select() easily, but poll() is prob'ly good enough) Still, there is the problem of read()/write()/etc. semantics; sure, we can declare that 'negative FDs' have their own semantics which just happen to include poll(), but it sure looks like a kludge... -az - Original Message - From: "Alan Cox" [EMAIL PROTECTED] To: "Alon Ziv" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 22, 2001 14:44 Subject: Re: light weight user level semaphores All of this FD allocation stuff is truly distrurbing. This appears to be the one place where Win32 got it (almost) right--- quite about every kernel object looks to userland just like an opaque handle, and the same operations apply to all of them. Unix got this right, then ATT broke it in System III. One very good reason for pipe based semaphore stuff is precisely that it works in poll/select/SIGIO Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Oh, I don't argue about that. (Well, almost--- see below...) It's just that we need _some_ method for getting over the silly POSIX FD-handling restrictions... And the negative-FDs may be the solution. (Note I said we 'can' declare other semantics; not 'should'. So these FDs can still be normal ones, just at the other end of the numbering range...) My misgivings are: * There's no way to integrate other signalling mechanisms; e.g., we may wish for a 'wake-all-waiters' signaller, or for a 'timed-wait' that arrives via an FD and not as a signal * a pipe is a more-or-less good semaphore; it may be too heavyweight, as it's forced to pass useless [in this case] info, and we can't control its wakeup order [although POSIX doesn't seem to require this] [ Actually, I once had an idea of binding signals into an FD, so they can be 'read' out of it... with that, an alarm() is a 'timed-wait' waitable by poll() :-) ] -az - Original Message - From: "Alexander Viro" [EMAIL PROTECTED] To: "Alon Ziv" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; "Alan Cox" [EMAIL PROTECTED] Sent: Sunday, April 22, 2001 16:31 Subject: Re: light weight user level semaphores On Sun, 22 Apr 2001, Alon Ziv wrote: Well, that's the reason for my small-negative-integer semaphore-FD idea... (It won't support select() easily, but poll() is prob'ly good enough) Still, there is the problem of read()/write()/etc. semantics; sure, we can declare that 'negative FDs' have their own semantics which just happen to include poll(), but it sure looks like a kludge... You _still_ don't get it. The question is not "how to add magic kernel objects that would look like descriptors and support a binch of ioctls, allowing to do semaphores", it's "do we need semaphores to be kernel-level objects". Implementation with pipes allows to avoid the magic crap - they are real, normal pipes - nothing special from the kernel POV. read(), write(), etc. are nothing but reading and writing for pipes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Hmm... I already started (long ago, and abandoned since due to lack of time :-( ) down another path; I'd like to resurrect it... My lightweight-semaphores were actually even simpler in userspace: * the userspace struct was just a signed count and a file handle. * Uncontended case is exactly like Linus' version (i.e., down() is decl + js, up() is incl()). * The contention syscall was (in my implementation) an ioctl on the FH; the FH was a special one, from a private syscall (although with the new VFS I'd have written it as just another specialized FS, or even referred into the SysVsem FS). So, there is no chance for user corruption of kernel data (as it just ain't there...); and the contended-case cost is probably equivalent (VFS cost vs. validation). Hope I inspired someone... -az - Original Message - From: "Ulrich Drepper" <[EMAIL PROTECTED]> To: "Linus Torvalds" <[EMAIL PROTECTED]> Cc: "Mike Kravetz" <[EMAIL PROTECTED]>; "Kernel Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, April 18, 2001 21:35 Subject: Re: light weight user level semaphores > Linus Torvalds <[EMAIL PROTECTED]> writes: > > Sounds good so far. Some comments. > > > - FS_create is responsible for allocating a shared memory region > >at "FS_create()" time. > > This is not so great. The POSIX shared semaphores require that an > pthread_mutex_t object placed in a shared memory region can be > initialized to work across process boundaries. I.e., the FS_create > function would actually be FS_init. There is no problem with the > kernel or the helper code at user level allocating more storage (for > the waitlist of whatever) but it must not be necessary for the user to > know about them and place them in share memory themselves. > > The situation for non-shared (i.e. intra-process) semaphores are > easier. What I didn't understand is your remark about fork. The > semaphores should be cloned. Unless the shared flag is set there > should be no sharing among processes. > > > The rest seems OK. Thanks, > > -- > ---. ,-. 1325 Chesapeake Terrace > Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA > Red Hat `--' drepper at redhat.com ` > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: light weight user level semaphores
Hmm... I already started (long ago, and abandoned since due to lack of time :-( ) down another path; I'd like to resurrect it... My lightweight-semaphores were actually even simpler in userspace: * the userspace struct was just a signed count and a file handle. * Uncontended case is exactly like Linus' version (i.e., down() is decl + js, up() is incl()). * The contention syscall was (in my implementation) an ioctl on the FH; the FH was a special one, from a private syscall (although with the new VFS I'd have written it as just another specialized FS, or even referred into the SysVsem FS). So, there is no chance for user corruption of kernel data (as it just ain't there...); and the contended-case cost is probably equivalent (VFS cost vs. validation). Hope I inspired someone... -az - Original Message - From: "Ulrich Drepper" [EMAIL PROTECTED] To: "Linus Torvalds" [EMAIL PROTECTED] Cc: "Mike Kravetz" [EMAIL PROTECTED]; "Kernel Mailing List" [EMAIL PROTECTED] Sent: Wednesday, April 18, 2001 21:35 Subject: Re: light weight user level semaphores Linus Torvalds [EMAIL PROTECTED] writes: Sounds good so far. Some comments. - FS_create is responsible for allocating a shared memory region at "FS_create()" time. This is not so great. The POSIX shared semaphores require that an pthread_mutex_t object placed in a shared memory region can be initialized to work across process boundaries. I.e., the FS_create function would actually be FS_init. There is no problem with the kernel or the helper code at user level allocating more storage (for the waitlist of whatever) but it must not be necessary for the user to know about them and place them in share memory themselves. The situation for non-shared (i.e. intra-process) semaphores are easier. What I didn't understand is your remark about fork. The semaphores should be cloned. Unless the shared flag is set there should be no sharing among processes. The rest seems OK. Thanks, -- ---. ,-. 1325 Chesapeake Terrace Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com ` - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
The best solution to the sound driver issue, IMHO, is still entirely userspace--- just no-one has written it yet. What we should do: 1. Before auto-unload of the driver, run a small utility which will read mixer settings and save them somewhere 2. When auto-loading the driver, use driver arguments which are initialized from the settings saved above All that's missing is the method of passing data from step 1 to step 2. - Original Message - From: "David Woodhouse" <[EMAIL PROTECTED]> To: "Horst von Brand" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 06, 2000 19:06 Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page] > > [EMAIL PROTECTED] said: > > No funny "persistent data" mechanisms or screwups when the worker > > gets removed and reinserted. In many cases the data module could be > > shared among several others, in other cases it would have to be able > > lo load several times or manage several incarnations of its payload. > > The reason I brought this up now is because Keith's new > inter_module_register stuff could easily be used to provide this > functionality _without_ the extra module remaining loaded. > > > -- > dwmw2 > > > - > 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/ > - 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/
Re: Persistent module storage [was Linux 2.4 Status / TODO page]
The best solution to the sound driver issue, IMHO, is still entirely userspace--- just no-one has written it yet. What we should do: 1. Before auto-unload of the driver, run a small utility which will read mixer settings and save them somewhere 2. When auto-loading the driver, use driver arguments which are initialized from the settings saved above All that's missing is the method of passing data from step 1 to step 2. - Original Message - From: "David Woodhouse" [EMAIL PROTECTED] To: "Horst von Brand" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, November 06, 2000 19:06 Subject: Re: Persistent module storage [was Linux 2.4 Status / TODO page] [EMAIL PROTECTED] said: No funny "persistent data" mechanisms or screwups when the worker gets removed and reinserted. In many cases the data module could be shared among several others, in other cases it would have to be able lo load several times or manage several incarnations of its payload. The reason I brought this up now is because Keith's new inter_module_register stuff could easily be used to provide this functionality _without_ the extra module remaining loaded. -- dwmw2 - 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/ - 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/
Re: thread group comments
I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-) I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution. And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well. What I believe should be done is just a few (simple) extensions to prctl. Specifically, what we need is * prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent. * prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s. And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada. Now, userspace will be a different story. There, we'll need the following: - When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine. - Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-) - New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec(). - Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism. Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!? -az - 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/
Re: thread group comments
Title: I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-) I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution. And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well. What I believe should be done is just a few (simple) extensions to prctl. Specifically, what we need is * prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent. * prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s. And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada. Now, userspace will be a different story. There, we'll need the following: - When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine. - Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-) - New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec(). - Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism. Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!? -az Alon Ziv <mailto:[EMAIL PROTECTED]> System Architect (Client Team) Zapper Technologies Inc. <http://www.zapper.com/> Tel +972-3-6949226 BEGIN:VCARD VERSION:2.1 N:Ziv;Alon FN:Alon Ziv ORG:Zapper Technologies Inc.;Client TITLE:System Architect TEL;WORK;VOICE:+972 (3) 6949226 TEL;CELL;VOICE:+972 (54) 616935 TEL;WORK;FAX:+972 (3) 6965111 ADR;WORK:;;3 Azrieli Center;Tel-Aviv;;;Israel LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3 Azrieli Center=0D=0ATel-Aviv=0D=0AIsrael KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq xqiELFqvBvDknKMGDfPJ KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq xqiELFqvBvDknKMGDfPJ KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20
Re: thread group comments
Title: I find I have to comment... although I haven't had access to my Linux box for a while (Real Life is taking too much of my time ;-) I, for one, am _not_ in favor of the tgid approach. I believe it is _far_ too complex a solution. And, yes, I do have a better (IMNSHO) approach. I just didn't get enough time to code it. It feels _really_ rude to counter code with words. Oh well. What I believe should be done is just a few (simple) extensions to prctl. Specifically, what we need is * prctl(SEND_ME_PARENT_SIGNAL_x, s) --- tells kernel 'if my parent gets signal x, send me signal s' (signals will be queued atomically). This way, a thread can ask the kernel to be killed / stopped together with its parent. * prctl(SIGNAL_ON_PARENT_EXEC, s) --- when parent _successfully_ exec's, send me signal s. And that is _all_. No tgid mess, no specific handling of specific signals in the kernel, no 'all threads are blocking this signal' mess, no nada. Now, userspace will be a different story. There, we'll need the following: - When process does pthreads_init, it creates a new thread (N+1 model); control returns via the _new_ thread (a la userspace thread-switch), and original thread (which has the original pid) remains as master in a special routine. - Whenever a signal is handled _anywhere_ in the process, the master thread sets a handler for it. It's the master thread's job to distribute signals; also, when signal is blocked, it remains on master's queue. (If CLONE_SIGNAL lets thread do the sigaction setup by itself--- even better, less ITC :-) - New threads are created CLONE_PARENT. They ask to get SIGKILL on parent SIGKILL, SIGSTOP on parent SIGSTOP, possibly also SIGSEGV on parent SIGSEGV (and other 'terminating' signals). They also ask to get SIGKILL on parent exec(). - Userspace exec() is rerouted (in _userspace_) to master thread. If it succeeds, all other threads automagically disappear (they were SIGKILLed by their own request); if it fails, return code gets back to originating thread via same ITC mechanism. Now, just when do I find the time to get a test8-pre1, rip out the silly tgid stuff, and code my idea?!? -az Alon Ziv mailto:[EMAIL PROTECTED] System Architect (Client Team) Zapper Technologies Inc. http://www.zapper.com/ Tel +972-3-6949226 BEGIN:VCARD VERSION:2.1 N:Ziv;Alon FN:Alon Ziv ORG:Zapper Technologies Inc.;Client TITLE:System Architect TEL;WORK;VOICE:+972 (3) 6949226 TEL;CELL;VOICE:+972 (54) 616935 TEL;WORK;FAX:+972 (3) 6965111 ADR;WORK:;;3 Azrieli Center;Tel-Aviv;;;Israel LABEL;WORK;ENCODING=QUOTED-PRINTABLE:3 Azrieli Center=0D=0ATel-Aviv=0D=0AIsrael KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq xqiELFqvBvDknKMGDfPJ KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB AAGjUDBOMB0GA1UdEQQWMBSBEmFsb256QGd1aWRlbGV0LmNvbTAMBgNVHRMBAf8EAjAAMB8G A1UdIwQYMBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAFu2NmDE ZXfi/ZaqZs9qLxDXS3+zsGQhJfrkSu/Ri1DwG4+YCwEX+qTqvy2aJGTRzWVJktaRXt+Ir0GZ Pt5etD2gN1hrB2glzs3q2QnhSuSthyCZEytnyskCFODgipYOhzGvvf9CLYkckoQZgl6+O3Nq xqiELFqvBvDknKMGDfPJ KEY;X509;ENCODING=BASE64: MIICXTCCAcagAwIBAgIDAe3OMA0GCSqGSIb3DQEBBAUAMIGUMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDE5OTkuOS4xNjAeFw0wMDAxMTIxNDU1NDRaFw0wMTAxMTExNDU1NDRa MEQxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEmFs b256QGd1aWRlbGV0LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCzjDylN8coWhh65ISV l6bpa1beg/aMr6XlIhuUFwIBLyHjf3ZFxxz7yH7JxR692hEgr20JjdWDlO245Qn+SqoVAgMB
Re: SCO: "thread creation is about a thousand times faster than on
From: "David Howells" <[EMAIL PROTECTED]> > > Would it be possible to make fork() or clone() from a process whose tgid!=pid > reparent the child to the thread group leader automatically? Thus, when the > creating thread goes away, the child is still a child of the "process", and > SIGCHLD is still going to go to the process (leader thread). > No need--- it's userspace-solvable; we just need a rule that says "fork() in a thread is actually a clone(...|CLONE_PARENT,...)" and the magic happens all by itself. > Also all child "processes" and "threads" are then logically children of the > "process", given that a "process" is then defined by the tgid. > > Also my 2p on the execve() problem: if the master thread does an execve(), > there must be a point of no return, at which point all the child threads > should be deleted, IMHO, otherwise they turn into full processes in their own > right, and the thread-signalling framework goes out the window. > > And for a further thought on the subject, is it possible for when a child > thread does an execve(), to wangle the master thread into making this call, > with all other threads SIGSTOP'd until completion (& death) or failure (& > resumption)? (though that's probably better done in userspace) Exactly. Userspace is the key. (We just probably need a 'parent has exec()ed' notification signal in the children, like the current 'parent has exit()ed' one). -az - 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/
