linux-ext4 - Re: Add SEEK_DATA/SEEK

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:	Wed, 28 Sep 2011 15:21:08 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	jeff.liu@...cle.com
Cc:	linux-ext4@...r.kernel.org,
	Sunil Mushran <sunil.mushran@...cle.com>
Subject: Re: Add SEEK_DATA/SEEK_HOLE support V2

On Wed, Sep 28, 2011 at 2:32 PM, Jeff Liu <jeff.liu@...cle.com> wrote:
> Hello all,
>
> This is the V2 for add SEEK_DATA/SEEK_HOLE support to ext4.
> In V1, I copied all the codes regarding fetching delayed-extents out to
> my seek callback function, it's stupid to duplicate the code blocks.
>
> Now the idea is, since the delayed-extents is the main concern to search
> extents for both fiemap and seek, so IMHO, it's better to consolidate
> this procedure into a new function(get_delayed_extent() in my patch),
> and call it in fiemap and seek call-back functions if necessary.  In
> this way, when yongqiang's delayed-extents tree is ready, we only need
> to modify the code block at get_delayed_extent() accordingly.
>
> In addition, yongqiang has pointed out there might be a deadlock, but
> per my understood, as the target inode already locked via i_mutex in
> ext4_llseek() before, this lock can prevent any modification to the
> file, and we call find_get_pages_tag() when trying to fetch the dirty
> pages, this function using rcu read lock, it also safe to read.  So I
> have no idea what's wrong, could anyone please kindly point me out in
> this case?  I'm definitely a newbie to this list, sorry for my ignorant.
Ok.  There is no deadlock, fiemap releases i_data_sem before calling
get_delayed_extent().

BTW: It seems that there is a bug in fiemap according to code, I am
not sure which commit introduced it, delayed extents beyond last
allocated block are ignored.

Yongqiang.
>
> Anyway, I'd like to post the revised for your guys review first.
> In have split the modification to two patches this time, since I hope to
> make it looks more convenient for the review purpose.
>
> The 1st patch, remove the delayed-extents fetching procedure to a
> function named as get_delayed_extent(), and modify the
> ext4_ext_fiemap_cb() accordingly.
>
> The 2nd path add the ext4_ext_seek_cb() to implement the
> SEEK_HOLE/SEEK_DATA stuff based on previous code change.
>
> Testing:
> ========
> In addition to the test cases mentioned in V1, I also done another tests
> through sunil's seek test program, please refer to:
> http://oss.oracle.com/~smushran/seek_data/seek_test.c
>
> To ensure the 1st patch does not cause regression issue on fiemap, I
> have done some tests via cp(1) with fiemap copy support, the sparse file
> used for this test is produced by:
> python -c "f=open('./sptest', 'w'); [(f.seek(x) or f.write(str(x))) for
> x in range(1, 1000000000, 99999)]; f.close()
>
>
> Any feedback are appreciated!
>
>
> Thanks,
> -Jeff
>



-- 
Best Wishes
Yongqiang Yang
--
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