oe-lkp.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: kernel test robot <oliver.sang@intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: <oe-lkp@lists.linux.dev>, <lkp@intel.com>,
	<linux-kernel@vger.kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	<linux-trace-kernel@vger.kernel.org>, <oliver.sang@intel.com>
Subject: [linus:master] [trace_seq]  40fc60e36c: BUG:KASAN:global-out-of-bounds_in_hex_string
Date: Wed, 10 Apr 2024 16:00:03 +0800	[thread overview]
Message-ID: <202404101431.bb9742bf-lkp@intel.com> (raw)



Hello,

kernel test robot noticed "BUG:KASAN:global-out-of-bounds_in_hex_string" on:

commit: 40fc60e36c60ba85b2974e507b67df40c94e9578 ("trace_seq: Increase the buffer size to almost two pages")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

[test failed on linus/master 6c6e47d69d821047097909288b6d7f1aafb3b9b1]
[test failed on linux-next/master 8568bb2ccc278f344e6ac44af6ed010a90aa88dc]

in testcase: rcuscale
version: 
with following parameters:

	runtime: 300s
	scale_type: tasks



compiler: clang-17
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G

(please refer to attached dmesg/kmsg for entire log/backtrace)


we also noticed this issue does not always happen. we observed it 17 times
out of 30 runs as below, but did not observe it on parent.


8ec90be7f15fac42 40fc60e36c60ba85b2974e507b6
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :30          57%          17:30    dmesg.BUG:KASAN:global-out-of-bounds_in_hex_string


If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202404101431.bb9742bf-lkp@intel.com


[ 413.751080][ T494] BUG: KASAN: global-out-of-bounds in hex_string (lib/vsprintf.c:?) 
[  413.752115][  T494] Read of size 1 at addr ffffffff960c19c4 by task rcu_scale_write/494
[  413.753237][  T494]
[  413.753659][  T494] CPU: 0 PID: 494 Comm: rcu_scale_write Tainted: G                T  6.7.0-rc2-00035-g40fc60e36c60 #1 a4d5f5b4375fec29a5dddc8a474a6031f87af2c2
[  413.755544][  T494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[  413.756859][  T494] Call Trace:
[  413.757375][  T494]  <TASK>
[ 413.757850][ T494] dump_stack_lvl (lib/dump_stack.c:?) 
[ 413.758486][ T494] print_report (mm/kasan/report.c:365) 
[ 413.759147][ T494] ? hex_string (lib/vsprintf.c:?) 
[ 413.759803][ T494] kasan_report (mm/kasan/report.c:590) 
[ 413.760455][ T494] ? hex_string (lib/vsprintf.c:?) 
[ 413.761099][ T494] hex_string (lib/vsprintf.c:?) 
[ 413.761719][ T494] pointer (lib/vsprintf.c:?) 
[ 413.762328][ T494] vsnprintf (lib/vsprintf.c:2823) 
[ 413.762978][ T494] seq_buf_vprintf (lib/seq_buf.c:64) 
[ 413.763647][ T494] trace_seq_vprintf (include/linux/seq_buf.h:53 kernel/trace/trace_seq.c:151) 
[ 413.764351][ T494] trace_event_printf (kernel/trace/trace_output.c:325) 
[ 413.765043][ T494] trace_raw_output_i2c_write (include/trace/events/i2c.h:25) i2c_core
[ 413.766410][ T494] ? i2c_put_dma_safe_msg_buf (include/trace/events/i2c.h:25) i2c_core
[ 413.767794][ T494] ftrace_dump (kernel/trace/trace.c:10262) 
[ 413.768472][ T494] rcu_scale_writer (kernel/rcu/rcuscale.c:535) rcuscale
[ 413.769741][ T494] ? rcu_scale_writer (kernel/rcu/rcuscale.c:526) rcuscale
[ 413.771241][ T494] kthread (kernel/kthread.c:390) 
[ 413.771847][ T494] ? rcu_scale_reader (kernel/rcu/rcuscale.c:453) rcuscale
[ 413.773073][ T494] ? kthread_unuse_mm (kernel/kthread.c:341) 
[ 413.773791][ T494] ret_from_fork (arch/x86/kernel/process.c:153) 
[ 413.774441][ T494] ? kthread_unuse_mm (kernel/kthread.c:341) 
[ 413.775186][ T494] ret_from_fork_asm (arch/x86/entry/entry_64.S:250) 
[  413.775893][  T494]  </TASK>
[  413.776406][  T494]
[  413.776859][  T494] The buggy address belongs to the variable:
[ 413.777635][ T494] btf_allowlist_d_path+0x4/0x20 
[  413.778325][  T494]
[  413.778740][  T494] The buggy address belongs to the physical page:
[  413.779592][  T494] page:ffffea00074c3040 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1d30c1
[  413.780914][  T494] flags: 0x8000000000004000(reserved|zone=2)
[  413.781710][  T494] page_type: 0xffffffff()
[  413.782341][  T494] raw: 8000000000004000 ffffea00074c3048 ffffea00074c3048 0000000000000000
[  413.783501][  T494] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[  413.784669][  T494] page dumped because: kasan: bad access detected
[  413.785556][  T494] page_owner info is not present (never set?)
[  413.786370][  T494]
[  413.786789][  T494] Memory state around the buggy address:
[  413.787550][  T494]  ffffffff960c1880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  413.788643][  T494]  ffffffff960c1900: 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
[  413.789739][  T494] >ffffffff960c1980: 04 f9 f9 f9 04 f9 f9 f9 04 f9 f9 f9 00 00 00 f9
[  413.790848][  T494]                                            ^
[  413.791705][  T494]  ffffffff960c1a00: f9 f9 f9 f9 00 f9 f9 f9 00 f9 f9 f9 04 f9 f9 f9
[  413.792789][  T494]  ffffffff960c1a80: 01 f9 f9 f9 01 f9 f9 f9 00 00 f9 f9 00 00 f9 f9
[  413.797442][  T494] ==================================================================
[  413.798544][  T494] Disabling lock debugging due to kernel taint
[  413.799401][  T494]  swapper-1         0dNZ.. 118977266us : i2c_write: i2c--1868734768 #65535 a=ffff f=7b28 l=4231 [00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00]
[  413.802715][  T494]  swapper-1         0.N.1. 118977275us : i2c_read: i2c--1868734768 #65535 a=ffff f=36fb l=38182
[  413.804088][  T494] ---------------------------------
[  413.804885][  T494] tasks-scale: Test complete



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240410/202404101431.bb9742bf-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


                 reply	other threads:[~2024-04-10  8:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202404101431.bb9742bf-lkp@intel.com \
    --to=oliver.sang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=oe-lkp@lists.linux.dev \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).