Don't block – spotting possibly blocking code paths

This really boils down to the fact that when you're in an interrupt or atomic context, don't do anything that will call schedule(). Now, let's look at what happens if our interrupt handler's pseudocode looks like this:

my_interrupt()
{
    struct mys *sp;
    ack_intr();
    x = read_regX();
    sp = kzalloc(SIZE_HWBUF, GFP_KERNEL);
    if (!sp)
        return -ENOMEM;
    sp = fetch_data_from_hw();
    copy_to_user(ubuf, sp, count);
    kfree(sp);
}

Did you spot the big fat potential (though perhaps still subtle) bugs here? (Take a moment to spot them before moving on.)

First, the invocation of kzalloc() with the GFP_KERNEL flag might cause its kernel code to invoke schedule()! If it does, this will result in an "Oops," which is a kernel bug. In typical production environments, this causes the kernel to panic (as the sysctl named ...