linux-kernel - Re: [PATCH v4 11/23] powerpc/syscall: Rename syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 2 Feb 2021 07:58:25 +0100
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Nicholas Piggin <npiggin@...il.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        David Laight <David.Laight@...LAB.COM>,
        Michael Ellerman <mpe@...erman.id.au>,
        "msuchanek@...e.de" <msuchanek@...e.de>,
        Paul Mackerras <paulus@...ba.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH v4 11/23] powerpc/syscall: Rename syscall_64.c into
 syscall.c



Le 02/02/2021 à 07:38, Nicholas Piggin a écrit :
> Excerpts from Christophe Leroy's message of February 2, 2021 4:15 pm:
>>
>>
>> Le 28/01/2021 à 00:50, Nicholas Piggin a écrit :
>>> Excerpts from David Laight's message of January 26, 2021 8:28 pm:
>>>> From: Nicholas Piggin
>>>>> Sent: 26 January 2021 10:21
>>>>>
>>>>> Excerpts from Christophe Leroy's message of January 26, 2021 12:48 am:
>>>>>> syscall_64.c will be reused almost as is for PPC32.
>>>>>>
>>>>>> Rename it syscall.c
>>>>>
>>>>> Could you rename it to interrupt.c instead? A system call is an
>>>>> interrupt, and the file now also has code to return from other
>>>>> interrupts as well, and it matches the new asm/interrupt.h from
>>>>> the interrupts series.
>>>>
>>>> Hmmm....
>>>>
>>>> That might make it harder for someone looking for the system call
>>>> entry code to find it.
>>>
>>> It's very grep'able.
>>>
>>>> In some sense interrupts are the simpler case.
>>>>
>>>> Especially when comparing with other architectures which have
>>>> special instructions for syscall entry.
>>>
>>> powerpc does have a special instruction for syscall, and it causes a
>>> system call interrupt.
>>>
>>> I'm not sure about other architectures, but for powerpc its more
>>> sensible to call it interrupt.c than syscall.c.
>>
>> Many other architectures have a syscall.c but for a different purpose: it contains arch specific
>> system calls. We have that in powerpc as well, it is called syscalls.c
>>
>> So to avoid confusion, I'll rename it. But I think "interrupt" is maybe not the right name. An
>> interrupt most of the time refers to IRQ.
> 
> That depends what you mean by interrupt and IRQ.
> 
> Linux kind of considers any asynchronous maskable interrupt an irq
> (local_irq_disable()). But if you say irq it's more likely to mean
> a device interrupt, and "interrupt" usually refres to the asynch
> ones.
> 
> But Linux doesn't really assign names to synchronous interrupts in
> core code. It doesn't say they aren't interrupts, it just doesn't
> really have a convention for them at all.
> 
> Other architectures e.g., x86 also have things like interrupt
> descriptor table for synchronous interrupts as well. That's where
> I got the interrupt wrappers code from actually.
> 
> So it's really fine to use the proper arch-specific names for things
> in arch code. I'm trying to slowly change names from exception to
> interrupt.
> 
>> For me system call is not an interrupt in the way it
>> doesn't unexpectedly interrupt a program flow. In powerpc manuals it is generally called exceptions,
>> no I'm more inclined to call it exception.c
> 
> Actually that's backwards. Powerpc manuals (at least the one I look at)
> calls them all interrupts including system calls, and also the system
> call interrupt is actually the only one that doesn't appear to be
> associated with an exception.
> 
> Also there is no distinction about expecte/unexpected -- a data storage
> interrupt is expected if you access a location without the right access
> permissions for example, but it is still an interrupt.
> 
> These handlers very specifically deal with the change to execution flow
> (i.e., the interrupt), they do *not* deal with the exception which may
> be associated with it (that is the job of the handler).
> 
> And on the other hand you can deal with exceptions in some cases without
> taking an interrupt at all. For example if you had MSR[EE]=0 you could
> change the decrementer or execute msgclr or change HMER SPR etc to clear
> various exceptions without ever taking the interrupt.
> 

Ok, let's call it interrupt.c then, to be consistant with the interrupt wrapper story.

Christophe