1. Please describe the problem:
In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
to init priv->rings and bound &ring->work with p9_xen_response.
When it calls xen_9pfs_front_event_handler to handle IRQ requests,
it will finally call schedule_work to start the work.
When we call xen_9pfs_front_remove to remove the driver, there
may be a sequence as follows:
Fix it by finishing the work before cleanup in xen_9pfs_front_free.
CPU0 CPU1
|p9_xen_response
xen_9pfs_front_remove|
xen_9pfs_front_free|
kfree(priv) |
//free priv |
|p9_tag_lookup
|//use priv->client
2. What is the Version-Release number of the kernel:
38
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Sorry it' too old to find.
4. Can you reproduce this issue? If so, please provide the steps to reproduce
the issue below:
No, this is a bug found by static analysis and there are some similar problems which have been confirmed reprodoceable.
5. Does this problem occur with the latest Rawhide kernel? To install the
Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
``sudo dnf update --enablerepo=rawhide kernel``:
Yes
6. Are you running any modules that not shipped with directly Fedora's kernel?:
Enable Linux 9p file system.
7. Please attach the kernel logs. You can get the complete kernel log
for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
issue occurred on a previous boot, use the journalctl ``-b`` flag.
There's no kernel log. Here is the patch link of [1] Linux-v6.3 and [2]patchwork
[1] https://lore.kernel.org/v9fs/
[2] https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz@163.com/
1. Please describe the problem: In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring to init priv->rings and bound &ring->work with p9_xen_response. When it calls xen_9pfs_front_event_handler to handle IRQ requests, it will finally call schedule_work to start the work. When we call xen_9pfs_front_remove to remove the driver, there may be a sequence as follows: Fix it by finishing the work before cleanup in xen_9pfs_front_free. CPU0 CPU1 |p9_xen_response xen_9pfs_front_remove| xen_9pfs_front_free| kfree(priv) | //free priv | |p9_tag_lookup |//use priv->client 2. What is the Version-Release number of the kernel: 38 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Sorry it' too old to find. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: No, this is a bug found by static analysis and there are some similar problems which have been confirmed reprodoceable. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: Enable Linux 9p file system. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. There's no kernel log. Here is the patch link of [1] Linux-v6.3 and [2]patchwork [1] https://lore.kernel.org/v9fs/ [2] https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz@163.com/