Some improvements for `quick-start.rst` by ojeda · Pull Request #138 · Rust-for-Linux/linux

ojeda · 2021-03-21T22:55:18Z

Reported-by: Pavel Machek pavel@ucw.cz
Signed-off-by: Miguel Ojeda ojeda@kernel.org

alex · 2021-03-21T23:03:08Z

 If you have worked previously with Rust, this will only take a moment.

+Please note that, at the moment, a very restricted subset of architectures
+is supported, see :ref:`Documentation/rust/arch-support.rst <_rust_arch_support>`.


Suggested change

is supported, see :ref:`Documentation/rust/arch-support.rst <_rust_arch_support>`.

is supported, see :doc:`/rust/arch-support.rst`.

It is:

:doc:`Documentation/rust/arch-support.rst`

no? Otherwise I get a warning on htmldocs.

I don't think so, none of the other :doc: links I see in there have the Documentation/ prefix.

Ah, I saw the problem: one needs to remove the extension:

:doc:`/rust/arch-support`.

Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30 Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever@oracle.com>

A crash was observed with the following output: BUG: kernel NULL pointer dereference, address: 0000000000000010 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 92 Comm: osnoise_cpus Not tainted 6.17.0-rc4-00201-gd69eb204c255 #138 PREEMPT(voluntary) RIP: 0010:bitmap_parselist+0x53/0x3e0 Call Trace: <TASK> osnoise_cpus_write+0x7a/0x190 vfs_write+0xf8/0x410 ? do_sys_openat2+0x88/0xd0 ksys_write+0x60/0xd0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This issue can be reproduced by below code: fd=open("/sys/kernel/debug/tracing/osnoise/cpus", O_WRONLY); write(fd, "0-2", 0); When user pass 'count=0' to osnoise_cpus_write(), kmalloc() will return ZERO_SIZE_PTR (16) and cpulist_parse() treat it as a normal value, which trigger the null pointer dereference. Add check for the parameter 'count'. Cc: <mhiramat@kernel.org> Cc: <mathieu.desnoyers@efficios.com> Cc: <tglozar@redhat.com> Link: https://lore.kernel.org/20250906035610.3880282-1-wangliang74@huawei.com Fixes: 17f8910 ("tracing/osnoise: Allow arbitrarily long CPU string") Signed-off-by: Wang Liang <wangliang74@huawei.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>

Leon Hwang says: ==================== Similar to commit 98770bd ("bpf,x86: add fsession support for x86_64"), add fsession support on arm64. Patch Rust-for-Linux#1 adds bpf_jit_supports_fsession() to prevent fsession loading on architectures that do not implement fsession support. Patch Rust-for-Linux#2 implements fsession support in the arm64 BPF JIT trampoline. Patch Rust-for-Linux#3 enables the relevant selftests on arm64, including get_func_ip, and get_func_args. All enabled tests pass on arm64: cd tools/testing/selftests/bpf ./test_progs -t fsession Rust-for-Linux#136/1 fsession_test/fsession_test:OK Rust-for-Linux#136/2 fsession_test/fsession_reattach:OK Rust-for-Linux#136/3 fsession_test/fsession_cookie:OK Rust-for-Linux#136 fsession_test:OK Summary: 1/3 PASSED, 0 SKIPPED, 0 FAILED ./test_progs -t get_func Rust-for-Linux#138 get_func_args_test:OK Rust-for-Linux#139 get_func_ip_test:OK Summary: 2/0 PASSED, 0 SKIPPED, 0 FAILED Changes: v4 -> v5: * Address comment from Alexei: * Rename helper bpf_link_prog_session_cookie() to bpf_prog_calls_session_cookie(). * v4: https://lore.kernel.org/bpf/20260129154953.66915-1-leon.hwang@linux.dev/ v3 -> v4: * Add a log when !bpf_jit_supports_fsession() in patch Rust-for-Linux#1 (per AI). * v3: https://lore.kernel.org/bpf/20260129142536.48637-1-leon.hwang@linux.dev/ v2 -> v3: * Fix typo in subject and patch message of patch Rust-for-Linux#1 (per AI and Chris). * Collect Acked-by, and Tested-by from Puranjay, thanks. * v2: https://lore.kernel.org/bpf/20260128150112.8873-1-leon.hwang@linux.dev/ v1 -> v2: * Add bpf_jit_supports_fsession(). * v1: https://lore.kernel.org/bpf/20260127163344.92819-1-leon.hwang@linux.dev/ ==================== Link: https://patch.msgid.link/20260131144950.16294-1-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>

