Hi it is for the VFS, ext2 is selected in my .config. Concerning the filesystem, if the boot hasn't crashed until the start of /init means that it is correclty mounted (i suppose) In addition, the kernel does not output the well known message: "warning: unable to open an initial console", this means that it is able to open the /dev/console. I used initramfs support in order to mount the VFS, by supplying a config file to CONFIG_INITRAMFS_SOURCE option. However, the getattr method has been initialized, but not the getxattr. Have you any idea what the problem could be? Thanks. 2012/9/24 Mulyadi Santosa <mulyadi.santosa@gmail.com>

Hi...

On Mon, Sep 24, 2012 at 9:58 PM, stl <st.lambert02@gmail.com> wrote:

...

Hello all,

What is the purpose of the inode->i_op->getxattr method?

I think it has something related to extended attribute

...

During the boot of linux-2.6.37 on a new architecture, it crashes in the get_vfs_caps_from_disk() function because of the following security check, (in my case, this field is ot initialized).

if (!inode || !inode->i_op->getxattr) return -ENODATA;

May I know, what's the filesystem type that code currently checks? And are you sure that filesystem is completely ok?

-- regards,

Mulyadi Santosa Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com

hi,

Does your kernel config set this option: CONFIG_EXT2_FS_XATTR=y

The result is the same with and without CONFIG_EXT2_FS_XATTR enabled.

And what is the state of CONFIG_AUDIT option? Do you need Kernel Audit support in your environment?

CONFIG_AUDIT is disabled in my config. A priori, I don't need it at the moment. After searching 'getxattr' reference in my whole linux directory, .getxattr field should be initialized with "generic_getxattr" in ext2 and ext3 case. Is it really what it need, or does it require something specific else? Thanks in advance

so may be its not getxattr, but inode itself is null:

No, the inode is not NULL, it has been allocated in ram at adress 0x4654a0 and most of fields have been initialized. For example: d_inode->i_op->setattr = <ramfs_nommu_setattr> d_inode->i_op->getattr = <simple_getattr>

There are other options like CONFIG_AUDIT_TREE, disable that too. Also make sure that initrd image has the ext2 driver compiled for this kernel.

I am using initramfs support to mount VFS, not init ramdisk (initrd) If I well understand, in my case I have not to deal with precompiled drivers. I only provide a config file to the CONFIG_INITRAMFS_SOURCE option.

If you are using vanilla ext2 fs and CONFIG_EXT2_FS_XATTR is set, then it must be initialized in static inode operations table, look at: ext2_file_inode_operations for files ext2_dir_inode_operations for dir ext2_special_inode_operations for special files ext2_fast_symlink_inode_ operations and ext2_symlink_inode_operations for symlinks all of them are compiled and initialized with generic_getxattr if you compile with CONFIG_EXT2_FS_XATTR.

Indeed, I dug in the source code, I agree with this. Unfortunalety, when debugging, it appears that inode->i_op->getxattr remains null. But I am confused.. for example, what the difference (in the .config file) between "File systems" and "Pseudo filesystems" menus? Because we are speaking about my VFS, so at the moment, the kind of the filesystem is not really important for me. What the difference if I choose ramfs instead of ext2 for example? I have some shadow zones that make me confused.. Thanks for your help.