linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ynorov@caviumnetworks.com (Yury Norov)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
Date: Fri, 18 Mar 2016 19:46:27 +0300	[thread overview]
Message-ID: <20160318164627.GA3201@yury-N73SV> (raw)
In-Reply-To: <56EC24EE.6020803@suse.de>

On Fri, Mar 18, 2016 at 04:55:26PM +0100, Alexander Graf wrote:
> 
> 
> On 18.03.16 16:49, Yury Norov wrote:
> > On Fri, Mar 18, 2016 at 06:28:29PM +0800, Zhangjian (Bamvor) wrote:
> >>
> >> For the glibc part, I found that there are 11 patches of ilp32 in top,
> >> but the original 28 patches of ilp32 is not in the top, there are more
> >> than 900 patches between them(referece the list below). Are you
> >> willing rebase all the ilp32 relative patches. It is very useful for
> >> reviewing and debugging.  I saw andrew request the account in glibc,
> >> maybe it has already been in processs?).
> >>
> > 
> > I already told there's mess there, and I'd prefer to make things work
> > first and then do cleanup. 
> 
> So how is progress going overall? The last submission I've seen is
> already 2 months ago. Are there particular bits holding you up?
> 
> 
> Alex

Hi Alexander, 

For last time I mostly work on library, as it needs to be reworked
well. But yes, there's one serious bug puzzling me.

Tests like umount or pathconf fail but I see no major problem with
it, as it's most probably structure padding mismatch between kernel and
glibc. But there's (at least) one major problem I see.

Float tests fail due to NULL-dereferencing (0x14 actually) at
pthread_join(). It calls tgkill(), and after that child thread crashes.
See stack trace at the end.

The minimal test reproducing it is attached. The similar test where
parent forks a child and then kills it, works fine. (Attached too).

I see that in case of pthread, there's much more stuff that is cloned.
Other's looking similar.

pthread_create():
clone(child_stack=0xb953cea0, flags=CLONE_VM|CLONE_FS|CLONE_FILES
        |CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS
        |CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
        parent_tidptr=0xb953d398, tls=0xb953d7c0, child_tidptr=0xb953d398) = 1650

fork():
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
        child_tidptr=0xe5af6278) = 30537

So this most probably means that ilp32 code doesn't handle one of cloned
item properly. I have already discovered a bug where child processes
used parent TLS, so maybe this is something similar...

Except of this, I think ILP32 series is looking pretty well, at least
kernel part.

If you have any ideas/suggestions, I'll really appreciate it.

Yury.

