Re: [PATCH] int (*readpage)(struct file *, struct page *);

From: Roman V. Shaposhnick (vugluskr@unicorn.math.spbu.ru)
Date: Thu May 11 2000 - 11:54:37 EST


On Thu, May 11, 2000 at 10:36:58AM -0600, Jeff V. Merkey wrote:
>
>
> Trond Myklebust wrote:
> >
> > >>>>> " " == Jeff V Merkey <jmerkey@timpanogas.com> writes:
> >
> > > If I understand this correctly, then I am assuming that since
> > > the struct file *file can be NULL, then the struct inode *inode
> > > address will always be assumed to be available from
> > > page->mapping->host instead of dentry->d_inode? Knowing that
> > > callers may pass a NULL strut file * is useful to know.
> >
> > Stop it! This sort of thing should only be used by private code
> > (i.e. the disk-specific stuff) where one knows that the file/dentry is
> > not needed. If people want to document uses of that, then fine.
> >
> > The generic VM/VFS code should however never pass a NULL value for the
> > file parameter, or similarly assume that we can 'make do' with
> > page->mapping->host when calling readpage(), writepage() etc.
>
>
> According to comments made in this thread, the proposed change stated
> that FS's should handle a NULL case for file *. If this is so, I need
> to know so I don't try to use the file->private_data field and
> subsequently cause a NULL pointer dereference in kernel space.
  
  It's up to you. You can simply avoid using *generic* methods that can't
provide nonNULL file pointer. You are not bound to use *generic*
'page_readlink', for example, just because you can always code your own
variant of it.

Roman.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST