atp

We do odd things with java, that most places would probably use C or python for. Having said that we have some very talented people who can make java do wonderful things.

However when those wonderful things require elevated privilege like CAP_NET_RAW for packet capture, we run into a problem, which is that the kernel treats any executable which has a capability assigned as being equivalent to one with the "setuid" bit set.

As Java loads shared libraries by relying on glibc doing expansion of the environment variable $ORIGIN  this can get broken by the setuid bit and some rules introduced to close an exploit.

Looks like all the experimentation has paid off.

• 800g strong white flour
• 8g yeast
• 15g salt
• squidge of vegetable oil (1-2 tablespoons)
• 300g milk
• 220g water

Mix flour, yeast, salt. Add oil and water which should be just below body temperature. Mix and add extra water until sticky. Turn out and knead for 15 mins. Tuck under so that the gluten is stretched in the right direction. Pop in a bowl, smear oil on the surface of the dough to retard evaporation.  Put in a plastic bag and leave to rise on top of a Lexmark X543 in standby mode for 1.25 hours. Knock back, and shape into an oblong + pop into greased tin. Press into corners, and leave to prove for 1 hour or so, on top of Lexmark. Slash the top, add flour, oil, nuts, whatever. Leave to recover for 10-15 mins and pop into oven at 250 degrees for 10 mins, with plenty of steam. After 10 mins, turn round and drop to 170 degrees for 50 mins.

Result

and some buns..

Yum.

This was going to be a post about the performance overhead of the linux syscall interface. However, things have changed a little since I last was seriously looking at the linux syscall interface while trying to figure out how to map the linux syscall interface to the VAX System Control Block. So this is the collection of notes I've made about how things work in more modern linux kernels.

Back then the intel version of Linux used the 0x80 software interrupt. In fact you can still find this if you look;

arch/x86/vdso/vdso32/int80.S
__kernel_vsyscall:
.LSTART_vsyscall:
        int $0x80
        ret

(All kernel code fragments are from 2.6.39 on the excellent LXR here.)

Jumping ahead a little you can see that this has been buried away in a subdirectory called vdso, which stands for virtual dynamic shared object.

VDSO is one of the more interesting things from a performance and latency point of view. In fact if you look on a recent linux distro like ubuntu 10.04 (RedHat 5.4 is too old to have vdso) you'll see this strange entry in the link table for binaries;

atp@euston:~$ ldd /bin/true
    linux-vdso.so.1 =>  (0x00007fff1afff000)
    libc.so.6 => /lib/libc.so.6 (0x00007f5708905000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f5708caf000)

 Note how there is no file system reference. Thats because linux-vdso.so.1 is actually mapped by the kernel.

The other day we hit an interesting "feature" in the linux bridge implementation.

On one of our KVM hosts, starting or stopping a virtual machine would take the host off the network, by changing its MAC address. Service was restored only by restarting the virtual machine, which would change the MAC back, or by waiting for arp caches to expire and refresh (which takes 2 hours on our firewall).

IP address conflict? No.

It was down to how the linux bridge code picks its MAC address, and how we configure our systems.

If you have an HP 6550b and its using the intel ironlake mobile graphics adaptor, you may find that ubuntu 10.04 and 10.10 don't handle the graphics properly. You'll get a black screen or a failure to start X.

The only way to boot seemed to be to use the VESA driver.

Typical errors in Xorg.0.log are;  no kernel modesetting driver detected

Put

i915.modesetting=1

into /etc/default/grub (Kernel Command Line)  and add to your current kernel boot command line in /boot/grub/grub.cfg.

UPDATE: It seems as though something has changed. I had a similar problem on a far more recent laptop (a sandybridge based dell 6420) and kernel, and it seems that the kernel parameter is now;

i915.modeset=1


So, if one doesn't work, try the other!