<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/csky/kernel/perf_callchain.c, branch linux-5.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-02-25T08:36:05Z</updated>
<entry>
<title>uaccess: fix type mismatch warnings from access_ok()</title>
<updated>2022-02-25T08:36:05Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2022-02-14T19:22:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=23fc539e81295b14b50c6ccc5baeb4f3d59d822d'/>
<id>urn:sha1:23fc539e81295b14b50c6ccc5baeb4f3d59d822d</id>
<content type='text'>
On some architectures, access_ok() does not do any argument type
checking, so replacing the definition with a generic one causes
a few warnings for harmless issues that were never caught before.

Fix the ones that I found either through my own test builds or
that were reported by the 0-day bot.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Acked-by: Dinh Nguyen &lt;dinguyen@kernel.org&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
</entry>
<entry>
<title>perf: Drop dead and useless guest "support" from arm, csky, nds32 and riscv</title>
<updated>2021-11-17T13:49:07Z</updated>
<author>
<name>Sean Christopherson</name>
</author>
<published>2021-11-11T02:07:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=84af21d850ee1ccc990df37dd47c13fdfe93be75'/>
<id>urn:sha1:84af21d850ee1ccc990df37dd47c13fdfe93be75</id>
<content type='text'>
Drop "support" for guest callbacks from architectures that don't implement
the guest callbacks.  Future patches will convert the callbacks to
static_call; rather than churn a bunch of arch code (that was presumably
copy+pasted from x86), remove it wholesale as it's useless and at best
wasting cycles.

A future patch will also add a Kconfig to force architcture to opt into
the callbacks to make it more difficult for uses "support" to sneak in in
the future.

No functional change intended.

Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Link: https://lore.kernel.org/r/20211111020738.2512932-6-seanjc@google.com
</content>
</entry>
<entry>
<title>perf: Protect perf_guest_cbs with RCU</title>
<updated>2021-11-17T13:49:06Z</updated>
<author>
<name>Sean Christopherson</name>
</author>
<published>2021-11-11T02:07:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff083a2d972f56bebfd82409ca62e5dfce950961'/>
<id>urn:sha1:ff083a2d972f56bebfd82409ca62e5dfce950961</id>
<content type='text'>
Protect perf_guest_cbs with RCU to fix multiple possible errors.  Luckily,
all paths that read perf_guest_cbs already require RCU protection, e.g. to
protect the callback chains, so only the direct perf_guest_cbs touchpoints
need to be modified.

Bug #1 is a simple lack of WRITE_ONCE/READ_ONCE behavior to ensure
perf_guest_cbs isn't reloaded between a !NULL check and a dereference.
Fixed via the READ_ONCE() in rcu_dereference().

Bug #2 is that on weakly-ordered architectures, updates to the callbacks
themselves are not guaranteed to be visible before the pointer is made
visible to readers.  Fixed by the smp_store_release() in
rcu_assign_pointer() when the new pointer is non-NULL.

Bug #3 is that, because the callbacks are global, it's possible for
readers to run in parallel with an unregisters, and thus a module
implementing the callbacks can be unloaded while readers are in flight,
resulting in a use-after-free.  Fixed by a synchronize_rcu() call when
unregistering callbacks.

Bug #1 escaped notice because it's extremely unlikely a compiler will
reload perf_guest_cbs in this sequence.  perf_guest_cbs does get reloaded
for future derefs, e.g. for -&gt;is_user_mode(), but the -&gt;is_in_guest()
guard all but guarantees the consumer will win the race, e.g. to nullify
perf_guest_cbs, KVM has to completely exit the guest and teardown down
all VMs before KVM start its module unload / unregister sequence.  This
also makes it all but impossible to encounter bug #3.

Bug #2 has not been a problem because all architectures that register
callbacks are strongly ordered and/or have a static set of callbacks.

But with help, unloading kvm_intel can trigger bug #1 e.g. wrapping
perf_guest_cbs with READ_ONCE in perf_misc_flags() while spamming
kvm_intel module load/unload leads to:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] PREEMPT SMP
  CPU: 6 PID: 1825 Comm: stress Not tainted 5.14.0-rc2+ #459
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:perf_misc_flags+0x1c/0x70
  Call Trace:
   perf_prepare_sample+0x53/0x6b0
   perf_event_output_forward+0x67/0x160
   __perf_event_overflow+0x52/0xf0
   handle_pmi_common+0x207/0x300
   intel_pmu_handle_irq+0xcf/0x410
   perf_event_nmi_handler+0x28/0x50
   nmi_handle+0xc7/0x260
   default_do_nmi+0x6b/0x170
   exc_nmi+0x103/0x130
   asm_exc_nmi+0x76/0xbf

