Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1400800
| From | Catalin Marinas <catalin.marinas@arm.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 |
| Date | 2016-05-13 15:40 +0200 |
| Message-ID | <ryltV-49j-23@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <rxZto-7zr-15@gated-at.bofh.it> <ry0IO-eN-19@gated-at.bofh.it> <ry0IO-eN-17@gated-at.bofh.it> <rygue-822-7@gated-at.bofh.it> <ryhzY-Bj-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, May 13, 2016 at 09:28:03AM +0000, Catalin Marinas wrote:
> > >>>>>On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > >>>>>>I debugged preadv02 and pwritev02 failures and found very weird bug.
> > >>>>>>Test passes {iovec_base = 0xffffffff, iovec_len = 64} as one element
> > >>>>>>of vector, and kernel reports successful read/write.
[...]
> The discussion is mainly around whether USER_DS for 32-bit compat apps
> should be the same as USER_DS for native 32-bit apps. Even for native
> 32-bit kernels, we don't use STACK_TOP as addr_limit. A read/write from
> 0xffffffff would fail in both cases anyway. I think the LTP test doesn't
> even try to access such memory but only to probe the range validity (I
> haven't managed to build the latest LTP yet).
OK, so I managed to get the latest LTP (tag 20160510) built for AArch32
but the preadv02 does not fail:
-----------------------------
# uname -m
aarch64
# file ./testcases/bin/preadv02
./testcases/bin/preadv02: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=98066291426e1d3ee49d8504ce2a5bd721ab7fe8, not stripped
# ./testcases/bin/preadv02
preadv02.c:97: PASS: preadv() failed as expected: EINVAL
preadv02.c:97: PASS: preadv() failed as expected: EINVAL
preadv02.c:97: PASS: preadv() failed as expected: EINVAL
preadv02.c:97: PASS: preadv() failed as expected: EFAULT
preadv02.c:97: PASS: preadv() failed as expected: EBADF
preadv02.c:97: PASS: preadv() failed as expected: EBADF
preadv02.c:97: PASS: preadv() failed as expected: EISDIR
preadv02.c:97: PASS: preadv() failed as expected: ESPIPE
Summary:
passed 8
failed 0
skipped 0
warnings 0
-----------------------------
It's the 4th test above which passes iovec_base as -1 and expects
EFAULT. However, it seems to get the expected error. I guess that even
if access_ok() passes, the access to that location by the kernel would
fail since there isn't anything mapped.
With ILP32, however, STACK_TOP is TASK_SIZE and you may have the address
mapped already. I still think the USER_DS fix is useful, though I need
another way to check that it's actually a fix.
--
Catalin
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-12 15:40 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-12 16:10 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-12 16:30 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-12 17:00 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2016-05-12 17:40 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-12 17:30 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-05-13 10:20 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-13 11:30 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-13 13:10 +0200
Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2016-05-13 15:40 +0200
csiph-web