Simplify the code and reduce stack pressure a bit.
Signed-off-by: Erez Zadok <[email protected]>
---
fs/unionfs/mmap.c | 44 ++++++++++++++------------------------------
1 files changed, 14 insertions(+), 30 deletions(-)
diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index 34fd8aa..ef8822f 100644
--- a/fs/unionfs/mmap.c
+++ b/fs/unionfs/mmap.c
@@ -136,22 +136,22 @@ out:
return err;
}
-/*
- * readpage is called from generic_page_read and the fault handler.
- * If your file system uses generic_page_read for the read op, it
- * must implement readpage.
- *
- * Readpage expects a locked page, and must unlock it.
- */
-static int unionfs_do_readpage(struct file *file, struct page *page)
+/* Readpage expects a locked page, and must unlock it */
+static int unionfs_readpage(struct file *file, struct page *page)
{
- int err = -EIO;
+ int err;
struct file *lower_file;
struct inode *inode;
mm_segment_t old_fs;
char *page_data = NULL;
loff_t offset;
+ unionfs_read_lock(file->f_path.dentry->d_sb);
+ err = unionfs_file_revalidate(file, false);
+ if (unlikely(err))
+ goto out;
+ unionfs_check_file(file);
+
if (!UNIONFS_F(file)) {
err = -ENOENT;
goto out;
@@ -191,33 +191,17 @@ static int unionfs_do_readpage(struct file *file, struct page *page)
flush_dcache_page(page);
-out:
- if (err == 0)
- SetPageUptodate(page);
- else
- ClearPageUptodate(page);
-
- return err;
-}
-
-static int unionfs_readpage(struct file *file, struct page *page)
-{
- int err;
-
- unionfs_read_lock(file->f_path.dentry->d_sb);
- err = unionfs_file_revalidate(file, false);
- if (unlikely(err))
- goto out;
- unionfs_check_file(file);
-
- err = unionfs_do_readpage(file, page);
-
/*
* we have to unlock our page, b/c we _might_ have gotten a locked
* page. but we no longer have to wakeup on our page here, b/c
* UnlockPage does it
*/
out:
+ if (err == 0)
+ SetPageUptodate(page);
+ else
+ ClearPageUptodate(page);
+
unlock_page(page);
unionfs_check_file(file);
unionfs_read_unlock(file->f_path.dentry->d_sb);
--
1.5.2.2
-
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]