strace -f ./trigo
[...]
clone(child_stack=0xdbbfb000,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND
|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS
|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xdbbfb4f8, tls=0xdbbfb920, child_tidptr=0xdbbfb4f8) = 32030
rt_sigprocmask(SIG_BLOCK, [CHLD], Process 32030 attached [], 8) = 0
[pid 32029] rt_sigaction(SIGCHLD, NULL,  <unfinished ...>
[pid 32030] set_robust_list(0xdbbfb504, 12 <unfinished ...>
[pid 32029] <... rt_sigaction resumed> {SIG_DFL, [ILL ABRT SEGV URG], 0}, 8) = 0
[pid 32030] <... set_robust_list resumed> ) = 0
[pid 32029] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid 32030] write(1, "started\n", 8started
<unfinished ...>
[pid 32029] nanosleep({1, 65536},  <unfinished ...>
[pid 32030] <... write resumed> )       = 8
[pid 32030] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid 32030] rt_sigsuspend([] <unfinished ...>
[pid 32029] <... nanosleep resumed> 0xfff9fd98) = 0
[pid 32029] write(1, "stoping...\n", 11stoping...) = 11
[pid 32029] openat(AT_FDCWD, "/root/sys-root/libilp32/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
[pid 32029] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0 \0\0004\0\0\0"..., 512) = 512
[pid 32029] fstat(3, {st_mode=S_IFREG|0644, st_size=429138, ...}) = 0
[pid 32029] mmap(NULL, 135104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xdb3db000
[pid 32029] mprotect(0xdb3ec000, 61440, PROT_NONE) = 0
[pid 32029] mmap(0xdb3fb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0xdb3fb000
[pid 32029] close(3)                    = 0
[pid 32029] tgkill(32029, 32030, SIGRTMIN) = 0
[pid 32030] <... rt_sigsuspend resumed> ) = ? ERESTARTNOHAND (To be
restarted if no handler)
[pid 32029] write(1, "pthread_cancel == 0\n", 20pthread_cancel == 0) = 20
[pid 32030] --- SIGRTMIN {si_signo=SIGRTMIN, si_code=SI_TKILL, si_pid=32029, si_uid=0} ---
[pid 32029] write(1, "stopped\n", 8stopped
<unfinished ...>
[pid 32030] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x14} ---
[pid 32029] <... write resumed> )       = ? <unavailable>
[pid 32030] +++ killed by SIGSEGV +++
+++ killed by SIGSEGV +++
Segmentation fault

dmesg:
trigo[32246]: unhandled level 2 translation fault (11) at 0x00000014,
esr 0x90000006
pgd = ffffffc009335000
[00000014] *pgd=000000007917c003, *pud=000000007917c003,
*pmd=0000000000000000

CPU: 2 PID: 32246 Comm: trigo Not tainted 4.5.0+ #91
Hardware name: linux,dummy-virt (DT)
task: ffffffc00900e400 ti: ffffffc009078000 task.ti: ffffffc009078000
PC is at 0xda6853f0
LR is at 0xda6d5440
pc : [<00000000da6853f0>] lr : [<00000000da6d5440>] pstate: 60000000
sp : 00000000da511bc0
x29: 00000000da512e10 x28: 00000000da6a7000 
x27: 0000000000000000 x26: 00000000da513490 
x25: 0000000000000000 x24: 0000000000400820 
x23: 00000000da6a9000 x22: 00000000ff869acb 
x21: 00000000da6a9000 x20: 00000000da512e50 
x19: 0000000000000000 x18: 0000000000000001 
x17: 0000000000410bd8 x16: 00000000da691138 
x15: 0000000000000000 x14: 0000000000000000 
x13: 00000000da535970 x12: 0000000000000038 
x11: 0000000000000028 x10: 0101010101010101 
x9 : ff63647371607372 x8 : 0000000000000085 
x7 : 0000000000007df5 x6 : 00000000da512e1c 
x5 : 00000000da513518 x4 : 0000000000000002 
x3 : 00000000da513920 x2 : 0000000000000000 
x1 : 0000000000000008 x0 : 00000000da513490 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mykill.tar.gz
Type: application/gzip
Size: 1073 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160318/cddc89b0/attachment-0002.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trigo.tar.gz
Type: application/gzip
Size: 1207 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160318/cddc89b0/attachment-0003.gz>

  reply	other threads:[~2016-03-18 16:46 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-14 17:22 [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov
2016-01-14 17:22 ` [PATCH v6 01/21] arm64: ilp32: add documentation on the ILP32 ABI " Yury Norov
2016-01-14 17:22 ` [PATCH v6 02/21] arm64: ensure the kernel is compiled for LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 03/21] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 04/21] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2016-01-14 17:23 ` [PATCH v6 05/21] arm64: compat: change config dependences to aarch32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 06/21] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 07/21] thread: move thread bits accessors to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 08/21] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2016-01-14 17:23 ` [PATCH v6 09/21] arm64: ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 10/21] arm64: introduce binfmt_elf32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 11/21] arm64: ilp32: introduce binfmt_ilp32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 12/21] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 13/21] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2016-01-14 17:23 ` [PATCH v6 14/21] arm64: signal: wrap struct ucontext, fp and lr with struct sigframe Yury Norov
2016-01-14 17:23 ` [PATCH v6 15/21] arm64: signal: share lp64 signal routines to ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 16/21] arm64: signal32: move ilp32 and aarch32 common code to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 17/21] arm64: ilp32: introduce ilp32-specific handlers for sigframe Yury Norov
2016-02-29  8:27   ` Andreas Schwab
2016-01-14 17:23 ` [PATCH v6 18/21] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2016-01-14 17:23 ` [PATCH v6 19/21] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 20/21] all: s390: make compat wrappers the generic solution Yury Norov
2016-01-14 18:11   ` Yury Norov
2016-01-15 12:46   ` Heiko Carstens
     [not found]     ` <20160119175223.GA6603@yury-N73SV>
