linux-kernel - Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs

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, 06 Jun 2017 16:20:06 +0530
From:   kgunda@...eaurora.org
To:     Stephen Boyd <sboyd@...eaurora.org>
Cc:     Abhijeet Dharmapurikar <adharmap@...eaurora.org>,
        Subbaraman Narayanamurthy <subbaram@...eaurora.org>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        David Collins <collinsd@...eaurora.org>,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        adharmap@...cinc.com, aghayal@....qualcomm.com,
        linux-arm-msm-owner@...r.kernel.org
Subject: Re: [PATCH V1 05/15] spmi: pmic-arb: cleanup unrequested irqs

On 2017-05-31 07:27, Stephen Boyd wrote:
> On 05/30, Kiran Gunda wrote:
>> From: Abhijeet Dharmapurikar <adharmap@...eaurora.org>
>> 
>> We see a unmapped irqs trigger right around bootup. This could
>> likely be because the bootloader exited leaving the interrupts
>> in an unknown or unhandled state.  Ack and mask the interrupt
>> if one is found. A request_irq later will unmask it and also
>> setup proper mapping structures.
> 
> Do we have systems where this is causing an interrupt storm due
> to a level high interrupt or something? Just plain acking and
> masking irqs at boot if we don't have an irq descriptor created
> yet doesn't sound like a good idea, because we'll lose all
> interrupts that happen before this driver probes?
> 
Yes. There were instances of an interrupt storm without this patch.
There is an RT_STATUS register in the  peripheral address space which
maintains the real time state and can be read by the client driver
before it registers for the irq. Few client drivers such as charger
already doing this.
>> 
>> Also the current driver ensures that no read/write transaction
>> is in progress while it makes changes to the interrupt regions.
>> This is not necessary because read/writes over spmi and arbiter
>> interrupt control are independent operations. Hence, remove the
>> synchronized accesses to interrupt region.
> 
> That's another patch for this paragraph.
This patch is already pulled in to Greg's tree.