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

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

 



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]
  Powered by Linux