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

Warning: "symbol value 'm' invalid for BRCMFMAC_USB" #10

Open
tempestnano opened this issue Aug 22, 2014 · 0 comments
Open

Warning: "symbol value 'm' invalid for BRCMFMAC_USB" #10

tempestnano opened this issue Aug 22, 2014 · 0 comments

Comments

@tempestnano
Copy link 

make imx_v7_cbi_hb_defconfig
warning: symbol value 'm' invalid for BRCMFMAC_USB
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@torvalds
drivers/base/memory.c: fix show_mem_removable() to handle missing sec…
21ea9f5 
…tions

"cat /sys/devices/system/memory/memory*/removable" crashed the system.

The problem is that show_mem_removable() is passing a
bad pfn to is_mem_section_removable(), which causes

    if (!node_online(page_to_nid(page)))

to blow up.  Why is it passing in a bad pfn?

The reason is that show_mem_removable() will loop sections_per_block
times.  sections_per_block is 16, but mem->section_count is 8,
indicating holes in this memory block.  Checking that the memory section
is present before checking to see if the memory section is removable
fixes the problem.

   harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
   0
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   1
   BUG: unable to handle kernel paging request at ffffea00c3200000
   IP: [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   PGD 83ffd4067 PUD 37bdfce067 PMD 0
   Oops: 0000 [rabeeh#1] SMP
   Modules linked in: autofs4 binfmt_misc rdma_ucm rdma_cm iw_cm ib_addr ib_srp scsi_transport_srp scsi_tgt ib_ipoib ib_cm ib_uverbs ib_umad iw_cxgb3 cxgb3 mdio mlx4_en mlx4_ib ib_sa mlx4_core ib_mthca ib_mad ib_core fuse nls_iso8859_1 nls_cp437 vfat fat joydev loop hid_generic usbhid hid hwperf(O) numatools(O) dm_mod iTCO_wdt ipv6 iTCO_vendor_support igb i2c_i801 ioatdma i2c_algo_bit ehci_pci pcspkr lpc_ich i2c_core ehci_hcd ptp sg mfd_core dca rtc_cmos pps_core mperf button xhci_hcd sd_mod crc_t10dif usbcore usb_common scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh gru(O) xvma(O) xfs crc32c libcrc32c thermal sata_nv processor piix mptsas mptscsih scsi_transport_sas mptbase megaraid_sas fan thermal_sys hwmon ext3 jbd ata_piix ahci libahci libata scsi_mod
   CPU: 4 PID: 5991 Comm: cat Tainted: G           O 3.11.0-rc5-rja-uv+ linux4kix#10
   Hardware name: SGI UV2000/ROMLEY, BIOS SGI UV 2000/3000 series BIOS 01/15/2013
   task: ffff88081f034580 ti: ffff880820022000 task.ti: ffff880820022000
   RIP: 0010:[<ffffffff81117ed1>]  [<ffffffff81117ed1>] is_pageblock_removable_nolock+0x1/0x90
   RSP: 0018:ffff880820023df8  EFLAGS: 00010287
   RAX: 0000000000040000 RBX: ffffea00c3200000 RCX: 0000000000000004
   RDX: ffffea00c30b0000 RSI: 00000000001c0000 RDI: ffffea00c3200000
   RBP: ffff880820023e38 R08: 0000000000000000 R09: 0000000000000001
   R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00c33c0000
   R13: 0000160000000000 R14: 6db6db6db6db6db7 R15: 0000000000000001
   FS:  00007ffff7fb2700(0000) GS:ffff88083fc80000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: ffffea00c3200000 CR3: 000000081b954000 CR4: 00000000000407e0
   Call Trace:
     show_mem_removable+0x41/0x70
     dev_attr_show+0x2a/0x60
     sysfs_read_file+0xf7/0x1c0
     vfs_read+0xc8/0x130
     SyS_read+0x5d/0xa0
     system_call_fastpath+0x16/0x1b

Signed-off-by: Russ Anderson <rja@sgi.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@libin2015
x86/smpboot: Fix announce_cpu() to printk() the last "OK" properly
5223948 
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
@ahunter6 @acmel
perf annotate: Fix objdump line parsing offset validation
886b37b 
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
@suryasaimadhu
x86: Improve the printout of the SMP bootup CPU table
646e29a 
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
@bp3tk0v
x86/boot: Further compress CPUs bootup message
a17bce4 
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
@jmberg-intel
iwlwifi: mvm: fix locking in iwl_mvm_bt_rssi_event()
3dd1cd2 
This will deadlock due to commit 9f34783863bea806
("iwlwifi: mvm: Implement BT coex notifications"):

  =============================================
  [ INFO: possible recursive locking detected ]
  3.5.0 linux4kix#10 Tainted: G        W  O
  ---------------------------------------------
  kworker/2:1/5214 is trying to acquire lock:
   (&mvm->mutex){+.+.+.}, at: [<ffffffffa03be23e>] iwl_mvm_bt_rssi_event+0x5e/0x210 [iwlmvm]

  but task is already holding lock:
   (&mvm->mutex){+.+.+.}, at: [<ffffffffa03ab2d9>] iwl_mvm_async_handlers_wk+0x49/0x120 [iwlmvm]

  other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(&mvm->mutex);
    lock(&mvm->mutex);

   *** DEADLOCK ***

Change-Id: I9104f252b34676e2f7ffcd51166f95367e08a4d9
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-on: https://gerrit.rds.intel.com/21887
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Conflicts:
	drivers/net/wireless/iwlwifi/mvm/bt-coex.c
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@rostedt
tracing: Fix potential out-of-bounds in trace_get_user()
057db84 
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
@torvalds
Merge branch 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/lin…
014d595 
…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
@fabioestevam
ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS cal…
11d4bb1 
…culation

Currently mx53 (CortexA8) running at 1GHz reports:
Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760)

Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop)

