On Wed, 2011-09-21 at 11:42 +0200, Lukas Czerner wrote: > In xfs_ioc_trim it is possible that computing the last allocation group > to discard might overflow for big start & len values, because the result > might be bigger then xfs_agnumber_t which is 32 bit long. Fix this by not > allowing the start and end block of the range to be beyond the end of the > file system. > > Note that if the start is beyond the end of the file system we have to > return -EINVAL, but in the "end" case we have to truncate it to the fs > size. > > Also introduce "end" variable, rather than using start+len which which > might be more confusing to get right as this bug shows. > > Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx> There are cases where we're (still) not trimming blocks within the range specified when we could. I have an idea about how to do that but I'll send it out later and will commit this as-is. Reviewed-by: Alex Elder <aelder@xxxxxxx> _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
