linux-kernel - Re: Hibernate resume bug around 3,18-rc2

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:	Mon, 23 Nov 2015 16:11:26 +0200
From:	vasvir@....demokritos.gr
To:	"Juergen Gross" <jgross@...e.com>
Cc:	linux-kernel@...r.kernel.org, "Toshi Kani" <toshi.kani@...com>,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: Hibernate resume bug around 3,18-rc2 - Full PAT support

On 11/20/2015 02:23 PM, Juergen Gross wrote:

>
> As the BIOS obviously isn't disabling MTRR I don't think we have
> to go that route any longer.

ok.

>>
>> In the weekend I will return to 3.18-rc2 and I will try to verify my
>> bisection is correct. Double guessing your self is a terrible thing...
>
> Thanks.
>
>> I will also try with nopat and I will run dmesg | grep -i mtr and post
>> results
>>
>> Unless you have any other suggestions...
>

I hit a very big problem here. I did
$git checkout 773fed910d41e443e495a6bfa9ab1c2b7b13e012
$make (with gcc 4.8 - as all my tests)

and the resulting kernel in unbootable hunging in "Loading initial
ramdisk..." second line of the kernel boot

That means my bisection is not good because this release is marked as good.

So now I am at loss.

As I said I followed https://wiki.debian.org/DebianKernel/GitBisect

I notice now that the article suggest a step
  $make oldconfig

I did it once at the start of the bisection and then answering the default
(Enter) in all config questions.

> I think we have to find out where the kernel is really hanging. Do you
> have any chance to trigger a NMI?

I am googling about it.

>
> Looking into suspend/resume code I found a strange inconsistency for
> the lapic handling:
>
> lapic_suspend()
> {
> ...
> #ifdef CONFIG_X86_THERMAL_VECTOR
>         if (maxlvt >= 5)
>                 apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
> #endif
> ...
> }
>
> lapic_resume()
> {
> ...
> #if defined(CONFIG_X86_MCE_INTEL)
>         if (maxlvt >= 5)
>                 apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
> #endif
> ...
> }
>
> and comparing that to:
>
> clear_local_APIC()
> {
> ...
> #ifdef CONFIG_X86_THERMAL_VECTOR
>         if (maxlvt >= 5) {
>                 v = apic_read(APIC_LVTTHMR);
>                 apic_write(APIC_LVTTHMR, v | APIC_LVT_MASKED);
>         }
> #endif
> #ifdef CONFIG_X86_MCE_INTEL
>         if (maxlvt >= 6) {
>                 v = apic_read(APIC_LVTCMCI);
>                 if (!(v & APIC_LVT_MASKED))
>                         apic_write(APIC_LVTCMCI, v | APIC_LVT_MASKED);
>         }
> #endif
> ...
> }
>

Ok I will send the .config when I get back home. I have all kernels I
build in .deb archive. The problem is that the debian kernel build
procedure does not hold somewhere in the deb file the git commit hash.

Fow which kernel would you care to see the config? 4.3?

     Vassilis



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