fail to build ZUFS on ubuntu 19.10, please help #3
Comments
|
I tried another way to build module, also failed. ===detail info=== |
When lockdep is enabled, plugging Thunderbolt dock on Dominik's laptop triggers following splat: ====================================================== WARNING: possible circular locking dependency detected 5.3.0-rc6+ #1 Tainted: G T ------------------------------------------------------ pool-/usr/lib/b/1258 is trying to acquire lock: 000000005ab0ad43 (pci_rescan_remove_lock){+.+.}, at: authorized_store+0xe8/0x210 but task is already holding lock: 00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&tb->lock){+.+.}: __mutex_lock+0xac/0x9a0 tb_domain_add+0x2d/0x130 nhi_probe+0x1dd/0x330 pci_device_probe+0xd2/0x150 really_probe+0xee/0x280 driver_probe_device+0x50/0xc0 bus_for_each_drv+0x84/0xd0 __device_attach+0xe4/0x150 pci_bus_add_device+0x4e/0x70 pci_bus_add_devices+0x2e/0x66 pci_bus_add_devices+0x59/0x66 pci_bus_add_devices+0x59/0x66 enable_slot+0x344/0x450 acpiphp_check_bridge.part.0+0x119/0x150 acpiphp_hotplug_notify+0xaa/0x140 acpi_device_hotplug+0xa2/0x3f0 acpi_hotplug_work_fn+0x1a/0x30 process_one_work+0x234/0x580 worker_thread+0x50/0x3b0 kthread+0x10a/0x140 ret_from_fork+0x3a/0x50 -> #0 (pci_rescan_remove_lock){+.+.}: __lock_acquire+0xe54/0x1ac0 lock_acquire+0xb8/0x1b0 __mutex_lock+0xac/0x9a0 authorized_store+0xe8/0x210 kernfs_fop_write+0x125/0x1b0 vfs_write+0xc2/0x1d0 ksys_write+0x6c/0xf0 do_syscall_64+0x50/0x180 entry_SYSCALL_64_after_hwframe+0x49/0xbe other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&tb->lock); lock(pci_rescan_remove_lock); lock(&tb->lock); lock(pci_rescan_remove_lock); *** DEADLOCK *** 5 locks held by pool-/usr/lib/b/1258: #0: 000000003df1a1ad (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x4d/0x60 #1: 0000000095a40b02 (sb_writers#6){.+.+}, at: vfs_write+0x185/0x1d0 #2: 0000000017a7d714 (&of->mutex){+.+.}, at: kernfs_fop_write+0xf2/0x1b0 #3: 000000004f262981 (kn->count#208){.+.+}, at: kernfs_fop_write+0xfa/0x1b0 #4: 00000000bfb796b5 (&tb->lock){+.+.}, at: authorized_store+0x7c/0x210 stack backtrace: CPU: 0 PID: 1258 Comm: pool-/usr/lib/b Tainted: G T 5.3.0-rc6+ #1 On an system using ACPI hotplug the host router gets hotplugged first and then the firmware starts sending notifications about connected devices so the above scenario should not happen in reality. However, after taking a second look at commit a03e828 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan") that introduced the locking, I don't think it is actually correct. It may have cured the symptom but probably the real root cause was somewhere closer to PCI stack and possibly is already fixed with recent kernels. I also tried to reproduce the original issue with the commit reverted but could not. So to keep lockdep happy and the code bit less complex drop calls to pci_lock_rescan_remove()/pci_unlock_rescan_remove() in tb_switch_set_authorized() effectively reverting a03e828. Link: https://lkml.org/lkml/2019/8/30/513 Fixes: a03e828 ("thunderbolt: Serialize PCIe tunnel creation with PCI rescan") Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ------------------------->8---------------------- ARC perf : 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ------------------------->8---------------------- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP____" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "____" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "____" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: stable@vger.kernel.org Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Call napi_disable() twice would cause dead lock. There are three situations may result in the issue. 1. rtl8152_pre_reset() and set_carrier() are run at the same time. 2. Call rtl8152_set_tunable() after rtl8152_close(). 3. Call rtl8152_set_ringparam() after rtl8152_close(). For #1, use the same solution as commit 8481141 ("r8152: Re-order napi_disable in rtl8152_close"). For #2 and #3, add checking the flag of IFF_UP and using napi_disable/napi_enable during mutex. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
could you please check why I cannot make the driver on 19.10. the module.mk is missing.
===below is detail error.
wayne@ubuntu:
/zufs-zuf/fs/zuf$ sudo make -f fs/zuf/module.mk KDIR=linux-headers-5.3.0-46/zufs-zuf/fs/zuf$ ls -l fs/zufmake: fs/zuf/module.mk: No such file or directory
make: *** No rule to make target 'fs/zuf/module.mk'. Stop.
wayne@ubuntu:
ls: cannot access 'fs/zuf': No such file or directory
wayne@ubuntu:
/zufs-zuf/fs/zuf$ ls/zufs-zuf/fs/zuf$ ls -lacl.c _extern.h inode.c Kconfig md.c md.h module.c Module.symvers _pr.h rw.c symlink.c t2.c xattr.c zuf.h zus_api.h
directory.c file.c ioctl.c Makefile md_def.h mmap.c modules.order namei.c relay.h super.c t1.c t2.h zuf-core.c zuf-root.c
wayne@ubuntu:
total 340
-rw-r--r-- 1 wayne wayne 5961 Apr 18 01:00 acl.c
-rw-r--r-- 1 wayne wayne 4143 Apr 18 01:00 directory.c
-rw-r--r-- 1 wayne wayne 6886 Apr 18 01:00 _extern.h
-rw-r--r-- 1 wayne wayne 22269 Apr 18 01:00 file.c
-rw-r--r-- 1 wayne wayne 17620 Apr 18 01:00 inode.c
-rw-r--r-- 1 wayne wayne 8309 Apr 18 01:00 ioctl.c
-rw-r--r-- 1 wayne wayne 565 Apr 18 01:00 Kconfig
-rw-r--r-- 1 wayne wayne 462 Apr 18 01:00 Makefile
-rw-r--r-- 1 wayne wayne 17617 Apr 18 01:00 md.c
-rw-r--r-- 1 wayne wayne 3562 Apr 18 01:00 md_def.h
-rw-r--r-- 1 wayne wayne 7151 Apr 18 01:00 md.h
-rw-r--r-- 1 wayne wayne 7920 Apr 18 01:00 mmap.c
-rw-r--r-- 1 wayne wayne 1044 Apr 18 01:00 module.c
-rw-r--r-- 1 root root 0 Apr 18 01:10 modules.order
-rw-r--r-- 1 root root 0 Apr 18 01:05 Module.symvers
-rw-r--r-- 1 wayne wayne 10917 Apr 18 01:00 namei.c
-rw-r--r-- 1 wayne wayne 2331 Apr 18 01:00 _pr.h
-rw-r--r-- 1 wayne wayne 2058 Apr 18 01:00 relay.h
-rw-r--r-- 1 wayne wayne 28358 Apr 18 01:00 rw.c
-rw-r--r-- 1 wayne wayne 22095 Apr 18 01:00 super.c
-rw-r--r-- 1 wayne wayne 1788 Apr 18 01:00 symlink.c
-rw-r--r-- 1 wayne wayne 4283 Apr 18 01:00 t1.c
-rw-r--r-- 1 wayne wayne 8581 Apr 18 01:00 t2.c
-rw-r--r-- 1 wayne wayne 1720 Apr 18 01:00 t2.h
-rw-r--r-- 1 wayne wayne 8021 Apr 18 01:00 xattr.c
-rw-r--r-- 1 wayne wayne 46954 Apr 18 01:00 zuf-core.c
-rw-r--r-- 1 wayne wayne 9809 Apr 18 01:00 zuf.h
-rw-r--r-- 1 wayne wayne 12255 Apr 18 01:00 zuf-root.c
-rw-r--r-- 1 wayne wayne 25626 Apr 18 01:00 zus_api.h
wayne@ubuntu:~/zufs-zuf/fs/zuf$
The text was updated successfully, but these errors were encountered: