linux-ext4 - Re: [PATCH 26/25] libext2fs: call get_alloc

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:	Fri, 12 Sep 2014 18:17:53 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH 26/25] libext2fs: call get_alloc_block hook when
 allocating blocks

On Fri, Sep 12, 2014 at 10:57:50AM -0700, Darrick J. Wong wrote:
> 
> > errcode_t ext2fs_alloc_blocks(ext2_filsys fs, blk64_t goal,
> > 	  	              unsigned int *num_blocks,
> > 			      char *block_buf, int flags, blk64_t *ret)
> > 
> > ... which can be used to efficiently allocate up to *num_blocks blocks
> > at a time, much like the mballoc interface.  I suspect that would be
> > useful for a number of different cases, including ext2fs_fallocate and
> > mk_hugefiles.c.
> 
> Sounds familiar:  http://marc.info/?l=linux-ext4&m=139898612510491&w=2

Yes, but I'm thinking of something which is a superset of
ext2fs_alloc_block2().  That is, that it should call the
get_alloc_block hook (and also adding a possible get_alloc_blocks
hook), and that a flag would control whether the data blocks would be
zero'ed or not.  (Indeed, I was thinking originally of calling it
ext2fs_alloc_block3.)

> > What I'm currently wondering about is whether it's worth the interface
> > complexity to have something like a "struct ext2fs_allocation_request"
> > structure, so we can potentially add more hints that a future
> > implementation might use, or whether that's not worth it.
> > 
> > What do folks think?
> 
> I'm not sure changing a struct vs. changing whatever parameters we feed into
> that function is all that much different.  I guess you could get around
> structure size changes by forcing callers to use a library allocator function.
> But OTOH large allocations are probably rare.

We can also insulate against structure sizes by using padding fields,
but the ultimate question is how complicated we want to make this
interface.  We know it will be used by mk_hugeblock and the fallocate
interface.  In theory it could be use by your fuse driver to do
allocations more efficiently.  There is the question of whether it's
worth it, although it has crossed my mind that this might be an
interesting place to start experimenting with an eventual replacement
of the buddy-bitmap implementation in mballoc with something that use
in-memory rbtrees, for example....

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html