If range.start argument was between ULLONG_MAX - BBSIZE and ULLONG_MAX,
BTOBB macro resulted in overflow which caused start to be set to 0.
Now, invalid argument error is returned instead.
Signed-off-by: Tomas Racek
---
fs/xfs/xfs_discard.c |4
1 files changed, 4 insertions(+), 0
> > +
> > + if (range.start > ULLONG_MAX - BBSIZE)
> > + return -XFS_ERROR(EINVAL);
> > +
>
> There's no point checking for overflow on the range start - what we
> need to check is whether it is larger than the size of the
> filesystem. We do that after the conversion of range.start to
TIONS="-O bigalloc -C 8192"
If I understood it correctly, the dumpe2fs outputs free blocks even if bigalloc
is used, that is only the first block of the cluster. I changed the test to
count with whole cluster. Please try the following patch to the xfstests if it
helps you. I tried diff
If range.start points behind the filesystem, return invalid value error.
This fixes possible overflow in
start = BTOBB(range.start)
when range.start is nearly ULLONG_MAX.
Signed-off-by: Tomas Racek
---
fs/xfs/xfs_discard.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
- Original Message -
> On 08/22/2012 12:54 PM, Avi Kivity wrote:
> > On 08/21/2012 12:28 PM, Tomas Racek wrote:
> >>
> >> http://fi.muni.cz/~xracek/debian2.img.bz2
> >>
> >> Other things are the same.
> >>
> >> The runtest.
If range.start or range.minlen is bigger than filesystem size, return
invalid value error. This fixes possible overflow in BTOBB macro when
passed value was nearly ULLONG_MAX.
Signed-off-by: Tomas Racek
---
fs/xfs/xfs_discard.c |6 --
1 files changed, 4 insertions(+), 2 deletions
Hi,
I am writing a file system test which I execute in qemu with kernel compiled
from latest git sources and running it causes this error:
https://bugzilla.kernel.org/show_bug.cgi?id=45971
It works with v3.5, so I ran git bisect which pointed me to:
d6250a3f12edb3a86db9598ffeca3de8b4a219e9 x86
- Original Message -
> On Thu, Aug 16, 2012 at 09:35:12AM -0400, Tomas Racek wrote:
> > Hi,
> >
> > I am writing a file system test which I execute in qemu with kernel
> > compiled from latest git sources and running it causes this error:
> >
> > h
- Original Message -
> On 08/16/2012 11:53 AM, Alan Cox wrote:
> >>
> >> Yes, if I remove the break statement (introduced by this commit),
> >> it works fine.
> >
> > What version of qemu is this - do we have qemu bug here I wonder.
> >
>
> Also, is it 32 or 64 bits?
It's 64-bit.
Reg
- Original Message -
> On Fri, Aug 17, 2012 at 03:43:56AM -0400, Tomas Racek wrote:
> > Well, I've added some debug statements to the code:
> >
> > void __init arch_init_ideal_nops(void)
> > {
> > switch (boot_cpu_data.x86_vendo
> On 20.08.2012 21:13, Tomas Racek wrote:
> []
> Can we trim the old, large and now not-so-relevant discussion please?
> ;)
>
> > I can provide you with more different traces if it can help. But I
> > thought that maybe it will be more useful for you to try it on
>
11 matches
Mail list logo
