On Wed, Aug 14, 2013 at 8:28 PM, Josef Bacik wrote:
> The plan is to have a bunch of unit tests that run when btrfs is loaded when
> you
> build with the appropriate config option. My ultimate goal is to have a test
> for every non-static function we have, but at first I'm going to focus on the
raid6.c is built without access to the prototypes of functions it
exports.
warning: symbol 'raid6_gen_syndrome' was not declared. Should it be static?
They could be changed and get out of sync of the exported prototypes
without errors. So we add disk-io.h, and its dependency ctree.h, so
that
Storing fixed-endian values in native cpu types defeats the purpose of
using sparse endian types to find endian conversion bugs.
Signed-off-by: Zach Brown
---
print-tree.c | 6 +++---
uuid-tree.c | 5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/print-tree.c b/print-tree
sparse can freak out when is included because it redefines
approximately a gazillion symbols already found in :
/usr/include/linux/fs.h:203:9: warning: preprocessor token MS_RDONLY redefined
/usr/include/sys/mount.h:37:9: this was the original definition
Happily, we don't actually need to includ
The _una_ struct's entire job is to pass an argument to le*_to_cpu. So
it's a little embarassing that it uses a native cpu types and generates
endian warnings.
ctree.h:1616:1: warning: incorrect type in assignment (different base types)
ctree.h:1616:1:expected unsigned long long [unsigned] [u
sparse hates variable length array definitions on the stack:
btrfs-show-super.c:155:21: warning: Variable length array is used.
And it's right to. They're a fragile construct that doesn't handle bad
input well at all.
Signed-off-by: Zach Brown
---
btrfs-show-super.c | 2 +-
volumes.c
A disk_key was set by hand instead of using the endian helpers.
I *think* the second one is just a typo. The chunk's num_stripes was
already initialized from the record, but it's le16. So we'll set the
item's size based on the record's native num_stripes.
Signed-off-by: Zach Brown
---
cmds-ch
__CHECKER__ is only for the type juggling used to tell sparse which
types need conversion between address spaces. It is not OK to use to
change the code that gets checked to avoid bugs elsewhere in the build
infrastructure. We want to check the code that builds when the checker
isn't enabled.
Si
Extents rebuilt from backrefs can have their objectid mangled. The code
tried to build a disk_key by hand and got the swabbing backwards.
Signed-off-by: Zach Brown
---
cmds-check.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index 2318a
qgroup.c:82:23: warning: memcpy with byte count of 0
qgroup.c:83:23: warning: memcpy with byte count of 0
The inheritance wasn't copying qgroups[] because a confused sizeof()
gave 0 byte memcpy()s. It's been like this for the year since it was
merged, so I guess this isn't a very important thing
There were a few problems that were breaking sparse checking:
- We were defining CHECK_ENDIAN late in the environment, after
linux/fs.h has been included which defines __force and __bitwise in
confusing ways that conflict with ours. Define it up with __CHECKER__
so that linux/fs.h and our c
This fixes all the instances of warnings that symbols declared in blocks
shadow symbols with the same name in surrounding scopes:
cmds-device.c:341:22: warning: symbol 'path' shadows an earlier one
cmds-device.c:285:14: originally declared here
I just renamed or removed the risky shadow symbols
These were mostly in option structs but there were a few gross string
pointer arguments given as 0.
Signed-off-by: Zach Brown
---
btrfs-map-logical.c | 2 +-
btrfs.c | 2 +-
cmds-balance.c | 6 +++---
cmds-check.c| 2 +-
cmds-dedup.c| 4 ++--
cmds-device.c
This silences a sparse warning:
warning: constant 0x4D5F53665248425F is so big it is long
from
commit 52162700bb59663add809a6465ce2769d80b3664
Author: Zach Brown
Date: Thu Jan 17 11:54:47 2013 -0800
btrfs-progs: treat super.magic as an le64
High fives, past me!
Signed-o
This silences (reasonable) sparse warnings of the form:
warning: non-ANSI function declaration of ..
Signed-off-by: Zach Brown
---
btrfs-find-root.c | 2 +-
btrfs-list.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/btrfs-find-root.c b/btrfs-find-root.c
ind
Signed-off-by: Zach Brown
---
btrfs-convert.c| 2 +-
btrfs.c| 6 +++---
cmds-dedup.c | 2 +-
crc32c.c | 4 ++--
ctree.c| 4 ++--
free-space-cache.c | 4 ++--
help.c | 2 +-
radix-tree.c | 2 +-
8 files changed, 13 insertions(+), 13 del
Hi gang,
I was a little surprised to see that patch go by recently
which fixed an endian bug. I went to see how sparse
checking looked and it was.. broken. I got it going
again in my Fedora environment.
Most of the patches are just cleanups, but there *were*
three real bugs lurking in all that
Hello,
I hope this is the correct mailing list.
I have btrfs running on a 6TB (5.5ish TiB) raid10 array on a 3ware
9750-4i controller. I decided to run a script and a got 5 checksum
errors for the same file (errors from dmesg below).
I deleted the file without any issues, reran scrub, and no
On 07/24/2013 12:01 PM, Stefan Behrens wrote:
Since common/config is executed twice, if SCRATCH_DEV_POOL is configured
via the environment, the current code removes the first device entry twice
which means that you lose the second device for the test.
The fix is to not remove anything from SCRAT
On 07/31/2013 10:52 AM, Stefan Behrens wrote:
This test performs btrfs device replace tests with all possible profiles
(single/dup/mixed/raid0/raid1/raid10), one round with the '-r' option
to 'btrfs replace start' and one round without this option. The
cancelation is tested only once and with the
On 08/14/2013 03:07 PM, Josef Bacik wrote:
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik
---
V2->V3: remove comment and abstract out the subv
Cc: Josef Bacik
Cc: Chris Mason
Signed-off-by: Sergei Trofimovich
---
fs/btrfs/ctree.h | 2 --
fs/btrfs/disk-io.c | 8
fs/btrfs/extent_io.c | 2 +-
fs/btrfs/extent_io.h | 1 -
fs/btrfs/root-tree.c | 4 ++--
fs/btrfs/transaction.c | 2 +-
fs/btrfs/transaction.h | 2 --
7
On 08/07/2013 11:15 AM, Josef Bacik wrote:
There was a problem with send trying to overwrite a file that wasn't actually
the same. This is a test to check this particular case where receive fails when
it should succeed properly. I tested this to verify it fails without my fix and
passes with my
On 8/14/13 3:07 PM, Josef Bacik wrote:
> We were allowing users to delete their default subvolume, which is
> problematic.
> This test is a regression test to make sure we don't let that happen in the
> future. Thanks,
>
> Signed-off-by: Josef Bacik
> ---
> V2->V3: remove comment and abstract o
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik
---
V2->V3: remove comment and abstract out the subvolid logic as per Eric's
suggestions
V1->V2
On 08/12/2013 02:13 PM, Josef Bacik wrote:
This is a regression test for a problem we had where we'd assume we had created
a directory if it only had subvols inside of it. This was happening because
subvols would have lower inode numbers than our current send progress because
their inode numbers
>> trying to reproduce [1], i've came across another btrfs bug:
>>
>
> You hit the strangest things. I'm going to sit down and write a bunch of unit
> tests for this function to verify it is working properly. Thanks,
glad to help. not sure if this is related, but i always have some
warnings ab
On Wed, Aug 14, 2013 at 07:50:05PM +0200, tim wrote:
> hi all,
>
> trying to reproduce [1], i've came across another btrfs bug:
>
You hit the strangest things. I'm going to sit down and write a bunch of unit
tests for this function to verify it is working properly. Thanks,
Josef
--
To unsubsc
The plan is to have a bunch of unit tests that run when btrfs is loaded when you
build with the appropriate config option. My ultimate goal is to have a test
for every non-static function we have, but at first I'm going to focus on the
things that cause us the most problems. To start out with thi
I added a patch where we started taking the ordered operations mutex when we
waited on ordered extents. We need this because we splice the list and process
it, so if a flusher came in during this scenario it would think the list was
empty and we'd usually get an early ENOSPC. The problem with thi
On Wed, 2013-08-14 at 10:56 +0200, Geert Uytterhoeven wrote:
> These bring in the 64-bit divisor from somewhere else, so they're less
> trivial to fix.
Using div64_u64 or div64_s64 could fix it.
Maybe that could be added to do_div too.
--
To unsubscribe from this list: send the line "unsubscribe
hi all,
trying to reproduce [1], i've came across another btrfs bug:
[ 4031.725643] [ cut here ]
[ 4031.725647] kernel BUG at fs/btrfs/file.c:870!
[ 4031.725648] invalid opcode: [#1] PREEMPT SMP
[ 4031.725650] Modules linked in: ecryptfs sha256_generic encrypted_keys
make C=2 fs/btrfs/ CF=-D__CHECK_ENDIAN__
I tried to filter out the warnings for which patches have already
been sent to the mailing list, pending for inclusion in btrfs-next.
All these changes should be obviously safe.
Signed-off-by: Stefan Behrens
---
This patch is for the current btrfs-next w
I added a patch where we started taking the ordered operations mutex when we
waited on ordered extents. We need this because we splice the list and process
it, so if a flusher came in during this scenario it would think the list was
empty and we'd usually get an early ENOSPC. The problem with thi
On Wed, Aug 14, 2013 at 11:17:05AM +0800, Anand Jain wrote:
>
>
> On 08/14/2013 10:04 AM, Anand Jain wrote:
> >
> >
> >On 08/14/2013 03:14 AM, Josef Bacik wrote:
> >>On Fri, Jul 26, 2013 at 01:35:28AM +0800, Anand Jain wrote:
> >>>Signed-off-by: Anand Jain
> >>>---
> >>> mkfs.c |3 ++-
> >>>
On Sat, Aug 10, 2013 at 10:30 PM, Mitch Harder
wrote:
> On Fri, Aug 9, 2013 at 9:46 AM, David Sterba wrote:
>> On Fri, Aug 09, 2013 at 01:47:24PM +0800, Miao Xie wrote:
>>> On thu, 8 Aug 2013 22:45:48 +0100, Filipe David Borba Manana wrote:
>>> > 8MiB is way too large and likely set by mistake. T
Am Montag, 12. August 2013, 09:50:16 schrieb Josef Bacik:
> On Sun, Aug 11, 2013 at 03:44:10PM +0200, Florian Lindner wrote:
> > Hello!
> >
> > I'm using ArchLinux with kernel Linux horus 3.10.5-1-ARCH #1 SMP PREEMPT.
> > Mounting and unmounting takes a long time:
> >
> > # time mount -v /mnt/Arc
On Wed, Aug 14, 2013 at 10:40 AM, Geert Uytterhoeven
wrote:
> On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
> wrote:
>> On Fri, 9 Aug 2013, Zach Brown wrote:
>>> On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
>>> > Josef Bacik writes:
>>> >
>>> > > So stripe_len shouldn't
On Tue, Aug 13, 2013 at 6:32 PM, Geert Uytterhoeven
wrote:
> On Fri, 9 Aug 2013, Zach Brown wrote:
>> On Fri, Aug 09, 2013 at 02:26:36PM +0200, Andreas Schwab wrote:
>> > Josef Bacik writes:
>> >
>> > > So stripe_len shouldn't be 0, if it is you have bigger problems :).
>> >
>> > The bigger probl
39 matches
Mail list logo
