New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add loongarch support #2
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
我刚刚发现问题,这边似乎加的代码跟 32 位还是 64 位无关,应该把所有的 64 字样都去掉?
如果先前那个 PR 也有这个问题,其实提交上游之前也需要改掉的
@xen0n 先将本分支修改了,稍后修改la64/stable-0.11分支。麻烦帮忙看下本分支,谢谢。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
测试通过
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make check
和make regtest
测试通过。
@sibadawz 可以把 la64/master 向上游合并了,谢谢。 |
@sibadawz 这个没有往上游推吗? |
@sibadawz 我看你这个还没往上游推啊?等到啥时候呢? |
这个居然还没推 @yetist 我们谁 take over 一下吧,反正原作者的 Git author 信息也不会丢 |
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. See: gentoo#25189 Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. See: gentoo#25189 Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. See: gentoo#25189 Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. See: gentoo#25189 Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
The patch comes from loongarch64/userspace-rcu#2 which is reviewed by the LoongArch community, but not upstreamed yet. This has been inside loongson-overlay for a while, and is tested on real loong hardware. See: #25189 Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Fix a deadlock for auto-resize hash tables when cds_lfht_destroy is called with RCU read-side lock held. Example stack track of a hang: Thread 2 (Thread 0x7f21ba876700 (LWP 26114)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f21beba7aa0 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x7f21bedac308 <urcu_memb_gp+8>) at ../include/urcu/futex.h:81 #2 futex_noasync (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x7f21bedac308 <urcu_memb_gp+8>) at ../include/urcu/futex.h:90 #3 wait_gp () at urcu.c:265 urcu#4 wait_for_readers (input_readers=input_readers@entry=0x7f21ba8751b0, cur_snap_readers=cur_snap_readers@entry=0x0, qsreaders=qsreaders@entry=0x7f21ba8751c0) at urcu.c:357 urcu#5 0x00007f21beba8339 in urcu_memb_synchronize_rcu () at urcu.c:498 urcu#6 0x00007f21be99f93f in fini_table (last_order=<optimized out>, first_order=13, ht=0x5651cec75400) at rculfhash.c:1489 urcu#7 _do_cds_lfht_shrink (new_size=<optimized out>, old_size=<optimized out>, ht=0x5651cec75400) at rculfhash.c:2001 urcu#8 _do_cds_lfht_resize (ht=ht@entry=0x5651cec75400) at rculfhash.c:2023 urcu#9 0x00007f21be99fa26 in do_resize_cb (work=0x5651e20621a0) at rculfhash.c:2063 urcu#10 0x00007f21be99dbfd in workqueue_thread (arg=0x5651cec74a00) at workqueue.c:234 urcu#11 0x00007f21bd7c06db in start_thread (arg=0x7f21ba876700) at pthread_create.c:463 urcu#12 0x00007f21bd4e961f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f21bf285300 (LWP 26098)): #0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 #1 0x00007f21be99d8b7 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x5651d8b38584) at ../include/urcu/futex.h:81 #2 futex_async (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x5651d8b38584) at ../include/urcu/futex.h:113 #3 futex_wait (futex=futex@entry=0x5651d8b38584) at workqueue.c:135 urcu#4 0x00007f21be99e2c8 in urcu_workqueue_wait_completion (completion=completion@entry=0x5651d8b38580) at workqueue.c:423 urcu#5 0x00007f21be99e3f9 in urcu_workqueue_flush_queued_work (workqueue=0x5651cec74a00) at workqueue.c:452 urcu#6 0x00007f21be9a0c83 in cds_lfht_destroy (ht=0x5651d8b2fcf0, attr=attr@entry=0x0) at rculfhash.c:1906 This deadlock is easy to reproduce when rapidly adding a large number of entries in the cds_lfht, removing them, and calling cds_lfht_destroy(). The deadlock will occur if the call to cds_lfht_destroy() takes place while a resize of the hash table is ongoing. Fix this by moving the teardown of the lfht worker thread to libcds library destructor, so it does not have to wait on synchronize_rcu from a resize callback from within a read-side critical section. As a consequence, the atfork callbacks are left registered within each urcu flavor for which a resizeable hash table is created until the end of the executable lifetime. The other part of the fix is to move the hash table destruction to the worker thread for auto-resize hash tables. This prevents having to wait for resize callbacks from RCU read-side critical section. This is guaranteed by the fact that the worker thread serializes previously queued resize callbacks before the destroy callback. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Change-Id: If8b1c3c8063dc7b9846dc5c3fc452efd917eab4d
@loongarch64/dev-team
Please review and test the code."make check" and "make regtest".