linux-ext4 - Re: Question about ext4 online defrag test case

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:	Sat, 16 Jan 2010 22:58:30 +0530
From:	Manish Katiyar <mkatiyar@...il.com>
To:	tytso@....edu
Cc:	SandeepKsinha <sandeepksinha@...il.com>,
	Greg Freemyer <greg.freemyer@...il.com>,
	Akira Fujita <a-fujita@...jp.nec.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Question about ext4 online defrag test case

On Sat, Jan 16, 2010 at 11:59 AM,  <tytso@....edu> wrote:
> On Fri, Jan 15, 2010 at 07:11:28PM +0530, SandeepKsinha wrote:
>> >> I found your comment about ext4 online defrag on Ubuntu BBS by accident.
>> >> https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/321528
>> >>
>> >> I would like to address this problem so I ran e4defrag on the system
>> >> which was under memory pressure. But unfortunately I could not find the bug.
>> >> If you have already known how to reproduce this kind of problem,
>> >> could you teach me how?
>
> I'm sorry I wasn't clear.  I don't know of any specific problem with
> the code,

Hi Akira/Ted,

I am trying to use EXT4_TOC_MOVE_EXT ioctl for one of my test programs
to move blocks in a file (the code has been copied from e4defrag) But
it fails with below error.


Little bit of debugging reveals that the ioctl  expects the source
file also to be in both read write mode. Once I open the file in rw
mode it succeeds, but e4defrag also seems to be opening the source
file in readonly mode only.  Wondering how it succeeds
=====================================================
	case EXT4_IOC_MOVE_EXT: {
		struct move_extent me;
		struct file *donor_filp;
		int err;
                /* Manish debug code */
		printk(KERN_CRIT "Read mode : %d\n", filp->f_mode & FMODE_READ);
		printk(KERN_CRIT "Write mode : %d\n", filp->f_mode & FMODE_WRITE);
		if (!(filp->f_mode & FMODE_READ) ||
		    !(filp->f_mode & FMODE_WRITE))
			return -EBADF;

========== Dmesg output ================
[ 7893.627735] Read mode : 1
[ 7893.627744] Write mode : 0

Is intended ? or has been changed in recent code ?

Thanks -
Manish

> but I and some other ext4 developers remain a bit conerned
> about the code because of how it is structured, and the fact that
> there is so much code and there hasn't been a lot of people spent a
> lot of time going through it and cleaning it up.  We also don't have
> good regression tests for the kernel defrag support code.
>
> This is partially my fault; I haven't had enough time to do more
> testing and code clean up on the defrag code.  I need to spend more
> time doing some testing and code cleanup before I'll be comfortable
> telling people that it is as reliable as other parts of ext4 in terms
> of not potentially losing their data.  Maybe it's just my paranoia....
>
>                                                  - 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
>



-- 
Thanks -
Manish
==================================
[$\*.^ -- I miss being one of them
==================================
--
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