linux-ext4 - Re: Committing changes to an ext3

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] [day] [month] [year] [list]

Date:	Sat, 23 Oct 2010 22:58:36 +0100
From:	Felipe Franciosi <felipe@...adoxo.org>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Committing changes to an ext3_inode structure

Hi Amir,

I finally got it working this morning, but thanks for your reply.  
Indeed all I had to do was to modify i_data... I got confused because  
of this:

On the kernel I have (haven't checked other versions), I see:

include/linux/ext3_fs_i.h:
struct ext3_inode_info {
    __le32 i_data[15];   /* unconverted */
    ...
}

include/linux/ext3_fs.h:
struct ext3_inode {
    ...
    __le32 i_block[EXT3_N_BLOCKS};   /* Pointers to blocks */
    ...
}

I never associated the two as being the same, even though I obviously  
knew EXT3_N_BLOCKS is 15, and the comments on ext3_fs_i.h are not very  
useful, are they? :-/
When I glanced at them, I just assumed it was some raw unconverted  
stuff that had nothing to do with what I wanted.

And yes, as you pointed out and as I said late last night, my fears  
were confirmed: my changes were being overwritten by the  
ext3_inode_info later on. :-(

But I'm glad it's (almost) all working now. I had tried to look for  
the code that manipulate inodes (and not buffer_heads), but I was  
overlooking anything related to an ext3_inode_info struct (I had in my  
head that things were related to the ext3_inode struct). After  
checking out the code pointed out to me here in the list (fs/ext4/ 
migrate.c) I finally got it working. Thanks again to Greg and Andreas  
as well.

Regards,
Felipe

On 23 Oct 2010, at 17:48, Amir Goldstein wrote:

> On Tue, Oct 19, 2010 at 5:23 PM, Felipe Franciosi  
> <felipe@...adoxo.org> wrote:
>> Dear all,
>>
>> I am experimenting on a 2.6.20.3-ubuntu1 kernel to prototype and  
>> evaluate
>> different methods for migrating datablocks for a given inode on the  
>> fly.
>>
>> I have created an ioctl call that implements some verifications and  
>> invokes
>> a function I wrote in balloc.c for such migration.
>>
>> Upon receiving a struct inode*, I retrieve the corresponding iloc  
>> using the
>> ext3_get_inode_iloc() function and then the struct ext3_inode*  
>> using the
>> ext3_raw_inode() on the iloc. I have confirmed the pointer is  
>> correct by
>> printing several ext3_inode relevant fields.
>>
>
> you've complicated things too much.
> all you have to do is modify EXT3_I(inode)->i_data and then call
> ext3_mark_inode_dirty().
> the rest of the iloc and raw inode stuff is taken care of by  
> ext3_put_inode().
>
>> After making my modifications to the i_block array, I am finding it
>> impossible to commit these changes to the inode itself.
>>
>
> that is because your changes are being overriden by the unmodified  
> ei->i_data.
>
>> I have tried different things such as marking the iloc.bh  
>> buffer_head as
>> dirty and submitting it for writing, marking the page as dirty,  
>> etc, but I
>> think I'm missing something more fundamental. Most of my attempts  
>> were
>> planned according to what I've seen inside similar code of  
>> buffer_head
>> manipulation.
>>
>
> maybe you should have looked at code that modifies inodes instead...
>
>> Can anyone shed some light on what I'm missing?
>>
>
> hope this helps,
> Amir.

--
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