| Message ID | 4A9DE3EA.1080602@rs.jp.nec.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
Hi, Akira, Akira Fujita wrote: > ext4: Return exchanged blocks count to user space in failure > > From: Akira Fujita <a-fujita@rs.jp.nec.com> > > Return exchanged blocks count (moved_len) to user space, > if ext4_move_extents() failed on the way. Even with the patch, I still don't see how users can fix EXT4_IOC_MOVE_EXT failures, because the orig file itself may be broken. > > Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com> > --- > fs/ext4/ioctl.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c > index b0b434b..efd11c8 100644 > --- a/fs/ext4/ioctl.c > +++ b/fs/ext4/ioctl.c > @@ -255,10 +255,9 @@ setversion_out: > me.donor_start, me.len, &me.moved_len); > fput(donor_filp); > > - if (!err) > - if (copy_to_user((struct move_extent *)arg, > - &me, sizeof(me))) > - return -EFAULT; > + if (copy_to_user((struct move_extent *)arg, &me, sizeof(me))) > + return -EFAULT; > + > return err; > } > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Wed, Sep 2, 2009 at 11:54 AM, Peng Tao<bergwolf@gmail.com> wrote: > Hi, Akira, > > Akira Fujita wrote: >> ext4: Return exchanged blocks count to user space in failure >> >> From: Akira Fujita <a-fujita@rs.jp.nec.com> >> >> Return exchanged blocks count (moved_len) to user space, >> if ext4_move_extents() failed on the way. > Even with the patch, I still don't see how users can fix EXT4_IOC_MOVE_EXT failures, > because the orig file itself may be broken. Peng, I have not looked at the code very closely, but can you tell me where a file corruption can take place? Not completing the replacement of extents with donor extents is one thing. Corrupting the original file contents is another. Clearly we need EXT4_IOC_MOVE_EXT to fail gracefully and not corrupt the original file the vast majority of the time. Greg -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Greg, On Thu, Sep 3, 2009 at 4:59 AM, Greg Freemyer<greg.freemyer@gmail.com> wrote: > Peng, > > I have not looked at the code very closely, but can you tell me where > a file corruption can take place? Not completing the replacement of > extents with donor extents is one thing. Corrupting the original file > contents is another. The file corruption is mainly because of the half done replacement. My test case is here: http://marc.info/?l=linux-ext4&m=124992522305319&w=2 With Akira's previous patch (http://marc.info/?l=linux-ext4&m=124937430627867&w=2), EXT4_IOC_MOVE_EXT does not panic the kernel any more. But it leaves the orig file's extent tree corrupted. > > Clearly we need EXT4_IOC_MOVE_EXT to fail gracefully and not corrupt > the original file the vast majority of the time. > > Greg >
On Thu, Sep 3, 2009 at 1:13 AM, Peng Tao<bergwolf@gmail.com> wrote: > Hi, Greg, > > On Thu, Sep 3, 2009 at 4:59 AM, Greg Freemyer<greg.freemyer@gmail.com> wrote: >> Peng, >> >> I have not looked at the code very closely, but can you tell me where >> a file corruption can take place? Not completing the replacement of >> extents with donor extents is one thing. Corrupting the original file >> contents is another. > The file corruption is mainly because of the half done replacement. > > My test case is here: > http://marc.info/?l=linux-ext4&m=124992522305319&w=2 > > With Akira's previous patch > (http://marc.info/?l=linux-ext4&m=124937430627867&w=2), > EXT4_IOC_MOVE_EXT does not panic the kernel any more. But it leaves > the orig file's extent tree corrupted. Is this highly repeatable, e4defrag using EXT4_IOC_MOVE_EXT corrupts sparse files? If so, it seems like a pretty major bug that will be exposed to userspace when 2.6.31 goes final. It seems to me at a minimum a Kconfig option should be added to enable the ioctl to userspace and that it should have depends on EXPERIMENTAL and default to NO for now. We don't want people thinking that this feature is stable in 2.6.31. Greg
On Thu, Sep 3, 2009 at 9:48 PM, Greg Freemyer<greg.freemyer@gmail.com> wrote: > On Thu, Sep 3, 2009 at 1:13 AM, Peng Tao<bergwolf@gmail.com> wrote: >> Hi, Greg, >> >> On Thu, Sep 3, 2009 at 4:59 AM, Greg Freemyer<greg.freemyer@gmail.com> wrote: >>> Peng, >>> >>> I have not looked at the code very closely, but can you tell me where >>> a file corruption can take place? Not completing the replacement of >>> extents with donor extents is one thing. Corrupting the original file >>> contents is another. >> The file corruption is mainly because of the half done replacement. >> >> My test case is here: >> http://marc.info/?l=linux-ext4&m=124992522305319&w=2 >> >> With Akira's previous patch >> (http://marc.info/?l=linux-ext4&m=124937430627867&w=2), >> EXT4_IOC_MOVE_EXT does not panic the kernel any more. But it leaves >> the orig file's extent tree corrupted. > > Is this highly repeatable, e4defrag using EXT4_IOC_MOVE_EXT corrupts > sparse files? It is the EXT4_IOC_MOVE_EXT ioctl corrupts sparse files because it doesn't handle well with file holes. The e4defrag program loops to call EXT4_IOC_MOVE_EXT for each non-continuous parts of a file, so it doesn't expose file holes to kernel. But since the ioctl interface is publicly usable, I do suggest making it behave better, at lease don't bug the kernel, because I did hit null pointer reference in my last time testing the new ioctl. So IMHO, Akira's previous patch (http://patchwork.ozlabs.org/patch/30707/) is really necessary. > > If so, it seems like a pretty major bug that will be exposed to > userspace when 2.6.31 goes final. > > It seems to me at a minimum a Kconfig option should be added to enable > the ioctl to userspace and that it should have depends on EXPERIMENTAL > and default to NO for now. > > We don't want people thinking that this feature is stable in 2.6.31. I do agree that the feature is still unstable ATM. > > Greg > -- > Greg Freemyer > Head of EDD Tape Extraction and Processing team > Litigation Triage Solutions Specialist > http://www.linkedin.com/in/gregfreemyer > Preservation and Forensic processing of Exchange Repositories White Paper - > <http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html> > > The Norcross Group > The Intersection of Evidence & Technology > http://www.norcrossgroup.com >
On Wed, Sep 02, 2009 at 12:18:02PM +0900, Akira Fujita wrote: > ext4: Return exchanged blocks count to user space in failure > > From: Akira Fujita <a-fujita@rs.jp.nec.com> > > Return exchanged blocks count (moved_len) to user space, > if ext4_move_extents() failed on the way. > > Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com> Added to the ext4 patch queue. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index b0b434b..efd11c8 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -255,10 +255,9 @@ setversion_out: me.donor_start, me.len, &me.moved_len); fput(donor_filp); - if (!err) - if (copy_to_user((struct move_extent *)arg, - &me, sizeof(me))) - return -EFAULT; + if (copy_to_user((struct move_extent *)arg, &me, sizeof(me))) + return -EFAULT; + return err; } -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in