On Thu, Oct 25, 2012 at 1:03 PM, Seiji Aguchi <seiji.agu...@hds.com> wrote: >> > - 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
Ah, I accidentally glossed over this bit. Thanks for correcting me :) > - 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. > So doesn't this break erasing of existing dumps in pstore-efivars? Unless efi_pstore_read still understands the older variable name formats, users will be stranded with dumps consuming space in efivars that aren't exported via pstore anymore. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
