Re: [PATCH 3/17] afs: convert afs_dir_get_page to read_kmap_page

From: Nate Diller
Date: Thu Apr 12 2007 - 15:27:30 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/