On 4/12/07, David Howells <[email protected]> wrote:
Nate Diller <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
