On 4/12/07, David Howells <dhowells@redhat.com> wrote:
quoted text
> Nate Diller <nate.diller@gmail.com> wrote:
>
> > Hmmm you're right.  Is your security work going into the next -mm?
>
> I don't know.  Andrew hasn't said anything.  Andrew?  Are you waiting for it
> to go through DaveM's networking tree?
>
> > If so, I'll just re-base this cleanup patch on that ... at the very least I
> > want to get rid of afs_dir_put_page().
>
> That's reasonable.
>
> > Also, did you consider passing the key pointer directly and modifying the
> > readpage actor to simply cast the pointer back, like
> > read_mapping_page(mapping, page, (struct file *)key)?  It seems like a waste
> > to allocate a whole file struct on the stack just for the ->private field.
>
> There's one small problem with that...  And that's filemap_nopage() (it passes
> vma->vm_file to readpage() unconditionally).  Unless, of course, your patches
> fix that too...

But you can't mmap() a directory anyway so ... oh.  Interesting.
afs_file_readpage() does directories too.  The only thing I can think
of then is

struct address_space_operations afs_file_aops = {
        .readpage       = afs_file_readpage,
}
struct address_space_operations afs_dir_aops = {
        .readpage       = afs_key_readpage,
}

int afs_file_readpage(file, page){
    return afs_key_readpage(file->private, page)
}

but that's a lot of code to avoid a single stack allocation.  The
whole fake file pointer thing still strikes me as a little ugly, and
you're definitely not the first one who needed this sort of hackery.
ugh

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html