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: <AANLkTinxJ3uTRanOmc615V1_S5D1L4v_5vSjPYCzjf2Q@mail.gmail.com>
Date:	Mon, 22 Nov 2010 10:17:28 -0800
From:	Tony Luck <tony.luck@...el.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Huang Ying <ying.huang@...el.com>,
	"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 Mon, Nov 22, 2010 at 2:43 AM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> > "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.
>
> One thing we need for some of the driver code sitting in the pending pile
> is support for hardware assisted logging, where record numberes are handed
> out by a device register access.

I don't follow you here ... perhaps we have a different idea
of what "record numbers" are?  I'm thinking they are purely
an internal implementation detail of a platform level pstore
driver ... but the generic code needs to use them as an
opaque object holding them from the result of a read and
using them when requesting an erase.  What usage are
you thinking of that needs this device register access?

>> > Once an error record has been viewed, analysed, saved. The
>> > user can request it to be cleared by writing its name to the
>> > "erase" file:
>
> How will fragmentation be handled ?

This is left as an exercise for the platform level diver (or
in the case of ERST, it is handled by the firmware that
implements ERST).  In general this shouldn't be a hard
problem because I think the usual use case will be that
just after boot we will run some processes that look at,
analyse, save and clear all the error records. Different
types of records may be handled by different processes,
so there can be some short term fragmentation when
one type of record has been erased, but the remainder
have not yet been processed.

>> > + * Erase records by writing their filename to the "erase" file. E.g.
>> > + *     # echo "dmesg-0" > erase
>
> rm dmesg-0
>
> We have a model for this and filesystem indirected via sysfs commands is
> in the daft category.

Yup - totally mad.  My sysfs-fu isn't up to figuring out how
to get a notification on unlink(2). Is that possible? It would
be a much superior metaphor.

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