On 4/12/07, David Howells <dhowells@xxxxxxxxxx> wrote:
Nate Diller <nate.diller@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
