All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@caviumnetworks.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-doc@vger.kernel.org,
	Andrew Pinski <Andrew.Pinski@caviumnetworks.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Chris Metcalf <cmetcalf@ezchip.com>,
	philipp.tomsich@theobroma-systems.com,
	Joseph Myers <joseph@codesourcery.com>,
	zhouchengming1@huawei.com,
	Steve Ellcey <sellcey@caviumnetworks.com>,
	Prasun.Kapoor@caviumnetworks.com, Andreas Schwab <schwab@suse.de>,
	agraf@suse.de, szabolcs.nagy@arm.com, geert@linux-m68k.org,
	Adam Borowski <kilobyte@angband.pl>,
	manuel.montezelo@gmail.com, Chris Metcalf <cmetcalf@mellanox.com>,
	Arnd Bergmann <arnd@arndb.de>, Andrew Pinski <pinskia@gmail.com>,
	linyongting@huawei.com, klimov.linux@gmail.com,
	broonie@kernel.org,
	Bamvor Zhangjian <bamvor.zhangjian@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
	Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org,
	Ramana Radhakrishnan <ramana.gcc@googlemail.com>,
	schwidefsky@de.ibm.com, davem@davemloft.net,
	christoph.muellner@theobroma-systems.com
Subject: Re: [PATCH v7 resend 00/20] ILP32 for ARM64
Date: Wed, 12 Apr 2017 00:52:34 +0400	[thread overview]
Message-ID: <20170411205234.GA26665@yury-N73SV> (raw)
In-Reply-To: <18edebeb-201e-a9d6-7e66-6e34f98a40df@redhat.com>

On Tue, Apr 11, 2017 at 08:42:24PM +0200, Florian Weimer wrote:
> On 04/11/2017 08:36 PM, Yury Norov wrote:
> >>Also, the latest benchmarks I've seen were mostly for user space
> >>while I'm more concerned with the user-kernel interface
> >>(https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2).
> >
> >>On the glibc testing side, have the regressions been identified/fixed?
> >
> >I run LTP for testing the ABI and kernel, and there is no failures in
> >ltplite scenario. With glibc testsuite, there's only 3 failures
> >comparing to lp64. (Steve, fix me if something changed.) This is
> >slides on ilp32 from Linaro Connect, hope you'll find it useful.
> >
> >https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing
> 
> The listed failures are:
> 
> misc/tst-sync_file_range
> nptl/tst-stack4
> malloc/tst-mallocstate
> 
> If necessary, I will fix malloc/tst-mallocstate once there's support for a
> new architecture in build-many-glibcs.py.  The failure is
> architecture-independent, it's related to the lack of a compat symbol and
> the difficulty of checking for that at the Makefile or test level.
> 
> nptl/tst-stack4 is also a generic failure, I think.

That would be great, thanks.

> misc/tst-sync_file_range is probably a real failure related to argument
> passing.  I think this system call was problematic on other architectures,
> too.

At first glance, it's pretty trivial, both on glibc and kernel side:

GLIBC:
int
sync_file_range (int fd, __off64_t offset, __off64_t len, unsigned int flags)
{
#if defined (__NR_sync_file_range2)
  return SYSCALL_CANCEL (sync_file_range2, fd, flags, SYSCALL_LL64 (offset),
                         SYSCALL_LL64 (len));
#elif defined (__NR_sync_file_range)
  return SYSCALL_CANCEL (sync_file_range, fd,
                         __ALIGNMENT_ARG SYSCALL_LL64 (offset),
                         SYSCALL_LL64 (len), flags);
#endif
}

And kernel:
ENTRY(compat_sys_sync_file_range2_wrapper)
        regs_to_64      x2, x2, x3
        regs_to_64      x3, x4, x5
        b       sys_sync_file_range2
ENDPROC(compat_sys_sync_file_range2_wrapper)

Anyway, I'll check everything and report here.

Yury

WARNING: multiple messages have this Message-ID (diff)
From: ynorov@caviumnetworks.com (Yury Norov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 resend 00/20] ILP32 for ARM64
Date: Wed, 12 Apr 2017 00:52:34 +0400	[thread overview]
Message-ID: <20170411205234.GA26665@yury-N73SV> (raw)
In-Reply-To: <18edebeb-201e-a9d6-7e66-6e34f98a40df@redhat.com>

