From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753026AbcGSI72 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 19 Jul 2016 04:59:28 -0400
Received: from mga04.intel.com ([192.55.52.120]:25644 "EHLO mga04.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751953AbcGSI70 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 19 Jul 2016 04:59:26 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.28,388,1464678000"; 
   d="scan'208";a="141749333"
From: Chen Yu <yu.c.chen@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
        "Rafael J. Wysock" <rjw@rjwysocki.net>,
        Linux PM list <linux-pm@vger.kernel.org>,
        Linux Kernel list <linux-kernel@vger.kernel.org>,
        "Stable # 3 . 17+" <stable@vger.kernel.org>
Subject: Re: [PATCH][v2] timekeeping: Fix memory overwrite of sleep_time_bin
 array
References: <1468903861-12487-1-git-send-email-yu.c.chen@intel.com>
 <alpine.DEB.2.11.1607191031260.3596@nanos>
Message-ID: <578DEDBB.9030602@intel.com>
Date: Tue, 19 Jul 2016 17:07:07 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1607191031260.3596@nanos>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Thomas,

On 2016年07月19日 16:36, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Chen Yu wrote:
>
>> It is reported the hibernation fails at 2nd attempt, which
>> hangs at hibernate() -> syscore_resume() -> i8237A_resume()
>> -> claim_dma_lock(), because the lock has already been taken.
>> However there is actually no other process would like to grab
>> this lock on that problematic platform.
>>
>> Further investigation shows that, the problem is caused by setting
>> /sys/power/pm_trace to 1 before the 1st hibernation, since once
>> pm_trace is enabled, the rtc becomes an unmeaningful value after resumed,
> So why is the RTC value useless if pm_trace is enabled? I really have a hard
> time to understand why pm_trace would affect the sleep time readout from RTC.
>
> Thanks,
>
> 	tglx
After pm_trace is enabled, during system suspend/hibernate, the hash name of
each devices will be written to rtc, so  the rtc value depends on what 
we write in last suspend
round, thus pm_trace can be  used for diagnose which device failed to 
suspend(eg, the suspending
on this device hang the system, we reboot the system , and check rtc 
hash value).

  In our case, after first hibernate/resume round,  we found our current 
system time
is  at  2117, so syscore_resume -> timekeeping_resume :
__timekeeping_inject_sleeptime(tk, &ts_delta)
would inject a quite large delta :  2117 - 2017 year, thus the 
sleep_time_bin is overflow.

thanks,
Yu