The original object code looks like this:

00000010 <__loop_const_udelay>:
  10:	e3e01000 	mvn	r1, #0
  14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
  18:	e5922000 	ldr	r2, [r2]
  1c:	e0800921 	add	r0, r0, r1, lsr linux4kix#18
  20:	e1a00720 	lsr	r0, r0, linux4kix#14
  24:	e0822b21 	add	r2, r2, r1, lsr linux4kix#22
  28:	e1a02522 	lsr	r2, r2, linux4kix#10
  2c:	e0000092 	mul	r0, r2, r0
  30:	e0800d21 	add	r0, r0, r1, lsr linux4kix#26
  34:	e1b00320 	lsrs	r0, r0, rabeeh#6
  38:	01a0f00e 	moveq	pc, lr

0000003c <__loop_delay>:
  3c:	e2500001 	subs	r0, r0, rabeeh#1
  40:	8afffffe 	bhi	3c <__loop_delay>
  44:	e1a0f00e 	mov	pc, lr

After adding the 'align 3' directive to __loop_delay (align to 8 bytes):

00000010 <__loop_const_udelay>:
  10:	e3e01000 	mvn	r1, #0
  14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
  18:	e5922000 	ldr	r2, [r2]
  1c:	e0800921 	add	r0, r0, r1, lsr linux4kix#18
  20:	e1a00720 	lsr	r0, r0, linux4kix#14
  24:	e0822b21 	add	r2, r2, r1, lsr linux4kix#22
  28:	e1a02522 	lsr	r2, r2, linux4kix#10
  2c:	e0000092 	mul	r0, r2, r0
  30:	e0800d21 	add	r0, r0, r1, lsr linux4kix#26
  34:	e1b00320 	lsrs	r0, r0, rabeeh#6
  38:	01a0f00e 	moveq	pc, lr
  3c:	e320f000 	nop	{0}

00000040 <__loop_delay>:
  40:	e2500001 	subs	r0, r0, rabeeh#1
  44:	8afffffe 	bhi	40 <__loop_delay>
  48:	e1a0f00e 	mov	pc, lr
  4c:	e320f000 	nop	{0}

, which now reports:
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)

Some more test results:

On mx31 (ARM1136) running at 532 MHz, before the patch:
Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184)

On mx31 (ARM1136) running at 532 MHz after the patch:
Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968)

Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same
BogoMIPS value before and after this patch.

Reported-by: Tom Evans <tom_usenet@optusnet.com.au>
Suggested-by: Tom Evans <tom_usenet@optusnet.com.au>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@davem330
Merge branch 'dev_get_by_index'
c4ba999 
Ying Xue says:

