On Tue, Feb 16, 2016 at 10:37:09PM -0800, Darren Hart wrote: > On Mon, Feb 15, 2016 at 08:32:33AM -0800, Andy Lutomirski wrote: > > The dmi_walk function maps the DMI table, walks it, and unmaps it. > > This means that the dell_bios_hotkey_table that find_hk_type stores > > points to unmapped memory by the time it gets read. > > > > I've been able to trigger crashes caused by the stale pointer a > > couple of times, but never on a stock kernel. > > > > Fix it by generating the keymap in the dmi_walk callback instead of > > storing a pointer. > > > > Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx> > > --- > > > > Changes from v3: None > > Did you have any Acked-by's thus far? > > > > > Changes from v2: > > - dmi_walk failure is no longer fatal (Jean) > > > > Changes from v1: > > - Rename handle_dmi_table to handle_dmi_entry (Jean) > > - Remove useless assignment to results->err (Jean) > > > > drivers/platform/x86/dell-wmi.c | 74 +++++++++++++++++++++++++---------------- > > 1 file changed, 46 insertions(+), 28 deletions(-) > > > > diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c > > index 368e193c2741..d6ae69e0a787 100644 > > --- a/drivers/platform/x86/dell-wmi.c > > +++ b/drivers/platform/x86/dell-wmi.c > > ... > > > @@ -379,11 +396,12 @@ static const struct key_entry * __init dell_wmi_prepare_new_keymap(void) > > > > keymap[hotkey_num].type = KE_END; > > > > - return keymap; > > + results->keymap = keymap; > > This appears to change this function not to return anything, while the > declaration appears to still expect a "const struct key_entry *". Is my visual > diff parser broken? Duh, nevermind. The context matching the before-renamed and new signature function threw me initially. Apologies. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
