From patchwork Mon Dec 8 21:01:57 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Sitnicki X-Patchwork-Id: 5458751 X-Patchwork-Delegate: rjw@sisk.pl Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 7AE009F1D4 for ; Mon, 8 Dec 2014 21:02:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 80F8920160 for ; Mon, 8 Dec 2014 21:02:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 53B5120172 for ; Mon, 8 Dec 2014 21:02:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752432AbaLHVCI (ORCPT ); Mon, 8 Dec 2014 16:02:08 -0500 Received: from mail-wg0-f52.google.com ([74.125.82.52]:59005 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbaLHVCH (ORCPT ); Mon, 8 Dec 2014 16:02:07 -0500 Received: by mail-wg0-f52.google.com with SMTP id x12so4668520wgg.25 for ; Mon, 08 Dec 2014 13:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=ewP656VO1ZBCs8pYM+gr8s3uE9J2FAevrca6dpxXMic=; b=QBReypFwrHOqaUHo2wvUR2GIkFs9fkpogCqXGEFP8iNSUC2fprq/oYlPvUNe+60H1o pO2qKIoAQmYrO8N8MJG4zVZWbAm0e1+Wberc9LwN2HIdJO1Ed6rqNek+CCtUDOrbRKpd Xehb9q9NrvEqjqXu754WEZZfxdnuQMBlVXNw7L2Ch928C+N327vVVeieEZbzbKerAKbh dlmjFFFzxpyK9XPBzHW0rhEiYCH7KqjAILDarx7avmdZj18jjtq8AOMWog6PpOD6nJxw XFU5VeW8AoK/er4Zmw5tov8l+zPTPq9u/6TTG+2J9d33+13DCC+48+Z4xbcVnoyh23PY eEaQ== X-Received: by 10.180.88.165 with SMTP id bh5mr27000357wib.77.1418072525948; Mon, 08 Dec 2014 13:02:05 -0800 (PST) Received: from gmail.com (89-72-187-15.dynamic.chello.pl. [89.72.187.15]) by mx.google.com with ESMTPSA id nb8sm11202083wic.7.2014.12.08.13.02.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Dec 2014 13:02:05 -0800 (PST) From: Jakub Sitnicki To: rafael.j.wysocki@intel.com Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Jakub Sitnicki Subject: [PATCH] PNP: Switch from __check_region() to __request_region() Date: Mon, 8 Dec 2014 22:01:57 +0100 Message-Id: <1418072517-5413-1-git-send-email-jsitnicki@gmail.com> X-Mailer: git-send-email 1.9.3 Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, FSL_HELO_FAKE, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP PNP core is the last user of the __check_region() which has been deprecated for almost 12 years (since v2.5.54). Replace it with a combo of __request_region() followed by __release_region(). pnp_check_port() and pnp_check_mem() remain racy after this change. Signed-off-by: Jakub Sitnicki --- There was a previous attempt at making this change 3 years ago but the author has never addressed the review comments: https://lkml.org/lkml/2011/8/12/216 The end goal here is to get rid of __check_region() which lands in every kernel image because of the PNP core. It has been previously pointed out that replacing __check_region() with request_region() obscures the fact that pnp_check_port() is racy: https://lkml.org/lkml/2011/8/11/466 Because of that I've also considered just moving __check_region() to PNP core. However, that would require making free_resource() an exported symbol in kernel/resource.c. On the other hand, a switch to request/release_region() makes pnp_check_port() and pnp_check_mem() follow the same pattern as found in pnp_check_irq() and pnp_check_dma(): if (!dev->active) { if (request_(...)) return 0; free_(...); } Admittedly, I was not able to exercise the touched code paths on a commodity x86_64 laptop or under QEMU / VirtualBox (which lack ISA PnP support, AFAIK). To my understanding, the correct way to test pnp_check_port() or pnp_check_mem() would be by issuing either: $ echo fill >/sys/bus/pnp/devices/XX:YY/resources or $ echo auto >/sys/bus/pnp/devices/XX:YY/resources ... but only if the device is not attached or active, which is not the case for ACPI PnP devices on my machines. If anyone can provide hints on steps to test this, I will be glad to do so. drivers/pnp/resource.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c index 782e822..f980ff7 100644 --- a/drivers/pnp/resource.c +++ b/drivers/pnp/resource.c @@ -179,8 +179,9 @@ int pnp_check_port(struct pnp_dev *dev, struct resource *res) /* check if the resource is already in use, skip if the * device is active because it itself may be in use */ if (!dev->active) { - if (__check_region(&ioport_resource, *port, length(port, end))) + if (!request_region(*port, length(port, end), "pnp")) return 0; + release_region(*port, length(port, end)); } /* check if the resource is reserved */ @@ -241,8 +242,9 @@ int pnp_check_mem(struct pnp_dev *dev, struct resource *res) /* check if the resource is already in use, skip if the * device is active because it itself may be in use */ if (!dev->active) { - if (check_mem_region(*addr, length(addr, end))) + if (!request_mem_region(*addr, length(addr, end), "pnp")) return 0; + release_mem_region(*addr, length(addr, end)); } /* check if the resource is reserved */