[RFC] what the hell is ->f_mapping->host->i_mapping thing about?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	In do_dentry_open() we have the following weirdness:

        file_ra_state_init(&f->f_ra, f->f_mapping->host->i_mapping);

What is it about?  How and when can ->f_mapping->host->i_mapping be *NOT*
equal to ->f_mapping?

It came from
commit 1c211088833a27daa4512348bcae9890e8cf92d4
Author: Andrew Morton <akpm@xxxxxxxx>
Date:   Wed May 26 17:35:42 2004 -0700

    [PATCH] Fix the setting of file->f_ra on block-special files
	
    We need to set file->f_ra _after_ calling blkdev_open(), when inode->i_mapping
    points at the right thing.  And we need to get it from
    inode->i_mapping->host->i_mapping too, which represents the underlying device.

    Also, don't test for null file->f_mapping in the O_DIRECT checks.

Sure, we need to set ->f_ra after ->open(), since ->f_mapping might be
changed by ->open().  No arguments here - that call should've been moved.
But what the hell has the last bit come from?  What am I missing here?
IDGI...

And that gift keeps giving -
fs/nfs/nfs4file.c:388:  file_ra_state_init(&filep->f_ra, filep->f_mapping->host->i_mapping);
is a copy of that thing.  Equally bogus, AFAICT...



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux