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


Groups > linux.kernel > #1281230 > unrolled thread

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

Started byYury Norov <ynorov@caviumnetworks.com>
First post2015-12-01 22:40 +0100
Last post2015-12-03 21:50 +0100
Articles 12 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  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

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

FromYury Norov <ynorov@caviumnetworks.com>
Date2015-12-01 22:40 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qB0Ou-6Du-7@gated-at.bofh.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] | [next] | [standalone]


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

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-01 23:50 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qB1Ue-7g2-11@gated-at.bofh.it>
In reply to#1281230
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

FromYury Norov <ynorov@caviumnetworks.com>
Date2015-12-02 00:40 +0100
Message-ID<qB2GD-7Ot-37@gated-at.bofh.it>
In reply to#1281277
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

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 09:40 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qBb7b-4IB-5@gated-at.bofh.it>
In reply to#1281349
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

FromYury Norov <ynorov@caviumnetworks.com>
Date2015-12-02 10:20 +0100
Message-ID<qBbJU-5dP-17@gated-at.bofh.it>
In reply to#1281523
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

FromYury Norov <ynorov@caviumnetworks.com>
Date2015-12-02 11:40 +0100
Message-ID<qBcZk-5WX-17@gated-at.bofh.it>
In reply to#1281523
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

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 14:50 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qBfXc-7QB-35@gated-at.bofh.it>
In reply to#1281611
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

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-02 15:00 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qBg6S-7Ug-11@gated-at.bofh.it>
In reply to#1281793
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]


#1281813

FromWill Deacon <will.deacon@arm.com>
Date2015-12-02 15:00 +0100
Message-ID<qBg6S-7Ug-21@gated-at.bofh.it>
In reply to#1281811
On Wed, Dec 02, 2015 at 02:54:18PM +0100, Arnd Bergmann wrote:
> 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?

Looks ok on the face of it (although I haven't tried compat w/ 64k pages).

I'll take it via the arm64 tree with your ack.

Cheers,

Will
--
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]


#1283219

FromCatalin Marinas <catalin.marinas@arm.com>
Date2015-12-03 18:50 +0100
Message-ID<qBGb0-8e4-15@gated-at.bofh.it>
In reply to#1281230
On Wed, Dec 02, 2015 at 12:29:04AM +0300, Yury Norov wrote:
> My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000?

This was done to match the arch/arm value of 4 * 4K. The historical
32-bit reason for 4 pages is to cope with aliasing VIPT caches (see
https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit?id=4197692eef113eeb8e3e413cc70993a5e667e5b8)

> 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 */

I guess you meant COMPAT_SHMLBA. I'm not sure there is much value in
keeping 4*PAGE_SIZE for larger page sizes but I agree that the current
16K value doesn't work well with 64K pages.

-- 
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]


#1283241

FromYury Norov <ynorov@caviumnetworks.com>
Date2015-12-03 19:20 +0100
Message-ID<qBGE3-cG-29@gated-at.bofh.it>
In reply to#1283219
On Thu, Dec 03, 2015 at 05:47:08PM +0000, Catalin Marinas wrote:
> On Wed, Dec 02, 2015 at 12:29:04AM +0300, Yury Norov wrote:
> > My question. Why aarch64 defines COMPAT_SHMLBA as 0x4000?
> 
> This was done to match the arch/arm value of 4 * 4K. The historical
> 32-bit reason for 4 pages is to cope with aliasing VIPT caches (see
> https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit?id=4197692eef113eeb8e3e413cc70993a5e667e5b8)
> 
> > 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 */
> 
> I guess you meant COMPAT_SHMLBA.

I citated arm code here. In aarch64 it's COMPAT_SHMLBA, of course.

> I'm not sure there is much value in
> keeping 4*PAGE_SIZE for larger page sizes but I agree that the current
> 16K value doesn't work well with 64K pages.

Arnd told there will be a workaround for arm v6 caches. Than this
header will not be needed at all. Until that, this is simpliest
fix as it doesn't affect userspace.

> 
> -- 
> 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]


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

FromArnd Bergmann <arnd@arndb.de>
Date2015-12-03 21:50 +0100
SubjectRe: [PATCH v6 14/19] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Message-ID<qBIZb-1y2-9@gated-at.bofh.it>
In reply to#1283241
On Thursday 03 December 2015 21:14:41 Yury Norov wrote:
> 
> > I'm not sure there is much value in
> > keeping 4*PAGE_SIZE for larger page sizes but I agree that the current
> > 16K value doesn't work well with 64K pages.
> 
> Arnd told there will be a workaround for arm v6 caches. Than this
> header will not be needed at all. Until that, this is simpliest
> fix as it doesn't affect userspace.

I think we should do whatever matches user space: There is no harm
in going to 256KB instead of 64KB if current glibc already uses
4*getpagetsize() for a kernel with native 64K pages.

	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] | [standalone]


Back to top | Article view | linux.kernel


csiph-web