====================
use appropriate APIs to get interfaces

Under rtnl_lock protection, we should use __dev_get_name/index()
rather than dev_get_name()/index() to find interface handlers
because the former interfaces can help us avoid to change interface
reference counter.

v2 changes:
 - Change return value of nl80211_set_wiphy() to 0 in patch linux4kix#10
   by johannes's suggestion.
 - Add 'Acked-by' into several patches which were acknowledged by
   corresponding maintainers.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
mk01 pushed a commit to mk01/linux-linaro-stable-mx6 that referenced this issue Sep 3, 2014
@snitm @axboe
block: fix q->flush_rq NULL pointer crash on dm-mpath flush
7982e90 
Commit 1874198 ("blk-mq: rework flush sequencing logic") switched
->flush_rq from being an embedded member of the request_queue structure
to being dynamically allocated in blk_init_queue_node().

Request-based DM multipath doesn't use blk_init_queue_node(), instead it
uses blk_alloc_queue_node() + blk_init_allocated_queue().  Because
commit 1874198 placed the dynamic allocation of ->flush_rq in
blk_init_queue_node() any flush issued to a dm-mpath device would crash
with a NULL pointer, e.g.:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff8125037e>] blk_rq_init+0x1e/0xb0
PGD bb3c7067 PUD bb01d067 PMD 0
Oops: 0002 [rabeeh#1] SMP
...
CPU: 5 PID: 5028 Comm: dt Tainted: G        W  O 3.14.0-rc3.snitm+ linux4kix#10
...
task: ffff88032fb270e0 ti: ffff880079564000 task.ti: ffff880079564000
RIP: 0010:[<ffffffff8125037e>]  [<ffffffff8125037e>] blk_rq_init+0x1e/0xb0
RSP: 0018:ffff880079565c98  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000030
RDX: ffff880260c74048 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff880079565ca8 R08: ffff880260aa1e98 R09: 0000000000000001
R10: ffff88032fa78500 R11: 0000000000000246 R12: 0000000000000000
R13: ffff880260aa1de8 R14: 0000000000000650 R15: 0000000000000000
FS:  00007f8d36a2a700(0000) GS:ffff88033fca0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000079b36000 CR4: 00000000000007e0
Stack:
 0000000000000000 ffff880260c74048 ffff880079565cd8 ffffffff81257a47
 ffff880260aa1de8 ffff880260c74048 0000000000000001 0000000000000000
 ffff880079565d08 ffffffff81257c2d 0000000000000000 ffff880260aa1de8
Call Trace:
 [<ffffffff81257a47>] blk_flush_complete_seq+0x2d7/0x2e0
 [<ffffffff81257c2d>] blk_insert_flush+0x1dd/0x210
 [<ffffffff8124ec59>] __elv_add_request+0x1f9/0x320
 [<ffffffff81250681>] ? blk_account_io_start+0x111/0x190
 [<ffffffff81253a4b>] blk_queue_bio+0x25b/0x330
 [<ffffffffa0020bf5>] dm_request+0x35/0x40 [dm_mod]
 [<ffffffff812530c0>] generic_make_request+0xc0/0x100
 [<ffffffff81253173>] submit_bio+0x73/0x140
 [<ffffffff811becdd>] submit_bio_wait+0x5d/0x80
 [<ffffffff81257528>] blkdev_issue_flush+0x78/0xa0
 [<ffffffff811c1f6f>] blkdev_fsync+0x3f/0x60
 [<ffffffff811b7fde>] vfs_fsync_range+0x1e/0x20
 [<ffffffff811b7ffc>] vfs_fsync+0x1c/0x20
 [<ffffffff811b81f1>] do_fsync+0x41/0x80
 [<ffffffff8118874e>] ? SyS_lseek+0x7e/0x80
 [<ffffffff811b8260>] SyS_fsync+0x10/0x20
 [<ffffffff8154c2d2>] system_call_fastpath+0x16/0x1b

Fix this by moving the ->flush_rq allocation from blk_init_queue_node()
to blk_init_allocated_queue().  blk_init_queue_node() also calls
blk_init_allocated_queue() so this change is functionality equivalent
for all blk_init_queue_node() callers.

Reported-by: Hannes Reinecke <hare@suse.de>
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
n-aizu pushed a commit to n-aizu/linux-linaro-stable-mx6 that referenced this issue Jan 28, 2015
@jhovold @gregkh
USB: console: fix uninitialised ldisc semaphore
8438d81 
commit d269d4434c72ed0da3a9b1230c30da82c4918c63 upstream.

The USB console currently allocates a temporary fake tty which is used
to pass terminal settings to the underlying serial driver.

The tty struct is not fully initialised, something which can lead to a
lockdep warning (or worse) if a serial driver tries to acquire a
line-discipline reference:

	usbserial: USB Serial support registered for pl2303
	pl2303 1-2.1:1.0: pl2303 converter detected
	usb 1-2.1: pl2303 converter now attached to ttyUSB0
	INFO: trying to register non-static key.
	the code is fine but needs lockdep annotation.
	turning off the locking correctness validator.
	CPU: 0 PID: 68 Comm: udevd Tainted: G        W      3.18.0-rc5 linux4kix#10
	[<c0016f04>] (unwind_backtrace) from [<c0013978>] (show_stack+0x20/0x24)
	[<c0013978>] (show_stack) from [<c0449794>] (dump_stack+0x24/0x28)
	[<c0449794>] (dump_stack) from [<c006f730>] (__lock_acquire+0x1e50/0x2004)
	[<c006f730>] (__lock_acquire) from [<c0070128>] (lock_acquire+0xe4/0x18c)
	[<c0070128>] (lock_acquire) from [<c027c6f8>] (ldsem_down_read_trylock+0x78/0x90)
	[<c027c6f8>] (ldsem_down_read_trylock) from [<c027a1cc>] (tty_ldisc_ref+0x24/0x58)
	[<c027a1cc>] (tty_ldisc_ref) from [<c0340760>] (usb_serial_handle_dcd_change+0x48/0xe8)
	[<c0340760>] (usb_serial_handle_dcd_change) from [<bf000484>] (pl2303_read_int_callback+0x210/0x220 [pl2303])
	[<bf000484>] (pl2303_read_int_callback [pl2303]) from [<c031624c>] (__usb_hcd_giveback_urb+0x80/0x140)
	[<c031624c>] (__usb_hcd_giveback_urb) from [<c0316fc0>] (usb_giveback_urb_bh+0x98/0xd4)
	[<c0316fc0>] (usb_giveback_urb_bh) from [<c0042e44>] (tasklet_hi_action+0x9c/0x108)
	[<c0042e44>] (tasklet_hi_action) from [<c0042380>] (__do_softirq+0x148/0x42c)
	[<c0042380>] (__do_softirq) from [<c00429cc>] (irq_exit+0xd8/0x114)
	[<c00429cc>] (irq_exit) from [<c007ae58>] (__handle_domain_irq+0x84/0xdc)
	[<c007ae58>] (__handle_domain_irq) from [<c000879c>] (omap_intc_handle_irq+0xd8/0xe0)
	[<c000879c>] (omap_intc_handle_irq) from [<c0014544>] (__irq_svc+0x44/0x7c)
	Exception stack(0xdf4e7f08 to 0xdf4e7f50)
	7f00:                   debc0b80 df4e7f5c 00000000 00000000 debc0b80 be8da96c
	7f20: 00000000 00000128 c000fc84 df4e6000 00000000 df4e7f94 00000004 df4e7f50
	7f40: c038ebc0 c038d74c 600f0013 ffffffff
	[<c0014544>] (__irq_svc) from [<c038d74c>] (___sys_sendmsg.part.29+0x0/0x2e0)
	[<c038d74c>] (___sys_sendmsg.part.29) from [<c038ec08>] (SyS_sendmsg+0x18/0x1c)
	[<c038ec08>] (SyS_sendmsg) from [<c000fa00>] (ret_fast_syscall+0x0/0x48)
	console [ttyUSB0] enabled

Fixes: 3669752 ("tty: Replace ldisc locking with ldisc_sem")
Signed-off-by: Johan Hovold <johan@kernel.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
@rabeeh
Merge pull request linux4kix#10 from linux4kix/linux-linaro-lsk-v3.14…
07da1e8 
…-mx6

brcmfmac: kernel oops on wrong ifidx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@tempestnano