From patchwork Thu Mar 14 16:55:14 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 160362 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp15737580jad; Thu, 14 Mar 2019 09:55:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqyzkSLuCkmVQ+Y7Hjt/cU5gWYVXCk9h7W0i60aCPSl2II73NVUPY5BZcub2ndnC1OmLobqi X-Received: by 2002:a17:902:22f:: with SMTP id 44mr46277713plc.138.1552582528431; Thu, 14 Mar 2019 09:55:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552582528; cv=none; d=google.com; s=arc-20160816; b=W5boWPjqvWP8spnpKDgQNsqonzV+dDf+K2p0vj7Zba1qig8o6E+zGfIlzrSrE21fIC XvQXk/tUJ7AGxlf0FXYGvJWxLlIYnJuLImdYHltr1IgwoKaUZyt/kmLFSABawQn5hPMO MXGPttu55j7gFqnSkmJ84c8hDqVX18Cu12YBT8difr+AcR85DhGE9Y8CRLE3NNGIGym/ Cq7LgfQU5E2RWiGipGDSqTsgnuLjuh1nFpMQPxTcf+0u8XllAiXBbGR6JGgCRu8rhD0g 8SsBrn15p5q0zP+1pVix7jHCli8/5hj0W+iJfoz4rgNcr+qHkuRVIdcdhjAPRHWZJ/DN /6cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=9Ux/pO8s+lvtwbbOs2Dnq9lDd+xrWzG8xFp8LICUFM0=; b=Vp+9Ady5fTQTmgz4b5K/GRQO8u/aWrkSyGhidvnjImSl7IxPDQjNhwMeCgNAKWsOsd PgKryxgSyAmHxXsdYYYliNzUDdVQ+C3DjpgcV2Pml4a6rVoSK/ADNoV0WRyDiaXU/4bX S7xVieG7EBHCuViz9KSHs5A6DYAz44Z5vkI0HVlvQUAiUZabbXycSjZ6tCzaJg8Tdvh8 twNj6gzg7z+MQR4Sc6GtxYEOcOgxaS42oiJ+pPThFGVLa477XmJZvwnVDeqqPtFxvK3i 5V/U6t17nux1YWTCZmkjfjPVgJ357UhzjWJvixvBjNZqcP0+E3mSQub489ZHHdPZxt95 rQug== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 70si14372218pla.128.2019.03.14.09.55.28; Thu, 14 Mar 2019 09:55:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727551AbfCNQz1 (ORCPT + 31 others); Thu, 14 Mar 2019 12:55:27 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:5248 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727131AbfCNQz0 (ORCPT ); Thu, 14 Mar 2019 12:55:26 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B170D95E339E8C2C5FCE; Fri, 15 Mar 2019 00:55:22 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.408.0; Fri, 15 Mar 2019 00:55:14 +0800 From: John Garry To: , , , , , , CC: , , , , , John Garry Subject: [RFC PATCH 0/2] Fix system crash for accessing unmapped IO port regions Date: Fri, 15 Mar 2019 00:55:14 +0800 Message-ID: <1552582516-70855-1-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It was reported some time ago that systems will crash if a driver attempts to access IO port addresses when the PCI IO port region has not been mapped [1]. More recently, a similar crash was seen where the system PCI host probe fails, and the IPMI driver crashes the system while attempting to do some IO port accesses [2]. This (incomplete) patchset attempts to keep the kernel alive in such situations, by rejecting IO port resource requests until PCI IO port regions have been mapped (in a pci_remap_iospace() call). Currently the PCI IO port region is initialized to the full range, {0, IO_SPACE_LIMIT}. As such, any IO port region requests would not fail because of PCI IO port regions not being mapped. This patchset looks to remedy this issue by ensuring IO port requests are made to direct children of ioport_resource (PCI host IO port regions), similar to Arnd's solution, in [1]: "I see that ioport_resource gets initialized to the {0, IO_SPACE_LIMIT} range. If we could change it so that pci_remap_iospace() hooks up to ioport_resource and extends it whenever something gets mapped there up to IO_SPACE_LIMIT, we can change the default range to {0,0}, which would fail for any request_region call before the first pci_remap_iospace." I didn't use this solution exactly, as I thought that it may cause problems if we later wanted to remove PCI host IO port regions. There is another separate issue that many drivers fail to request IO port region, prior to access. This patchset fixes the f71805f driver as an example. There are others drivers which need to be fixed up to do the same. 1. https://www.spinics.net/lists/linux-pci/msg49821.html 2. https://www.spinics.net/lists/arm-kernel/msg694702.html John Garry (2): resource: Request IO port regions from children of ioport_resource hwmon: (f71805f): Use request_region() in f71805f_init() drivers/hwmon/f71805f.c | 13 ++++++++++++- include/linux/ioport.h | 6 +++++- kernel/resource.c | 19 +++++++++++++++++++ 3 files changed, 36 insertions(+), 2 deletions(-) -- 2.17.1