On 25 January 2013 01:01, Tejun Heo <[email protected]> wrote: > Hello, > > On Fri, Jan 25, 2013 at 12:13:45AM +0000, James Hogan wrote: >> Should it have this? >> + else >> + INIT_LIST_HEAD(&entry->global_list) > > I think it would be better to have INIT_LIST_HEAD() during @entry > initialization. Heh, I forgot that. I wonder why it didn't crash on > my machine. Can you please cook up a patch to init both list fields > right after kzalloc()?
How does the following patch look? Feel free to squash it into the original to avoid breaking bisection :). Cheers James From: James Hogan <[email protected]> Date: Fri, 25 Jan 2013 09:46:58 +0000 Subject: [PATCH 1/1] async: initialise list heads to fix crash The commit "async: replace list of active domains with global list of pending items" added a struct list_head global_list in struct async_entry, which isn't initialised. This means that if !domain->registered at __async_schedule(), then list_del_init() will be called on the list head in async_run_entry_fn with both pointers NULL, causing a crash. This is fixed by initialising both the global_list and domain_list list_heads after kzalloc'ing the entry. This was noticed due to dapm_power_widgets() which uses ASYNC_DOMAIN_EXCLUSIVE, which initialises the domain->registered to 0. Signed-off-by: James Hogan <[email protected]> --- kernel/async.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/async.c b/kernel/async.c index 6958000..8ddee2c 100644 --- a/kernel/async.c +++ b/kernel/async.c @@ -172,6 +172,8 @@ static async_cookie_t __async_schedule(async_func_ptr *ptr, void *data, struct a ptr(data, newcookie); return newcookie; } + INIT_LIST_HEAD(&entry->domain_list); + INIT_LIST_HEAD(&entry->global_list); INIT_WORK(&entry->work, async_run_entry_fn); entry->func = ptr; entry->data = data; -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
