linux-kernel - Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)

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:	Thu, 26 Mar 2015 20:13:59 +0800
From:	"Li, Aubrey" <aubrey.li@...ux.intel.com>
To:	Huang Ying <ying.huang@...el.com>
CC:	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, LKP ML <lkp@...org>
Subject: Re: [LKP] [x86/platform, acpi] 7486341a98f: genirq: Flags mismatch
 irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)

On 2015/3/25 15:22, Huang Ying wrote:
> [   28.745155] genirq: Flags mismatch irq 8. 00000080 (mmc0) vs. 00000000 (rtc0)

okay, I replicated this on my side now.

Firstly, I don't think the patch did anything wrong. However, the patch
exposes a few issues FWICT currently:

- Should we enable RTC Alarm the kind of Fixed hardware event in
hardware-reduced ACPI mode? I found RTC required registers in ACPI PM
block are not valid(register address = 0)

- I checked RTC device in ACPI table, there is no interrupt resource
under RTC(firmware bug?), So irq 8 should be a hardcoded number. The
question is, shouldn't we update bitmap of allocated_irqs here? Or we
assume irq0~15 is reserved? If we assume IRQ0~15 is reserved, then
requesting IRQ8 without updating bitmap of allocated_irqs is fine.

- Because we don't update bitmap of allocated_irqs when RTC request
IRQ8, so when MMC driver allocate irq resource, it's possible it gets
irq8, so we saw "genirq: Flags mismatch irq 8. 00000080 (mmc0) vs.
00000000 (rtc0)". So here is another question, when we dynamically
allocate irq from irq domain, shouldn't we start from IRQ16? Yes, if
allocated_irqs bitmap is updated, then it should be fine if we start
from IRQ1.

What the patch does is, it changes the behavior of how we allocate irq
from irq domain. Previously we have legacy IRQs so we statically assign
IRQ numbers for IOAPICs to host legacy IRQs, and now we allocate every
IRQ dynamically.

For me I think I can deliver a patch against RTC driver to update
allocated_irqs bitmap, also, we should free irq when we found RTC ACPI
registers are not valid.

Certainly I'm open to any suggestions.

Thanks,
-Aubrey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/