From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752654AbdKHOle (ORCPT ); Wed, 8 Nov 2017 09:41:34 -0500 Received: from mail-yw0-f194.google.com ([209.85.161.194]:56898 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdKHOld (ORCPT ); Wed, 8 Nov 2017 09:41:33 -0500 X-Google-Smtp-Source: ABhQp+TSkGyBigU3yuBd3+07mefp3GOj+6voI4tX3SiJsyKGxGP+nJcwtcO7tixAWA6JmYVd2uyH6g== Date: Wed, 8 Nov 2017 09:41:25 -0500 From: William Breathitt Gray To: Linus Torvalds Cc: Fengguang Wu , Greg Kroah-Hartman , Linux Kernel Mailing List Subject: Re: [isa_bus_shutdown] ALSA es1688_lib.c:113 ess_reset at 0x220: failed!!! Message-ID: <20171108144125.GA14032@sophia> References: <20171107102522.gr4hptim4toyezfd@wfg-t540p.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 07, 2017 at 09:03:48AM -0800, Linus Torvalds wrote: >On Tue, Nov 7, 2017 at 2:25 AM, Fengguang Wu wrote: >> >> FYI this happens in v4.14-rc8 -- it's not necessarily a new bug. > >Yeah, no it is not new. > >It also likely doesn't matter (I suspect it happens if you try to >force-load crazy modules that don't exist, and ISA doesn't have proper >probing). > >But the code disassembles to > > 0: 8b 50 7c mov 0x7c(%eax),%edx > 3: 83 05 38 86 21 44 01 addl $0x1,X > a:* 8b 4a 0c mov 0xc(%edx),%ecx <-- trapping instruction > d: 83 15 3c 86 21 44 00 adcl $0x0,X+4 > 14: 85 c9 test %ecx,%ecx > >and while I have no idea what that odd addl/adcl is (other than the >obvious "it's a 64-bit increment" - probably some random statistics >due to your config), it looks like the oops is due to > > struct isa_driver *isa_driver = dev->platform_data; > > if (isa_driver->shutdown) > >with isa_driver being NULL (EDX: 00000000). > >So dev->platform_data is NULL, but why that actually happens I don't >know. Some bad ISA device registration that _should_ have failed but >instead got into some half-alive state, I'm sure. > >I'm not sure if anybody cares, but maybe adding a NULL check just to >make the 0day robot not report this is a good idea. > > Linus I suspect platform_data is being set to NULL when a device match fails (via the snd_es1688_match callback) in the isa_bus_match function. The NULL pointer dereference then subsequently occurs in isa_bus_shutdown since the platform_data member has been reset to indicate an unsupported device. The most straight-forward solution is as mentioned: perform a NULL check to ensure we're actually working with a valid ISA device before blindly poking it. I'll submit a simple patch then that should placate this error. William Breathitt Gray