Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support x86 (i.e. 32-bit) #78

Open
ojeda opened this issue Jan 21, 2021 · 0 comments
Open

Support x86 (i.e. 32-bit) #78

ojeda opened this issue Jan 21, 2021 · 0 comments
Labels
• arch Related to a particular arch, `arch/` support in general...

Comments

@ojeda
Copy link
Member

ojeda commented Jan 21, 2021 •
edited
Loading

While x86 (i.e. 32-bit) will become less important over time, it is a key architecture of the kernel (and the original one, too). In addition, it is a non-64 bit target (which helps widening our tests to uncover potential issues) and it is a target that pretty much everyone can natively run. Thus we should support it.

Linux x86 targets with official Ubuntu binutils etc. support:

Linux arch  QEMU target     LLVM target  Ubuntu binutils            Example Rust triple
----------  --------------  -----------  -------------------------  ----------------------

x86         i386-softmmu    X86          binutils-i686-linux-gnu    i686-unknown-linux-gnu
x86         x86_64-softmmu  X86          binutils-x86-64-linux-gnu  x86_64-linux-kernel
@ojeda ojeda added upstream - optional • misc Related to other topics (e.g. CI). labels Jan 21, 2021
@ojeda ojeda added • arch Related to a particular arch, `arch/` support in general... prio: high and removed • misc Related to other topics (e.g. CI). upstream - optional labels Mar 18, 2021
ojeda added a commit to ojeda/linux that referenced this issue Jul 29, 2021
@ojeda
rust: support x86 (i.e. 32-bit)
22a4b6d 
Closes Rust-for-Linux#78.
Closes Rust-for-Linux#460.

Signed-off-by: Miguel Ojeda <[email protected]>
@ojeda ojeda removed the prio: high label Feb 17, 2023
fbq pushed a commit that referenced this issue Dec 28, 2023
@borkmann
bpf: Fix a few selftest failures due to llvm18 change
b16904f 
With latest upstream llvm18, the following test cases failed:

  $ ./test_progs -j
  #13/2    bpf_cookie/multi_kprobe_link_api:FAIL
  #13/3    bpf_cookie/multi_kprobe_attach_api:FAIL
  #13      bpf_cookie:FAIL
  #77      fentry_fexit:FAIL
  #78/1    fentry_test/fentry:FAIL
  #78      fentry_test:FAIL
  #82/1    fexit_test/fexit:FAIL
  #82      fexit_test:FAIL
  #112/1   kprobe_multi_test/skel_api:FAIL
  #112/2   kprobe_multi_test/link_api_addrs:FAIL
  [...]
  #112     kprobe_multi_test:FAIL
  #356/17  test_global_funcs/global_func17:FAIL
  #356     test_global_funcs:FAIL

Further analysis shows llvm upstream patch [1] is responsible for the above
failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c,
without [1], the asm code is:

  0000000000000400 <bpf_fentry_test7>:
     400: f3 0f 1e fa                   endbr64
     404: e8 00 00 00 00                callq   0x409 <bpf_fentry_test7+0x9>
     409: 48 89 f8                      movq    %rdi, %rax
     40c: c3                            retq
     40d: 0f 1f 00                      nopl    (%rax)

... and with [1], the asm code is:

  0000000000005d20 <bpf_fentry_test7.specialized.1>:
    5d20: e8 00 00 00 00                callq   0x5d25 <bpf_fentry_test7.specialized.1+0x5>
    5d25: c3                            retq

... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7>
and this caused test failures for #13/#77 etc. except #356.

For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog
looks like:

  0000000000000000 <global_func17>:
       0:       b4 00 00 00 2a 00 00 00 w0 = 0x2a
       1:       95 00 00 00 00 00 00 00 exit

... which passed verification while the test itself expects a verification
failure.

Let us add 'barrier_var' style asm code in both places to prevent function
specialization which caused selftests failure.

  [1] llvm/llvm-project#72903

Signed-off-by: Yonghong Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
metaspace pushed a commit to metaspace/linux that referenced this issue Dec 17, 2024
@melver @gregkh
kcsan, seqlock: Support seqcount_latch_t
a694fc0 
[ Upstream commit 5c1806c ]

While fuzzing an arm64 kernel, Alexander Potapenko reported:

| BUG: KCSAN: data-race in ktime_get_mono_fast_ns / timekeeping_update
|
| write to 0xffffffc082e74248 of 56 bytes by interrupt on cpu 0:
|  update_fast_timekeeper kernel/time/timekeeping.c:430 [inline]
|  timekeeping_update+0x1d8/0x2d8 kernel/time/timekeeping.c:768
|  timekeeping_advance+0x9e8/0xb78 kernel/time/timekeeping.c:2344
|  update_wall_time+0x18/0x38 kernel/time/timekeeping.c:2360
|  [...]
|
| read to 0xffffffc082e74258 of 8 bytes by task 5260 on cpu 1:
|  __ktime_get_fast_ns kernel/time/timekeeping.c:372 [inline]
|  ktime_get_mono_fast_ns+0x88/0x174 kernel/time/timekeeping.c:489
|  init_srcu_struct_fields+0x40c/0x530 kernel/rcu/srcutree.c:263
|  init_srcu_struct+0x14/0x20 kernel/rcu/srcutree.c:311
|  [...]
|
| value changed: 0x000002f875d33266 -> 0x000002f877416866
|
| Reported by Kernel Concurrency Sanitizer on:
| CPU: 1 UID: 0 PID: 5260 Comm: syz.2.7483 Not tainted 6.12.0-rc3-dirty Rust-for-Linux#78

This is a false positive data race between a seqcount latch writer and a reader
accessing stale data. Since its introduction, KCSAN has never understood the
seqcount_latch interface (due to being unannotated).

Unlike the regular seqlock interface, the seqcount_latch interface for latch
writers never has had a well-defined critical section, making it difficult to
teach tooling where the critical section starts and ends.

Introduce an instrumentable (non-raw) seqcount_latch interface, with
which we can clearly denote writer critical sections. This both helps
readability and tooling like KCSAN to understand when the writer is done
updating all latch copies.

Fixes: 88ecd15 ("seqlock, kcsan: Add annotations for KCSAN")
Reported-by: Alexander Potapenko <[email protected]>
Co-developed-by: "Peter Zijlstra (Intel)" <[email protected]>
Signed-off-by: "Peter Zijlstra (Intel)" <[email protected]>
Signed-off-by: Marco Elver <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
• arch Related to a particular arch, `arch/` support in general...
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ojeda