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]

Date:	Thu, 05 Sep 2013 13:15:40 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	rob.gittins@...ux.intel.com, linux-pmfs@...ts.infradead.org,
	linux-fsdevel@...er.org, linux-kernel@...r.kernel.org
Subject: Re: RFC Block Layer Extensions to Support NV-DIMMs

Matthew Wilcox <willy@...ux.intel.com> writes:

> On Thu, Sep 05, 2013 at 08:12:05AM -0400, Jeff Moyer wrote:
>> If the memory is available to be mapped into the address space of the
>> kernel or a user process, then I don't see why we should have a block
>> device at all.  I think it would make more sense to have a different
>> driver class for these persistent memory devices.
>
> We already have at least two block devices in the tree that provide
> this kind of functionality (arch/powerpc/sysdev/axonram.c and
> drivers/s390/block/dcssblk.c).  Looking at how they're written, it
> seems like implementing either of them as a block device on top of a
> character device that extended their functionality in the direction we
> want would be a pretty major bloating factor for no real benefit (not
> even a particularly cleaner architecture).

Fun examples to read, thanks for the pointers.  I'll note that neither
required extensions to the block device operations.  ;-)  I do agree with
you that neither would benefit from changing.

There are a couple of things in this proposal that cause me grief,
centered around the commitpmem call:

>>    void (*commitpmem)(struct block_device *bdev, void *addr);

For block devices, when you want to flush something out, you submit a
bio with REQ_FLUSH set.  Or, you could have submitted one or more I/Os
with REQ_FUA.  Here, you want to add another method to accomplish the
same thing, but outside of the data path.  So, who would the caller of
this commitpmem function be?  Let's assume that we have a file system
layered on top of this block device.  Will the file system need to call
commitpmem in addition to sending down the appropriate flags with the
I/Os?

This brings me to the other thing.  If the caller of commitpmem is a
persistent memory-aware file system, then it seems awkward to call into
a block driver at all.  You are basically turning the block device into
a sort of hybrid thing, where you can access stuff behind it in myriad
ways.  That's the part that doesn't make sense to me.

So, that's why I suggested that maybe pmem is different from a block
device, but a block device could certainly be layered on top of it.

Hopefully that clears up my concerns with the approach.

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