Re: [PATCH] include/linux/slab.h: new KFREE() macro.

[Vadim Lobanov]

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()
agenda.

> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/