linux-kernel - Re: [PATCH v2] powerpc/traps: Enhance readability for trap types

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] [day] [month] [year] [list]

Date:   Mon, 5 Apr 2021 20:10:07 +0800
From:   Xiongwei Song <sxwjean@...com>
To:     Nicholas Piggin <npiggin@...il.com>
Cc:     Michael Ellerman <mpe@...erman.id.au>,
        Segher Boessenkool <segher@...nel.crashing.org>, aik@...abs.ru,
        akpm@...ux-foundation.org, alistair@...ple.id.au,
        aneesh.kumar@...ux.ibm.com, atrajeev@...ux.vnet.ibm.com,
        benh@...nel.crashing.org,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        haren@...ux.ibm.com, jniethe5@...il.com, john.ogness@...utronix.de,
        kan.liang@...ux.intel.com, kjain@...ux.ibm.com,
        kvm-ppc@...r.kernel.org, leobras.c@...il.com,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        maddy@...ux.ibm.com, mikey@...ling.org, msuchanek@...e.de,
        oleg@...hat.com, paulus@...ba.org, peterx@...hat.com,
        peterz@...radead.org, pmladek@...e.com,
        ravi.bangoria@...ux.ibm.com, rppt@...nel.org,
        Xiongwei Song <sxwjean@...il.com>
Subject: Re: [PATCH v2] powerpc/traps: Enhance readability for trap types


Regards,
Xiongwei




> On Apr 1, 2021, at 4:01 PM, Nicholas Piggin <npiggin@...il.com> wrote:
> 
> Excerpts from Michael Ellerman's message of April 1, 2021 12:39 pm:
>> Segher Boessenkool <segher@...nel.crashing.org> writes:
>>> On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote:
>>>> So perhaps:
>>>> 
>>>>  EXC_SYSTEM_RESET
>>>>  EXC_MACHINE_CHECK
>>>>  EXC_DATA_STORAGE
>>>>  EXC_DATA_SEGMENT
>>>>  EXC_INST_STORAGE
>>>>  EXC_INST_SEGMENT
>>>>  EXC_EXTERNAL_INTERRUPT
>>>>  EXC_ALIGNMENT
>>>>  EXC_PROGRAM_CHECK
>>>>  EXC_FP_UNAVAILABLE
>>>>  EXC_DECREMENTER
>>>>  EXC_HV_DECREMENTER
>>>>  EXC_SYSTEM_CALL
>>>>  EXC_HV_DATA_STORAGE
>>>>  EXC_PERF_MONITOR
>>> 
>>> These are interrupt (vectors), not exceptions.  It doesn't matter all
>>> that much, but confusing things more isn't useful either!  There can be
>>> multiple exceptions that all can trigger the same interrupt.
>> 
>> Yeah I know, but I think that ship has already sailed as far as the
>> naming we have in the kernel.
> 
> It has, but there are also several other ships also sailing in different 
> directions. It could be worse though, at least they are not sideways in 
> the Suez.
> 
>> We have over 250 uses of "exc", and several files called "exception"
>> something.
>> 
>> Using "interrupt" can also be confusing because Linux uses that to mean
>> "external interrupt".
>> 
>> But I dunno, maybe INT or VEC is clearer? .. or TRAP :)
> 
> We actually already have defines that follow Segher's suggestion, it's 
> just that they're hidden away in a KVM header.
> 
> #define BOOK3S_INTERRUPT_SYSTEM_RESET   0x100
> #define BOOK3S_INTERRUPT_MACHINE_CHECK  0x200
> #define BOOK3S_INTERRUPT_DATA_STORAGE   0x300
> #define BOOK3S_INTERRUPT_DATA_SEGMENT   0x380
> #define BOOK3S_INTERRUPT_INST_STORAGE   0x400
> #define BOOK3S_INTERRUPT_INST_SEGMENT   0x480
> #define BOOK3S_INTERRUPT_EXTERNAL       0x500
> #define BOOK3S_INTERRUPT_EXTERNAL_HV    0x502
> #define BOOK3S_INTERRUPT_ALIGNMENT      0x600
> 
> It would take just a small amount of work to move these to general 
> powerpc header, add #ifdefs for Book E/S where the numbers differ,
> and remove the BOOK3S_ prefix.
> 
> I don't mind INTERRUPT_ but INT_ would be okay too. VEC_ actually
> doesn't match what Book E does (which is some weirdness to map some
> of them to match Book S but not all, arguably we should clean that
> up too and just use vector numbers consistently, but the INTERRUPT_
> prefix would still be valid if we did that).
> 
> BookE KVM entry will still continue to use a different convention
> there so I would leave all those KVM defines in place for now, we
> might do another pass on them later.

Thanks for the comments. 

> 
> Thanks,
> Nick