linux-kernel - Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87ob8agjlo.fsf@xmission.com>
Date:	Tue, 03 Sep 2013 05:44:51 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc:	Don Zickus <dzickus@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>, Gleb Natapov <gleb@...hat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Joerg Roedel <joro@...tes.org>, x86@...nel.org,
	stable@...r.kernel.org, Marcelo Tosatti <mtosatti@...hat.com>,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>,
	Ingo Molnar <mingo@...hat.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>,
	yrl.pp-manager.tt@...achi.com,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Seiji Aguchi <seiji.aguchi@....com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] [BUGFIX] crash/ioapic: Prevent crash_kexec() from deadlocking of ioapic_lock

Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com> writes:

> (2013/09/03 9:12), Eric W. Biederman wrote:
>>>>> Then again looking at the output of the latest dmesg, it seems the IO APIC
>>>>> is initialized way before the tsc is calibrated.  So I am not sure what
>>>>> needed to get done or what interrupts are needed before the IO APIC gets
>>>>> initialized.
>>>>
>>>> The practical issue is that jiffies was calibrated off of the PIT timer
>>>> if I recall.  But that is all old news.
>>>
>>> Are the jiffies calibration codes calibrate_delay()?
>>> It seems that the jiffies calibration have not used PIT in 2005
>>> according to 8a9e1b0.
>> 
>> Exactly.  That was the original reason why we put in the code to
>> disable the IOAPIC and the local apic.  There might have been other
>> reasons but that was the primary.
>
> Thanks, but I have still a question for jiffies calibration.
>
> When kernel boots, calibrate_delay_direct() will be called in
> calibrate_delay() for calculating loops_per_jiffy.  Then,
> calibrate_delay_direct() waits until jiffies is incremented.
> I think this means PIT or HPET is still used for the calibration.
> Is there something wrong with my understanding?
> If wrong, how is jiffies incremented?

Things have definitely changed, and I believe part of what you are
seeing is the path when things are not calibrated by an arch specific
means.

Ulimately the issue was not that we waited (or possibly still wait) for
a timer interrupt to calibrate the delay loop.  The problem was that we
had initialized the interrupt controller in PIC mode (when the kernel
did not later use the interrupt controller in PIC mode) to receive the
interrupt.

The actual impetus for getting the last of the bugs shaken out is that
we have subarchitectures on x86 that do no support interrupt controllers
in PIC mode at all.

Recently the code seems to get reorganized every other year and I loose
track of the details of which piece of code is doing what, but the
general gist remains.

The key thing to look for is that we initialize the interrupt
controllers in apic mode before we receive interrupts.  That is really
the only thing that matters, and for a long time the calibration of the
delay loop was the one notable exception.

> OK. In order to judge whether a kernel version as crashdump kernel is
> usable or not, I want to understand why we can remove disable_IO_APIC
> in detail.

That sounds like responsible engineering.

>> At the same time it has always been the targets kernel's responsibility
>> to sort out the hardware devices unless it can't possibily do it.  And
>> apics for the longest time were very very hard to reset in the target
>> kernel, but now that they are not.  It makes sense for time permitting
>> to remove the now unnecessary code in the crashing kernel.  Because
>> ultimately the less code we have the fewer possible ways we can fail
>> in a known broken kernel.
>
> Yes, I agree with you.

Eric

--
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/