On Mon, 30 Jan 2012, Tejun Heo wrote:
Hello,
On Mon, Jan 30, 2012 at 11:58:52AM -0600, Christoph Lameter wrote:
No, NULL is never gonna be a valid return from any allocator including percpu. Percpu allocator doesn't and will never do so.
How do you prevent the percpu allocator from returning NULL? I thought the per cpu offsets can wrap around?
I thought it didn't. I rememer thinking about this and determining that NULL can't be allocated for dynamic addresses. Maybe I'm imagining things. Anyways, if it can return NULL for valid allocation, it is a bug and should be fixed.
I dont see anything that would hinder an arbitrary value to be returned. NULL is also used for the failure case. Definitely a bug.
I'm saying we don't have this for ZERO_SIZE_PTR in any meaningful way at this point. If somebody wants to implement it properly, please feel free to, but simply applying ZERO_SIZE_PTR without other changes doesn't make any sense.
We have no clean notion of how a percpu pointer needs to be handled. Both ways of handling things have drawbacks.
We don't have returned addr >= PAGE_SIZE guarantee yet but I'm fairly sure that's the only acceptable direction if we want any improvement in this area.
The ZERO_SIZE_PTR patch would not make the situation that much worse.
If the per cpu allocator happens to return NULL for a valid allocation then this allocation cannot be freed anymore since the free function checks for NULL. Most callers check the result for NULL though and will fail in other ways at a higher level. Such an allocation can only happen once and from hen on some memory is wasted.
If the per cpu allocator just happens to return ZERO_SIZE_PTR for a valid allocation then this value is going to be passed to other per cpu functions. However, the size is 0 so no actual read or write should ever take place.
On free its not going to be freed since the free function checks for ZERO_SIZE_PTR. So we have a situation almost the same as for NULL pointer.