Re: [PATCH v3 01/17] gcc PR 88409: miscompilation due to missing cc clobber in longlong.h macros
On 3/6/20 4:12 PM, Joseph Myers wrote: > If this gets longlong.h back in sync with changes made in the GCC version, > then please commit. This is now committed (my first commit yay !) Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 3/3] sysv: linux: Pass 64-bit version of semctl syscall
Hi Alistair,
On 3/4/20 5:26 PM, Alistair Francis wrote:
> The semctl_syscall() function passes a union semun to the kernel. The
> union includes struct semid_ds as a member. On 32-bit architectures the
> Linux kernel provides a *_high version of the 32-bit sem_otime and
> sem_ctime values. These can be combined to get a 64-bit version of the
> time.
>
> This patch adjusts the struct semid_ds to support the *_high versions
> of sem_otime and sem_ctime. For 32-bit systems with a 64-bit time_t
> this can be used to get a 64-bit time from the two 32-bit values.
>
> We protect this new code via the __IPC_TIME64 marco, which is only true
> for 32-bit architectures with a 64-bit time_t.
> ---
> bits/ipc.h| 6 -
> sysdeps/gnu/bits/ipc.h| 6 -
> sysdeps/unix/sysv/linux/bits/ipc.h| 6 -
> sysdeps/unix/sysv/linux/bits/semid_ds_t.h | 15 +++
> .../unix/sysv/linux/hppa/bits/semid_ds_t.h| 15 +++
> .../unix/sysv/linux/mips/bits/semid_ds_t.h| 13 ++
> .../unix/sysv/linux/powerpc/bits/semid_ds_t.h | 15 +++
> sysdeps/unix/sysv/linux/semctl.c | 25 ---
> .../unix/sysv/linux/sparc/bits/semid_ds_t.h | 15 +++
> sysdeps/unix/sysv/linux/x86/bits/semid_ds_t.h | 15 +++
> 10 files changed, 124 insertions(+), 7 deletions(-)
>
> diff --git a/bits/ipc.h b/bits/ipc.h
> index e2981fd5c3..9ac8485193 100644
> --- a/bits/ipc.h
> +++ b/bits/ipc.h
> @@ -29,7 +29,11 @@
> /* Control commands for `msgctl', `semctl', and `shmctl'. */
> #define IPC_RMID 0 /* remove identifier */
> #define IPC_SET 1 /* set `ipc_perm' options */
> -#define IPC_STAT 2 /* get `ipc_perm' options */
> +#if __TIMESIZE == 64 && __WORDSIZE == 32
> +# define IPC_STAT 0x102 /* Get `ipc_perm' options. */
> +#else
> +# define IPC_STAT 2 /* Get `ipc_perm' options. */
> +#endif
Why is this needed. Linux kernel seems to be returning EINVAL for this cmd-id
and
following fail for ARC.
FAIL: sysvipc/test-sysvmsg
FAIL: sysvipc/test-sysvsem
FAIL: sysvipc/test-sysvshm
Shouldn't this use the default __IPC_64 value which is 0 not 0x100.
>
> /* Special key values. */
> #define IPC_PRIVATE ((key_t) 0) /* private key */
> diff --git a/sysdeps/gnu/bits/ipc.h b/sysdeps/gnu/bits/ipc.h
> index 47df305e1c..328c11a0d7 100644
> --- a/sysdeps/gnu/bits/ipc.h
> +++ b/sysdeps/gnu/bits/ipc.h
> @@ -29,7 +29,11 @@
> /* Control commands for `msgctl', `semctl', and `shmctl'. */
> #define IPC_RMID 0 /* Remove identifier. */
> #define IPC_SET 1 /* Set `ipc_perm' options. */
> -#define IPC_STAT 2 /* Get `ipc_perm' options. */
> +#if __TIMESIZE == 64 && __WORDSIZE == 32
> +# define IPC_STAT 0x102 /* Get `ipc_perm' options. */
> +#else
> +# define IPC_STAT 2 /* Get `ipc_perm' options. */
> +#endif
> #ifdef __USE_GNU
> # define IPC_INFO3 /* See ipcs. */
> #endif
> diff --git a/sysdeps/unix/sysv/linux/bits/ipc.h
> b/sysdeps/unix/sysv/linux/bits/ipc.h
> index 085dd628ac..9de62f 100644
> --- a/sysdeps/unix/sysv/linux/bits/ipc.h
> +++ b/sysdeps/unix/sysv/linux/bits/ipc.h
> @@ -29,7 +29,11 @@
> /* Control commands for `msgctl', `semctl', and `shmctl'. */
> #define IPC_RMID 0 /* Remove identifier. */
> #define IPC_SET 1 /* Set `ipc_perm' options. */
> -#define IPC_STAT 2 /* Get `ipc_perm' options. */
> +#if __TIMESIZE == 64 && __WORDSIZE == 32
> +# define IPC_STAT 0x102 /* Get `ipc_perm' options. */
> +#else
> +# define IPC_STAT2 /* Get `ipc_perm' options. */
> +#endif
> #ifdef __USE_GNU
> # define IPC_INFO3 /* See ipcs. */
> #endif
> diff --git a/sysdeps/unix/sysv/linux/bits/semid_ds_t.h
> b/sysdeps/unix/sysv/linux/bits/semid_ds_t.h
> index d9d902ed0d..b135301356 100644
> --- a/sysdeps/unix/sysv/linux/bits/semid_ds_t.h
> +++ b/sysdeps/unix/sysv/linux/bits/semid_ds_t.h
> @@ -20,6 +20,21 @@
> # error "Never include directly; use
> instead."
> #endif
>
> +#if __WORDSIZE == 32
> +/* This is the "new" y2038 types defined after the 5.1 kernel. It allows
> + * the kernel to use {o,c}time{_high} values to support a 64-bit time_t. */
> +struct __semid_ds32 {
> + struct ipc_perm sem_perm; /* operation permission struct */
> + __syscall_ulong_t sem_otime; /* last semop() time */
> + __syscall_ulong_t sem_otime_high;/* last semop() time high */
> + __syscall_ulong_t sem_ctime; /* last time changed by semctl() */
> + __syscall_ulong_t sem_ctime_high;/* last time changed by semctl()
> high */
> + __syscall_ulong_t sem_nsems; /* number of semaphores in set */
> + __syscall_ulong_t __glibc_reserved3;
> + __syscall_ulong_t __glibc_reserved4;
> +};
> +#endif
> +
> /* Da
Re: sourceware account access
On 3/10/20 2:08 PM, Vineet Gupta wrote: > On 3/10/20 10:57 AM, Carlos O'Donell via Libc-alpha wrote: >> Please take a look at the following page: >> >> "Becoming a maintainer (developer)": >> https://sourceware.org/glibc/wiki/MAINTAINERS#Becoming_a_maintainer_.28developer.29 >> ~~~ >> 5. Ask for commit access. >> >> * Ask one of the project stewards to authorize your commit access. >> >> * If the project steward authorizes you for commit access follow these >> instructions to create a sourceware account with commit access to the >> glibc repository. >> ~~~ >> >> Joseph and I are both stewards. >> "Project stewards (GNU package maintainers)" >> https://sourceware.org/glibc/wiki/MAINTAINERS#Project_stewards_.28GNU_package_maintainers.29 >> >> I would be happy to authorize your commit access. >> >> I assume your intent is to be one of the machine maintainers for ARC? > > Yeah, this email was my indirect way of asking for commit access :-) > Indeed this is for ARC glibc machine maintainer. Please submit the request then and include my email. -- Cheers, Carlos. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: sourceware account access
On 3/10/20 10:57 AM, Carlos O'Donell via Libc-alpha wrote: > Please take a look at the following page: > > "Becoming a maintainer (developer)": > https://sourceware.org/glibc/wiki/MAINTAINERS#Becoming_a_maintainer_.28developer.29 > ~~~ > 5. Ask for commit access. > > * Ask one of the project stewards to authorize your commit access. > > * If the project steward authorizes you for commit access follow these > instructions to create a sourceware account with commit access to the > glibc repository. > ~~~ > > Joseph and I are both stewards. > "Project stewards (GNU package maintainers)" > https://sourceware.org/glibc/wiki/MAINTAINERS#Project_stewards_.28GNU_package_maintainers.29 > > I would be happy to authorize your commit access. > > I assume your intent is to be one of the machine maintainers for ARC? Yeah, this email was my indirect way of asking for commit access :-) Indeed this is for ARC glibc machine maintainer. Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: sourceware account access (was Re: [PATCH v3 01/17] gcc PR 88409: miscompilation due to missing cc clobber in longlong.h macros)
On 3/10/20 1:23 PM, Vineet Gupta wrote: > On 3/6/20 4:21 PM, Vineet Gupta wrote: >> >> BTW, I don't think I asked for commit access before. I just rechecked >> MAINTAINERS >> wiki page and seems like someone needs to grant me that. > > Hi Joseph, Carlos > > I'm trying to setup my sourceware account etc and the form below [1] needs > "email > address of person who approved request". Whats the typical procedure for > getting > that ? Please take a look at the following page: "Becoming a maintainer (developer)": https://sourceware.org/glibc/wiki/MAINTAINERS#Becoming_a_maintainer_.28developer.29 ~~~ 5. Ask for commit access. * Ask one of the project stewards to authorize your commit access. * If the project steward authorizes you for commit access follow these instructions to create a sourceware account with commit access to the glibc repository. ~~~ Joseph and I are both stewards. "Project stewards (GNU package maintainers)" https://sourceware.org/glibc/wiki/MAINTAINERS#Project_stewards_.28GNU_package_maintainers.29 I would be happy to authorize your commit access. I assume your intent is to be one of the machine maintainers for ARC? > Thx, > -Vineet > > [1] https://sourceware.org/cgi-bin/pdw/ps_form.cgi > -- Cheers, Carlos. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
sourceware account access (was Re: [PATCH v3 01/17] gcc PR 88409: miscompilation due to missing cc clobber in longlong.h macros)
On 3/6/20 4:21 PM, Vineet Gupta wrote: > > BTW, I don't think I asked for commit access before. I just rechecked > MAINTAINERS > wiki page and seems like someone needs to grant me that. Hi Joseph, Carlos I'm trying to setup my sourceware account etc and the form below [1] needs "email address of person who approved request". Whats the typical procedure for getting that ? Thx, -Vineet [1] https://sourceware.org/cgi-bin/pdw/ps_form.cgi 0x69D7F1DDE28AC25E.asc Description: 0x69D7F1DDE28AC25E.asc ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/4] ARC: handle DSP presence in HW
>From: Vineet Gupta >Sent: Saturday, March 7, 2020 03:12 >To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org >Cc: Alexey Brodkin; linux-ker...@vger.kernel.org >Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW > >On 3/5/20 12:02 PM, Eugeniy Paltsev wrote: >> In case of DSP extension presence in HW some instructions >> (related to integer multiply, multiply-accumulate, and divide >> operation) executes on this DSP execution unit. So their >> execution will depend on dsp configuration register (DSP_CTRL) >> >> As we want these instructions to execute the same way regardless >> of DSP presence we need to set DSP_CTRL properly. However this >> register can be modified bu any usersace app therefore any >> usersace may break kernel execution. >> >> Fix that by configure DSP_CTRL in CPU early code and in IRQs >> entries. > > How about below Good description, ACK. > "When DSP extensions are present, some of the regular integer instructions > such as > DIV, MACD etc are executed in the DSP unit with semantics alterable by flags > in > DSP_CTRL aux register. This register is writable by userspace and thus can > potentially affect corresponding instructions in kernel code, intentionally or > otherwise. So safegaurd kernel by effectively disabling DSP_CTRL upon bootup > and > every entry to kernel. > > Do note that for this config we simply zero out the DSP_CTRL reg assuming > userspace doesn't really care about DSP. The next patch caters to the DSP > aware > userspace which this actually saved/restored upon kernel entry." ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 2/4] ARC: handle DSP presence in HW
>From: Vineet Gupta >Sent: Saturday, March 7, 2020 03:12 >To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org >Cc: Alexey Brodkin; linux-ker...@vger.kernel.org >Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW > >On 3/5/20 12:02 PM, Eugeniy Paltsev wrote: >> In case of DSP extension presence in HW some instructions >> (related to integer multiply, multiply-accumulate, and divide >> operation) executes on this DSP execution unit. So their >> execution will depend on dsp configuration register (DSP_CTRL) >> >> As we want these instructions to execute the same way regardless >> of DSP presence we need to set DSP_CTRL properly. However this >> register can be modified bu any usersace app therefore any >> usersace may break kernel execution. >> >> Fix that by configure DSP_CTRL in CPU early code and in IRQs >> entries. > > How about below > > "When DSP extensions are present, some of the regular integer instructions > such as > DIV, MACD etc are executed in the DSP unit with semantics alterable by flags > in > DSP_CTRL aux register. This register is writable by userspace and thus can > potentially affect corresponding instructions in kernel code, intentionally or > otherwise. So safegaurd kernel by effectively disabling DSP_CTRL upon bootup > and > every entry to kernel. > > Do note that for this config we simply zero out the DSP_CTRL reg assuming > userspace doesn't really care about DSP. The next patch caters to the DSP > aware > userspace which this actually saved/restored upon kernel entry." >From: Vineet Gupta >Sent: Saturday, March 7, 2020 03:12 >To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org >Cc: Alexey Brodkin; linux-ker...@vger.kernel.org >Subject: Re: [PATCH v2 2/4] ARC: handle DSP presence in HW > >On 3/5/20 12:02 PM, Eugeniy Paltsev wrote: >> In case of DSP extension presence in HW some instructions >> (related to integer multiply, multiply-accumulate, and divide >> operation) executes on this DSP execution unit. So their >> execution will depend on dsp configuration register (DSP_CTRL) >> >> As we want these instructions to execute the same way regardless >> of DSP presence we need to set DSP_CTRL properly. However this >> register can be modified bu any usersace app therefore any >> usersace may break kernel execution. >> >> Fix that by configure DSP_CTRL in CPU early code and in IRQs >> entries. > > How about below > > "When DSP extensions are present, some of the regular integer instructions > such as > DIV, MACD etc are executed in the DSP unit with semantics alterable by flags > in > DSP_CTRL aux register. This register is writable by userspace and thus can > potentially affect corresponding instructions in kernel code, intentionally or > otherwise. So safegaurd kernel by effectively disabling DSP_CTRL upon bootup > and > every entry to kernel. > > Do note that for this config we simply zero out the DSP_CTRL reg assuming > userspace doesn't really care about DSP. The next patch caters to the DSP > aware > userspace which this actually saved/restored upon kernel entry." ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
