Re: [PATCH v3 01/17] gcc PR 88409: miscompilation due to missing cc clobber in longlong.h macros

2020-03-10 Thread Vineet Gupta
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

2020-03-10 Thread Vineet Gupta
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

2020-03-10 Thread Carlos O'Donell
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

2020-03-10 Thread Vineet Gupta
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)

2020-03-10 Thread Carlos O'Donell
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)

2020-03-10 Thread Vineet Gupta
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

2020-03-10 Thread Eugeniy Paltsev
>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

2020-03-10 Thread Eugeniy Paltsev
>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