On Tue, Aug 20, 2019 at 12:20 AM Kees Cook wrote:
>
> On Sun, Aug 18, 2019 at 09:58:16AM -0700, Deepa Dinamani wrote:
> > Leaving granularity at 1ns because it is dependent on the specific
> > attached backing pstore module. ramoops has microsecond resolution.
> >
> > Fix the readback of ramoops
On Tue, Aug 20, 2019 at 9:28 AM Matthew Wilcox wrote:
>
> On Sun, Aug 18, 2019 at 09:58:05AM -0700, Deepa Dinamani wrote:
> > Note that the min timestamp is assumed to be
> > 01 Jan 1970 00:00:00 (Unix epoch). This is consistent
> > with the way we convert timestamps in adfs_adfs2unix_time().
>
>
On Sun, Aug 18, 2019 at 09:58:05AM -0700, Deepa Dinamani wrote:
> Note that the min timestamp is assumed to be
> 01 Jan 1970 00:00:00 (Unix epoch). This is consistent
> with the way we convert timestamps in adfs_adfs2unix_time().
That's not actually correct. RISC OS timestamps are centiseconds
I see no problems for BFS.
Acked-By: Tigran Aivazian
On Sun, 18 Aug 2019 at 17:59, Deepa Dinamani wrote:
> Fill in the appropriate limits to avoid inconsistencies
> in the vfs cached inode times when timestamps are
> outside the permitted range.
>
> Even though some filesystems are read-only,
On Sunday, 2019-08-18 18:58 Deepa Dinamani wrote:
> Fill in the appropriate limits to avoid inconsistencies
> in the vfs cached inode times when timestamps are
> outside the permitted range.
>
> Even though some filesystems are read-only, fill in the
> timestamps to reflect the on-disk
On Sun, Aug 18, 2019 at 09:58:16AM -0700, Deepa Dinamani wrote:
> Leaving granularity at 1ns because it is dependent on the specific
> attached backing pstore module. ramoops has microsecond resolution.
>
> Fix the readback of ramoops fractional timestamp microseconds,
> which has incorrectly
