Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH 06/13] arc: define syscall_get_arch()
From:   Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <456a69c6e01a6ab5b1af6d459a249388f8b4c1f5.camel@synopsys.com>
Date:   Fri, 9 Nov 2018 07:56:12 -0800
Cc:     "luto@kernel.org" <luto@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-audit@redhat.com" <linux-audit@redhat.com>,
        "vineet.gupta1@synopsys.com" <vineet.gupta1@synopsys.com>,
        "eparis@redhat.com" <eparis@redhat.com>,
        "ldv@altlinux.org" <ldv@altlinux.org>,
        "linux-snps-arc@lists.infradead.org" 
        <linux-snps-arc@lists.infradead.org>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "lineprinter@altlinux.org" <lineprinter@altlinux.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6CF3942-3307-431F-B76C-B550BB48F472@amacapital.net>
References: <20181109031605.GF21511@altlinux.org> <e729da9ed78b6b62463a27d3012ac63c7b66be08.camel@synopsys.com> <CALCETrUzfOcLYDUW6s1Ra2xduDCQSbscKBw=vApCP2HNmfDmMw@mail.gmail.com> <456a69c6e01a6ab5b1af6d459a249388f8b4c1f5.camel@synopsys.com>
To:     Alexey Brodkin <alexey.brodkin@synopsys.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 9, 2018, at 7:27 AM, Alexey Brodkin <alexey.brodkin@synopsys.com> w=
rote:
>=20
> Hi Andy,
>=20
>> On Fri, 2018-11-09 at 07:17 -0800, Andy Lutomirski wrote:
>> On Fri, Nov 9, 2018 at 6:22 AM Alexey Brodkin
>> <alexey.brodkin@synopsys.com> wrote:
>>> Hi Dmitry,
>>>=20
>>>> On Fri, 2018-11-09 at 06:16 +0300, Dmitry V. Levin wrote:
>>>> syscall_get_arch() is required to be implemented on all architectures
>>>> that use tracehook_report_syscall_entry() in order to extend
>>>> the generic ptrace API with PTRACE_GET_SYSCALL_INFO request.
>>>>=20
>>>> Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
>>>> ---
>>>> arch/arc/include/asm/syscall.h | 6 ++++++
>>>> include/uapi/linux/audit.h     | 1 +
>>>> 2 files changed, 7 insertions(+)
>>>=20
>>> [snip]
>>>=20
>>>> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
>>>> index 818ae690ab79..a7149ceb5b98 100644
>>>> --- a/include/uapi/linux/audit.h
>>>> +++ b/include/uapi/linux/audit.h
>>>> @@ -375,6 +375,7 @@ enum {
>>>>=20
>>>> #define AUDIT_ARCH_AARCH64   (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARC=
H_LE)
>>>> #define AUDIT_ARCH_ALPHA     (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_=
LE)
>>>> +#define AUDIT_ARCH_ARC               (EM_ARC)
>>>=20
>>> Similarly here we need to have:
>>> ---------------------------->8-----------------------------
>>> +#define AUDIT_ARCH_ARC         (EM_ARC|EM_ARCV2)
>>> ---------------------------->8-----------------------------
>>>=20
>>=20
>> Huh?  How does the bitwise or of two ELF machine codes make any sense?
>=20
> Oops... I didn't read examples of AUDIT_ARCH_ALPHA above :(
> Indeed that was stupid.
>=20
> But what would be a proper fix then?
>=20
> Something like that?
> ---------------------------->8-----------------------------
> #define AUDIT_ARCH_ARC               (EM_ARC)
> #define AUDIT_ARCH_ARCV2             (EM_ARCV2)
>=20
>=20
> static inline int syscall_get_arch(void)
> {
> #ifdef __ARC700__
>       return AUDIT_ARCH_ARC;
> #else
>       return AUDIT_ARCH_ARCV2;
> #endif
> }
> ---------------------------->8-----------------------------
>=20

Maybe, but I know basically nothing about ARC.  Is the syscall numbering or c=
alling convention different on ARC vs ARCv2?=