Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Thu, 5 Oct 2023 11:16:11 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     Valentine Sinitsyn <valesini@yandex-team.ru>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Tejun Heo <tj@kernel.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Bjorn Helgaas <bhelgaas@google.com>
CC:     Daniel Vetter <daniel.vetter@ffwll.ch>,
        Dan Williams <dan.j.williams@intel.com>,
        <linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>
Subject: RE: [PATCH v9 2/2] PCI: Implement custom llseek for sysfs resource
 entries
Message-ID: <651efd6b8596_ae7e7294fa@dwillia2-xfh.jf.intel.com.notmuch>
References: <2023092241-obedient-squirt-966c@gregkh>
 <20230925084013.309399-2-valesini@yandex-team.ru>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230925084013.309399-2-valesini@yandex-team.ru>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?lNd/BjoiSxtE6y5hHRtAxOaR4qy8fl2s2JWfojo6mmmdiCb7C4yAwr5QwrD3?=
 =?us-ascii?Q?/8/ModGwcYVayBw2Ulf5IA1gnjzE/zkFHoHwTH7CjvLkjUCfm7uK2+CJ/iZA?=
 =?us-ascii?Q?HBqHgz1ebHJWpyEepYrI0rqjE9CS09sx8YZkaNC35S1+BU+7OS+zFCk5V6B/?=
 =?us-ascii?Q?62cSHKozlGV51C6k9TDyiaZYznFEDkeogSZdbfghFMdOgX3itNh2GceXDa7u?=
 =?us-ascii?Q?umGwDcgY81u4EZwHHrwOXWNjM2/hjVeauhXJP417Nl4cLzBSPHjOT/oPjeA1?=
 =?us-ascii?Q?ZVnK+EQEVc5qVafcb7jkgTckt0lWI6ocBKOCr0PvX5yAC3HVliQLsxMo3pvF?=
 =?us-ascii?Q?oSq2YSgQHkalzS0n4OMdaq+SgTxg55mJiHkvti4IR66sZeDTGjniKepNzFG7?=
 =?us-ascii?Q?gm1H4wyK0qgaPEM0dBz6FtdCyRE/S5tgEGkH41VwRaAYEqqKTPrv/OALqZKw?=
 =?us-ascii?Q?yHeCUX6iLXdzWxXwW3j98BPUXgUWi+CZCE68G11MYptwMNaiADy4t5o1Ss/p?=
 =?us-ascii?Q?j1pbAeq7ZXL/UV01YlCD+uidx2B3FSwmcoUoG4WWDkhT/0lr9bolPZ02p8DT?=
 =?us-ascii?Q?Y5U3qY1gu4/SjCP7J0Ruk8lIlK0zoWuw8vfV0r0d7pkEk54xZY7RHscnCKne?=
 =?us-ascii?Q?tijd4Hh1LAtndIr9nfnAd+aB7eQw//DazT7v9JgVdKt3l7q05nz3kwXayVZ7?=
 =?us-ascii?Q?zAsCj6nidDFmcBNpkUBZ1aJFlpJEzwsjjRgAPsQA8SVUBts2AK+e7t2G2BVo?=
 =?us-ascii?Q?1puz0kQDT9tJRMjk+tcNOtlAGZpDwqWrvaA3gcO1uLHesN0d5G7hdqIjkbA2?=
 =?us-ascii?Q?EDZDBPr1DcZLhlW11Xd7cvUB3yQ3QBMIk+22dQGGKIp7NUttrYZ/0lSlcCjy?=
 =?us-ascii?Q?iXDw266JYLPCx+rejEW3EH5Dt0lIk3991w5w+L2oBj8h58QKgVFZWUe+ALwL?=
 =?us-ascii?Q?yVYCeZH7SnXyM+pP1pfT3Wi0Bvxvqu9BAJPkqdRn+qhPNeTTyrwBpvYYQPgj?=
 =?us-ascii?Q?t0Hst19cX2ubChCM7P8Cejt0yBlgombHAZX+MWYbkAWOSY7EhuJxVbHAWnXY?=
 =?us-ascii?Q?Ex030OC9MoWd1tYFTuGSYjQ2nED+cWLgE3aOp3TyJ1LZ7NQrKg3WwW9iXh3D?=
 =?us-ascii?Q?nqgpnW8iohyqPqKkniEzQo0oxBqYxvvCdUmhtESm+b8Gi06ggtiTG2z+vbJu?=
 =?us-ascii?Q?/5rvvLYxpSmkIDwyioubeq2x6PM2Jd2XhP/xTtz0JymchYBv6ZMwnbkf5qgt?=
 =?us-ascii?Q?XG0l/wyjEPattRTQIj9UVI4RUlyvst/MFHl8NgKhXXbkjfDmClYfb8dWz9D0?=
 =?us-ascii?Q?0tzYZpRIBxYOwPcWOvUafm2Oehlh8i8XQD7Lc3ln0VCX0SHpKXylml4qCD5m?=
 =?us-ascii?Q?IHbft8iDFG6l8Oc9fT7XBC6IscE1wPApCTngt2dDWw95tEEHNyhCUyFXw7NS?=
 =?us-ascii?Q?kzQB+A7+pnwPc9/L+0Ik7hxDsNgQFsQRA1bs+y7qYgDh/Qer0aJLZCAxjJX3?=
 =?us-ascii?Q?hr7QZtJbxwVpTnePquzQwt4hbtNbd9F5P3YTo2RPj23ZDV8o/QPG5xOed8Ai?=
 =?us-ascii?Q?/JkrzxLddHsiob5/aiKh3Zdkq0f0A4EWh2rK+2LRBDOSWnTO88l+72m7dZnk?=
 =?us-ascii?Q?LA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a37ce08-657a-4bb6-b01e-08dbc5cf2b70
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Oct 2023 18:16:18.2077
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: wg2W4wk8yXnxrIuTowXmrSrR08jtQXxWql+eESLmuMmDxIcXc4SaQkcT6j9EDD4xoGUt+tt+FVntL/3p+9FgRMuuLL0DV6IpqmplpkKzMHI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7777
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Thu, 05 Oct 2023 11:17:44 -0700 (PDT)

Valentine Sinitsyn wrote:
> 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 <valesini@yandex-team.ru>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>

Thanks for doing this reorganization and the follow-up, looks good to me:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>