linux-kernel - Re: RFC Block Layer Extensions to Support NV-DIMMs

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: <x49vc2f89vd.fsf@segfault.boston.devel.redhat.com>
Date:	Thu, 05 Sep 2013 13:19:02 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	rob.gittins@...ux.intel.com
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...er.org,
	linux-pmfs@...ts.infradead.org
Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs

Rob Gittins <rob.gittins@...ux.intel.com> writes:

>> >    void (*commitpmem)(struct block_device *bdev, void *addr);
>> 
>> Seems like this would benefit from a length argument as well, no?
>
> Yes.  Great point.  I will add that in.

Rob, taking it a step further, maybe a vectored interface would be more
flexible.  Something to consider, anyway.

>> > Another area requiring extension is the need to be able to clear PMEM
>> > errors.  When data is fetched from errored PMEM it is marked with the
>> > poison attribute.  If the CPU attempts to access the data it causes a
>> > machine check.  How errors are cleared is hardware dependent and needs
>> > to be handled by the specific device driver.  The following function
>> > in the block_device_operations vector would clear the correct range
>> > of PMEM and put new data there.  If the argument data is null or the
>> > size is zero the driver is free to put any data in PMEM it wishes.
>> >
>> > 	void (*clearerrorpmem)(struct block_device *bdev, void *addr,
>> > 			size_t len, void *data);
>
>> What is the size of data?
>
> clearerrorpmem as part of the process of clearing an error 
> can effectively write a buffer of data as part of the
> clear process.  If the len is zero or the data pointer is null then
> only a error clear happens.    

So data would be of 'len' size, then?  In other words, this would be a
way to restore data that may have been there?

> The existing partitioning mechanism was intended for small drives
> and works best for a single fs/device.  We are approaching NV-DIMMs
> as if they were more like LUNs in storage arrays.  Each range is 
> treated as a device.  A range of an NV-DIMM could be partitioned if
> someone wanted to do such a thing.

OK, that clears things up, thanks.

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