Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp2706585rdb; Fri, 22 Sep 2023 06:28:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH9DiT7bFYKSqy+lkcE0Vd7wmBmvIjMI+yEYunlzn7EzTKDCRsSNhyf2A289g34A1Q6PfG7 X-Received: by 2002:a05:6a00:3195:b0:68f:c9f6:f366 with SMTP id bj21-20020a056a00319500b0068fc9f6f366mr8444013pfb.0.1695389303889; Fri, 22 Sep 2023 06:28:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695389303; cv=none; d=google.com; s=arc-20160816; b=UOi/QCrgj6PVkMuGlL8UElr+lDRdshXItIlWfHjvzGpuECKYcddAoUepmQrNFc95tN 6jRmPQG8A/gijqpmUWawSgCQ2hB8rnZnymr2RQNzDniSgant3ZfRT+JbmEJbtiJce65B YYG6p1t2ypKV4wtLssWab2j9tFMpYHU4MK6NyH+FN4//ztjAElLE7kydQ7buN0JM9cSy bZjpTea/gFeIDeT1vvuHwJSZ+bBylqHk1pk9gz4/MN3YXBY77/3RfQagaVPiBvytXVqe 5E9XNpcD5XXZyJAz/kqMsaw9ApqHrlRJ305t6/2V8a+pJm2CA1Ad0RLEhV5c1hh4IvtL HF9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=XpSiMgstCaB6mxfNqbC2zgKSk3FX6BnjwH2YglOmEPc=; fh=qy7XMuwYhBh0AfpP7C/h3uQiMjzWp9Etm3Bd/ArEuEw=; b=IgkSH7VDoA/yqhp1quERIovUJOvHPsxcn4WS3DKNUd/uYpbXvZSZUOspJrc/GGFyvA X4SRmuxYVdSXPTjZadFrq4GRUUI5+i6vAp7MLsEdwl6xYDrBpJqvOfOJgOs+Gta0SHPo NTVR0wis2rhnQiZZ3guy655VoJx+u97ysFBnKzSSCJgysfqDcMs3AHo9x5wy1QrZXUTL wFEeGC5VWdjD6daPPHfUWWkdA1YFNt2o1mnCJM824/hDl+xQllTJ3lEBoTqh1UwPrjwC ao62PmFluExyXwyQw+zuKQLZ8U8jQ19m3gdCBrBBlUE1mraTcRHy8ZJBZAg3Um1TjnrC s5yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=1eW4SVn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id m14-20020a056a00080e00b0069024c6a9a8si4090330pfk.389.2023.09.22.06.28.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Sep 2023 06:28:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=1eW4SVn8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id A693E80F7E40; Fri, 22 Sep 2023 05:07:30 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233921AbjIVMHU (ORCPT + 99 others); Fri, 22 Sep 2023 08:07:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232336AbjIVMHS (ORCPT ); Fri, 22 Sep 2023 08:07:18 -0400 Received: from forwardcorp1a.mail.yandex.net (forwardcorp1a.mail.yandex.net [178.154.239.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52AFE92 for ; Fri, 22 Sep 2023 05:07:06 -0700 (PDT) Received: from mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net [IPv6:2a02:6b8:c18:d11:0:640:6943:0]) by forwardcorp1a.mail.yandex.net (Yandex) with ESMTP id D26B86070C; Fri, 22 Sep 2023 15:07:03 +0300 (MSK) Received: from valesini-ubuntu.yandex-team.ru (unknown [2a02:6b8:b081:b66f::1:2]) by mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id j6K8x60OmmI0-J1FVVYbg; Fri, 22 Sep 2023 15:07:03 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1695384423; bh=XpSiMgstCaB6mxfNqbC2zgKSk3FX6BnjwH2YglOmEPc=; h=Message-Id:Date:In-Reply-To:Cc:Subject:References:To:From; b=1eW4SVn8aYPXfyy7JCRRVqYtO0HPkRwjMVW7APHVCEbL+zjf4H4d+HcEAe4sCPb7C CIcmT7hWUXr3KNRpFNzrAD7Ze5E+hZzaTDlg4GYGde/1ehNMsxHOvHkvhdaidjKFSg GHWQPavLHpJE62ENDNnPBQU8v9Uyk+Zp80wPGEbs= Authentication-Results: mail-nwsmtp-smtp-corp-main-83.vla.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: Valentine Sinitsyn To: Greg Kroah-Hartman , Tejun Heo , "Rafael J. Wysocki" , Bjorn Helgaas Cc: Daniel Vetter , Dan Williams , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org Subject: [PATCH v8 2/2] PCI: Implement custom llseek for sysfs resource entries Date: Fri, 22 Sep 2023 17:06:45 +0500 Message-Id: <20230922120645.65190-2-valesini@yandex-team.ru> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230922120645.65190-1-valesini@yandex-team.ru> References: <20230922120645.65190-1-valesini@yandex-team.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Fri, 22 Sep 2023 05:07:30 -0700 (PDT) Since commit 636b21b50152 ("PCI: Revoke mappings like devmem"), mmappable sysfs entries have started to receive their f_mapping from the iomem pseudo filesystem, so that CONFIG_IO_STRICT_DEVMEM is honored in sysfs (and procfs) as well as in /dev/[k]mem. This resulted in a userspace-visible regression: 1. Open a sysfs PCI resource file (eg. /sys/bus/pci/devices/*/resource0) 2. Use lseek(fd, 0, SEEK_END) to determine its size Expected result: a PCI region size is returned. Actual result: 0 is returned. The reason is that PCI resource files residing in sysfs use generic_file_llseek(), which relies on f_mapping->host inode to get the file size. As f_mapping is now redefined, f_mapping->host points to an anonymous zero-sized iomem_inode which has nothing to do with sysfs file in question. Implement a custom llseek method for sysfs PCI resources, which is almost the same as proc_bus_pci_lseek() used for procfs entries. This makes sysfs and procfs entries consistent with regards to seeking, but also introduces userspace-visible changes to seeking PCI resources in sysfs: - SEEK_DATA and SEEK_HOLE are no longer supported; - Seeking past the end of the file is prohibited while previously offsets up to MAX_NON_LFS were accepted (reading from these offsets was always invalid). Fixes: 636b21b50152 ("PCI: Revoke mappings like devmem") Cc: stable@vger.kernel.org Signed-off-by: Valentine Sinitsyn Acked-by: Bjorn Helgaas --- drivers/pci/pci-sysfs.c | 26 +++++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index d9eede2dbc0e..97c9c62d5e3e 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -835,6 +835,19 @@ static const struct attribute_group pci_dev_config_attr_group = { .is_bin_visible = pci_dev_config_attr_is_visible, }; +/* + * llseek operation for mmappable PCI resources. + * May be left unused if the arch doesn't provide them. + */ +static __maybe_unused loff_t +pci_llseek_resource(struct file *filep, + struct kobject *kobj __always_unused, + struct bin_attribute *attr, + loff_t offset, int whence) +{ + return fixed_size_llseek(filep, offset, whence, attr->size); +} + #ifdef HAVE_PCI_LEGACY /** * pci_read_legacy_io - read byte(s) from legacy I/O port space @@ -967,6 +980,8 @@ void pci_create_legacy_files(struct pci_bus *b) b->legacy_io->attr.mode = 0600; b->legacy_io->read = pci_read_legacy_io; b->legacy_io->write = pci_write_legacy_io; + /* See pci_create_attr() for motivation */ + b->legacy_io->llseek = pci_llseek_resource; b->legacy_io->mmap = pci_mmap_legacy_io; b->legacy_io->f_mapping = iomem_get_mapping; pci_adjust_legacy_attr(b, pci_mmap_io); @@ -981,6 +996,8 @@ void pci_create_legacy_files(struct pci_bus *b) b->legacy_mem->size = 1024*1024; b->legacy_mem->attr.mode = 0600; b->legacy_mem->mmap = pci_mmap_legacy_mem; + /* See pci_create_attr() for motivation */ + b->legacy_mem->llseek = pci_llseek_resource; b->legacy_mem->f_mapping = iomem_get_mapping; pci_adjust_legacy_attr(b, pci_mmap_mem); error = device_create_bin_file(&b->dev, b->legacy_mem); @@ -1199,8 +1216,15 @@ static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine) res_attr->mmap = pci_mmap_resource_uc; } } - if (res_attr->mmap) + if (res_attr->mmap) { res_attr->f_mapping = iomem_get_mapping; + /* + * generic_file_llseek() consults f_mapping->host to determine + * the file size. As iomem_inode knows nothing about the + * attribute, it's not going to work, so override it as well. + */ + res_attr->llseek = pci_llseek_resource; + } res_attr->attr.name = res_attr_name; res_attr->attr.mode = 0600; res_attr->size = pci_resource_len(pdev, num); -- 2.34.1