raph: I'm very happy with how my meagre google juice has worked for me. Now if you search for "oktoberfest" on images.google.com, the first page of results shows me enjoying a stein there last year. Fame beyond my wildest dreams :-)
(Thanks again purcell for the photo!)
robocoder: Thanks for having a look, but I don't think the problem in my iptables target is the search for the "fatso" - that part looks correct to me.
Here's the snippet again. (Note that tasklist_lock does get unlocked in the code that follows this snippet!):
struct task_struct *p, *fatso = NULL;
int fatso_rss;
/* Find the "fatso" process -- the one with the most RSS */
read_lock(&tasklist_lock);
for_each_task(p) {
spin_lock(&p->mm->page_table_lock);
if (fatso == NULL || (p->mm->rss > fatso_rss)) {
fatso = p;
fatso_rss = p->mm->rss;
}
spin_unlock(&p->mm->page_table_lock);
}
The "post condition" is that fatso should always be set to the process with the most RSS, and it looks correct to me:
In the first iteration, fatso is NULL so the if will be entered, causing fatso and fatso_rss to be initialized based on the first process. The uninitialized value of fatso_rss wasn't used because fatso == NULL is true in the condition.
On each other iteration (one for each other process), if that process has more RSS then it will replace fatso. Eventually the process with the most RSS will be considered and will replace the current fatso, and then won't be replaced by another process because none has more RSS. So after all processes are considered the fatso should be the process with the most RSS.
Or am I missing something trivial?
I've been expecting the problem to be some subtle kernel issue, like perhaps it being illegal to take the process list lock from the context where iptables rules are invoked. It's certainly true that suspicions like that tend to blind one to his own embarrassing programming errors though :-). I have tried moving the "real work" into a kernel thread, but that didn't help.
I've done a small kernel hack, and it doesn't work. I suspect the problem is some deep kernel magic ("blame the compiler" :-)), so I'm hoping that posting it here will lead to some kindly kernel hacker spotting the trouble.
The idea is to make an "emergency rescue" feature for a thrasing system. Recently my desktop machine was thrashing so badly that I couldn't rsh into it, couldn't kill the X server with C-M-Backspace, and basically just couldn't get it working again. It did however have perfectly good pings times during the thrasing. I assume that the kernel was healthy but all userspace processes were swapped into oblivion, and I ended up cycling the power to recover.
The attempted solution is a kernel-space program that simply kills the process using the most physical memory. It is implemented as an iptables target, so that it can be triggered remotely by sending a magic packet that matches some special iptables rule. Fun, huh?
Here's the code for the iptables target, which freezes the whole machine when I try to use it. See the problem?
/*-*- linux-c -*- * * This is a module for recovering a system that is thrashing. When * trigged by a matched packet, it will kill the task that is using * the most physical memory (RSS). Not too subtle, but hopefully it * beats hitting the power button when userspace is totally thrashed * out of operation. * * -- luke@bluetail.com * */ #include <linux/sched.h> #include <linux/module.h> #include <linux/skbuff.h> #include <linux/ip.h> #include <linux/spinlock.h> #include <net/icmp.h> #include <net/udp.h> #include <net/tcp.h> #include <linux/netfilter_ipv4/ip_tables.h>struct in_device; #include <net/route.h>
static unsigned int ipt_killfatso_target(struct sk_buff **pskb, unsigned int hooknum, const struct net_device *in, const struct net_device *out, const void *targinfo, void *userinfo) { struct task_struct *p, *fatso = NULL; int fatso_rss; /* Find the "fatso" process -- the one with the most RSS */ read_lock(&tasklist_lock); for_each_task(p) { spin_lock(&p->mm->page_table_lock); if (fatso == NULL || (p->mm->rss > fatso_rss)) { fatso = p; fatso_rss = p->mm->rss; } spin_unlock(&p->mm->page_table_lock); } /* And kill him.. */ if (fatso != NULL) { /* presumably there is some process.. */ printk(KERN_NOTICE "killing fatso: %d", fatso->pid); force_sig(SIGKILL, fatso); } /* Unlock the task list, *after* sending the signal - this seems to be important. */ read_unlock(&tasklist_lock); return IPT_CONTINUE; }
static int ipt_killfatso_checkentry(const char *tablename, const struct ipt_entry *e, void *targinfo, unsigned int targinfosize, unsigned int hook_mask) { return 1; }
static struct ipt_target ipt_killfatso_reg = { { NULL, NULL }, "KILLFATSO", ipt_killfatso_target, ipt_killfatso_checkentry, NULL, THIS_MODULE };
static int __init init(void) { if (ipt_register_target(&ipt_killfatso_reg)) { return -EINVAL; }
return 0; }
static void __exit fini(void) { ipt_unregister_target(&ipt_killfatso_reg); }
module_init(init); module_exit(fini); /* MODULE_LICENSE("GPL"); */
Presented my paper about Distel at the Erlang conference, where my prerelease Emacs slideware package (shot1 shot2) went over really well - nothin' like executing code from inside the slides to distract people from your blathering :-). Also implemented some really nice new Distel features, like completion of Erlang modules and functions in Emacs based on the lisp-complete-symbol command for Emacs Lisp.
Great fun, the Erlang hackers are a fun bunch :-)
wlach: as an Emacs tutorial I would highly recommend Keywiz!
Did some fun stuff:
I hope the paper is interesting to Emacs hackers, though it'll take an afternoon's perusal of Concurrent Programming in Erlang to see the programming model that's being implemented.
And otherwise occupied with Erlang hacking at work. Also visited Canada, braved the first real snow of the winter in Stockholm, and some other real world things.
More hacking on my Lisp IP stack. Just got it to answer pings! Very exciting :-)
The code's a little untidy at the moment, but it's still down at 823 lines of hand-written code, and I'm pretty happy with that. I've left out everything not absolutely essential sofar, like routing, fragmentation, etc.
It also seems to me that the low-level internet protocols are a lot more straightforward than CORBA/HTTP/XML/Javathings/etc, and much better specified too. Maybe toy IP stacks could become suitable weekend-hacks like toy webservers are today - that would be pretty interesting!
Long time no diary! Many random hacks:
And, learned to use Word and Powerpoint at work - obviously signaling a great disturbance in the Force.
(I also crashed Netscape right before posting this article, and am delighted to find that Advogato preserved it.)
Of Roshambo, Bram writes:
Going random when you're down sounds like a recipe for staying down. How about going random any time you get a modest lead, in the hope of keeping it?
Me, demoncrat, and another friend have had some ultra-simple Roshambo tornaments recently, with robots written in idel. The game is included in the Idel distro if you're interested in having a crack.
You can see demoncrat's first-generation champion to get the flavour.
Did a nice-looking but nasty Lisp hack today.
Just noticed that the ICFP 2002 programming contest now has a website up. It starts on August 30, so it's probably not too soon to make sure your favourite language is installed on the contest machine.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
