/usr/src/linux-linaro-stable-mx6/drivers/mmc/core/core.c #11
Comments
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
When booting secondary CPUs, announce_cpu() is called to show which cpu has been brought up. For example: [ 0.402751] smpboot: Booting Node 0, Processors rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 OK [ 0.525667] smpboot: Booting Node 1, Processors rabeeh#6 linux4kix#7 linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 OK [ 0.755592] smpboot: Booting Node 0, Processors linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 linux4kix#16 linux4kix#17 OK [ 0.890495] smpboot: Booting Node 1, Processors linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 But the last "OK" is lost, because 'nr_cpu_ids-1' represents the maximum possible cpu id. It should use the maximum present cpu id in case not all CPUs booted up. Signed-off-by: Libin <huawei.libin@huawei.com> Cc: <guohanjun@huawei.com> Cc: <wangyijing@huawei.com> Cc: <fenghua.yu@intel.com> Cc: <paul.gortmaker@windriver.com> Link: http://lkml.kernel.org/r/1378378676-18276-1-git-send-email-huawei.libin@huawei.com [ tweaked the changelog, removed unnecessary line break, tweaked the format to align the fields vertically. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
When parsing lines from objdump a line containing source code starting
with a numeric label is mistaken for a line of disassembly starting with
a memory address.
Current validation fails to recognise that the "memory address" is out
of range and calculates an invalid offset which later causes this
segfault:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
at util/annotate.c:631
631 hits += h->addr[offset++];
(gdb) bt
#0 0x0000000000457315 in disasm__calc_percent (notes=0xc98970, evidx=0, offset=143705, end=2127526177, path=0x7fffffffbf50)
at util/annotate.c:631
rabeeh#1 0x00000000004d65e3 in annotate_browser__calc_percent (browser=0x7fffffffd130, evsel=0xa01da0) at ui/browsers/annotate.c:364
rabeeh#2 0x00000000004d7433 in annotate_browser__run (browser=0x7fffffffd130, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:672
rabeeh#3 0x00000000004d80c9 in symbol__tui_annotate (sym=0xc989a0, map=0xa02660, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:962
rabeeh#4 0x00000000004d7aa0 in hist_entry__tui_annotate (he=0xdf73f0, evsel=0xa01da0, hbt=0x0) at ui/browsers/annotate.c:823
rabeeh#5 0x00000000004dd648 in perf_evsel__hists_browse (evsel=0xa01da0, nr_events=1, helpline=
0x58b768 "For a higher level overview, try: perf report --sort comm,dso", ev_name=0xa02cd0 "cycles", left_exits=false, hbt=
0x0, min_pcnt=0, env=0xa011e0) at ui/browsers/hists.c:1659
rabeeh#6 0x00000000004de372 in perf_evlist__tui_browse_hists (evlist=0xa01520, help=
0x58b768 "For a higher level overview, try: perf report --sort comm,dso", hbt=0x0, min_pcnt=0, env=0xa011e0)
at ui/browsers/hists.c:1950
linux4kix#7 0x000000000042cf6b in __cmd_report (rep=0x7fffffffd6c0) at builtin-report.c:581
linux4kix#8 0x000000000042e25d in cmd_report (argc=0, argv=0x7fffffffe4b0, prefix=0x0) at builtin-report.c:965
linux4kix#9 0x000000000041a0e1 in run_builtin (p=0x801548, argc=1, argv=0x7fffffffe4b0) at perf.c:319
linux4kix#10 0x000000000041a319 in handle_internal_command (argc=1, argv=0x7fffffffe4b0) at perf.c:376
linux4kix#11 0x000000000041a465 in run_argv (argcp=0x7fffffffe38c, argv=0x7fffffffe380) at perf.c:420
linux4kix#12 0x000000000041a707 in main (argc=1, argv=0x7fffffffe4b0) at perf.c:521
After the fix is applied the symbol can be annotated showing the
problematic line "1: rep"
copy_user_generic_string /usr/lib/debug/lib/modules/3.9.10-100.fc17.x86_64/vmlinux
*/
ENTRY(copy_user_generic_string)
CFI_STARTPROC
ASM_STAC
andl %edx,%edx
and %edx,%edx
jz 4f
je 37
cmpl $8,%edx
cmp $0x8,%edx
jb 2f /* less than 8 bytes, go to byte copy loop */
jb 33
ALIGN_DESTINATION
mov %edi,%ecx
and $0x7,%ecx
je 28
sub $0x8,%ecx
neg %ecx
sub %ecx,%edx
1a: mov (%rsi),%al
mov %al,(%rdi)
inc %rsi
inc %rdi
dec %ecx
jne 1a
movl %edx,%ecx
28: mov %edx,%ecx
shrl $3,%ecx
shr $0x3,%ecx
andl $7,%edx
and $0x7,%edx
1: rep
100.00 rep movsq %ds:(%rsi),%es:(%rdi)
movsq
2: movl %edx,%ecx
33: mov %edx,%ecx
3: rep
rep movsb %ds:(%rsi),%es:(%rdi)
movsb
4: xorl %eax,%eax
37: xor %eax,%eax
data32 xchg %ax,%ax
ASM_CLAC
ret
retq
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1379009721-27667-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 OK [ 0.644008] smpboot: Booting Node 1, Processors: linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 OK [ 1.245006] smpboot: Booting Node 2, Processors: linux4kix#16 linux4kix#17 linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 OK [ 1.864005] smpboot: Booting Node 3, Processors: linux4kix#24 linux4kix#25 linux4kix#26 linux4kix#27 linux4kix#28 #29 #30 #31 OK [ 2.489005] smpboot: Booting Node 4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK [ 3.093005] smpboot: Booting Node 5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK [ 3.698005] smpboot: Booting Node 6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK [ 4.304005] smpboot: Booting Node 7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Libin <huawei.libin@huawei.com> Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: rabeeh#1 rabeeh#2 rabeeh#3 rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 [ 0.603005] .... node rabeeh#1, CPUs: linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 [ 1.200005] .... node rabeeh#2, CPUs: linux4kix#16 linux4kix#17 linux4kix#18 linux4kix#19 linux4kix#20 linux4kix#21 linux4kix#22 linux4kix#23 [ 1.796005] .... node rabeeh#3, CPUs: linux4kix#24 linux4kix#25 linux4kix#26 linux4kix#27 linux4kix#28 #29 #30 #31 [ 2.393005] .... node rabeeh#4, CPUs: #32 #33 #34 #35 #36 #37 #38 #39 [ 2.996005] .... node rabeeh#5, CPUs: #40 #41 #42 #43 #44 #45 #46 #47 [ 3.600005] .... node rabeeh#6, CPUs: #48 #49 #50 #51 #52 #53 #54 #55 [ 4.202005] .... node linux4kix#7, CPUs: #56 #57 #58 #59 #60 #61 #62 #63 [ 4.811005] .... node linux4kix#8, CPUs: #64 #65 #66 #67 #68 #69 #70 #71 [ 5.421006] .... node linux4kix#9, CPUs: #72 #73 #74 #75 #76 #77 #78 #79 [ 6.032005] .... node linux4kix#10, CPUs: #80 #81 #82 #83 #84 #85 #86 #87 [ 6.648006] .... node linux4kix#11, CPUs: #88 #89 #90 #91 #92 #93 #94 #95 [ 7.262005] .... node linux4kix#12, CPUs: #96 #97 #98 #99 #100 #101 #102 #103 [ 7.865005] .... node linux4kix#13, CPUs: #104 #105 #106 #107 #108 #109 #110 #111 [ 8.466005] .... node linux4kix#14, CPUs: #112 #113 #114 #115 #116 #117 #118 #119 [ 9.073006] .... node linux4kix#15, CPUs: #120 #121 #122 #123 #124 #125 #126 #127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
Andrey reported the following report: ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3 ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3) Accessed by thread T13003: #0 ffffffff810dd2da (asan_report_error+0x32a/0x440) rabeeh#1 ffffffff810dc6b0 (asan_check_region+0x30/0x40) rabeeh#2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20) rabeeh#3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260) rabeeh#4 ffffffff812a1065 (__fput+0x155/0x360) rabeeh#5 ffffffff812a12de (____fput+0x1e/0x30) rabeeh#6 ffffffff8111708d (task_work_run+0x10d/0x140) linux4kix#7 ffffffff810ea043 (do_exit+0x433/0x11f0) linux4kix#8 ffffffff810eaee4 (do_group_exit+0x84/0x130) linux4kix#9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30) linux4kix#10 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Allocated by thread T5167: #0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0) rabeeh#1 ffffffff8128337c (__kmalloc+0xbc/0x500) rabeeh#2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90) rabeeh#3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0) rabeeh#4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40) rabeeh#5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430) rabeeh#6 ffffffff8129b668 (finish_open+0x68/0xa0) linux4kix#7 ffffffff812b66ac (do_last+0xb8c/0x1710) linux4kix#8 ffffffff812b7350 (path_openat+0x120/0xb50) linux4kix#9 ffffffff812b8884 (do_filp_open+0x54/0xb0) linux4kix#10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0) linux4kix#11 ffffffff8129d4b7 (SyS_open+0x37/0x50) linux4kix#12 ffffffff81928782 (system_call_fastpath+0x16/0x1b) Shadow bytes around the buggy address: ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap redzone: fa Heap kmalloc redzone: fb Freed heap region: fd Shadow gap: fe The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;' Although the crash happened in ftrace_regex_open() the real bug occurred in trace_get_user() where there's an incrementation to parser->idx without a check against the size. The way it is triggered is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop that reads the last character stores it and then breaks out because there is no more characters. Then the last character is read to determine what to do next, and the index is incremented without checking size. Then the caller of trace_get_user() usually nulls out the last character with a zero, but since the index is equal to the size, it writes a nul character after the allocated space, which can corrupt memory. Luckily, only root user has write access to this file. Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
…ux/kernel/git/tip/tip
Pull x86 boot changes from Ingo Molnar:
"Two changes that prettify and compactify the SMP bootup output from:
smpboot: Booting Node 0, Processors rabeeh#1 rabeeh#2 rabeeh#3 OK
smpboot: Booting Node 1, Processors rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7 OK
smpboot: Booting Node 2, Processors linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11 OK
smpboot: Booting Node 3, Processors linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15 OK
Brought up 16 CPUs
to something like:
x86: Booting SMP configuration:
.... node #0, CPUs: rabeeh#1 rabeeh#2 rabeeh#3
.... node rabeeh#1, CPUs: rabeeh#4 rabeeh#5 rabeeh#6 linux4kix#7
.... node rabeeh#2, CPUs: linux4kix#8 linux4kix#9 linux4kix#10 linux4kix#11
.... node rabeeh#3, CPUs: linux4kix#12 linux4kix#13 linux4kix#14 linux4kix#15
x86: Booted up 4 nodes, 16 CPUs"
* 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/boot: Further compress CPUs bootup message
x86: Improve the printout of the SMP bootup CPU table
mk01
pushed a commit
to mk01/linux-linaro-stable-mx6
that referenced
this issue
Sep 3, 2014
commit 561a4fe851ccab9dd0d14989ab566f9392d9f8b5 upstream. As trace event triggers are now part of the mainline kernel, I added my trace event trigger tests to my test suite I run on all my kernels. Now these tests get run under different config options, and one of those options is CONFIG_PROVE_RCU, which checks under lockdep that the rcu locking primitives are being used correctly. This triggered the following splat: =============================== [ INFO: suspicious RCU usage. ] 3.15.0-rc2-test+ linux4kix#11 Not tainted ------------------------------- kernel/trace/trace_events_trigger.c:80 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 4 locks held by swapper/1/0: #0: ((&(&j_cdbs->work)->timer)){..-...}, at: [<ffffffff8104d2cc>] call_timer_fn+0x5/0x1be rabeeh#1: (&(&pool->lock)->rlock){-.-...}, at: [<ffffffff81059856>] __queue_work+0x140/0x283 rabeeh#2: (&p->pi_lock){-.-.-.}, at: [<ffffffff8106e961>] try_to_wake_up+0x2e/0x1e8 rabeeh#3: (&rq->lock){-.-.-.}, at: [<ffffffff8106ead3>] try_to_wake_up+0x1a0/0x1e8 stack backtrace: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc2-test+ linux4kix#11 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 0000000000000001 ffff88007e083b98 ffffffff819f53a5 0000000000000006 ffff88007b0942c0 ffff88007e083bc8 ffffffff81081307 ffff88007ad96d20 0000000000000000 ffff88007af2d840 ffff88007b2e701c ffff88007e083c18 Call Trace: <IRQ> [<ffffffff819f53a5>] dump_stack+0x4f/0x7c [<ffffffff81081307>] lockdep_rcu_suspicious+0x107/0x110 [<ffffffff810ee51c>] event_triggers_call+0x99/0x108 [<ffffffff810e8174>] ftrace_event_buffer_commit+0x42/0xa4 [<ffffffff8106aadc>] ftrace_raw_event_sched_wakeup_template+0x71/0x7c [<ffffffff8106bcbf>] ttwu_do_wakeup+0x7f/0xff [<ffffffff8106bd9b>] ttwu_do_activate.constprop.126+0x5c/0x61 [<ffffffff8106eadf>] try_to_wake_up+0x1ac/0x1e8 [<ffffffff8106eb77>] wake_up_process+0x36/0x3b [<ffffffff810575cc>] wake_up_worker+0x24/0x26 [<ffffffff810578bc>] insert_work+0x5c/0x65 [<ffffffff81059982>] __queue_work+0x26c/0x283 [<ffffffff81059999>] ? __queue_work+0x283/0x283 [<ffffffff810599b7>] delayed_work_timer_fn+0x1e/0x20 [<ffffffff8104d3a6>] call_timer_fn+0xdf/0x1be^M [<ffffffff8104d2cc>] ? call_timer_fn+0x5/0x1be [<ffffffff81059999>] ? __queue_work+0x283/0x283 [<ffffffff8104d823>] run_timer_softirq+0x1a4/0x22f^M [<ffffffff8104696d>] __do_softirq+0x17b/0x31b^M [<ffffffff81046d03>] irq_exit+0x42/0x97 [<ffffffff81a08db6>] smp_apic_timer_interrupt+0x37/0x44 [<ffffffff81a07a2f>] apic_timer_interrupt+0x6f/0x80 <EOI> [<ffffffff8100a5d8>] ? default_idle+0x21/0x32 [<ffffffff8100a5d6>] ? default_idle+0x1f/0x32 [<ffffffff8100ac10>] arch_cpu_idle+0xf/0x11 [<ffffffff8107b3a4>] cpu_startup_entry+0x1a3/0x213 [<ffffffff8102a23c>] start_secondary+0x212/0x219 The cause is that the triggers are protected by rcu_read_lock_sched() but the data is dereferenced with rcu_dereference() which expects it to be protected with rcu_read_lock(). The proper reference should be rcu_dereference_sched(). Cc: Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
n-aizu
pushed a commit
to n-aizu/linux-linaro-stable-mx6
that referenced
this issue
Apr 19, 2015
…-mx6 arm: cubox-i and hummingboard defconfig
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found a small bug in
/usr/src/linux-linaro-stable-mx6/drivers/mmc/core/core.c
Requires an include for GPIO
e.g.:
include <linux/gpio/consumer.h>
No expert on git or I would maybe be able to push this myself; I did all the work for ya though :)
The text was updated successfully, but these errors were encountered: