x86: irq: Cut out the work done by Michel Megens.

The setting up of IRQ's was flawed. His implementation, prepared a stub
function, for which memory was allocated.

With the allocated memory, the IRQ stub code was then copied into the
allocated region, before a few pointers were set.

In future implementations, a stub will be made present, which then calls
a function pointer implemented in this stub. This can either be fetched
from a separate table, easier to implement in C, or point to a generic
function, that contains an IRQ identifying number.

This static approach might require a little more memory in systems that
don't require the entire IRQ space to be available, but it does help in
keeping the code more debuggable and understandable.

Also, maintaining a static approach, allows us to keep track of where
the code is in the future, so that we can detect whenever the EIP goes
somewhere it shouldn't (in case of a stack or heap overflow attack).

Note that in the case of detecting a stack overflow attack, the stack
should be registered in a different location to enable it to be marked
as unexecutable by the page tables.

Signed-off-by: Bart Kuivenhoven <bemkuivenhoven@gmail.com>
kbd: Fix keyboard unresponsive after early keypress

If a key was pressed but the kernel was not listening for interrupts,
the interrupt controller would wait until the previous interrupt was
handled, thus the kernel never finds out about the keypress and the
keyboard becomes unresponsive.

Signed-off-by: Bart Kuivenhoven <bemkuivenhoven@gmail.com>
build: Fix broken symlink bug

If the build binary is available, but the symlink is not yet present,
the kernel will fail to configure and build. By moving the code for
making the symlink away from the condition in which the binary has to be
fetched, we eliminate the possibility of this bug.

Signed-off-by: Bart Kuivenhoven <bemkuivenhoven@gmail.com>
mm: slab: Fix faulty size failure bug

In careful rereading of the code one potential bug became evident. The
kfree macro calls upon kmem_free. The size of the object is determined
by the sizeof operator embedded within this macro.

Exactly herein lies the theoretical bug, as the given size might be
smaller than the given object, and only larger object sizes are scanned
by this function.

To patch this issue, if the object is not found within the constraints
of the object size parameter, the search for the appropriate cache is
widened to include all caches.

Signed-off-by: Bart Kuivenhoven <bemkuivenhoven@gmail.com>