mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

      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