On Thu, Jul 19, 2012 at 09:57:50AM -0700, Tejun Heo wrote:

Hello,

On Thu, Jul 19, 2012 at 09:48:45AM +0900, Minchan Kim wrote:

quoted

quoted

Maybe trigger warning if some fields which have to be zero aren't?

It's not good because this causes adding new WARNING in that part
whenever we add new field in pgdat. It nullify this patch's goal.

Maybe just do that on some fields?  The goal is catching unlikely case
where archs leave the struct with garbage data.  I don't think full
coverage is an absolute requirement.  Or reorganize the fields such

IIUC your previous reply, archs can use any fields during boot.
If so, we need full coverage for catching it.

that fields unused by boot code is collected at the top so that it can
be memset after certain offset?

If the fields touched by boot are limited, it's good idea.
Let me ask a question.
What fields are used by boot code before calling free_area_init_node
(excpet struct bootmem_data *bdata)?

But, really, given how the structure is used, I think we're better off
just making sure all archs clear them and maybe have a sanity check or
two just in case.  It's not like breakage on that front is gonna be
subtle.

Of course, it seems all archs seems to zero-out already as I mentioned
(Not sure, MIPS) but Andrew doesn't want it. Andrew?

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>