linux-kernel - Re: [RFC] persistent store

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=fNH4-VjLh1zzk-UdEQevR16_K8igdLeodw6yL@mail.gmail.com>
Date:	Mon, 22 Nov 2010 08:55:34 -0800
From:	Tony Luck <tony.luck@...el.com>
To:	Huang Ying <ying.huang@...el.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>, "greg@...ah.com" <greg@...ah.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [RFC] persistent store

On Sun, Nov 21, 2010 at 5:59 PM, Huang Ying <ying.huang@...el.com> wrote:
> This patch provides a general "read" interface for kmsg_dumper and some
> other persistent storage users. Another possible choice is to just
> extend the original interface to add persistent store support. For
> example, we can add a "read" function in kmsg_dumper, and output the
> content of persistent store via extend /dev/kmsg via prefix every line
> comes from persistent store or adding some "ioctl" to do that. (But it
> seems that nobody likes "ioctl").

In Linux (and Unix before it) "everything is a file" ... but this
doesn't work very well if the file has internal structure (e.g.
is made of records that can be individually changed or
deleted).  A filesystem seems a much better model.

>> "writer" which writes a record with a type to the persistent store
>
> I think it is necessary to require this to be NMI safe (in comments?),
> because hardware error handler may need to write to persistent storage
> in NMI context. Or we can add a "flag" field to let storage provider
> advocate its capability of NMI safe.

I can add a comment to pstore.h to document the NMI-safe
requirement for the "writer" function.

>>   - Which device(s) should error records be written to?
>>     All of them? Start with one and move on when it is
>>     full?  Write some types of records to one device?
>
> The persistent storage may be full, and the writing may fail. So I think
> we can just try to write one by one, until the first success writing.

A good option - if we ever find someone luck enough to have
more than one persistent store device.

>> +       sysfs_remove_bin_file(&pstore_kset->kobj, &search_pstore->attr);
>
> It seems that the corresponding memory is not freed after erasing.

Ouch!  Good catch.  Will add a kfree()

-Tony
--
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/