In read_one_chunk(), we may add an empty entry for a missing device.
However, this entry wasn't being added to the dev_list, and so it never
got freed.
Signed-off-by: Justin Maggard
---
volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/volumes.c b/volumes.c
index ccfa732..b5066b9 1
I've run into a couple filesystems where btrfs-find-root would spin
indefinitely.
If the first cache extent start location is 0, we end up in an infinite
loop in btrfs_next_bg(). Fix it by checking for that situation, and
jumping to the next bg if necessary.
Fixes: e2e0dae9 (btrfs-progs: volume:
There's a race condition that leads to a NULL pointer dereference if you
disable quotas while a quota rescan is running. To fix this, we just need
to wait for the quota rescan worker to actually exit before tearing down
the quota structures.
Signed-off-by: Justin Maggard
---
fs/btrfs/qgroup.c |
Commit c6887cd11149 (Btrfs: don't do nocow check unless we have to)
changed the behavior of __btrfs_buffered_write() so that it first tries
to get a data space reservation, and then skips the relatively expensive
nocow check if the reservation succeeded.
If we have quotas enabled, the data space r
I was hitting a consistent NULL pointer dereference during shutdown that
showed the trace running through end_workqueue_bio(). I traced it back to
the endio_meta_workers workqueue being poked after it had already been
destroyed.
Eventually I found that the root cause was a qgroup rescan that was
v2: Fix stupid error while making formatting changes...
I was hitting a consistent NULL pointer dereference during shutdown that
showed the trace running through end_workqueue_bio(). I traced it back to
the endio_meta_workers workqueue being poked after it had already been
destroyed.
Eventually
I was hitting a consistent NULL pointer dereference during shutdown that
showed the trace running through end_workqueue_bio(). I traced it back to
the endio_meta_workers workqueue being poked after it had already been
destroyed.
Eventually I found that the root cause was a qgroup rescan that was
This test case tests if we are able to unmount a filesystem while
a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: exit the rescan worker during umount).
Signed-off-by: Justin Maggard
---
tests/btrfs/114 | 61
This test case tests if we are able to disable quotas on a filesystem
while a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: fix quota disable during rescan).
Signed-off-by: Justin Maggard
---
tests/btrfs/115
This test case writes into pre-allocated space, then tries to fallocate
some more within the defined quota limit. Currently (4.14-rc7) this fails
with EDQUOT due to quota reservation leakage when writing into pre-
allocated space.
A possible fix has been sent to the ML as "btrfs: Fix quota reserva
This test case tests if we are able to unmount a filesystem while
a quota rescan is running. Up to now (4.3-rc4) this would result
in a kernel NULL pointer dereference.
Signed-off-by: Justin Maggard
---
tests/btrfs/104 | 85 +
tests/btrfs/
This test case does some concurrent send/receives with qgroups enabled.
Currently (4.13-rc1) this usually results in btrfs check errors, and
often also results in a WARN_ON in record_root_in_trans().
Bisecting points to 6426c7ad697d (btrfs: qgroup: Fix qgroup accounting
when creating snapshot) as
This test case does some concurrent send/receives with qgroups enabled.
Currently (4.14-rc7) this usually results in btrfs check errors, and
often also results in a WARN_ON in record_root_in_trans().
Bisecting points to 6426c7ad697d (btrfs: qgroup: Fix qgroup accounting
when creating snapshot) as
13 matches
Mail list logo
