Fat fingered the original email and didn't get the fsdevel address correct.
-----------------------
Hi,
I have bisected a strange regression down to this commit that you made.
If I apply the attached patch (which restores the original 2 lines of
code), then everything works correctly. I apologize, but I don't have a
simple reproducer. The gist of the problem is that Java cannot decrypt a
file under certain circumstances, e.g., "ERROR
javax.crypto.BadPaddingException: pad block corrupted". There is more
information in the bug report at http://bugs.launchpad.net/bugs/588861 ,
but not all of it is helpful.
Any thoughts?
rtg
--
Tim Gardner tim.gardner@xxxxxxxxxxxxx
>From 8565505534da369292d593e174255cf5c398f703 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@xxxxxxxxxxxxx>
Date: Fri, 25 Jun 2010 13:53:55 -0600
Subject: [PATCH] fs: Restore previously removed f_op checks.
BugLink: http://bugs.launchpad.net/bugs/588861
commit cc56f7de7f00d188c7c4da1e9861581853b9e92f removed
a check for output file f_op and f_op->sendpage. This appears
to have caused a regression in the ability of Java
to read and decrypt files. This would be simpler if
there was an easy reproducer, but so far the only way I've
been able to get it to fail is within the Maverick
UEC environment.
Signed-off-by: Tim Gardner <tim.gardner@xxxxxxxxxxxxx>
---
fs/read_write.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/read_write.c b/fs/read_write.c
index 9c04852..3203ca1 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -845,6 +845,8 @@ static ssize_t do_sendfile(int out_fd, int in_fd, loff_t *ppos,
if (!(out_file->f_mode & FMODE_WRITE))
goto fput_out;
retval = -EINVAL;
+ if (!out_file->f_op || !out_file->f_op->sendpage)
+ goto fput_out;
in_inode = in_file->f_path.dentry->d_inode;
out_inode = out_file->f_path.dentry->d_inode;
retval = rw_verify_area(WRITE, out_file, &out_file->f_pos, count);
--
1.7.0.4