Message-ID: <447C2AF3.6060200@de.ibm.com>
Date: Tue, 30 May 2006 13:22:27 +0200
From: Martin Peschke <mp3@de.ibm.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Heiko Carstens <heiko.carstens@de.ibm.com>
CC: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [Patch] statistics infrastructure - update 1
References: <1148474038.2934.18.camel@dyn-9-152-230-71.boeblingen.de.ibm.com> <20060524155735.04ed777a.akpm@osdl.org> <1148941055.3005.73.camel@dyn-9-152-230-71.boeblingen.de.ibm.com> <20060530080700.GA9419@osiris.boeblingen.de.ibm.com>
In-Reply-To: <20060530080700.GA9419@osiris.boeblingen.de.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 917
Lines: 32

Heiko Carstens wrote:
>>  	case CPU_UP_PREPARE:
>>  		stat->pdata->ptrs[cpu] = statistic_alloc_ptr(stat, GFP_ATOMIC,
> 
> Why not GFP_KERNEL?

I see. Schedule() is permitted in this context. Will change it.

>> +		if (!stat->pdata->ptrs[cpu])
>> +			return -ENOMEM;
> 
> NOTIFY_BAD instead of -ENOMEM, I guess.

Not a bug, but slightly confusing. I think I will clean it up in my
next update patch.

>>  		break;
>>  	case CPU_UP_CANCELED:
>>  	case CPU_DEAD:
> 
> I think your merge code (which gets called if CPU_UP_PREPARE fails) expects
> stat->pdata->ptrs[cpu] to be non-zero, right?

That's a bug and needs fixing (just bail out if pointer if zero).

Thanks, Martin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/