2016-01-20  8:16       ` Heiko Carstens
2016-01-20 12:17         ` Yury Norov
2016-01-14 17:23 ` [PATCH v6 21/21] arm64: ilp32: wrap syscalls to remove top 32-bit vulnerability Yury Norov
2016-01-18 13:18 ` [RFC5 PATCH v6 00/21] ILP32 for ARM64 Zhangjian (Bamvor)
2016-01-18 13:26   ` Andreas Schwab
2016-01-18 13:41     ` Bamvor Zhang Jian
2016-01-29  9:59 ` Zhangjian (Bamvor)
2016-01-29 17:09   ` Yury Norov
2016-01-30  4:15     ` Zhangjian (Bamvor)
2016-02-18 22:35       ` Yury Norov
2016-02-19  8:23         ` Arnd Bergmann
2016-02-19 12:59           ` Yury Norov
2016-02-19 14:06             ` Arnd Bergmann
2016-02-29 15:39           ` Yury Norov
2016-02-29 16:00           ` Andreas Schwab
2016-02-29 16:30             ` Arnd Bergmann
2016-02-25 10:50         ` Andreas Schwab
2016-02-25 20:28           ` Yury Norov
2016-03-18 10:28             ` Zhangjian (Bamvor)
2016-03-18 15:49               ` Yury Norov
2016-03-18 15:55                 ` Alexander Graf
2016-03-18 16:46                   ` Yury Norov [this message]
2016-03-20  8:12                     ` Zhangjian (Bamvor)
2016-03-21 11:23                       ` Zhangjian (Bamvor)
2016-03-21 18:43                         ` Yury Norov
2016-03-22  1:49                           ` Yury Norov
2016-03-21  9:07                 ` Andreas Schwab
2016-03-21  9:43                   ` Arnd Bergmann
2016-03-21 10:52                     ` Andreas Schwab
2016-03-21 17:02                       ` Arnd Bergmann
2016-03-26 12:36                     ` Zhangjian (Bamvor)
2016-03-29 10:58                       ` Arnd Bergmann
2016-03-29 12:01                         ` Yury Norov
2016-03-29 12:42                           ` Arnd Bergmann
2016-03-29 13:21                           ` Zhangjian (Bamvor)
2016-03-29 13:27                             ` Arnd Bergmann
2016-03-29 15:54                               ` Joseph Myers
2016-03-29 19:30                                 ` Arnd Bergmann
2016-03-29 20:15                                   ` Joseph Myers
2016-03-29 20:24                                     ` Arnd Bergmann
2016-03-29 21:00                                       ` Joseph Myers
2016-03-29 21:39                                         ` Arnd Bergmann
2016-03-31  7:35                               ` Zhangjian (Bamvor)
2016-03-21 18:40                   ` Yury Norov
2016-03-26 13:08                     ` Zhangjian (Bamvor)
2016-03-26 13:45                     ` Zhangjian (Bamvor)
2016-03-26 22:46                       ` Yury Norov

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=20160318164627.GA3201@yury-N73SV \
    --to=ynorov@caviumnetworks.com \
    --cc=linux-arm-kernel@lists.infradead.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 NNTP newsgroup(s).