linux-kernel - Re: Adjust interrupt Priority for ARM64 GIC

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]

Message-ID: <003822ee-c43b-9572-7a64-fda049ecb05f@huawei.com>
Date:   Tue, 1 Sep 2020 16:48:08 +0800
From:   Dongjiu Geng <gengdongjiu@...wei.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     <linux-kernel@...r.kernel.org>
Subject: Re: Adjust interrupt Priority for ARM64 GIC



On 2020/9/1 15:48, Marc Zyngier wrote:
> Hi Dongjiu,
> 
> In the future, please use my kernel.org address, as I don't work
> for ARM anymore, and would have missed this email if I wasn't pointed
> to it.
> 
> On 2020-08-14 18:10, Dongjiu Geng wrote:
>> Hi Marc,
>>    In the Linux kernel, we can not adjust the  interrupt Priority, For
>> all the interrupts, the interrupt Priority are fixed to 0xa0.
>> In some scenarios, it needs to change the Priority. so I want to
>> upstream a serie patch to support to change the Priority through
>> procfs. do you agree I upstream this feature? thanks~
> 
> No, that's not something I would ever consider, and for multiple
> reasons:
> 
> - Linux only supports a single priority, meaning that interrupts are
>   themselves aren't preemptable. Dealing with things like (pseudo) NMI
>   is invasive enough, and I can't see a good reason to relax the
>   single priority requirement.
> 
> - Building on top of the above, the whole scheduler and locking model
>   relies on the non-preemptable property of an interrupt.
> 
> - I cannot see a good reason to leave the priority control to userspace.
>   That's a sure recipe for userspace-controlled livelocks.
> 
> Now, I'm sure you want to introduce this for a reason, and you are not
> explaining it ("some scenarios" doesn't quite cut it). If you care to
> explain these "scenarios", maybe there is something we can do.
Marc，
    Thanks for answer.
    In the real-time system(RTOS), we want the timer tick irq is responded as
soon as possible to trigger kernel do task schedule. Non-preemptable  IRQ decreases the Real-Time Performance of Real-Time Operating System

> 
> But please don't waste time implementing any sort of priority change,
> there is no way I'll consider it as such.
> 
> Thanks,
> 
>         M.