From: Madper Xie <cxie@redhat.com>
To: Tony Luck <tony.luck@gmail.com>
Cc: "Anton Vorontsov" <anton@enomsg.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Seiji Aguchi" <seiji.aguchi@hds.com>,
"Lenny Szubowicz" <lszubowi@redhat.com>,
"成骏 谢" <bbboson@gmail.com>, "Colin Cross" <ccross@android.com>,
"Kees Cook" <keescook@chromium.org>
Subject: Re: [PATCH] pstore: avoid incorrectly mark entry as duplicate
Date: Mon, 28 Oct 2013 21:36:57 +0800 [thread overview]
Message-ID: <87iowhv7nq.fsf@redhat.com> (raw)
In-Reply-To: <87k3h35xij.fsf@redhat.com>
Howdy Tony,
Does this patch still need some rework?
cxie@redhat.com writes:
> tony.luck@gmail.com writes:
>
>> On Wed, Oct 23, 2013 at 7:55 AM, Madper Xie <cxie@redhat.com> wrote:
>>> The "duplicate" entries won't appear in pstorefs. And a complain will be
>>> print -- pstore: failed to load 76 record(s) from 'efi'
>>
>> Maybe I don't quite get this - but it sounds like you have a whole lot
>> of entries using up space in efivars that have similar names - differing
>> just in the timestamp - that won't show up in the pstore filesystem - because
>> we'd try to name them all the same thing.
>>
> Maybe I misunderstand you...
>
> Sure pstore try to name them all the same thing, but it's another
> issue. and it doesn't prevent entries showing up in pstore fs.
>
> Consider the following case: (after efi-pstore support append mode, it
> always like this case):
>
> I choose four dumped efivars from my DELL XPS:
> dump-type0-9-1-1380441690-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> dump-type0-9-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> dump-type0-9-1-1380460890-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> dump-type0-9-1-1382496073-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
> ^ ^ [ ^ ]
> ! ! !
> type timestamp GUID
>
> When pstore load them from efivars, pstore incorrectly assuming that
> efivars with the same TYPE, ID and GUID are duplicate.
>
> list_for_each_entry(pos, &allpstore, list) {
> if (pos->type == type && /---
> pos->id == id && <-| as I said, it only check type,id,psi
> pos->psi == psi) { \---
> rc = -EEXIST; <- then set -EEXIST, and ignore *dup* entry
> break;
> }
> }
> You can see the code above, for those four entries, only one could be
> showed in pstorefs, all others will get a -EEXIST. So I add a timestamp
> check here, it's the only different part.
>
>> How did all those things end up in efivars?
> before the patch I can see
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-3 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-10 dmesg-efi-2 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8
> after apply the patch:
> [root@dhcp-13-41 vars]# ls /dev/pstore/
> dmesg-efi-1 dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6 dmesg-efi-8
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-7 dmesg-efi-8
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-12 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5 dmesg-efi-7 dmesg-efi-8
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-13 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-14 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-15 dmesg-efi-2 dmesg-efi-4 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-16 dmesg-efi-3 dmesg-efi-4 dmesg-efi-5 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6 dmesg-efi-7 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-10 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-4 dmesg-efi-6 dmesg-efi-8 dmesg-efi-9
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6 dmesg-efi-8
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6 dmesg-efi-8
> dmesg-efi-1 dmesg-efi-11 dmesg-efi-2 dmesg-efi-3 dmesg-efi-5 dmesg-efi-6 dmesg-efi-8
>
>>
>> Wouldn't the right fix be to make pstore allow them all to appear (using the
>> timestamp to differentiate names?) so that we could see them, log them,
>> and then remove them from pstore (in turn freeing up efivars space - which
>> people keep telling me is in short supply).
>>
> Yeah, many file have the same name, just like my case above. But it not
> really block the file shows up and should be solved in another
> patch. And I'm trying fix it.
>> -Tony
--
Best,
Madper Xie.
prev parent reply other threads:[~2013-10-28 13:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-23 14:55 Madper Xie
2013-10-23 15:58 ` Richard Weinberger
2013-10-23 16:11 ` Madper Xie
2013-10-23 21:57 ` Tony Luck
2013-10-24 0:21 ` Madper Xie
2013-10-28 13:36 ` Madper Xie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87iowhv7nq.fsf@redhat.com \
--to=cxie@redhat.com \
--cc=anton@enomsg.org \
--cc=bbboson@gmail.com \
--cc=ccross@android.com \
--cc=keescook@chromium.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lszubowi@redhat.com \
--cc=seiji.aguchi@hds.com \
--cc=tony.luck@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome