[lkml]   [2007]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] include/linux/slab.h: new KFREE() macro.
    On Sun, 2007-01-07 at 20:09 -0800, Amit Choudhary wrote:
    > I have already explained it earlier. I will try again. You will not need free_2: and free_1: with
    > KFREE(). You will only need one free: with KFREE.

    So, to rephrase, your stated goal is to get rid of any non-singular goto
    labels in function error handling paths? Aside from sounding trippy in a
    non-conformist kind of way, what benefits will this give to the kernel?

    I ask this because there's already one easy-to-spot downside: you'll end
    up calling kfree(NULL) a bunch of times that can be, and should be,
    avoided. Whereas turning my computer into a better space-heater using
    noops (like repeated kfree(NULL) calls) may be a noble goal, I'd much
    rather not waste this planet's limited resources unnecessarily.

    > Also, let's say that count is different for each array? Then how do you propose that memory be
    > allocated in one pass?

    The parameters to a '+' operator need not be equivalent.

    > I have scanned the whole kernel to check whether people are checking for return values of kmalloc,
    > I found that at many places they don't and have sent patches for them. Now, this too is brain
    > damaged code. And during the scan I saw examples of what I described earlier.

    These cases should be fixed independently of any particular KFREE()

    > KFREE() can fix some of those cases.

    I am curious as to how a KFREE() macro can fix cases where people don't
    check the kmalloc() return value.

    > Below are some examples where people are doing KFREE() kind of stuff:

    I glanced at one instance, and...

    > arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c: kfree(acpi_perf_data[j]);
    > arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c- acpi_perf_data[j] = NULL;

    'acpi_perf_data' is a global and persistent data structure, where a NULL
    value actually has a specific and distinct meaning (as in
    acpi_cpufreq_cpu_init()). How you think this helps your argument with
    setting a local pointer to NULL after free is beyond me.

    -- Vadim Lobanov

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-08 08:07    [W:0.021 / U:12.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site