Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1271664 > unrolled thread

[RFC2 PATCH v6 00/19] ILP32 for ARM64

Back to article view | Back to linux.kernel

Contents

  [RFC2 PATCH v6 00/19] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:20 +0100
    [PATCH v6 10/19] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
      Re: [PATCH v6 10/19] arm64:ilp32 use the native LP64 'start_thread'  for ILP32 threads Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 13:30 +0100
    [PATCH v6 12/19] ptrace: Allow compat to use the native siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
    [PATCH v6 19/19] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
    [PATCH v6 13/19] arm64: ilp32: common 32-bit wrappers Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
    [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
      Re: [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Arnd Bergmann <arnd@arndb.de> - 2015-11-17 23:10 +0100
        Re: [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Andreas Schwab <schwab@suse.de> - 2015-11-18 09:30 +0100
          Re: [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Arnd Bergmann <arnd@arndb.de> - 2015-11-18 10:30 +0100
            Re: [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Geert Uytterhoeven <geert@linux-m68k.org> - 2015-11-18 11:10 +0100
              Re: [PATCH v6 15/19] arm64: ilp32: force IPC_64 in msgctl, shmctl, semctl Arnd Bergmann <arnd@arndb.de> - 2015-11-18 13:10 +0100
    [PATCH v6 17/19] arm64:ilp32: use the native siginfo instead of the compat siginfo Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
    [PATCH v6 09/19] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
    [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
      Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-17 23:10 +0100
        Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-18 09:20 +0100
        Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-11-19 14:30 +0100
          Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-19 14:40 +0100
        Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-30 16:40 +0100
          Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-11-30 21:30 +0100
            Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-11-30 23:00 +0100
              Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Andrew Pinski <pinskia@gmail.com> - 2015-12-01 01:30 +0100
              Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-01 01:50 +0100
                Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-01 11:30 +0100
            Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-12-01 10:30 +0100
              Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-01 11:30 +0100
                Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Andreas Schwab <schwab@suse.de> - 2015-12-01 12:10 +0100
                  Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-01 12:40 +0100
                    Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-02 01:30 +0100
                      Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-02 11:10 +0100
                      Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 18:20 +0100
        Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-01 22:40 +0100
          Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-01 23:50 +0100
            Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-02 00:40 +0100
              Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-02 09:40 +0100
                Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-02 10:20 +0100
                Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-02 11:40 +0100
                  Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-02 14:50 +0100
                    Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-02 15:00 +0100
                      Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Will Deacon <will.deacon@arm.com> - 2015-12-02 15:00 +0100
          Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 18:50 +0100
            Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-03 19:20 +0100
              Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-03 21:50 +0100
        Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate  table (in entry.S) to use it Yury Norov <ynorov@caviumnetworks.com> - 2015-12-02 11:10 +0100
          Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Arnd Bergmann <arnd@arndb.de> - 2015-12-02 12:10 +0100
    [PATCH v6 16/19] aarch64: ilp32: use generic stat64 structure Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
      Re: [PATCH v6 16/19] aarch64: ilp32: use generic stat64 structure Arnd Bergmann <arnd@arndb.de> - 2015-11-17 23:20 +0100
        Re: [PATCH v6 16/19] aarch64: ilp32: use generic stat64 structure Arnd Bergmann <arnd@arndb.de> - 2015-11-18 22:00 +0100
    [PATCH v6 11/19] arm64:ilp32: support core dump generation for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-17 22:30 +0100
      Re: [PATCH v6 11/19] arm64:ilp32: support core dump generation for  ILP32 Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 17:50 +0100
    Re: [PATCH v6 06/19] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs Arnd Bergmann <arnd@arndb.de> - 2015-11-17 23:20 +0100
    Re: [RFC2 PATCH v6 00/19] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2015-11-18 09:10 +0100
    Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report  a a subplatform for ILP32 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2015-11-18 09:20 +0100
      Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 pinskia@gmail.com - 2015-11-18 12:30 +0100
        Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to  report a a subplatform for ILP32 Yury Norov <ynorov@caviumnetworks.com> - 2015-11-18 21:30 +0100
          Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com> - 2015-11-18 23:10 +0100
    Re: [PATCH v6 01/19] arm64:ilp32: add documentation on the ILP32  ABI for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2015-11-18 09:20 +0100
    Re: [RFC2 PATCH v6 00/19] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2015-11-23 17:50 +0100
    Re: [PATCH v6 04/19] arm64: change some CONFIG_COMPAT over to use  CONFIG_AARCH32_EL0 instead Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 13:10 +0100
      Re: [PATCH v6 04/19] arm64: change some CONFIG_COMPAT over to use  CONFIG_AARCH32_EL0 instead Yury Norov <ynorov@caviumnetworks.com> - 2015-12-04 23:00 +0100
    Re: [RFC2 PATCH v6 00/19] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-12-03 19:10 +0100
      Re: [RFC2 PATCH v6 00/19] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2015-12-04 16:40 +0100
        Re: [RFC2 PATCH v6 00/19] ILP32 for ARM64 Catalin Marinas <catalin.marinas@arm.com> - 2015-12-04 18:20 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#1280252 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Nov 30, 2015 at 04:34:22PM +0100, Arnd Bergmann wrote:
> On Tuesday 17 November 2015 22:57:52 Arnd Bergmann wrote:
> > On Wednesday 18 November 2015 00:16:54 Yury Norov wrote:
> > > From: Andrew Pinski <apinski@cavium.com>
> > > 
> > > Add a separate syscall-table for ILP32, which dispatches either to native
> > > LP64 system call implementation or to compat-syscalls, as appropriate.
> > 
> > I like it much better than the previous version, thanks for the rework!
> 
> Hi Yuri,
> 
> you must have missed my reply below. Are you still working on ilp32
> or did you drop this thread because you got distracted with something
> else?
> 
> 	Arnd
> 

Hi Arnd,

I didn't miss it, and I continue with ILP32. I really appreciate your
attention and time you spend on ILP32.

There's a tricky bug with signal stack, that Andreas also discovered.
It makes almost all tests that use posix threads crash. I want to fix
it and other bugs before next submission. 

I also update glibc to follow all recommendations, and I want to
upload it together with kernel patches.

BR,
Yury.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280324 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Monday 30 November 2015 23:21:41 Yury Norov wrote:
> On Mon, Nov 30, 2015 at 04:34:22PM +0100, Arnd Bergmann wrote:
> > On Tuesday 17 November 2015 22:57:52 Arnd Bergmann wrote:
> > > On Wednesday 18 November 2015 00:16:54 Yury Norov wrote:
> > > > From: Andrew Pinski <apinski@cavium.com>
> > > > 
> > > > Add a separate syscall-table for ILP32, which dispatches either to native
> > > > LP64 system call implementation or to compat-syscalls, as appropriate.
> > > 
> > > I like it much better than the previous version, thanks for the rework!
> > 
> > Hi Yuri,
> > 
> > you must have missed my reply below. Are you still working on ilp32
> > or did you drop this thread because you got distracted with something
> > else?
> > 
> 
> I didn't miss it, and I continue with ILP32. I really appreciate your
> attention and time you spend on ILP32.
> 
> There's a tricky bug with signal stack, that Andreas also discovered.
> It makes almost all tests that use posix threads crash. I want to fix
> it and other bugs before next submission. 
> 
> I also update glibc to follow all recommendations, and I want to
> upload it together with kernel patches.

Ok. As a reviewer, I find long waits between submissions a bit annoying
because that means I have already forgotten everything I commented on
the previous time.

Could we try to get consensus on how the syscall ABI should look
before you start adapting glibc to another intermediate version?
I think that would also save you duplicate work, as it's always
possible that we misunderstand each other in the review. Also,
when someone asks you questions during a review, please reply to
those questions so we can get a common understanding of the facts
and document that in the mail archives.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280423 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Nov 30, 2015 at 1:49 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 30 November 2015 23:21:41 Yury Norov wrote:
>> On Mon, Nov 30, 2015 at 04:34:22PM +0100, Arnd Bergmann wrote:
>> > On Tuesday 17 November 2015 22:57:52 Arnd Bergmann wrote:
>> > > On Wednesday 18 November 2015 00:16:54 Yury Norov wrote:
>> > > > From: Andrew Pinski <apinski@cavium.com>
>> > > >
>> > > > Add a separate syscall-table for ILP32, which dispatches either to native
>> > > > LP64 system call implementation or to compat-syscalls, as appropriate.
>> > >
>> > > I like it much better than the previous version, thanks for the rework!
>> >
>> > Hi Yuri,
>> >
>> > you must have missed my reply below. Are you still working on ilp32
>> > or did you drop this thread because you got distracted with something
>> > else?
>> >
>>
>> I didn't miss it, and I continue with ILP32. I really appreciate your
>> attention and time you spend on ILP32.
>>
>> There's a tricky bug with signal stack, that Andreas also discovered.
>> It makes almost all tests that use posix threads crash. I want to fix
>> it and other bugs before next submission.
>>
>> I also update glibc to follow all recommendations, and I want to
>> upload it together with kernel patches.
>
> Ok. As a reviewer, I find long waits between submissions a bit annoying
> because that means I have already forgotten everything I commented on
> the previous time.
>
> Could we try to get consensus on how the syscall ABI should look
> before you start adapting glibc to another intermediate version?

Sounds good. I have asked Yury to do that just that and change the
patches according to the current reviews without testing them with a
newer version of glibc.   Note getting consensus would be nice soon as
possible so I can start working again on glibc patches and make sure
the changes that are made to support a slightly different ABI on the
userland side is ok with them.

Thanks,
Andrew

> I think that would also save you duplicate work, as it's always
> possible that we misunderstand each other in the review. Also,
> when someone asks you questions during a review, please reply to
> those questions so we can get a common understanding of the facts
> and document that in the mail archives.
>
>         Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280437 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Nov 30, 2015 at 10:49:43PM +0100, Arnd Bergmann wrote:
> 
> Could we try to get consensus on how the syscall ABI should look
> before you start adapting glibc to another intermediate version?
> I think that would also save you duplicate work, as it's always
> possible that we misunderstand each other in the review. Also,
> when someone asks you questions during a review, please reply to
> those questions so we can get a common understanding of the facts
> and document that in the mail archives.
> 
> 	Arnd

This is full syscall table for ILP32, how it looks right now.
I collected all comments here and do rework according it.
Any comments?

BR,
Yury.

[0] = compat_sys_io_setup,			
[1] = sys_io_destroy,
[2] = compat_sys_io_submit,
[3] = sys_io_cancel,
[4] = sys_io_getevents,			wrong timespec_t and aio_context_t here
[5] = sys_setxattr,
[6] = sys_lsetxattr,
[7] = sys_fsetxattr,
[8] = sys_getxattr,
[9] = sys_lgetxattr,
[10] = sys_fgetxattr,
[11] = sys_listxattr,
[12] = sys_llistxattr,
[13] = sys_flistxattr,
[14] = sys_removexattr,
[15] = sys_lremovexattr,
[16] = sys_fremovexattr,
[17] = sys_getcwd,
[18] = sys_lookup_dcookie,
[19] = sys_eventfd2,
[20] = sys_epoll_create1,
[21] = sys_epoll_ctl,
[22] = sys_epoll_pwait,			way round: takes sigset_t check BE
[23] = sys_dup,
[24] = sys_dup3,
[25] = compat_sys_fcntl,		uses compat_off_t, not compat_loff_t
[26] = sys_inotify_init1,
[27] = sys_inotify_add_watch,
[28] = sys_inotify_rm_watch,
[29] = compat_sys_ioctl,
[30] = sys_ioprio_set,
[31] = sys_ioprio_get,
[32] = sys_flock,
[33] = sys_mknodat,
[34] = sys_mkdirat,
[35] = sys_unlinkat,
[36] = sys_symlinkat,
[37] = sys_linkat,
[38] = sys_renameat,
[39] = sys_umount,
[40] = compat_sys_mount,
[41] = sys_pivot_root,
[42] = sys_ni_syscall,
[43] = compat_sys_statfs64_wrapper,	check wrappers, maybe just statfs64
[44] = compat_sys_fstatfs64_wrapper,				   fstatfs64
[45] = sys_truncate,
[46] = sys_ftruncate,
[47] = sys_fallocate,
[48] = sys_faccessat,
[49] = sys_chdir,
[50] = sys_fchdir,
[51] = sys_chroot,
[52] = sys_fchmod,
[53] = sys_fchmodat,
[54] = sys_fchownat,
[55] = sys_fchown,
[56] = sys_openat,			force O_LARGEFILE in asm-generic/unistd.h
					make tile32 to use compat
[57] = sys_close,
[58] = sys_vhangup,
[59] = sys_pipe2,
[60] = sys_quotactl,
[61] = sys_getdents64,			check: glibc uses linux_dirent64 for
					32-bit architectures, so this looks wrong
[62] = sys_llseek,			use 3-argument lseek
[63] = sys_read,
[64] = sys_write,
[65] = compat_sys_readv,
[66] = compat_sys_writev,
[67] = sys_pread64,
[68] = sys_pwrite64,
[69] = compat_sys_preadv64,		use noncompat
[70] = compat_sys_pwritev64,		use noncompat
[71] = sys_sendfile64,
[72] = compat_sys_pselect6,
[73] = compat_sys_ppoll,
[74] = sys_signalfd4,			takes sigset_t, check BE
[75] = compat_sys_vmsplice,
[76] = sys_splice,
[77] = sys_tee,
[78] = sys_readlinkat,
[79] = ilp32_sys_fstatat64,		use compat. fix glibc
[80] = ilp32_sys_fstat64,		use compat. fix glibc
[81] = sys_sync,
[82] = sys_fsync,
[83] = sys_fdatasync,
[84] = sys_sync_file_range,
[85] = sys_timerfd_create,
[86] = compat_sys_timerfd_settime,
[87] = compat_sys_timerfd_gettime,
[88] = compat_sys_utimensat,
[89] = sys_acct,
[90] = sys_capget,
[91] = sys_capset,
[92] = sys_personality,
[93] = sys_exit,
[94] = sys_exit_group,
[95] = sys_waitid,			check: need a separate wrapper
					to convert rusage but not siginfo
[96] = sys_set_tid_address,
[97] = sys_unshare,
[98] = compat_sys_futex,
[99] = compat_sys_set_robust_list,
[100] = compat_sys_get_robust_list,
[101] = compat_sys_nanosleep,
[102] = compat_sys_getitimer,
[103] = compat_sys_setitimer,
[104] = compat_sys_kexec_load,
[105] = sys_init_module,
[106] = sys_delete_module,
[107] = sys_timer_create,		check 64-bit sigevent, maybe use compat
[108] = sys_timer_gettime,		timespec
[109] = sys_timer_getoverrun,
[110] = sys_timer_settime,		timespec
[111] = sys_timer_delete,
[112] = compat_sys_clock_settime,
[113] = compat_sys_clock_gettime,
[114] = sys_clock_getres,		timespec
[115] = sys_clock_nanosleep,		timespec (?)
[116] = sys_syslog,
[117] = sys_ptrace,
[118] = sys_sched_setparam,
[119] = sys_sched_setscheduler,
[120] = sys_sched_getscheduler,
[121] = sys_sched_getparam,
[122] = compat_sys_sched_setaffinity,
[123] = compat_sys_sched_getaffinity,
[124] = sys_sched_yield,
[125] = sys_sched_get_priority_max,
[126] = sys_sched_get_priority_min,
[127] = sys_sched_rr_get_interval,	timespec
[128] = sys_restart_syscall,
[129] = sys_kill,
[130] = sys_tkill,
[131] = sys_tgkill,
[132] = sys_sigaltstack,
[133] = sys_rt_sigsuspend,		takes sigset_t check BE
[134] = sys_rt_sigaction,
[135] = sys_rt_sigprocmask,		takes sigset_t check BE
[136] = sys_rt_sigpending,		takes sigset_t check BE
[137] = sys_rt_sigtimedwait,		wrapper? 64-bit siginfo but
					32-bit sigset and timespec
[138] = sys_rt_sigqueueinfo,		this is OK (?)
[139] = sys_rt_sigreturn_wrapper,
[140] = sys_setpriority,
[141] = sys_getpriority,
[142] = sys_reboot,
[143] = sys_setregid,
[144] = sys_setgid,
[145] = sys_setreuid,
[146] = sys_setuid,
[147] = sys_setresuid,
[148] = sys_getresuid,
[149] = sys_setresgid,
[150] = sys_getresgid,
[151] = sys_setfsuid,
[152] = sys_setfsgid,
[153] = compat_sys_times,
[154] = sys_setpgid,
[155] = sys_getpgid,
[156] = sys_getsid,
[157] = sys_setsid,
[158] = sys_getgroups,
[159] = sys_setgroups,
[160] = sys_newuname,
[161] = sys_sethostname,
[162] = sys_setdomainname,
[163] = compat_sys_getrlimit,
[164] = compat_sys_setrlimit,
[165] = compat_sys_getrusage,
[166] = sys_umask,
[167] = sys_prctl,
[168] = sys_getcpu,
[169] = compat_sys_gettimeofday,
[170] = compat_sys_settimeofday,
[171] = compat_sys_adjtimex,
[172] = sys_getpid,
[173] = sys_getppid,
[174] = sys_getuid,
[175] = sys_geteuid,
[176] = sys_getgid,
[177] = sys_getegid,
[178] = sys_gettid,
[179] = compat_sys_sysinfo,
[180] = sys_mq_open,			wrong struct mq_attr
[181] = sys_mq_unlink,
[182] = sys_mq_timedsend,		wrong struct mq_attr
[183] = sys_mq_timedreceive,		wrong struct mq_attr
[184] = sys_mq_notify,
[185] = sys_mq_getsetattr,		wrong struct mq_attr
[186] = sys_msgget,
[187] = ilp32_sys_msgctl,		as is, waiting for generic fix (?)
[188] = compat_sys_msgrcv,
[189] = compat_sys_msgsnd,
[190] = sys_semget,
[191] = ilp32_sys_semctl,		as is, waiting for generic fix (?)
[192] = sys_semtimedop,			timespec_t
[193] = sys_semop,
[194] = sys_shmget,
[195] = ilp32_sys_shmctl,		as is, waiting for generic fix (?)
[196] = sys_shmat,			check (shmat01 test fails if compat)
[197] = sys_shmdt,
[198] = sys_socket,
[199] = sys_socketpair,
[200] = sys_bind,
[201] = sys_listen,
[202] = sys_accept,
[203] = sys_connect,
[204] = sys_getsockname,
[205] = sys_getpeername,
[206] = sys_sendto,
[207] = compat_sys_recvfrom,
[208] = compat_sys_setsockopt,
[209] = compat_sys_getsockopt,
[210] = sys_shutdown,
[211] = compat_sys_sendmsg,
[212] = compat_sys_recvmsg,
[213] = sys_readahead,
[214] = sys_brk,
[215] = sys_munmap,
[216] = sys_mremap,
[217] = sys_add_key,
[218] = sys_request_key,
[219] = compat_sys_keyctl,
[220] = sys_clone,
[221] = compat_sys_execve,
[222] = compat_sys_mmap2_wrapper, 	check. maybe just mmap2
[223] = sys_fadvise64_64,
[224] = sys_swapon,
[225] = sys_swapoff,
[226] = sys_mprotect,
[227] = sys_msync,
[228] = sys_mlock,
[229] = sys_munlock,
[230] = sys_mlockall,
[231] = sys_munlockall,
[232] = sys_mincore,
[233] = sys_madvise,
[234] = sys_remap_file_pages,
[235] = compat_sys_mbind,
[236] = compat_sys_get_mempolicy,
[237] = compat_sys_set_mempolicy,
[238] = compat_sys_migrate_pages,
[239] = compat_sys_move_pages,
[240] = sys_rt_tgsigqueueinfo,
[241] = sys_perf_event_open,
[242] = sys_accept4,
[243] = compat_sys_recvmmsg,
[260] = compat_sys_wait4,
[261] = sys_prlimit64,
[262] = sys_fanotify_init,
[263] = sys_fanotify_mark,
[264] = sys_name_to_handle_at,
[265] = sys_open_by_handle_at,		force O_LARGEFILE in asm-generic/unistd.h
					make tile32 to use compat
[266] = sys_clock_adjtime,		wrong timex structure
[267] = sys_syncfs,
[268] = sys_setns,
[269] = compat_sys_sendmmsg,
[270] = compat_sys_process_vm_readv,
[271] = compat_sys_process_vm_writev,
[272] = sys_kcmp,
[273] = sys_finit_module,
[274] = sys_sched_setattr,
[275] = sys_sched_getattr,
[276] = sys_renameat2,
[277] = sys_seccomp,
[278] = sys_getrandom,
[279] = sys_memfd_create,
[280] = sys_bpf,
[281] = sys_execveat,			check: wrong struct user_arg_ptr
[282] = sys_userfaultfd,
[283] = sys_membarrier,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280735 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tuesday 01 December 2015 03:40:09 Yury Norov wrote:
> On Mon, Nov 30, 2015 at 10:49:43PM +0100, Arnd Bergmann wrote:
> > 
> > Could we try to get consensus on how the syscall ABI should look
> > before you start adapting glibc to another intermediate version?
> > I think that would also save you duplicate work, as it's always
> > possible that we misunderstand each other in the review. Also,
> > when someone asks you questions during a review, please reply to
> > those questions so we can get a common understanding of the facts
> > and document that in the mail archives.
> > 
> >       Arnd
> 
> This is full syscall table for ILP32, how it looks right now.
> I collected all comments here and do rework according it.
> Any comments?

It might be easier to start the other way round: rather than
annotating the things that might be wrong, remove all the overrides
and add back only the 64-bit syscalls that we want instead of the
32-bit variants when you find that they are absolutely needed.

> [0] = compat_sys_io_setup,                      
> [1] = sys_io_destroy,
> [2] = compat_sys_io_submit,
> [3] = sys_io_cancel,
> [4] = sys_io_getevents,                 wrong timespec_t and aio_context_t here
> [5] = sys_setxattr,
> [6] = sys_lsetxattr,
> [7] = sys_fsetxattr,
> [8] = sys_getxattr,
> [9] = sys_lgetxattr,
> [10] = sys_fgetxattr,
> [11] = sys_listxattr,
> [12] = sys_llistxattr,
> [13] = sys_flistxattr,
> [14] = sys_removexattr,
> [15] = sys_lremovexattr,
> [16] = sys_fremovexattr,
> [17] = sys_getcwd,
> [18] = sys_lookup_dcookie,
> [19] = sys_eventfd2,
> [20] = sys_epoll_create1,
> [21] = sys_epoll_ctl,
> [22] = sys_epoll_pwait,                 way round: takes sigset_t check BE
> [23] = sys_dup,
> [24] = sys_dup3,
> [25] = compat_sys_fcntl,                uses compat_off_t, not compat_loff_t
> [26] = sys_inotify_init1,
> [27] = sys_inotify_add_watch,

I was looking for your latest arch/arm64/kernel/sys_ilp32.c version. I'm
not that interested in the ones that are just using the normal compat API,
just the ones that you still think we have to override, and why that
override is required.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280686 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Yury Norov <ynorov@caviumnetworks.com> writes:

> There's a tricky bug with signal stack, that Andreas also discovered.

That was only a confusion about the compat state of sys_rt_sigaction.
It just requires making sure glibc uses the correct (64bit layout)
struct kernel_sigaction.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280736 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
> Yury Norov <ynorov@caviumnetworks.com> writes:
> 
> > There's a tricky bug with signal stack, that Andreas also discovered.
> 
> That was only a confusion about the compat state of sys_rt_sigaction.
> It just requires making sure glibc uses the correct (64bit layout)
> struct kernel_sigaction.

I don't think we need to use the 64-bit version of sigaction, both
kernel and libc are simpler if we use the normal 32-bit version.

We should always default to using the generic 32-bit structures
unless there is a strong reason not to.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280769 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Arnd Bergmann <arnd@arndb.de> writes:

> On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
>> Yury Norov <ynorov@caviumnetworks.com> writes:
>> 
>> > There's a tricky bug with signal stack, that Andreas also discovered.
>> 
>> That was only a confusion about the compat state of sys_rt_sigaction.
>> It just requires making sure glibc uses the correct (64bit layout)
>> struct kernel_sigaction.
>
> I don't think we need to use the 64-bit version of sigaction, both
> kernel and libc are simpler if we use the normal 32-bit version.

Since glibc has to do the conversion anyway (due to sigset_t), using the
64bit layout avoids a second conversion in the kernel.

> We should always default to using the generic 32-bit structures
> unless there is a strong reason not to.

The goal should be to avoid conversion layers where it makes sense.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1280801 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tuesday 01 December 2015 12:01:12 Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
> > On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
> >> Yury Norov <ynorov@caviumnetworks.com> writes:
> >> 
> >> > There's a tricky bug with signal stack, that Andreas also discovered.
> >> 
> >> That was only a confusion about the compat state of sys_rt_sigaction.
> >> It just requires making sure glibc uses the correct (64bit layout)
> >> struct kernel_sigaction.
> >
> > I don't think we need to use the 64-bit version of sigaction, both
> > kernel and libc are simpler if we use the normal 32-bit version.
> 
> Since glibc has to do the conversion anyway (due to sigset_t), using the
> 64bit layout avoids a second conversion in the kernel.

I don't get the part about sigset_t. Why would glibc want to use the
64-bit layout? This one looks like one of the cases where we absolutely
want to use the 32-bit layout or otherwise get into big trouble if
we ever want to support native ILP32 kernels.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281373 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tue, Dec 01, 2015 at 12:30:56PM +0100, Arnd Bergmann wrote:
> On Tuesday 01 December 2015 12:01:12 Andreas Schwab wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> > 
> > > On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
> > >> Yury Norov <ynorov@caviumnetworks.com> writes:
> > >> 
> > >> > There's a tricky bug with signal stack, that Andreas also discovered.
> > >> 
> > >> That was only a confusion about the compat state of sys_rt_sigaction.
> > >> It just requires making sure glibc uses the correct (64bit layout)
> > >> struct kernel_sigaction.
> > >
> > > I don't think we need to use the 64-bit version of sigaction, both
> > > kernel and libc are simpler if we use the normal 32-bit version.
> > 
> > Since glibc has to do the conversion anyway (due to sigset_t), using the
> > 64bit layout avoids a second conversion in the kernel.
> 
> I don't get the part about sigset_t. Why would glibc want to use the
> 64-bit layout? This one looks like one of the cases where we absolutely
> want to use the 32-bit layout or otherwise get into big trouble if
> we ever want to support native ILP32 kernels.
> 
> 	Arnd

So, we drop patch #6, and use 32-bit layout for all signal structures.

Correct?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281583 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wednesday 02 December 2015 03:24:30 Yury Norov wrote:
> On Tue, Dec 01, 2015 at 12:30:56PM +0100, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 12:01:12 Andreas Schwab wrote:
> > > Arnd Bergmann <arnd@arndb.de> writes:
> > > 
> > > > On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
> > > >> Yury Norov <ynorov@caviumnetworks.com> writes:
> > > >> 
> > > >> > There's a tricky bug with signal stack, that Andreas also discovered.
> > > >> 
> > > >> That was only a confusion about the compat state of sys_rt_sigaction.
> > > >> It just requires making sure glibc uses the correct (64bit layout)
> > > >> struct kernel_sigaction.
> > > >
> > > > I don't think we need to use the 64-bit version of sigaction, both
> > > > kernel and libc are simpler if we use the normal 32-bit version.
> > > 
> > > Since glibc has to do the conversion anyway (due to sigset_t), using the
> > > 64bit layout avoids a second conversion in the kernel.
> > 
> > I don't get the part about sigset_t. Why would glibc want to use the
> > 64-bit layout? This one looks like one of the cases where we absolutely
> > want to use the 32-bit layout or otherwise get into big trouble if
> > we ever want to support native ILP32 kernels.
> > 
> >       Arnd
> 
> So, we drop patch #6, and use 32-bit layout for all signal structures.
> 
> Correct?

If the 32-bit layout is sane, yes. Andrew can surely judge this better
than I can. The goal should be to have the most straightforward
implementation for both kernel and libc, and reuse either the compat
signal handling or the native one as much as we can.

Looking at the API, I find that ARM fortunately uses all the standard
definitions for sigset_t, struct siginfo/siginfo_t, union sigval/sigval_t,
struct sigaction, struct sigaltstack/stack_t. It took me a while to
figure out that the definitions in the uapi headers are different but
actually unused (probably remaining from libc5 days or earlier).
The signal numbers are all the same, and so are the 

The SA_* flags are all the same too, except for SA_THIRTYTWO, but
that is not implemented by the compat handling because we do not
support 26 bit tasks anyway.

struct sigcontext is obviously different because of the changed
register set, and we will have to deal with that in some form in the
compat code. struct ucontext and struct rt_sigframe includes that,
which I assume is the main part we need to handle correctly
by having ilp32 specific setup_rt_frame/sys_rt_sigreturn functions.

One small difference is the handling of MINSIGSTKSZ, which would
currently work for ilp32, but I noticed that commit c9692657c032
("arm64: Fix MINSIGSTKSZ and SIGSTKSZ") from Manjeet Pawar broke
compat mode: Any 32-bit (aarch32) task that passes an altstack smaller
than 5120 bytes now gets rejected by the kernel, whereas the native
32-bit kernel checks for 2048 bytes instead. We need to fix the
existing compat case here without breaking the ilp32 case.

With all that said, I would assume that just having separate
sigcontext/ucontext/rt_sigframe and reusing the compat code otherwise,
we are overall better off than with using the native 64-bit signal
handling with everything that ties in (waitid, epoll_pwait,
signalfd, ppoll, ...), but we can discuss this further if someone
sees major downsides of that compared to your existing approach.
In particular, I don't know what the difference means for gdb,
glibc or strace.


	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1283207 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wed, Dec 02, 2015 at 03:24:30AM +0300, Yury Norov wrote:
> On Tue, Dec 01, 2015 at 12:30:56PM +0100, Arnd Bergmann wrote:
> > On Tuesday 01 December 2015 12:01:12 Andreas Schwab wrote:
> > > Arnd Bergmann <arnd@arndb.de> writes:
> > > 
> > > > On Tuesday 01 December 2015 10:20:59 Andreas Schwab wrote:
> > > >> Yury Norov <ynorov@caviumnetworks.com> writes:
> > > >> 
> > > >> > There's a tricky bug with signal stack, that Andreas also discovered.
> > > >> 
> > > >> That was only a confusion about the compat state of sys_rt_sigaction.
> > > >> It just requires making sure glibc uses the correct (64bit layout)
> > > >> struct kernel_sigaction.
> > > >
> > > > I don't think we need to use the 64-bit version of sigaction, both
> > > > kernel and libc are simpler if we use the normal 32-bit version.
> > > 
> > > Since glibc has to do the conversion anyway (due to sigset_t), using the
> > > 64bit layout avoids a second conversion in the kernel.
> > 
> > I don't get the part about sigset_t. Why would glibc want to use the
> > 64-bit layout? This one looks like one of the cases where we absolutely
> > want to use the 32-bit layout or otherwise get into big trouble if
> > we ever want to support native ILP32 kernels.
> > 
> > 	Arnd
> 
> So, we drop patch #6, and use 32-bit layout for all signal structures.
> 
> Correct?

I would vote for this as well. I think it probably removes patch 12 as
well (COMPAT_USE_NATIVE_SIGINFO).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281230 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

> > +#define compat_sys_shmat               sys_shmat
> 
> What's special about compat_sys_shmat?
> 

It's about SHMLBA definition.
For aarch32 glibc defines it as (__getpagesize () << 2).
For ILP32 there's no definition, and so generic one is used: (__getpagesize ()).

In kernel, for ARM64, COMPAT_SHMLBA defined just as 0x4000. Both
compat and non-compat shmat syscalls pass identical arguments to
do_shmat, except shmlba. Effectively, library expects shmlba to
be 0x1000, as sys_shmat does. And compat_sys_shmat expects 0x4000.

I think, both kernel and library parts are to be fixed. In library
we'd use definition identical to ARM. For kernel we'd use compat
syscall.

My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000? If there's
no specific reason for it, it looks like a bug, and we should
define it like in arch/arm:
        #define SHMLBA  (4 * PAGE_SIZE)          /* attach addr a multiple of this */

Maybe that's why AARCH32 is limited to 4K pages in config.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281277 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wednesday 02 December 2015 00:29:04 Yury Norov wrote:
> > > +#define compat_sys_shmat               sys_shmat
> > 
> > What's special about compat_sys_shmat?
> > 
> 
> It's about  	 definition.
> For aarch32 glibc defines it as (__getpagesize () << 2).
> For ILP32 there's no definition, and so generic one is used: (__getpagesize ()).

Ok, got it.

> In kernel, for ARM64, COMPAT_SHMLBA defined just as 0x4000. Both
> compat and non-compat shmat syscalls pass identical arguments to
> do_shmat, except shmlba. Effectively, library expects shmlba to
> be 0x1000, as sys_shmat does. And compat_sys_shmat expects 0x4000.
> 
> I think, both kernel and library parts are to be fixed. In library
> we'd use definition identical to ARM. For kernel we'd use compat
> syscall.

I'm not sure I understand this part. What changes specifically do we need?

It sounds like shmat is one of the cases we an override makes sense
and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode.

> My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000? If there's
> no specific reason for it, it looks like a bug, and we should
> define it like in arch/arm:
>         #define SHMLBA  (4 * PAGE_SIZE)          /* attach addr a multiple of this */
> 
> Maybe that's why AARCH32 is limited to 4K pages in config.

The reason why AARCH32 is limited to 4K pages is the alignment of
ELF sections, and with newer binutils versions, that is no longer
a problem, other than the bug you just found.

We normally assume that the page size on ARM is fixed to 4K, so
there might be user space that just hardcodes 16K SHMLBA rather
than using the glibc (__getpagesize () << 2) definition. Changing
the kernel would break those programs, but you can also argue that
they are already broken today.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281349 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Tue, Dec 01, 2015 at 11:39:42PM +0100, Arnd Bergmann wrote:
> On Wednesday 02 December 2015 00:29:04 Yury Norov wrote:
> > > > +#define compat_sys_shmat               sys_shmat
> > > 
> > > What's special about compat_sys_shmat?
> > > 
> > 
> > It's about  	 definition.
> > For aarch32 glibc defines it as (__getpagesize () << 2).
> > For ILP32 there's no definition, and so generic one is used: (__getpagesize ()).
> 
> Ok, got it.
> 
> > In kernel, for ARM64, COMPAT_SHMLBA defined just as 0x4000. Both
> > compat and non-compat shmat syscalls pass identical arguments to
> > do_shmat, except shmlba. Effectively, library expects shmlba to
> > be 0x1000, as sys_shmat does. And compat_sys_shmat expects 0x4000.
> > 
> > I think, both kernel and library parts are to be fixed. In library
> > we'd use definition identical to ARM. For kernel we'd use compat
> > syscall.
> 
> I'm not sure I understand this part. What changes specifically do we need?
> 

For kernel:

        diff --git a/arch/arm64/include/asm/shmparam.h b/arch/arm64/include/asm/shmparam.h
        index 4df608a..e368a55 100644
        --- a/arch/arm64/include/asm/shmparam.h
        +++ b/arch/arm64/include/asm/shmparam.h
        @@ -21,7 +21,7 @@
          * alignment value. Since we don't have aliasing D-caches, the rest of
          * the time we can safely use PAGE_SIZE.
          */
        -#define COMPAT_SHMLBA	0x4000
        +#define COMPAT_SHMLBA	(4 * PAGE_SIZE)
         
         #include <asm-generic/shmparam.h>
         
        diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
        index c5bc712..877bedf 100644
        --- a/arch/arm64/kernel/sys_ilp32.c
        +++ b/arch/arm64/kernel/sys_ilp32.c
        @@ -42,15 +42,12 @@ asmlinkage long sys_rt_sigreturn_wrapper(void);
         #define compat_sys_pwrite64            sys_pwrite64
         #define compat_sys_readahead           sys_readahead
         #define compat_sys_rt_sigaction        sys_rt_sigaction
        -#define compat_sys_shmat               sys_shmat
         #define compat_sys_sync_file_range     sys_sync_file_range
         #define compat_sys_truncate64          sys_truncate
         #define compat_sys_sigaltstack         sys_sigaltstack
 
For library - just create a header in ilp32 directory that defines
SHMLBA exactly as arm: __getpagesize () << 2

> It sounds like shmat is one of the cases we an override makes sense
> and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode.
> 

[...]

> We normally assume that the page size on ARM is fixed to 4K, so
> there might be user space that just hardcodes 16K SHMLBA 

It means that we should use compat_sys_shmat because hardcoded
userspace may have a chance to work for 4K pages. If we'll use
sys_shmat (and so 4K SHMLBA), we'll definitely make hardcoded
userspace broken. Non-hardcoded userspace will work anyway.

We can describe in documentation that 4k pages are prefferable.

Yury

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281523 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wednesday 02 December 2015 02:35:03 Yury Norov wrote:
> On Tue, Dec 01, 2015 at 11:39:42PM +0100, Arnd Bergmann wrote:
> > On Wednesday 02 December 2015 00:29:04 Yury Norov wrote:
> > I'm not sure I understand this part. What changes specifically do we need?
> > 
> 
> For kernel:
> 
>         diff --git a/arch/arm64/include/asm/shmparam.h b/arch/arm64/include/asm/shmparam.h
>         index 4df608a..e368a55 100644
>         --- a/arch/arm64/include/asm/shmparam.h
>         +++ b/arch/arm64/include/asm/shmparam.h
>         @@ -21,7 +21,7 @@
>           * alignment value. Since we don't have aliasing D-caches, the rest of
>           * the time we can safely use PAGE_SIZE.
>           */
>         -#define COMPAT_SHMLBA	0x4000
>         +#define COMPAT_SHMLBA	(4 * PAGE_SIZE)
>          
>          #include <asm-generic/shmparam.h>
>          
>         diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
>         index c5bc712..877bedf 100644
>         --- a/arch/arm64/kernel/sys_ilp32.c
>         +++ b/arch/arm64/kernel/sys_ilp32.c
>         @@ -42,15 +42,12 @@ asmlinkage long sys_rt_sigreturn_wrapper(void);
>          #define compat_sys_pwrite64            sys_pwrite64
>          #define compat_sys_readahead           sys_readahead
>          #define compat_sys_rt_sigaction        sys_rt_sigaction
>         -#define compat_sys_shmat               sys_shmat
>          #define compat_sys_sync_file_range     sys_sync_file_range
>          #define compat_sys_truncate64          sys_truncate
>          #define compat_sys_sigaltstack         sys_sigaltstack
>  
> For library - just create a header in ilp32 directory that defines
> SHMLBA exactly as arm: __getpagesize () << 2

I think we both reversed our positions here ;-)

The 4*PAGE_SIZE on ARM is an architecture specific oddity, I believe
to work around aliasing caches on ARMv6. As no other architecture does
this, we're probably better off not duplicating it for aarch64-ilp32
and just use sys_shmat as your v6 patch does.

> > It sounds like shmat is one of the cases we an override makes sense
> > and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode.
> > 
> 
> [...]
> 
> > We normally assume that the page size on ARM is fixed to 4K, so
> > there might be user space that just hardcodes 16K SHMLBA 
> 
> It means that we should use compat_sys_shmat because hardcoded
> userspace may have a chance to work for 4K pages. If we'll use
> sys_shmat (and so 4K SHMLBA), we'll definitely make hardcoded
> userspace broken. Non-hardcoded userspace will work anyway.
> 
> We can describe in documentation that 4k pages are prefferable.

The hardcoded user space would only apply to old source code that
specifically tries to adapt to what ARM does, but gets it wrong,
If we have source code that is converted from x86 or mips and
hardcodes anything, it's more likely to be the normal __getpagesize().

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281541 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wed, Dec 02, 2015 at 09:37:05AM +0100, Arnd Bergmann wrote:
> On Wednesday 02 December 2015 02:35:03 Yury Norov wrote:
> > On Tue, Dec 01, 2015 at 11:39:42PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 02 December 2015 00:29:04 Yury Norov wrote:
> > > I'm not sure I understand this part. What changes specifically do we need?
> > > 
> > 
> > For kernel:
> > 
> >         diff --git a/arch/arm64/include/asm/shmparam.h b/arch/arm64/include/asm/shmparam.h
> >         index 4df608a..e368a55 100644
> >         --- a/arch/arm64/include/asm/shmparam.h
> >         +++ b/arch/arm64/include/asm/shmparam.h
> >         @@ -21,7 +21,7 @@
> >           * alignment value. Since we don't have aliasing D-caches, the rest of
> >           * the time we can safely use PAGE_SIZE.
> >           */
> >         -#define COMPAT_SHMLBA	0x4000
> >         +#define COMPAT_SHMLBA	(4 * PAGE_SIZE)
> >          
> >          #include <asm-generic/shmparam.h>
> >          
> >         diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
> >         index c5bc712..877bedf 100644
> >         --- a/arch/arm64/kernel/sys_ilp32.c
> >         +++ b/arch/arm64/kernel/sys_ilp32.c
> >         @@ -42,15 +42,12 @@ asmlinkage long sys_rt_sigreturn_wrapper(void);
> >          #define compat_sys_pwrite64            sys_pwrite64
> >          #define compat_sys_readahead           sys_readahead
> >          #define compat_sys_rt_sigaction        sys_rt_sigaction
> >         -#define compat_sys_shmat               sys_shmat
> >          #define compat_sys_sync_file_range     sys_sync_file_range
> >          #define compat_sys_truncate64          sys_truncate
> >          #define compat_sys_sigaltstack         sys_sigaltstack
> >  
> > For library - just create a header in ilp32 directory that defines
> > SHMLBA exactly as arm: __getpagesize () << 2
> 
> I think we both reversed our positions here ;-)
> 
> The 4*PAGE_SIZE on ARM is an architecture specific oddity, I believe
> to work around aliasing caches on ARMv6. As no other architecture does
> this, we're probably better off not duplicating it for aarch64-ilp32
> and just use sys_shmat as your v6 patch does.
> 
> > > It sounds like shmat is one of the cases we an override makes sense
> > > and we should use sys_shmat with PAGE_SIZE for aarch64 ilp32 mode.
> > > 
> > 
> > [...]
> > 
> > > We normally assume that the page size on ARM is fixed to 4K, so
> > > there might be user space that just hardcodes 16K SHMLBA 
> > 
> > It means that we should use compat_sys_shmat because hardcoded
> > userspace may have a chance to work for 4K pages. If we'll use
> > sys_shmat (and so 4K SHMLBA), we'll definitely make hardcoded
> > userspace broken. Non-hardcoded userspace will work anyway.
> > 
> > We can describe in documentation that 4k pages are prefferable.
> 
> The hardcoded user space would only apply to old source code that
> specifically tries to adapt to what ARM does, but gets it wrong,
> If we have source code that is converted from x86 or mips and
> hardcodes anything, it's more likely to be the normal __getpagesize().
> 
> 	Arnd

Hmm... OK. Let's have non-compat shmat here...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281611 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wed, Dec 02, 2015 at 09:37:05AM +0100, Arnd Bergmann wrote:
> The 4*PAGE_SIZE on ARM is an architecture specific oddity, I believe
> to work around aliasing caches on ARMv6. As no other architecture does
> this, we're probably better off not duplicating it for aarch64-ilp32
> and just use sys_shmat as your v6 patch does.
> 	Arnd

If you feel ARMv6 fix for caches will come soon, just ignore it.
Otherwise, please pull it because compat_sys_shmat is broken now
for 64K pages.

Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
---
 arch/arm64/include/asm/shmparam.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/shmparam.h b/arch/arm64/include/asm/shmparam.h
index 4df608a..e368a55 100644
--- a/arch/arm64/include/asm/shmparam.h
+++ b/arch/arm64/include/asm/shmparam.h
@@ -21,7 +21,7 @@
  * alignment value. Since we don't have aliasing D-caches, the rest of
  * the time we can safely use PAGE_SIZE.
  */
-#define COMPAT_SHMLBA	0x4000
+#define COMPAT_SHMLBA	(4 * PAGE_SIZE)
 
 #include <asm-generic/shmparam.h>
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281793 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wednesday 02 December 2015 13:35:22 Yury Norov wrote:
> On Wed, Dec 02, 2015 at 09:37:05AM +0100, Arnd Bergmann wrote:
> > The 4*PAGE_SIZE on ARM is an architecture specific oddity, I believe
> > to work around aliasing caches on ARMv6. As no other architecture does
> > this, we're probably better off not duplicating it for aarch64-ilp32
> > and just use sys_shmat as your v6 patch does.
> >       Arnd
> 
> If you feel ARMv6 fix for caches will come soon, just ignore it.
> Otherwise, please pull it because compat_sys_shmat is broken now
> for 64K pages.
> 
> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> 

Sounds good. Will, do you want to take this for the arm64 tree.

Acked-by: Arnd Bergmann <arnd@arndb.de>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1281811 — Re: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wednesday 02 December 2015 14:46:32 Arnd Bergmann wrote:
> On Wednesday 02 December 2015 13:35:22 Yury Norov wrote:
> > On Wed, Dec 02, 2015 at 09:37:05AM +0100, Arnd Bergmann wrote:
> > > The 4*PAGE_SIZE on ARM is an architecture specific oddity, I believe
> > > to work around aliasing caches on ARMv6. As no other architecture does
> > > this, we're probably better off not duplicating it for aarch64-ilp32
> > > and just use sys_shmat as your v6 patch does.
> > >       Arnd
> > 
> > If you feel ARMv6 fix for caches will come soon, just ignore it.
> > Otherwise, please pull it because compat_sys_shmat is broken now
> > for 64K pages.
> > 
> > Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
> > 
> 
> Sounds good. Will, do you want to take this for the arm64 tree.
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

(actually Cc Will Deacon)

Will or Catalin, does this look ok to you?

8<----
Subject: fix COMPAT_SHMLBA definition for large pages
From: Yury Norov <ynorov@caviumnetworks.com>

ARM glibc uses (4 * __getpagesize()) for SHMLBA, which is correct for 4KB pages
and works fine for 64KB pages, but the kernel uses a hardcoded 16KB that
is too small for 64KB page based kernels. This changes the definition to
what user space sees when using 64KB pages.

Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 arch/arm64/include/asm/shmparam.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/shmparam.h b/arch/arm64/include/asm/shmparam.h
index 4df608a..e368a55 100644
--- a/arch/arm64/include/asm/shmparam.h
+++ b/arch/arm64/include/asm/shmparam.h
@@ -21,7 +21,7 @@
  * alignment value. Since we don't have aliasing D-caches, the rest of
  * the time we can safely use PAGE_SIZE.
  */
-#define COMPAT_SHMLBA  0x4000
+#define COMPAT_SHMLBA  (4 * PAGE_SIZE)
 
 #include <asm-generic/shmparam.h>
 
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | linux.kernel

csiph-web