There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b #138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: <TASK> dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 </TASK> Found by Linux Verification Center (linuxtesting.org). Fixes: d5fc140 ("smb/server: avoid deadlock when linking with ReplaceIfExists") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>

commit a09dc10 upstream. There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b Rust-for-Linux#138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: <TASK> dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 </TASK> Found by Linux Verification Center (linuxtesting.org). Fixes: d5fc140 ("smb/server: avoid deadlock when linking with ReplaceIfExists") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit a09dc10 ] There are two places where ksmbd_vfs_kern_path_end_removing() needs to be called in order to balance what the corresponding successful call to ksmbd_vfs_kern_path_start_removing() has done, i.e. drop inode locks and put the taken references. Otherwise there might be potential deadlocks and unbalanced locks which are caught like: BUG: workqueue leaked lock or atomic: kworker/5:21/0x00000000/7596 last function: handle_ksmbd_work 2 locks held by kworker/5:21/7596: #0: ffff8881051ae448 (sb_writers#3){.+.+}-{0:0}, at: ksmbd_vfs_kern_path_locked+0x142/0x660 #1: ffff888130e966c0 (&type->i_mutex_dir_key#3/1){+.+.}-{4:4}, at: ksmbd_vfs_kern_path_locked+0x17d/0x660 CPU: 5 PID: 7596 Comm: kworker/5:21 Not tainted 6.1.162-00456-gc29b353f383b Rust-for-Linux#138 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: ksmbd-io handle_ksmbd_work Call Trace: <TASK> dump_stack_lvl+0x44/0x5b process_one_work.cold+0x57/0x5c worker_thread+0x82/0x600 kthread+0x153/0x190 ret_from_fork+0x22/0x30 </TASK> Found by Linux Verification Center (linuxtesting.org). Fixes: d5fc140 ("smb/server: avoid deadlock when linking with ReplaceIfExists") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> [ ksmbd_vfs_kern_path_end_removing() call -> ksmbd_vfs_kern_path_unlock() ] Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ojeda force-pushed the quick-start branch from 4ec0611 to aaca25d Compare March 21, 2021 23:00

alex reviewed Mar 21, 2021

View reviewed changes

ojeda force-pushed the quick-start branch from aaca25d to ac28cc7 Compare March 21, 2021 23:07

alex approved these changes Mar 21, 2021

View reviewed changes

ojeda force-pushed the quick-start branch from ac28cc7 to 5d1cd48 Compare March 21, 2021 23:13

Some improvements for quick-start.rst

a989492

Reported-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

ojeda force-pushed the quick-start branch from 5d1cd48 to a989492 Compare March 21, 2021 23:19

alex approved these changes Mar 21, 2021

View reviewed changes

ojeda merged commit d72964e into Rust-for-Linux:rust Mar 21, 2021

ojeda deleted the quick-start branch March 21, 2021 23:26

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some improvements for `quick-start.rst`#138

Some improvements for `quick-start.rst`#138
ojeda merged 1 commit intoRust-for-Linux:rustfrom
ojeda:quick-start

ojeda commented Mar 21, 2021

Uh oh!

alex Mar 21, 2021

Uh oh!

ojeda Mar 21, 2021

Uh oh!

ojeda Mar 21, 2021

Uh oh!

alex Mar 21, 2021

Uh oh!

ojeda Mar 21, 2021

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

	is supported, see :ref:`Documentation/rust/arch-support.rst <_rust_arch_support>`.
	is supported, see :doc:`/rust/arch-support.rst`.

Conversation

ojeda commented Mar 21, 2021

Uh oh!

alex Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

ojeda Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

ojeda Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

alex Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

ojeda Mar 21, 2021

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants