linux-kernel - Re: 2.6.38.2 breaks suspend to disk

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: <4D9607E8.2040500@kernel.org>
Date:	Fri, 01 Apr 2011 10:14:16 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Ingo Molnar <mingo@...hat.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Michael Leun <lkml20101129@...ton.leun.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Mike Pagano <mpagano@...too.org>
Subject: Re: 2.6.38.2 breaks suspend to disk

On 04/01/2011 09:22 AM, H. Peter Anvin wrote:
> On 04/01/2011 09:06 AM, Yinghai Lu wrote:
>> Index: linux-2.6/arch/x86/kernel/setup.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/setup.c
>> +++ linux-2.6/arch/x86/kernel/setup.c
>> @@ -294,10 +294,17 @@ static void __init init_gbpages(void)
>>       else
>>           direct_gbpages = 0;
>>   }
>> +static void __init store_mmu_cr4(void)
>> +{
>> +    mmu_cr4_features = read_cr4();
>> +}
>>   #else
>>   static inline void init_gbpages(void)
>>   {
>>   }
>> +static void __init store_mmu_cr4(void)
>> +{
>> +}
>>   static void __init cleanup_highmap(void)
>>   {
>>   }
>> @@ -929,6 +936,8 @@ void __init setup_arch(char **cmdline_p)
>>       /* max_pfn_mapped is updated here */
>>       max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<<PAGE_SHIFT);
>>       max_pfn_mapped = max_low_pfn_mapped;
>> +    /* after init_memory_mapping updating cr4*/
>> +    store_mmu_cr4();
>>
>>   #ifdef CONFIG_X86_64
>>       if (max_pfn>  max_low_pfn) {
>
> This looks really, really, really wrong.
>
> Why the heck should we save and restore CR4 only for x86-64?

Peter, this patch just restoring old sequence. If you think 32 bit should do same thing, we can do that in another patch.

Also after closing looking, Stefano's v1 patch should be ok too.
because init_memory_mapping is using set_in_cr4(...) and it will update mmu_cr4_features at the same time.

Thanks

Yinghai

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