From HAZLIMSX@hotmail.com Mon Jun 7 04:53:06 2004 Received: with ECARTIS (v1.0.0; list pagg); Mon, 07 Jun 2004 04:53:07 -0700 (PDT) Received: from 192.48.159.27 ([220.65.18.44]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i57Br4gi021341 for ; Mon, 7 Jun 2004 04:53:05 -0700 X-Message-Info: ad112OU8AJwuhae3gQDjdnP2FZ239bjrGNvlkNJF99 Received: (from busy@localhost) by infelicitytheory1.HAZLIMSX@hotmail.com (5.79.0/2.28.5) id nw925CAtK36997; Mon, 07 Jun 2004 10:51:58 -0200 Message-ID: <571618441237.00551@HAZLIMSX@hotmail.com> Reply-To: "Keri Owens" From: "Keri Owens" To: "Pagg" Subject: Fw: Sh0cking health revealati0ns Date: Mon, 07 Jun 2004 07:49:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--47290020759842456" X-archive-position: 27 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: HAZLIMSX@hotmail.com Precedence: bulk X-list: pagg ----47290020759842456 Content-Type: text/html; charset="iso-0618-4" Content-Transfer-Encoding: quoted-printable Content-Description: gullet anamorphic.frederic

As se= en on NBC, CBS, and CNN, and even Oprah! The h= ealth
discovery tha= t actually reverses aging while burning fat, <= br> without dieti= ng or exercise! This proven discovery has even
been reported on by major Science Journals.
Forget aging and dieting forever! And It= 's Guaranteed!

* Reduce body fat and build lean muscle WITHOUT EXERCISE!
* Enhance sexual performance
* Remove wrinkles and cellulite
* Lower blood pressure and improve cholesterol profile
* Improve sleep, vision and memory
* Restore hair color and growth
* Strengthen the immune system
* Increase energy and cardiac output
* Turn back your body's biological clock 10-20 years in 6 months!!= !

Shop here= for HGH

Smart Way to lose the weight!
Revolutionary Diet Patch
No Pills
No Exercise
No Starving
Natural and Safe
Guaranteed Results
Lose 3 to 8 pounds each week
Increased Energy
Decreased Food Cravings
Boosted Metabolism
It Works!

Shop here for Diet Patch

Why was this email sent to you? At some point you registered or made a purchase on a Web site with privacy policies explaining= that they may share your information with partners who will send you valuable= offers from time to time.

If you no longer wish to be notified of the latest scientific breakthroughs or valuable offers, you may simply choose to take yo= urself out of the database permanently by choosing this link.

----47290020759842456-- From pwil3058@bigpond.net.au Wed Jun 16 00:46:21 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 00:46:27 -0700 (PDT) Received: from gizmo07bw.bigpond.com (gizmo07bw.bigpond.com [144.140.70.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5G7kJgi005521 for ; Wed, 16 Jun 2004 00:46:19 -0700 Received: (qmail 10795 invoked from network); 15 Jun 2004 22:58:07 -0000 Received: from unknown (HELO bwmam01.bigpond.com) (144.135.24.69) by gizmo07bw.bigpond.com with SMTP; 15 Jun 2004 22:58:07 -0000 Received: from cpe-203-45-94-214.nsw.bigpond.net.au ([203.45.94.214]) by bwmam01.bigpond.com(MAM REL_3_4_2a 8/3591615) with SMTP id 3591615; Wed, 16 Jun 2004 08:58:07 +1000 Message-ID: <40CF7EFF.5090200@bigpond.net.au> Date: Wed, 16 Jun 2004 08:58:07 +1000 From: Peter Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Jacobson CC: pagg@oss.sgi.com Subject: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 28 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pwil3058@bigpond.net.au Precedence: bulk X-list: pagg This seems to be doing what PAGG does (or should do). -------- Original Message -------- Subject: [Announce] Non Invasive Kernel Monitor for threads/processes Date: Tue, 15 Jun 2004 12:54:23 -0700 From: Atul Sabharwal To: linux-kernel@vger.kernel.org References: <40CF4233.70709@linux.jf.intel.com> We have been working with a solution for non-intrusively trapping on lifetime of processes/threads. This is useful for management applications running in telecom and enterprise data centers that need to monitor a set of threads/ processes. Project Goal:: ~~~~~~~~~~~~~~ To create a kernel patch that shall support methods to non-intrusively monitor processes/threads at the kernel level. It would use a notfication mechanism in the kernel that allows registration of events of interest regarding processes/ threads. Events of interest could be the following : Process creation (fork), Process exit(exit), Process calls(exec), thread creation & thread exit. The implementation needs to provide high performance with low overhead. Monitoring would be driven directly by the events in the kernel to ensure low latency access to interesting events. Solution Approach: ~~~~~~~~~~~~~~~~~~ This method requires a user space process (called monitor) to start and stop monitoring in the system. The monitor sends the list of pids and the events to be monitored for that pid. Once the ioctl is received, the kernel establishes a filter for it. Events get flooded in the system as each call (fork, exec and exit) has been modified to generate events. The events which match the filter become interesting and require that a notification is sent to the monitor process. Events which do no match the filter get dropped. In the case when we have multiple monitor processes, signals are sent to each monitor whose filters match the event which has occurred. Solution Description : ~~~~~~~~~~~~~~~~~~~~~~ The registration and de-registration command are implemented as ioctls. The notification command is implemented as a sigqueue signal. The system calls such as fork, exit, and exec have been changed to add a notification call to the monitor process. The filter for events is populated with the registration command. Events & their respective thread/process get removed from the filter with the de-registration command. Threads and processes follow the same code path for task creation & termination. Hence, the code path is the same for threads and processes. There is no equivalent of an exec call with threads. The only distinction for a thread is that in the task struct, the thread group id (tgid) and process id (pid) are different. For a process, they are the same. The signal used for notification is also specified with the registration command. If it is a real-time signal, it would perform better as signals would get queued for the monitor. With non-real time signals, signals would get dropped if one signal exists. Hence, it is recommended to specify a real time signal. Also, it is to be noted that the solution is totally architecture independent. So, would just need a re-compile on the respective platform. Kmonitor has been implemented as a miscellaneous character driver built into the Linux kernel. It cannot be compiled as a loadable module. It supports the relevant driver calls for open, release, ioctl, init, cleanup calls. The character driver code contains the filtering, registration/de-registration and notification functions of Kmonitor as wells as routines to manage the linked list(s) for filtering. Kmonitor has 256 buckets and each bucket contains a spinlock and a linked list. This works around the sequential search operation in linked list by using a hashing function to change the complexity from O(N) to O(N/M) where M is the number of buckets. Kernel Version & Code location: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The kernel used was the 2.6.6 kernel and the code is at http://kmonitor.bkbits.net User space programs: ~~~~~~~~~~~~~~~~~~~~ 1. unit_test : A sample program to monitor future processes. http://kmonitor.bkbits.net:8080/tools/anno/unit_test.c@1.4?nav=index.html|ChangeSet@-3w|cset@1.35 2. monitor_pid: A sample program to monitor a process sub-tree. http://kmonitor.bkbits.net:8080/tools/anno/monitor_pid.c@1.2?nav=index.html|ChangeSet@-2w|cset@1.37 3. wait_on_pid : A sample program which waits till a pid dies. http://kmonitor.bkbits.net:8080/tools/anno/wait_on_pid.c@1.5?nav=index.html|ChangeSet@-2w|cset@1.37 Source Code: ~~~~~~~~~~~~ The patch for Kmonitor is as below : diff -Nru a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt --- a/Documentation/ioctl-number.txt 2004-06-14 11:24:08 -07:00 +++ b/Documentation/ioctl-number.txt 2004-06-14 11:24:08 -07:00 @@ -189,3 +189,4 @@ 0xDD 00-3F ZFCP device driver see drivers/s390/scsi/ +0xDE all drivers/char/kmonitor diff -Nru a/Documentation/kmonitor.txt b/Documentation/kmonitor.txt --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/Documentation/kmonitor.txt 2004-06-14 11:24:08 -07:00 @@ -0,0 +1,119 @@ +Enabling Non-intrusive Application Monitoring with kmonitor +----------------------------------------------------------- +The kmonitor driver implements a kernel level non-intrusive +mechanism for rapidly notifying a monitoring user space process +of key (process/thread creation/exit) kernel events. + +The monitoring user space process registers and deregisters for events via +a new misc char device using two new ioctl's. The kernel notifies the +monitoring process(es) of the events via a signal that the monitor specifies +during registration. + +An example of how this would be used in an minimal command line utility +to wait for an arbitrary process to exit: + +rest of required headers... +#include + +void target_exit_handler (int signum , struct siginfo * info, void * buf) +{ + /* + * Since we only registered for one type of event, + * KMONITOR_PROCESS_EXIT, on one process, then we already + * know our target process has exited + * + * If we were doing something more complex, then the data in + * info might be usefull: + * 1. info->si_pid: process id of target process + * 2. info->si_gid: group id of target process + * 3. info->si_int: event that triggered this signal + * (See include/linux/kmonitor.h for the list of events) + * + * The target process has exited, so we are done. Kmonitor + * will do cleanup when we close the file descriptor for + * /dev/kmonitor (which will happen automatically when we + * exit.) + */ + exit(0); +} + +int main(int argc, char *argv[]) +{ +... + + /* + * kmonitor will notify us that the target process has exited + * by sending us a real-time signal with the payload containing + * the event that triggered the notification. + */ + action.sa_sigaction = target_exit_handler; + action.sa_flags = SA_SIGINFO; + if (-1 == sigaction(SIGRTMIN, &action, NULL)) { + perror("sigaction"); + exit(-1); + } + + /* + * The kmonitor is implemented as misc char device, so the + * file that needs to be opened (assumed to be /dev/kmonitor + * in this example) is a char device with a major number of 10 + * and a minor number of 221. + * + * mknod /dev/kmonitor c 10 221 + */ + fd = open("/dev/kmonitor", O_WRONLY); + if (-1 == fd) { + perror("open /dev/kmonitor"); + exit(-1); + } + + /* + * To sign up for notification of an arbitrary event on an + * arbitrary process then we send the KMONITOR_IOW_REGISTER + * command to the device via the ioctl system call. + * + * We indicate the target process and event by sending a + * kmonitor_cmd structure. + * + * NOTE: The 'type' field in the structure is actually + * a bitmask, so it is possible to register for + * multiple events on a given target process in one + * ioctl call. The possible events are... + * #define KMONITOR_THREAD_CREATE 0x01 + * #define KMONITOR_THREAD_ABORT 0x02 + * #define KMONITOR_THREAD_EXIT 0x04 + * #define KMONITOR_PROCESS_FORK 0x08 + * #define KMONITOR_PROCESS_ABORT 0x10 + * #define KMONITOR_PROCESS_EXEC 0x20 + * #define KMONITOR_PROCESS_EXIT 0x40 + */ + hdr.signal = SIGRTMIN; + hdr.pid = args.pid; + hdr.type = KMONITOR_PROCESS_EXIT; + if (-1 == ioctl(fd, KMONITOR_IOW_REGISTER, &hdr)) { + perror("ioctl"); + exit(-1); + } + + /* + * In this very simple example all we need to do is wait + * for a signal to be sent. The signal handler will exit + * when it is notified of the target process exiting. + */ + sigemptyset(&empty_mask); + sigsuspend(&empty_mask); + + /* + * kmonitor will perform a cleanup of all request a given + * monitoring process has made, so it is required to deregister + * each of the specific request. + * + * If for some reason a monitoring process wanted to deregister + * a specific request, then the procedure is just like registering, + * other then the ioctl command is KMONITOR_IOW_DEREGISTER. + */ + close(fd); + exit (0); +} + + diff -Nru a/drivers/char/Kconfig b/drivers/char/Kconfig --- a/drivers/char/Kconfig 2004-06-14 11:24:08 -07:00 +++ b/drivers/char/Kconfig 2004-06-14 11:24:08 -07:00 @@ -974,5 +974,15 @@ out to lunch past a certain margin. It can reboot the system or merely print a warning. +config KMONITOR + bool "Kmonitor driver" + help + The kmonitor driver implements a kernel level non-intrusive + mechanism for rapidly notifying a monitoring user space process + of key (process/thread creation/exit) kernel events. For more + info see Documentation/kmonitor.txt + + If in doubt, say 'N'. + endmenu diff -Nru a/drivers/char/Makefile b/drivers/char/Makefile --- a/drivers/char/Makefile 2004-06-14 11:24:08 -07:00 +++ b/drivers/char/Makefile 2004-06-14 11:24:08 -07:00 @@ -79,6 +79,7 @@ obj-$(CONFIG_DRM) += drm/ obj-$(CONFIG_PCMCIA) += pcmcia/ obj-$(CONFIG_IPMI_HANDLER) += ipmi/ +obj-$(CONFIG_KMONITOR) += kmonitor.o obj-$(CONFIG_HANGCHECK_TIMER) += hangcheck-timer.o diff -Nru a/drivers/char/kmonitor.c b/drivers/char/kmonitor.c --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/drivers/char/kmonitor.c 2004-06-14 11:24:08 -07:00 @@ -0,0 +1,336 @@ +/* + * linux/kmonitor.c + * + * Copyright (C) 2004 Intel Corporation. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public + * License v2.0 as published by the Free Software Foundation; + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 021110-1307, USA. + * + * Authors: Atul Sabharwal + * + * The kmonitor driver implements a kernel level non-intrusive + * mechanism for rapidly notifying a monitoring user space process + * of key (process/thread creation/exit) kernel events. + * + * See Documentation/kmonitor.txt for more details + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * kmonitor maintains a database of resources containing: + * - the pid of the process being monitored (target) + * - the pid of process that should be notified (monitor) + * - an event mask + * - a signal number to notify the monitor with + * - a list_head + * + * To improve scalability, a hash of linked listed is maintained + * with a per bucket read-write lock. KMONITOR_BITS defines the + * order of the list size, so setting KMONITOR_BITS to 8 would translate + * to 256 buckets. Using a hash of linked list improves the order of the + * search from an O(n) to O(n/m) where n is the number of resources and + * m is the number of buckets. + * + * Note that since we are using a per bucket read-write lock, the number + * of buckets also as an effect on SMP performance since the smaller the + * list of resources in each bucket, the less likely a processor will + * spin waiting for another processor to finish writing to the same list. + */ + +struct kmonitor_bucket +{ + struct list_head list; + rwlock_t lock; +}; + +#define KMONITOR_BITS 0x8 + +struct kmonitor_bucket kmonitor_resources[1<monitor == current->pid && r->target == target) { + /* + * There is an existing resource for this + * target/monitor combination so just flip + * a bit in the event mask indicating that + * this monitor also wants to be notified + * for this type of event. + */ + r->event_mask |= type; + r->signal = signal; + DBG("Added %i to existing res", type); + read_unlock(&kmonitor_resources[bucket].lock); + return 0; + } + } + read_unlock(&kmonitor_resources[bucket].lock); + + /* + * This is the first event registered for this target + * on this monitor. Allocate a new resource from our + * cache and add the resource to the global list. + * + * Note: There is no race condition between the top half & the + * bottom part of this function as if multiple monitors are active, + * each will have a unique resource for itself. So, the function + * is SMP safe. + */ + r = kmem_cache_alloc(kmonitor_cache, SLAB_KERNEL); + if (!r) + return -ENOMEM; + + r->target = target; + r->monitor = current->pid; + r->event_mask = type; + r->signal = signal; + write_lock(&kmonitor_resources[bucket].lock); + list_add(&r->rlist, &kmonitor_resources[bucket].list); + write_unlock(&kmonitor_resources[bucket].lock); + return 0; +} + +static int kmonitor_remove(pid_t target, int type) +{ + struct list_head *tmp, *next; + int ret = -EINVAL; + int bucket = khash(target); + + TRACE("%i, %i", target, type); + + write_lock(&kmonitor_resources[bucket].lock); + list_for_each_safe(tmp, next, &kmonitor_resources[bucket].list) { + struct kmonitor_res *r = to_kmonitor_res(tmp); + if (r->monitor == current->pid && r->target == target) { + r->event_mask &= ~type; + if (!r->event_mask) { + /* No more events so go ahead and cleanup */ + list_del(tmp); + kmem_cache_free(kmonitor_cache, r); + } + ret = 0; + break; + } + } + + write_unlock(&kmonitor_resources[bucket].lock); + return ret; +} + +void __kmonitor_notify_event(struct task_struct *tsk, int type) +{ + struct siginfo info; + struct list_head *tmp, *next; + int bucket = khash(current->pid); + + read_lock(&kmonitor_resources[bucket].lock); + list_for_each_safe(tmp,next,&kmonitor_resources[bucket].list) { + struct kmonitor_res *r = to_kmonitor_res(tmp); + if (r->target == current->pid && type & r->event_mask) { + info.si_signo = r->signal; + info.si_code = SI_QUEUE; + info.si_int = type; + info.si_pid = tsk->pid; + info.si_uid = tsk->uid; + kill_proc_info(r->signal, &info, r->monitor); + } + } + read_unlock(&kmonitor_resources[bucket].lock); +} + +static int kmonitor_open(struct inode *inode, struct file *file) +{ + atomic_inc(&kmonitor_active); + return 0; +} + +static int kmonitor_release(struct inode *inode, struct file *file) +{ + struct list_head *tmp, *next; + int i; + + TRACE("%p, %p", inode, file); + atomic_dec(&kmonitor_active); + + /* + * Remove any resources associated with this monitor + */ + for (i=0; i<(1<monitor == current->pid) { + list_del(tmp); + kmem_cache_free(kmonitor_cache, r); + } + } + write_unlock(&kmonitor_resources[i].lock); + } + + return 0; +} + +static int kmonitor_ioctl(struct inode *inode, struct file *file, + unsigned int cmd, unsigned long arg) +{ + struct kmonitor_cmd hdr; + + TRACE("%p, %p, %i, %i", inode, file, (int)cmd, (int)arg); + if (copy_from_user((struct kmonitor_cmd *)&hdr, + (struct kmonitor_cmd *)arg, + sizeof(struct kmonitor_cmd))) + return -EFAULT; + + switch (cmd) { + case KMONITOR_IOW_REGISTER: + return kmonitor_add(hdr.pid, hdr.type, hdr.signal); + case KMONITOR_IOW_DEREGISTER: + return kmonitor_remove(hdr.pid, hdr.type); + } + + DBG("Unexpected ioctl, %i", cmd); + return -EINVAL; +} + +static struct file_operations kmonitor_fops = { + .owner = THIS_MODULE, + .llseek = no_llseek, + .open = kmonitor_open, + .release = kmonitor_release, + .ioctl = kmonitor_ioctl, +}; + +static struct miscdevice kmonitor_miscdev = { + .minor = KMONITOR_MINOR, + .name = "kmonitor", + .fops = &kmonitor_fops, +}; + +static int __init kmonitor_init(void) +{ + int ret, i; + + TRACE("void"); + + for (i=0; i<(1< #include #include +#include #include #include @@ -1144,6 +1145,7 @@ free_arg_pages(&bprm); /* execve success */ + kmonitor_notify_event(current, KMONITOR_PROCESS_EXEC); security_bprm_free(&bprm); return retval; } diff -Nru a/include/linux/kmonitor.h b/include/linux/kmonitor.h --- /dev/null Wed Dec 31 16:00:00 196900 +++ b/include/linux/kmonitor.h 2004-06-14 11:24:08 -07:00 @@ -0,0 +1,62 @@ +/* + * + * linux/kmonitor.h + * + * Copyright (C) 2004 Intel Corporation. All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public + * License v2.0 as published by the Free Software Foundation; + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public + * License along with this program; if not, write to the + * Free Software Foundation, Inc., 59 Temple Place - Suite 330, + * Boston, MA 021110-1307, USA. + * + * Authors: Atul Sabharwal + * + */ +#ifndef _LINUX_KMONITOR_H_ +#define _LINUX_KMONITOR_H_ + +#include + +#define KMONITOR_THREAD_CREATE 0x01 +#define KMONITOR_THREAD_ABORT 0x02 +#define KMONITOR_THREAD_EXIT 0x04 +#define KMONITOR_PROCESS_FORK 0x08 +#define KMONITOR_PROCESS_ABORT 0x10 +#define KMONITOR_PROCESS_EXEC 0x20 +#define KMONITOR_PROCESS_EXIT 0x40 + +struct kmonitor_cmd +{ + pid_t pid; + int type; + int signal; +}; + +#define KMONITOR_IOW_REGISTER _IOW(0xDE, 1, struct kmonitor_cmd) +#define KMONITOR_IOW_DEREGISTER _IOW(0xDE, 2, struct kmonitor_cmd) + +#ifdef __KERNEL__ +#include + +extern atomic_t kmonitor_active; +extern void __kmonitor_notify_event(struct task_struct *tsk, int type); + +static inline void kmonitor_notify_event( struct task_struct *tsk, int type) +{ +#ifdef CONFIG_KMONITOR + if (atomic_read(&kmonitor_active)) + __kmonitor_notify_event(tsk, type); +#endif /* CONFIG_KMONITOR */ +} +#endif /* __KERNEL__ */ +#endif /* _LINUX_KMONITOR_H_ */ + diff -Nru a/include/linux/miscdevice.h b/include/linux/miscdevice.h --- a/include/linux/miscdevice.h 2004-06-14 11:24:08 -07:00 +++ b/include/linux/miscdevice.h 2004-06-14 11:24:08 -07:00 @@ -35,6 +35,7 @@ #define SGI_USEMACLONE 151 #define TUN_MINOR 200 +#define KMONITOR_MINOR 221 struct device; diff -Nru a/kernel/exit.c b/kernel/exit.c --- a/kernel/exit.c 2004-06-14 11:24:08 -07:00 +++ b/kernel/exit.c 2004-06-14 11:24:08 -07:00 @@ -22,6 +22,7 @@ #include #include #include +#include #include #include @@ -748,6 +749,11 @@ */ _raw_write_unlock(&tasklist_lock); local_irq_enable(); + + if (tsk->pid == tsk->tgid) + kmonitor_notify_event(tsk, KMONITOR_PROCESS_EXIT); + else + kmonitor_notify_event(tsk, KMONITOR_THREAD_EXIT); /* If the process is dead, release it - nobody will wait for it */ if (state == TASK_DEAD) diff -Nru a/kernel/fork.c b/kernel/fork.c --- a/kernel/fork.c 2004-06-14 11:24:08 -07:00 +++ b/kernel/fork.c 2004-06-14 11:24:08 -07:00 @@ -41,6 +41,7 @@ #include #include #include +#include /* The idle threads do not count.. * Protected by write_lock_irq(&tasklist_lock) @@ -1167,6 +1168,11 @@ if (!IS_ERR(p)) { struct completion vfork; + + if (p->pid == p->tgid) + kmonitor_notify_event(p, KMONITOR_PROCESS_FORK); + else + kmonitor_notify_event(p, KMONITOR_THREAD_CREATE); if (clone_flags & CLONE_VFORK) { p->vfork_done = &vfork; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce From pj@sgi.com Wed Jun 16 08:10:48 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 08:10:52 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GFAlgi031786 for ; Wed, 16 Jun 2004 08:10:47 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5GF0Ghv000357 for ; Wed, 16 Jun 2004 08:00:16 -0700 Received: from mtv-vpn-pj.corp.sgi.com (mtv-vpn-hw-pj-1.corp.sgi.com [134.15.25.218]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id i5GExnCd17210819; Wed, 16 Jun 2004 08:00:05 -0700 (PDT) Date: Wed, 16 Jun 2004 08:11:01 -0700 From: Paul Jackson To: Peter Williams Cc: erikj@subway.americas.sgi.com, pagg@oss.sgi.com Subject: Re: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes] Message-Id: <20040616081101.399343ab.pj@sgi.com> In-Reply-To: <40CF7EFF.5090200@bigpond.net.au> References: <40CF7EFF.5090200@bigpond.net.au> Organization: SGI X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 29 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: pagg > This seems to be doing what PAGG does (or should do). I'm not a PAGG expert, so my questions here are not definitive of what PAGG does or should do. However, I will confess to some puzzlement over your suggestion that such is the same as it is for the kernel monitor described in your note. I certainly see _some_ commonality in mechanisms, with one or another flavor of flexible and dynamically modified hooks in places such as fork and exit. But other mechanisms, such as filtering and queueing of events for transmission to a user deamon, don't match anything I was aware of in PAGG. And other mechanisms that I thought existed in PAGG, such as a sort of named callout to code in loadable kernel modules to be executed at such hooks, and such as some way of grouping related tasks which are to receive common treatment, I didn't notice, in my cursory reading, of this monitor mechanism. And I am at a loss to guess what you know that PAGG "should" do distinct from what it does. Perhaps it would help if you stated explicitly what you understand PAGG does, and should do, rather than leaving that as unspoken implication. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From pwil3058@bigpond.net.au Wed Jun 16 16:13:22 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 16:13:25 -0700 (PDT) Received: from gizmo02ps.bigpond.com (gizmo02ps.bigpond.com [144.140.71.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GNDLgi031063 for ; Wed, 16 Jun 2004 16:13:22 -0700 Received: (qmail 31053 invoked from network); 16 Jun 2004 23:06:06 -0000 Received: from unknown (HELO psmam01.bigpond.com) (144.135.25.69) by gizmo02ps.bigpond.com with SMTP; 16 Jun 2004 23:06:06 -0000 Received: from cpe-203-45-94-214.nsw.bigpond.net.au ([203.45.94.214]) by psmam01.bigpond.com(MAM REL_3_4_2a 71/14837331) with SMTP id 14837331; Thu, 17 Jun 2004 09:13:14 +1000 Message-ID: <40D0D40A.3070803@bigpond.net.au> Date: Thu, 17 Jun 2004 09:13:14 +1000 From: Peter Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jackson CC: erikj@subway.americas.sgi.com, pagg@oss.sgi.com Subject: Re: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes] References: <40CF7EFF.5090200@bigpond.net.au> <20040616081101.399343ab.pj@sgi.com> In-Reply-To: <20040616081101.399343ab.pj@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 30 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pwil3058@bigpond.net.au Precedence: bulk X-list: pagg Paul Jackson wrote: >>This seems to be doing what PAGG does (or should do). > > > I'm not a PAGG expert, so my questions here are not definitive of what > PAGG does or should do. > > However, I will confess to some puzzlement over your suggestion that > such is the same as it is for the kernel monitor described in your note. I guess that I really meant an overlap in functionality rather than an exact match :-) > > I certainly see _some_ commonality in mechanisms, with one or another > flavor of flexible and dynamically modified hooks in places such as fork > and exit. This is what I meant to draw to your attention. > > But other mechanisms, such as filtering and queueing of events for > transmission to a user deamon, don't match anything I was aware of in > PAGG. To my mind this part is just something that could be implemented with PAGG if you wanted to. > > And other mechanisms that I thought existed in PAGG, such as a sort of > named callout to code in loadable kernel modules to be executed at such > hooks, I don't think that PAGG has this but I'm sure that a PAGG client module could do that. > and such as some way of grouping related tasks which are to > receive common treatment, I didn't notice, in my cursory reading, of > this monitor mechanism. No. But what it does have is callbacks in the same place in the kernel that PAGG wants to put callbacks. I can't see multiple callback hooks in the same place getting accepted into the vanilla kernel so if this one was accepted it would make it hard for PAGG to get accepted. My e-mail was meant as a "heads up" on this possibility. > > And I am at a loss to guess what you know that PAGG "should" do distinct > from what it does. I'm referring to the extensions to PAGG that I've posted on this list. They add callbacks for changes to ruid, rgid and CPU affinity (mask) to the callback in exec(). > > Perhaps it would help if you stated explicitly what you understand PAGG > does, and should do, rather than leaving that as unspoken implication. See previous paragraph. I wasn't being critical and I'm sorry if you interpreted it that way. I like PAGG very much and in addition to the patches mentioned above I have sent patches that implement the "task initialization" mechanism during registration of a client and also code that automatically cleans up during deregistration which makes writing clients much simpler and greatly decreases the chances of leaving the kernel in an unstable state. As I understand it, Erik has been too busy with other matters to incorporate these changes into the official version of PAGG yet but he promises that he will get around to it soon. Sorry if I offended you Peter PS I was hoping that, as a result of my e-mail, somebody from PAGG would contact this guy and try to talk him into doing his stuff using the PAGG interface rather than inventing another one. -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce From pwil3058@bigpond.net.au Wed Jun 16 16:17:41 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 16:17:43 -0700 (PDT) Received: from gizmo09ps.bigpond.com (gizmo09ps.bigpond.com [144.140.71.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5GNHegi031803 for ; Wed, 16 Jun 2004 16:17:41 -0700 Received: (qmail 5615 invoked from network); 16 Jun 2004 23:06:53 -0000 Received: from unknown (HELO psmam01.bigpond.com) (144.135.25.69) by gizmo09ps.bigpond.com with SMTP; 16 Jun 2004 23:06:53 -0000 Received: from cpe-203-45-94-214.nsw.bigpond.net.au ([203.45.94.214]) by psmam01.bigpond.com(MAM REL_3_4_2a 71/14840779) with SMTP id 14840779; Thu, 17 Jun 2004 09:17:31 +1000 Message-ID: <40D0D50B.2040509@bigpond.net.au> Date: Thu, 17 Jun 2004 09:17:31 +1000 From: Peter Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jackson CC: Peter Williams , erikj@subway.americas.sgi.com, pagg@oss.sgi.com Subject: Re: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes] References: <40CF7EFF.5090200@bigpond.net.au> <20040616081101.399343ab.pj@sgi.com> <40D0D40A.3070803@bigpond.net.au> In-Reply-To: <40D0D40A.3070803@bigpond.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 31 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pwil3058@bigpond.net.au Precedence: bulk X-list: pagg Peter Williams wrote: > Paul Jackson wrote: > >>> This seems to be doing what PAGG does (or should do). >> >> >> >> I'm not a PAGG expert, so my questions here are not definitive of what >> PAGG does or should do. >> >> However, I will confess to some puzzlement over your suggestion that >> such is the same as it is for the kernel monitor described in your note. > > > I guess that I really meant an overlap in functionality rather than an > exact match :-) > >> >> I certainly see _some_ commonality in mechanisms, with one or another >> flavor of flexible and dynamically modified hooks in places such as fork >> and exit. > > > This is what I meant to draw to your attention. > >> >> But other mechanisms, such as filtering and queueing of events for >> transmission to a user deamon, don't match anything I was aware of in >> PAGG. > > > To my mind this part is just something that could be implemented with > PAGG if you wanted to. > >> >> And other mechanisms that I thought existed in PAGG, such as a sort of >> named callout to code in loadable kernel modules to be executed at such >> hooks, > > > I don't think that PAGG has this but I'm sure that a PAGG client module > could do that. > >> and such as some way of grouping related tasks which are to >> receive common treatment, I didn't notice, in my cursory reading, of >> this monitor mechanism. > > > No. But what it does have is callbacks in the same place in the kernel > that PAGG wants to put callbacks. I can't see multiple callback hooks > in the same place getting accepted into the vanilla kernel so if this > one was accepted it would make it hard for PAGG to get accepted. My > e-mail was meant as a "heads up" on this possibility. > >> >> And I am at a loss to guess what you know that PAGG "should" do distinct >> from what it does. > > > I'm referring to the extensions to PAGG that I've posted on this list. > They add callbacks for changes to ruid, rgid and CPU affinity (mask) to > the callback in exec(). > >> >> Perhaps it would help if you stated explicitly what you understand PAGG >> does, and should do, rather than leaving that as unspoken implication. > > > See previous paragraph. I wasn't being critical and I'm sorry if you > interpreted it that way. > > I like PAGG very much and in addition to the patches mentioned above I > have sent patches that implement the "task initialization" mechanism > during registration of a client and also code that automatically cleans > up during deregistration which makes writing clients much simpler and > greatly decreases the chances of leaving the kernel in an unstable > state. As I understand it, Erik has been too busy with other matters to > incorporate these changes into the official version of PAGG yet but he > promises that he will get around to it soon. > > Sorry if I offended you > Peter > PS I was hoping that, as a result of my e-mail, somebody from PAGG would > contact this guy and try to talk him into doing his stuff using the PAGG > interface rather than inventing another one. I just noticed on LKML that someone else has suggested that these guys look at PAGG (and some other options) :-) -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce From pj@sgi.com Wed Jun 16 17:26:48 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 17:27:07 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H0Qmgi004707 for ; Wed, 16 Jun 2004 17:26:48 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5H0JWhv003599 for ; Wed, 16 Jun 2004 17:19:32 -0700 Received: from mtv-vpn-pj.corp.sgi.com (mtv-vpn-hw-pj-1.corp.sgi.com [134.15.25.218]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id i5H0JBCd17296767; Wed, 16 Jun 2004 17:19:27 -0700 (PDT) Date: Wed, 16 Jun 2004 17:30:26 -0700 From: Paul Jackson To: Peter Williams Cc: pwil3058@bigpond.net.au, erikj@subway.americas.sgi.com, pagg@oss.sgi.com Subject: Re: [Fwd: [Announce] Non Invasive Kernel Monitor for threads/processes] Message-Id: <20040616173026.751483d1.pj@sgi.com> In-Reply-To: <40D0D50B.2040509@bigpond.net.au> References: <40CF7EFF.5090200@bigpond.net.au> <20040616081101.399343ab.pj@sgi.com> <40D0D40A.3070803@bigpond.net.au> <40D0D50B.2040509@bigpond.net.au> Organization: SGI X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 32 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pj@sgi.com Precedence: bulk X-list: pagg > See previous paragraph. I wasn't being critical and I'm sorry if you > interpreted it that way. Nah - no sweat - I was just in the usual state of caution that nerds lapse into when something confuses them ... ;). Your further explanations make sense, and I am at ease now. Thanks. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From erikj@subway.americas.sgi.com Wed Jun 16 17:56:34 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 17:56:39 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H0uYgi006089 for ; Wed, 16 Jun 2004 17:56:34 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5H0shhv003774 for ; Wed, 16 Jun 2004 17:54:43 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5H0sgKe40688862 for ; Wed, 16 Jun 2004 19:54:42 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5H0sgoo2177146 for ; Wed, 16 Jun 2004 19:54:42 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5H0skq01577979 for ; Wed, 16 Jun 2004 19:54:46 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5H0skvQ1577957 for ; Wed, 16 Jun 2004 19:54:46 -0500 (CDT) Date: Wed, 16 Jun 2004 19:54:46 -0500 From: Erik Jacobson To: pagg@oss.sgi.com Subject: 2.6.7 pagg patch available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 33 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg I've made available a pagg patch for the 2.6.7 kernel. It's named linux-2.6.7-pagg.patch Click on the 'download' link on the left of the following web page: oss.sgi.com/projects/pagg Note: The job patch did not need to change for the new kernel however I have copied the latest 2.6.6 job patch to linux-2.6.7-job.patch just to avoid confusion. -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From pwil3058@bigpond.net.au Wed Jun 16 18:51:48 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 18:51:50 -0700 (PDT) Received: from gizmo11ps.bigpond.com (gizmo11ps.bigpond.com [144.140.71.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H1pkgi007566 for ; Wed, 16 Jun 2004 18:51:47 -0700 Received: (qmail 19102 invoked from network); 17 Jun 2004 01:40:26 -0000 Received: from unknown (HELO psmam01.bigpond.com) (144.135.25.69) by gizmo11ps.bigpond.com with SMTP; 17 Jun 2004 01:40:26 -0000 Received: from cpe-203-45-94-214.nsw.bigpond.net.au ([203.45.94.214]) by psmam01.bigpond.com(MAM REL_3_4_2a 71/14961530) with SMTP id 14961530; Thu, 17 Jun 2004 11:51:40 +1000 Message-ID: <40D0F92B.1080104@bigpond.net.au> Date: Thu, 17 Jun 2004 11:51:39 +1000 From: Peter Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Jacobson CC: pagg@oss.sgi.com Subject: Re: 2.6.7 pagg patch available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 34 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pwil3058@bigpond.net.au Precedence: bulk X-list: pagg Erik Jacobson wrote: > I've made available a pagg patch for the 2.6.7 kernel. > It's named linux-2.6.7-pagg.patch > > Click on the 'download' link on the left of the following web page: > oss.sgi.com/projects/pagg > > Note: The job patch did not need to change for the new kernel however I > have copied the latest 2.6.6 job patch to linux-2.6.7-job.patch just to > avoid confusion. > > -- > Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota > > Did you include my modifications in this patch? -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce From erikj@subway.americas.sgi.com Wed Jun 16 19:51:46 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 19:51:55 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H2pkgi008917 for ; Wed, 16 Jun 2004 19:51:46 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5H2doiv018486 for ; Wed, 16 Jun 2004 21:39:50 -0500 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5H2dnKe40797308; Wed, 16 Jun 2004 21:39:49 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5H2dnoo2280841; Wed, 16 Jun 2004 21:39:49 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5H2dsq01578428; Wed, 16 Jun 2004 21:39:54 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5H2drU61578271; Wed, 16 Jun 2004 21:39:54 -0500 (CDT) Date: Wed, 16 Jun 2004 21:39:53 -0500 From: Erik Jacobson To: Peter Williams cc: pagg@oss.sgi.com Subject: Re: 2.6.7 pagg patch available In-Reply-To: <40D0F92B.1080104@bigpond.net.au> Message-ID: References: <40D0F92B.1080104@bigpond.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 35 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg > Did you include my modifications in this patch? All I did was resolve the build issues for 2.6.7 and tested to be sure it still worked. I sort of have a dilema here. We're going to post pagg and job to LKML tomorrow and I don't know how to test all the changes. You had mentioned you didn't think adding the new features would make it harder to accept. But, on the other hand, what we have now is well understood and we have test cases for most situations. The pagg code we have no has been through the ringer once already. What do you think? Any other thoughts? Erik From pwil3058@bigpond.net.au Wed Jun 16 20:19:08 2004 Received: with ECARTIS (v1.0.0; list pagg); Wed, 16 Jun 2004 20:19:14 -0700 (PDT) Received: from gizmo11ps.bigpond.com (gizmo11ps.bigpond.com [144.140.71.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5H3J6gi009918 for ; Wed, 16 Jun 2004 20:19:07 -0700 Received: (qmail 1065 invoked from network); 17 Jun 2004 03:07:47 -0000 Received: from unknown (HELO psmam01.bigpond.com) (144.135.25.69) by gizmo11ps.bigpond.com with SMTP; 17 Jun 2004 03:07:47 -0000 Received: from cpe-203-45-94-214.nsw.bigpond.net.au ([203.45.94.214]) by psmam01.bigpond.com(MAM REL_3_4_2a 71/15032192) with SMTP id 15032192; Thu, 17 Jun 2004 13:19:00 +1000 Message-ID: <40D10DA4.2080205@bigpond.net.au> Date: Thu, 17 Jun 2004 13:19:00 +1000 From: Peter Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Jacobson CC: pagg@oss.sgi.com Subject: Re: 2.6.7 pagg patch available References: <40D0F92B.1080104@bigpond.net.au> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 36 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: pwil3058@bigpond.net.au Precedence: bulk X-list: pagg Erik Jacobson wrote: >>Did you include my modifications in this patch? > > > All I did was resolve the build issues for 2.6.7 and tested to be sure it > still worked. > > I sort of have a dilema here. We're going to post pagg and job to LKML > tomorrow and I don't know how to test all the changes. > > You had mentioned you didn't think adding the new features would make it > harder to accept. But, on the other hand, what we have now is well > understood and we have test cases for most situations. The pagg code we > have no has been through the ringer once already. But it's incomplete and doesn't even completely implement its interface. > > What do you think? Any other thoughts? I think that you should at least put the changes that I sent that implement "per task initialization" during registration and do the automatic clean up at deregistration. Without the first of these you have a callback in your interface which doesn't get used (and that's bad). Without the second of these writing a "safe" client is much harder than it needs to be. The current implementation refuses to deregister if the client still has paggs attached to any tasks and this can lead to the system getting into an inconsistent state during the unloading of a client kernel module. My changes use the IMHO better option of detaching these paggs and calling the clients detach() callback on them which means that writing a client that loads and unloads safely is a doddle. The extra callbacks for ruid, rgid and CPU affinity are a different issue but I think that they will be acceptable to LKML. They have the advantage of making PAGG more useful and increasing the chances of more clients being created and made public (and also decreases the chances someone else will create a competing patch to PAGG because PAGG doesn't do enough). On the other hand, I don't think that they're urgent and they can wait until later if you're worried about rocking the boat. Looking at the NIKM announcement (that I forwarded you earlier) in more detail it would appear that attach(), detach() and exec() are sufficient for their purposes (you just have to convince them to use it :-)) so leaving these changes out is a safe option for now. Peter PS I think that I sent my patches in two parts so that you can apply the essential (or more precisely the ones that I think are essential :-)) ones without getting the others. BTW the "essential" patches only modify the PAGG files and don't touch any other kernel files so they should apply to your 2.6.7 version without any trouble. -- Peter Williams pwil3058@bigpond.net.au "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce From erikj@subway.americas.sgi.com Thu Jun 17 06:02:26 2004 Received: with ECARTIS (v1.0.0; list pagg); Thu, 17 Jun 2004 06:02:29 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5HD2Pgi018703 for ; Thu, 17 Jun 2004 06:02:25 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5HDAobg028502 for ; Thu, 17 Jun 2004 06:10:50 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5HD2JKe40745221; Thu, 17 Jun 2004 08:02:19 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5HD2Joo2275117; Thu, 17 Jun 2004 08:02:19 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5HD2Lq01570177; Thu, 17 Jun 2004 08:02:21 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5HD2L4A1590224; Thu, 17 Jun 2004 08:02:21 -0500 (CDT) Date: Thu, 17 Jun 2004 08:02:21 -0500 From: Erik Jacobson To: Peter Williams cc: pagg@oss.sgi.com Subject: Re: 2.6.7 pagg patch available In-Reply-To: <40D10DA4.2080205@bigpond.net.au> Message-ID: References: <40D0F92B.1080104@bigpond.net.au> <40D10DA4.2080205@bigpond.net.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 37 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg > But it's incomplete and doesn't even completely implement its interface. I'm just nervous that I'll have another round of edits but I understand what you're saying. I hate being difficult :) Ok - I'll take a look at the "non-rock-the-boat" patch again this morning. Erik From erikj@subway.americas.sgi.com Tue Jun 22 13:51:37 2004 Received: with ECARTIS (v1.0.0; list pagg); Tue, 22 Jun 2004 13:51:38 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MKpYgi032205 for ; Tue, 22 Jun 2004 13:51:37 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5ML0l25023388 for ; Tue, 22 Jun 2004 14:00:47 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5MKpTKe41158398 for ; Tue, 22 Jun 2004 15:51:29 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5MKpSet2671842 for ; Tue, 22 Jun 2004 15:51:28 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5MKpSGA238225 for ; Tue, 22 Jun 2004 15:51:28 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5MKpS4W238245 for ; Tue, 22 Jun 2004 15:51:28 -0500 (CDT) Date: Tue, 22 Jun 2004 15:51:28 -0500 From: Erik Jacobson To: pagg@oss.sgi.com Subject: new kernel 2.4.26 pagg patch - bug fix Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 38 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg Jay Lan discovered a bug in the 2.4 kernel pagg patch - the exec.c hook. linux-2.4.26-5 is available for download. Click on the 'download' link on the left of the following web page: oss.sgi.com/projects/pagg -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From erikj@subway.americas.sgi.com Tue Jun 22 14:57:59 2004 Received: with ECARTIS (v1.0.0; list pagg); Tue, 22 Jun 2004 14:58:01 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5MLvxgi005575 for ; Tue, 22 Jun 2004 14:57:59 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5MLq7hv019719 for ; Tue, 22 Jun 2004 14:52:07 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5MLq6Ke41130056 for ; Tue, 22 Jun 2004 16:52:06 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5MLq6et2623619 for ; Tue, 22 Jun 2004 16:52:06 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5MLq6GA238724 for ; Tue, 22 Jun 2004 16:52:06 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5MLq5mT238620 for ; Tue, 22 Jun 2004 16:52:05 -0500 (CDT) Date: Tue, 22 Jun 2004 16:52:05 -0500 From: Erik Jacobson To: pagg@oss.sgi.com Subject: New 2.6 kernel pagg patch (bugfix only) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 39 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg Dean Roe discovered a bug in the pagg patch where we hook in to fork.c. We moved the pagg_attatch call to after sched_fork. Otherwise, sched_fork can zap us. Find linux-2.6.7-pagg.patch-2 in the regular spot... -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota From erikj@subway.americas.sgi.com Thu Jun 24 09:36:52 2004 Received: with ECARTIS (v1.0.0; list pagg); Thu, 24 Jun 2004 09:36:55 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i5OGapgi030274 for ; Thu, 24 Jun 2004 09:36:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i5OGUKiv014410 for ; Thu, 24 Jun 2004 11:30:20 -0500 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i5OGUKKe41259441 for ; Thu, 24 Jun 2004 11:30:20 -0500 (CDT) Received: from subway.americas.sgi.com (subway.americas.sgi.com [128.162.236.152]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i5OGUKet2837257 for ; Thu, 24 Jun 2004 11:30:20 -0500 (CDT) Received: from subway.americas.sgi.com (localhost [127.0.0.1]) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i5OGUJGA339747 for ; Thu, 24 Jun 2004 11:30:19 -0500 (CDT) Received: from localhost (erikj@localhost) by subway.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) with ESMTP id i5OGUJlq339814 for ; Thu, 24 Jun 2004 11:30:19 -0500 (CDT) Date: Thu, 24 Jun 2004 11:30:19 -0500 From: Erik Jacobson To: pagg@oss.sgi.com Subject: New pagg and job patches available for 2.6.7 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 40 X-ecartis-version: Ecartis v1.0.0 Sender: pagg-bounce@oss.sgi.com Errors-to: pagg-bounce@oss.sgi.com X-original-sender: erikj@subway.americas.sgi.com Precedence: bulk X-list: pagg Howdy. Peter Williams provided code to implement the init function pointer functionality in pagg. This function (pointed to in the pagg hook) is used when the module is loaded to attach existing processes to a default container as defined by the pagg module. This is optional... We bounced it back and fourth a couple times trying to resolve all the locking issues. Peter had some other suggestions that we also implemented. One small change required that we re-spin the job patch. Please find linux-2.6.7-pagg.patch-3 and linux-2.6.7-job.patch-2 on oss.sgi.com/projects/pagg - click the download link on the left. I'll make a 2.4.26 version of these two patches later. -- Erik Jacobson - Linux System Software - Silicon Graphics - Eagan, Minnesota