On Mon, Nov 19, 2012 at 10:57 AM, John Stultz wrote:
> On 11/19/2012 09:45 AM, Kees Cook wrote:
>>
>> On Mon, Nov 19, 2012 at 9:23 AM, John Stultz wrote:
>>>
>>> On 11/18/2012 12:09 PM, Kees Cook wrote:
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz
wrote:
>
> Yea, I wanted
On 11/19/2012 09:45 AM, Kees Cook wrote:
On Mon, Nov 19, 2012 at 9:23 AM, John Stultz wrote:
On 11/18/2012 12:09 PM, Kees Cook wrote:
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
Yea, I wanted to revisit this, because it is an odd case.
We don't want to call getnstimeofday() while th
On Mon, Nov 19, 2012 at 9:23 AM, John Stultz wrote:
> On 11/18/2012 12:09 PM, Kees Cook wrote:
>>
>> On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
>>>
>>> Yea, I wanted to revisit this, because it is an odd case.
>>>
>>> We don't want to call getnstimeofday() while the timekeeping code is
>
On 11/18/2012 12:09 PM, Kees Cook wrote:
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
Yea, I wanted to revisit this, because it is an odd case.
We don't want to call getnstimeofday() while the timekeeping code is
suspended, since the clocksource cycle_last value may be invalid if the
ha
On Fri, Nov 16, 2012 at 7:16 PM, John Stultz wrote:
> Yea, I wanted to revisit this, because it is an odd case.
>
> We don't want to call getnstimeofday() while the timekeeping code is
> suspended, since the clocksource cycle_last value may be invalid if the
> hardware was reset during suspend. K
On 11/16/2012 06:53 PM, Anton Vorontsov wrote:
On Fri, Nov 09, 2012 at 05:26:53PM -0800, Kees Cook wrote:
[]
@@ -171,7 +171,13 @@ static size_t ramoops_write_kmsg_hdr(struct
persistent_ram_zone *prz)
struct timeval timestamp;
size_t len;
- do_gettimeofday(×tamp);
+
On Fri, Nov 09, 2012 at 05:26:53PM -0800, Kees Cook wrote:
[]
> >> @@ -171,7 +171,13 @@ static size_t ramoops_write_kmsg_hdr(struct
> >> persistent_ram_zone *prz)
> >> struct timeval timestamp;
> >> size_t len;
> >>
> >> - do_gettimeofday(×tamp);
> >> + /* Handle dum
On 11/05/2012 02:00 PM, Kees Cook wrote:
We must not call timekeeping functions unless they are available. If we dump
before they have resumed, avoid a WARN_ON by setting the timestamp to 0.
Since the "ram" pstore driver can be a module, we must have
timekeeping_suspended exported.
Reported-by:
On Fri, Nov 9, 2012 at 4:56 PM, John Stultz wrote:
> On 11/05/2012 02:00 PM, Kees Cook wrote:
>>
>> We must not call timekeeping functions unless they are available. If we
>> dump
>> before they have resumed, avoid a WARN_ON by setting the timestamp to 0.
>>
>> Since the "ram" pstore driver can be
We must not call timekeeping functions unless they are available. If we dump
before they have resumed, avoid a WARN_ON by setting the timestamp to 0.
Since the "ram" pstore driver can be a module, we must have
timekeeping_suspended exported.
Reported-by: Doug Anderson
Cc: Anton Vorontsov
Cc: Jo
10 matches
Mail list logo
