linux-kernel - Re: [BUG] n_tty: 4.0-rc3+: Unable to handle kernel paging request at virtual address 000044d0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACVXFVM0kPM65GNOvB6SOaEB+JRuOsxcPJiYkG=7dnxeQP-i3A@mail.gmail.com>
Date:	Sat, 14 Mar 2015 07:09:03 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-serial@...r.kernel.org, Will Deacon <will.deacon@....com>,
	Linux ARM Kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [BUG] n_tty: 4.0-rc3+: Unable to handle kernel paging request at
 virtual address 000044d0

On Fri, Mar 13, 2015 at 8:59 PM, Peter Hurley <peter@...leysoftware.com> wrote:
> [ +cc Will Deacon, linux-arm ]
>
> Hi Ming,
>
> On 03/13/2015 02:02 AM, Ming Lei wrote:
>> Hi Guys,
>>
>> Just found the following oops during kernel booting when I
>> test the latest linus tree on one arm64 VM booted from uefi
>> plus grub2:
>
> Thanks for the bug report.
>
> This looks like a compiler bug when generating code for
> smp_load_acquire() (see below); what compiler are you using?

It is one gcc-4.7 based compiler from one customer, and when I switch
to aarch64-linux-gnu, the bug does disappear.

Thanks for your help!