Fixes: 39447b386c84 ("perf: Enhance perf to allow for guest statistic collection from host")
Signed-off-by: Sean Christopherson &lt;seanjc@google.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211111020738.2512932-2-seanjc@google.com
</content>
</entry>
<entry>
<title>csky: Fixup perf callchain unwind</title>
<updated>2020-05-13T09:55:05Z</updated>
<author>
<name>Mao Han</name>
</author>
<published>2020-04-20T04:55:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=229a0ddee1108a3f82a873e6cbbe35c92c540444'/>
<id>urn:sha1:229a0ddee1108a3f82a873e6cbbe35c92c540444</id>
<content type='text'>
 [ 5221.974084] Unable to handle kernel paging request at virtual address 0xfffff000, pc: 0x8002c18e
 [ 5221.985929] Oops: 00000000
 [ 5221.989488]
 [ 5221.989488] CURRENT PROCESS:
 [ 5221.989488]
 [ 5221.992877] COMM=callchain_test PID=11962
 [ 5221.995213] TEXT=00008000-000087e0 DATA=00009f1c-0000a018 BSS=0000a018-0000b000
 [ 5221.999037] USER-STACK=7fc18e20  KERNEL-STACK=be204680
 [ 5221.999037]
 [ 5222.003292] PC: 0x8002c18e (perf_callchain_kernel+0x3e/0xd4)
 [ 5222.007957] LR: 0x8002c198 (perf_callchain_kernel+0x48/0xd4)
 [ 5222.074873] Call Trace:
 [ 5222.074873] [&lt;800a248e&gt;] get_perf_callchain+0x20a/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de6e&gt;] perf_event_output_forward+0x36/0x98
 [ 5222.074873] [&lt;800497e0&gt;] search_exception_tables+0x20/0x44
 [ 5222.074873] [&lt;8002cbb6&gt;] do_page_fault+0x92/0x378
 [ 5222.074873] [&lt;80098608&gt;] __perf_event_overflow+0x54/0xdc
 [ 5222.074873] [&lt;80098778&gt;] perf_swevent_hrtimer+0xe8/0x164
 [ 5222.074873] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.074873] [&lt;8002c014&gt;] user_backtrace+0x58/0xc4
 [ 5222.074873] [&lt;8002c0b4&gt;] perf_callchain_user+0x34/0xd0
 [ 5222.074873] [&lt;800a2442&gt;] get_perf_callchain+0x1be/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009d834&gt;] perf_output_sample+0x78c/0x858
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de94&gt;] perf_event_output_forward+0x5c/0x98
 [ 5222.097846]
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;8006c874&gt;] hrtimer_interrupt+0x104/0x2ec
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8006c770&gt;] hrtimer_interrupt+0x0/0x2ec
 [ 5222.097846] [&lt;8005f2e4&gt;] __handle_irq_event_percpu+0xac/0x19c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8005f408&gt;] handle_irq_event_percpu+0x34/0x88
 [ 5222.097846] [&lt;8005f480&gt;] handle_irq_event+0x24/0x64
 [ 5222.097846] [&lt;8006218c&gt;] handle_level_irq+0x68/0xdc
 [ 5222.097846] [&lt;8005ec76&gt;] __handle_domain_irq+0x56/0xa8
 [ 5222.097846] [&lt;80450e90&gt;] ck_irq_handler+0xac/0xe4
 [ 5222.097846] [&lt;80029012&gt;] csky_do_IRQ+0x12/0x24
 [ 5222.097846] [&lt;8002a3a0&gt;] csky_irq+0x70/0x80
 [ 5222.097846] [&lt;800ca612&gt;] alloc_set_pte+0xd2/0x238
 [ 5222.097846] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.097846] [&lt;800a0340&gt;] perf_event_exit_task+0x98/0x43c

The original fp check doesn't base on the real kernal stack region.
Invalid fp address may cause kernel panic.

Signed-off-by: Mao Han &lt;han_mao@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
</content>
</entry>
<entry>
<title>csky: Add perf callchain support</title>
<updated>2019-04-22T05:44:57Z</updated>
<author>
<name>Mao Han</name>
</author>
<published>2019-02-21T13:41:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cfa4d93b977a1b1129e7207d11b5daecdf0c56c4'/>
<id>urn:sha1:cfa4d93b977a1b1129e7207d11b5daecdf0c56c4</id>
<content type='text'>
This patch add support for perf callchain sampling on csky platform.
As fp is used to unwind the stack, the program being sampled and the
C library need to be compiled with -mbacktrace for user callchains,
kernel callchains require CONFIG_STACKTRACE = y.

Changelog:
 - Coding convention with Christoph's advice for riscv's.

Signed-off-by: Mao Han &lt;han_mao@c-sky.com&gt;
Signed-off-by: Guo Ren &lt;ren_guo@c-sky.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
</content>
</entry>
</feed>
