[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D413889851@USINDEM103.corp.hds.com>
Date: Thu, 25 Oct 2012 20:03:49 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: Mike Waychison <mikew@...gle.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"Luck, Tony (tony.luck@...el.com)" <tony.luck@...el.com>,
"Matthew Garrett (mjg@...hat.com)" <mjg@...hat.com>,
"dzickus@...hat.com" <dzickus@...hat.com>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>,
Satoru Moriya <satoru.moriya@....com>
Subject: RE: [PATCH v2 3/5] efi_pstore: Remove a logic erasing entries from
a write callback to hold multiple logs
> > - list_del(&found->list);
> > + sprintf(name, "dump-type%u-%u-%lu", type, part,
> > + get_seconds());
>
> Actually, nothing seems to be ensuring that the value used here ends up being the same as the ctime :\ Consider what happens if the
> get_seconds() call here happens at second N, and the i_ctime is collected at time N+1. The object wouldn't be able to be deleted after
> patch 4/5 is applied. How can we better ensure that the i_ctime is the same value as serialized into the efi var name here?
i_ctime of pstore file system is different from normal file systems.
As I said in patch v1, i_ctime of pstore means the date that the record was "originally" stored.
I_ctime is always set to N.
Here is the scenario.
1. writing time
- get_seconds() call here happens at second N
- "N" is stored to a variable name
2. System reboots...
3. System boots up...
4. reading time
- pstore calls a read callback, efi_pstore_read()
- efi_pstore_read extracts ctime, "N", from the virable name
- efi_pstore passes "N" to pstore file system
- pstore create a file, /dev/pstore/dmesg* and set "N" to i_ctime
Pstore file system doesn't set i_ctime by itself but set ctime passed by platform drivers.
Seiji
--
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/
Powered by blists - more mailing lists