On Tue, Apr 11, 2017 at 08:42:24PM +0200, Florian Weimer wrote:
> On 04/11/2017 08:36 PM, Yury Norov wrote:
> >>Also, the latest benchmarks I've seen were mostly for user space
> >>while I'm more concerned with the user-kernel interface
> >>(https://marc.info/?l=linux-arm-kernel&m=148690490713310&w=2).
> >
> >>On the glibc testing side, have the regressions been identified/fixed?
> >
> >I run LTP for testing the ABI and kernel, and there is no failures in
> >ltplite scenario. With glibc testsuite, there's only 3 failures
> >comparing to lp64. (Steve, fix me if something changed.) This is
> >slides on ilp32 from Linaro Connect, hope you'll find it useful.
> >
> >https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing
> 
> The listed failures are:
> 
> misc/tst-sync_file_range
> nptl/tst-stack4
> malloc/tst-mallocstate
> 
> If necessary, I will fix malloc/tst-mallocstate once there's support for a
> new architecture in build-many-glibcs.py.  The failure is
> architecture-independent, it's related to the lack of a compat symbol and
> the difficulty of checking for that at the Makefile or test level.
> 
> nptl/tst-stack4 is also a generic failure, I think.

That would be great, thanks.

> misc/tst-sync_file_range is probably a real failure related to argument
> passing.  I think this system call was problematic on other architectures,
> too.

At first glance, it's pretty trivial, both on glibc and kernel side:

GLIBC:
int
sync_file_range (int fd, __off64_t offset, __off64_t len, unsigned int flags)
{
#if defined (__NR_sync_file_range2)
  return SYSCALL_CANCEL (sync_file_range2, fd, flags, SYSCALL_LL64 (offset),
                         SYSCALL_LL64 (len));
#elif defined (__NR_sync_file_range)
  return SYSCALL_CANCEL (sync_file_range, fd,
                         __ALIGNMENT_ARG SYSCALL_LL64 (offset),
                         SYSCALL_LL64 (len), flags);
#endif
}

And kernel:
ENTRY(compat_sys_sync_file_range2_wrapper)
        regs_to_64      x2, x2, x3
        regs_to_64      x3, x4, x5
        b       sys_sync_file_range2
ENDPROC(compat_sys_sync_file_range2_wrapper)

Anyway, I'll check everything and report here.

Yury

  reply	other threads:[~2017-04-11 20:52 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-01 19:19 [PATCH v7 resend 00/20] ILP32 for ARM64 Yury Norov
2017-03-01 19:19 ` Yury Norov
2017-03-01 19:19 ` [PATCH 01/20] compat ABI: use non-compat openat and open_by_handle_at variants Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 02/20] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-10 18:09   ` Will Deacon
2017-03-10 18:09     ` Will Deacon
2017-03-10 18:09     ` Will Deacon
2017-03-01 19:19 ` [PATCH 04/20] arm64: ilp32: add documentation on the ILP32 ABI for ARM64 Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 05/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 06/20] arm64: ensure the kernel is compiled for LP64 Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 07/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 08/20] thread: move thread bits accessors to separated file Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 09/20] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 10/20] arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64 Yury Norov
2017-03-01 19:19   ` [PATCH 10/20] arm64: ilp32: add is_ilp32_compat_{task, thread} " Yury Norov
2017-03-01 19:19 ` [PATCH 11/20] arm64: introduce binfmt_elf32.c Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 12/20] arm64: ilp32: introduce binfmt_ilp32.c Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 13/20] arm64: ilp32: share aarch32 syscall handlers Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 14/20] arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 15/20] arm64: signal: share lp64 signal routines to ilp32 Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 16/20] arm64: signal32: move ilp32 and aarch32 common code to separated file Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 17/20] arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 19/20] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-03-01 19:19 ` [PATCH 20/20] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2017-03-01 19:19   ` Yury Norov
2017-04-10 19:47 ` [PATCH v7 resend 00/20] ILP32 for ARM64 Yury Norov
2017-04-10 19:47   ` Yury Norov
2017-04-11 11:33   ` Catalin Marinas
2017-04-11 11:33     ` Catalin Marinas
2017-04-11 11:54     ` Andreas Schwab
2017-04-11 11:54       ` Andreas Schwab
2017-04-11 13:33     ` Yury Norov
2017-04-11 13:33       ` Yury Norov
2017-04-11 18:36     ` Yury Norov
2017-04-11 18:36       ` Yury Norov
2017-04-11 18:42       ` Florian Weimer
2017-04-11 18:42         ` Florian Weimer
2017-04-11 20:52         ` Yury Norov [this message]
2017-04-11 20:52           ` 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=20170411205234.GA26665@yury-N73SV \
    --to=ynorov@caviumnetworks.com \
    --cc=Andrew.Pinski@caviumnetworks.com \
    --cc=Nathan_Lynch@mentor.com \
    --cc=Prasun.Kapoor@caviumnetworks.com \
    --cc=agraf@suse.de \
    --cc=arnd@arndb.de \
    --cc=bamvor.zhangjian@huawei.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoph.muellner@theobroma-systems.com \
    --cc=cmetcalf@ezchip.com \
    --cc=cmetcalf@mellanox.com \
    --cc=davem@davemloft.net \
    --cc=fweimer@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=joseph@codesourcery.com \
    --cc=kilobyte@angband.pl \
    --cc=klimov.linux@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyongting@huawei.com \
    --cc=manuel.montezelo@gmail.com \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=philipp.tomsich@theobroma-systems.com \
    --cc=pinskia@gmail.com \
    --cc=ramana.gcc@googlemail.com \
    --cc=schwab@suse.de \
    --cc=schwidefsky@de.ibm.com \
    --cc=sellcey@caviumnetworks.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=zhouchengming1@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.