Messages in this thread | | | Date | Thu, 5 Sep 2013 10:37:49 -0400 | From | Dave Jones <> | Subject | Re: ext4: cache all of an extent tree's leaf block upon reading |
| |
On Thu, Sep 05, 2013 at 01:38:48AM +0000, Linux Kernel wrote: > Gitweb: http://git.kernel.org/linus/;a=commit;h=107a7bd31ac003e42c0f966aa8e5b26947de6024 > Commit: 107a7bd31ac003e42c0f966aa8e5b26947de6024 > Parent: 3be78c73179c9347bdc0a92b2898063bd2300ff7 > Author: Theodore Ts'o <tytso@mit.edu> > AuthorDate: Fri Aug 16 21:23:41 2013 -0400 > Committer: Theodore Ts'o <tytso@mit.edu> > CommitDate: Fri Aug 16 21:23:41 2013 -0400 > > ext4: cache all of an extent tree's leaf block upon reading
> + * ext4_es_cache_extent() inserts information into the extent status > + * tree if and only if there isn't information about the range in > + * question already. > + */ > +void ext4_es_cache_extent(struct inode *inode, ext4_lblk_t lblk, > + ext4_lblk_t len, ext4_fsblk_t pblk, > + unsigned int status) > +{ > + struct extent_status *es; > + struct extent_status newes; > + ext4_lblk_t end = lblk + len - 1; > + > + newes.es_lblk = lblk; > + newes.es_len = len; > + ext4_es_store_pblock(&newes, pblk);
ext4_es_store_pblock or's the pblk with the existing contents of the struct member. (albeit masked with ES_MASK)
Should there be a
newes.es_pblk = 0;
up there too ?
It seems like if the stack happened to contain any of ES_WRITTEN | ES_UNWRITTEN | ES_DELAYED | ES_HOLE then it could leak through into the new extent status.
Dave
| |