[+cc Daniel (author of 74b30195395c), Greg]
On Tue, Jan 30, 2024 at 08:50:10AM +0530, aravind wrote:
> Hi,
> I am facing an issue in v5.15 kernel due to " [PATCH v7 12/17] PCI:
> Revoke mappings like devmem "related changes.
> Whenever a PCI device (4f:00.0)is removed while being accessed from
> user space (mmaped (sys/bus/pci/device/....4f:00.0/resource0)), no sig
> bus error is raised. in earlier kernel v5.2, a sig bus error used to
> get generated for this scenario.
> In v5.15 5 kernel , value 0xffffffff is returned when the device is
> plugged out or it is reset.
> if the device is removed through "echo 1 >
> /sys/bus/pci/devices/..4f:00.0/remove") command. user space code is
> still able to access device memory no fault is generated in this case.
> not sure if this is expected behavior. as the file which is mapped is
> removed .(/sys/bus/pci/.../resource0)
>
> After making the below change in v5.15 , I am able to get fault for
> above scenarios. (device removal or unplug/reset.)
> Please let me know if this is a new feature introduced to handle
> mmaped memory access holes ? and allow to work inspite of sysfs files
> removal.
>
>
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index d019d6ac6ad0..5f9b59ba8320 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -251,7 +251,7 @@ static const struct kernfs_ops sysfs_bin_kfops_mmap = {
> .read = sysfs_kf_bin_read,
> .write = sysfs_kf_bin_write,
> .mmap = sysfs_kf_bin_mmap,
> - .open = sysfs_kf_bin_open,
> +// .open = sysfs_kf_bin_open,
> };
If the change above makes the difference, I guess the change might be
related to https://git.kernel.org/linus/74b30195395c ("sysfs: Support
zapping of binary attr mmaps"), which appeared in v5.12.
I agree that SIGBUS when accessing MMIO space of a device that has
been removed sounds like a better experience than reading 0xffffffff.
I don't know enough about the VM side of this to know just how
74b30195395c makes this difference. Maybe Daniel will chime in.
Bjorn
