* Sasha Levin (levinsasha928@xxxxxxxxx) wrote: > On Mon, Oct 29, 2012 at 12:14 PM, Mathieu Desnoyers > <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > * Sasha Levin (levinsasha928@xxxxxxxxx) wrote: > >> On Mon, Oct 29, 2012 at 7:29 AM, Mathieu Desnoyers > >> <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > >> > * Sasha Levin (levinsasha928@xxxxxxxxx) wrote: > >> >> + > >> >> + for (i = 0; i < sz; i++) > >> >> + INIT_HLIST_HEAD(&ht[sz]); > >> > > >> > ouch. How did this work ? Has it been tested at all ? > >> > > >> > sz -> i > >> > >> Funny enough, it works perfectly. Generally as a test I boot the > >> kernel in a VM and let it fuzz with trinity for a bit, doing that with > >> the code above worked flawlessly. > >> > >> While it works, it's obviously wrong. Why does it work though? Usually > >> there's a list op happening pretty soon after that which brings the > >> list into proper state. > >> > >> I've been playing with a patch that adds a magic value into list_head > >> if CONFIG_DEBUG_LIST is set, and checks that magic in the list debug > >> code in lib/list_debug.c. > >> > >> Does it sound like something useful? If so I'll send that patch out. > > > > Most of the calls to this initialization function apply it on zeroed > > memory (static/kzalloc'd...), which makes it useless. I'd actually be in > > favor of removing those redundant calls (as I pointed out in another > > email), and document that zeroed memory don't need to be explicitly > > initialized. > > Why would that make it useless? The idea is that the init functions > will set the magic field to something random, like: > > .magic = 0xBADBEEF0; > > And have list_add() and friends WARN(.magic != 0xBADBEEF0, "Using an > uninitialized list\n"); > > This way we'll catch all places that don't go through list initialization code. As I replied to Tejun Heo already, I agree that keeping the initialization in place makes sense for future-proofness. This intent should probably be documented in a comment about the initialization function though, just to make sure nobody will try to skip it. Thanks, Mathieu > > > Thanks, > Sasha -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>