>
>
>> Unable to handle kernel paging request at virtual address 000044d0
>> pgd = ffffffc0007fb000
>> [000044d0] *pgd=0000000079407003, *pud=0000000079407003,
>> *pmd=0000000079408003, *pte=0060000008004707
>> Internal error: Oops: 94000005 [#1] PREEMPT SMP
>> Modules linked in:
>> CPU: 1 PID: 632 Comm: kworker/1:1 Not tainted 4.0.0-rc3+ #121
>> Hardware name: linux,dummy-virt (DT)
>> Workqueue: events flush_to_ldisc
>> task: ffffffc0395eac00 ti: ffffffc038cb0000 task.ti: ffffffc038cb0000
>> PC is at n_tty_receive_buf_common+0x60/0xa28
>> LR is at n_tty_receive_buf_common+0x4c/0xa28
>> pc : [<ffffffc000362490>] lr : [<ffffffc00036247c>] pstate: 20000145
>> sp : ffffffc038cb3c70
>> x29: ffffffc038cb3c70 x28: ffffffc0385ab400
>> x27: ffffffc03ffe3380 x26: 0000000000000008
>> x25: ffffffc0006a5260 x24: ffffffc0385b0e28
>> x23: ffffffc038557340 x22: ffffffc0385ab400
>> x21: ffffffc0385b0e08 x20: ffffffc0385b0e00
>> x19: ffffffc03854c800 x18: 0000007fda9ad810
>> x17: 0000007f8291ee7c x16: ffffffc000185540
>> x15: 0000007f8298f590 x14: 0000007472617473
>> x13: 2d65727000000009 x12: 0000000000000020
>> x11: 000000000000002c x10: 0000007fb1e23360
>> x9 : ffffffc038cb3d40 x8 : ffffffc00079cb10
>> x7 : ffffffc000362e58 x6 : ffffffc03854c820
>> x5 : 00000000000044d0 x4 : ffffff8000278000
>> x3 : 000000000000002e x2 : 0000000000000000
>> x1 : 0000000000000001 x0 : ffffffc00058f250
>>
>> Process kworker/1:1 (pid: 632, stack limit = 0xffffffc038cb0028)
>> Stack: (0xffffffc038cb3c70 to 0xffffffc038cb4000)
>> 3c60:                                     38cb3d20 ffffffc0 00362e68 ffffffc0
>> 3c80: 3854c800 ffffffc0 385b0e00 ffffffc0 385b0e08 ffffffc0 385ab400 ffffffc0
>> 3ca0: 38557340 ffffffc0 385b0e28 ffffffc0 006a5260 ffffffc0 00000008 00000000
>> 3cc0: 3ffe3380 ffffffc0 00000000 00000000 3946c200 ffffffc0 3946c268 ffffffc0
>> 3ce0: 385ab4d8 ffffffc0 00000001 00000000 00278000 ffffff80 3854c820 ffffffc0
>> 3d00: 00000000 00000000 0000002e ffffffc0 385b0e58 ffffffc0 0058f250 ffffffc0
>> 3d20: 38cb3d30 ffffffc0 00365b68 ffffffc0 38cb3d80 ffffffc0 000b522c ffffffc0
>> 3d40: 38b84540 ffffffc0 385b0e08 ffffffc0 3ffe3380 ffffffc0 3ffe7600 ffffffc0
>> 3d60: 00000000 00000000 00000000 00000000 006a5260 ffffffc0 000b5220 ffffffc0
>> 3d80: 38cb3dd0 ffffffc0 000b5974 ffffffc0 38b84540 ffffffc0 3ffe3398 ffffffc0
>> 3da0: 3ffe3380 ffffffc0 38b84570 ffffffc0 007c641d ffffffc0 00000001 00000000
>> 3dc0: 006a5260 ffffffc0 00000008 00000000 38cb3e30 ffffffc0 000ba900 ffffffc0
>> 3de0: 38c7d8c0 ffffffc0 007cced0 ffffffc0 006a3ee8 ffffffc0 38b84540 ffffffc0
>> 3e00: 000b5828 ffffffc0 00000000 00000000 00000000 00000000 00000000 00000000
>> 3e20: 00000000 00000000 00000000 00000000 00000000 00000000 00085bf0 ffffffc0
>> 3e40: 000ba828 ffffffc0 38c7d8c0 ffffffc0 00000000 00000000 00000000 00000000
>> 3e60: 00000000 00000000 000c0fbc ffffffc0 000ba828 ffffffc0 00000000 00000000
>> 3e80: 00000000 00000000 38b84540 ffffffc0 00000000 00000000 00000000 00000000
>> 3ea0: 38cb3ea0 ffffffc0 38cb3ea0 ffffffc0 00000000 ffffffc0 00000000 ffffffc0
>> 3ec0: 38cb3ec0 ffffffc0 38cb3ec0 ffffffc0 00000000 00000000 00000000 00000000
>> 3ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3fa0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000005 00000000
>> 3fe0: 00000000 00000000 00000000 00000000 afafafaf afafafaf afafafaf afafafaf
>> Call trace:
>> [<ffffffc000362490>] n_tty_receive_buf_common+0x60/0xa28
>> [<ffffffc000362e64>] n_tty_receive_buf2+0xc/0x18
>> [<ffffffc000365b64>] flush_to_ldisc+0xec/0x140
>> [<ffffffc0000b5228>] process_one_work+0x138/0x338
>> [<ffffffc0000b5970>] worker_thread+0x148/0x420
>> [<ffffffc0000ba8fc>] kthread+0xd4/0xf0
>> Code: 91094000 f90057a0 d2844d05 8b0500a5 (c8dffca3)
>
> This code disassembles as:
>
>    0:   91094000        add     x0, x0, #0x250
>    4:   f90057a0        str     x0, [x29,#168]
>    8:   d2844d05        mov     x5, #0x2268                     // #8808
>    c:   8b0500a5        add     x5, x5, x5
>   10:   c8dffca3        ldar    x3, [x5]           <==== faulting insn
>
> Using latest trusty gcc 4.8.2,
>
>     $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- O=../build/arm64/ drivers/tty/n_tty.lst
>
> generates the corresponding mixed listing for n_tty_receive_buf_common + 0x60
> (...3660b4 + 0x60 = ...366114), which is PC advanced to the insn after faulting:
>
>     ffffffc0003660b4 <n_tty_receive_buf_common>:
>     ....
>                  * paired with store in *_copy_from_read_buf() -- guarantees
>                  * the consumer has loaded the data in read_buf up to the new
>                  * read_tail (so this producer will not overwrite unread data)
>                  */
>                  size_t tail = smp_load_acquire(&ldata->read_tail);
>     ffffffc000366108:       d2844d00        mov     x0, #0x2268                // #8808
>     ffffffc00036610c:       8b170000        add     x0, x0, x23
>     ffffffc000366110:       c8dffc03        ldar    x3, [x0]      <==== corresponding insn
>
>
> Note that in the correctly generated machine code above, the ea in x0 is
>
>    x0 = x23 + 0x2268
>
> but in the your broken binary it's
>
>    x5 = 0x2268 + 0x2268   // 0x44d0
>
> Regards,
> Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/