Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754654AbbDIVhy (ORCPT ); Thu, 9 Apr 2015 17:37:54 -0400 Received: from mail-ig0-f170.google.com ([209.85.213.170]:34195 "EHLO mail-ig0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754588AbbDIVht (ORCPT ); Thu, 9 Apr 2015 17:37:49 -0400 MIME-Version: 1.0 In-Reply-To: <5526EE36.7050303@kernel.dk> References: <5526EE36.7050303@kernel.dk> Date: Thu, 9 Apr 2015 14:37:48 -0700 X-Google-Sender-Auth: tfwa9NzvWgn3rPefeFaty-KHHVA Message-ID: Subject: =?UTF-8?Q?Re=3A_NULL_deref_around_blkmq_in_v4=2E0=2Drc1=E2=80=93rc7?= From: Linus Torvalds To: Jens Axboe Cc: Jan Engelhardt , "Rafael J. Wysocki" , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2113 Lines: 48 On Thu, Apr 9, 2015 at 2:25 PM, Jens Axboe wrote: > > Not sure why it isn't all zeroed, definitely the saner thing to do at init > time. So practically speaking, it might well often be zeroed just because the BIOS may have initialized memory that way (and big multi-page allocations have probably not gotten re-used). > And if this is mpt, we recently ran into some list corruption issues due to > a bug in the driver. It hit on reboot, but it was scan related, so could be > a boot issue as well. So one of the earlier emails had this: Copyright (c) 1999-2008 LSI Corporation Fusion MPT SAS Host driver 3.04.20 mptbase: ioc0: Initiating bringup ioc0: LSISAS1068 A0: Capabilities={Initiator} scsi host0: ioc0: LSISAS1068 A0, FwRev=00000000h, Ports=8, MaxQ=256, IRQ=22 mptsas: ioc0: attaching ssp device: fw_channel 0, fw_id 1, phy 1, sas_addr 0x1060504030201a0 scsi 0:0:0:0: Direct-Access VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 scsi 0:0:0:0: Attached scsi generic sg0 type 0 mptbase: ioc1: Initiating bringup ioc1: LSISAS1068 A0: Capabilities={Initiator} scsi host1: ioc1: LSISAS1068 A0, FwRev=00000000h, Ports=8, MaxQ=256, IRQ=17 mptsas: ioc1: attaching ssp device: fw_channel 0, fw_id 0, phy 0, sas_addr 0x60504030201a0 scsi 1:0:0:0: Direct-Access VBOX HARDDISK 1.0 PQ: 0 ANSI: 5 scsi 1:0:0:0: Attached scsi generic sg1 type 0 and I'm assuming that that is the backing storage. And yes, memory corruption sounds like a more likely cause than anything else. I don't like how the request data wasn't fully initialized, but the cmd->sense_buffer pointer itself *should* have been initialized by the ->init_request() call. So I don't actually expect my patch to really make any difference, although I do think that code should be looked at. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/