On 3/1/21 5:28 pm, Su Yue wrote:
Some extent io trees are initialized with NULL private member(e.g., btrfs_devi
ce::alloc_state and btrfs_fs_info::excluded_extents). Dereference of a NULL
@tree->private as struct inode * will cause kernel panic.
Just pass @tree->fs_info as parameter to extent_io
On Sun, Jan 3, 2021 at 9:30 PM André Isidro da Silva
wrote:
>
> I might be in some panic, I'm sorry for the info I'm not experienced
> enough to give.
>
> I was in a live iso trying really hard to repair my root btrfs from
> which I had used all the space avaiable.. I was trying to move a /usr
> p
Hi Yugui,
I can reproduce the issue with your pstack trick. Many thanks! I am
trying to use a larger SEND_BUFFER_SIZE. The strange thing is socket
should never send wrong data. Thanks for the insight, my guess is
scheduling of the splicing-thread causes the problem. I will do more
investigation.
I might be in some panic, I'm sorry for the info I'm not experienced
enough to give.
I was in a live iso trying really hard to repair my root btrfs from
which I had used all the space avaiable.. I was trying to move a /usr
partition into the btrfs system, but I didn't check the space available
Hi Yugui,
Thanks for the testing! The error message from your two failed cases
shows that sender is still working on splice. So I made two patches:
- directly write to socket, instead of writing to pipe: on my
computer, it is much slower to do so
- enlarge pipe buffer size
I am not sure whether
The problem is worse on SSD than on HDD. It actually makes the SSD
*slower* than an HDD, on 5.10. For this workload
HDD
5.9.16-200.fc33.x86_64
mq-deadline kyber [bfq] none
$ time tar -xf /tmp/firefox-85.0b4.source.tar.xz && time sync
real1m27.299s
user0m27.294s
sys0m14.134s
real
I would like to create a btrfs raid array where one device (either hard drive,
SSD or flash drive) can fail, and all the data survives.
Also, I would like to have a write cache in front of all the mechanical drives,
so they can stay idle until the write cache if full, or data is requested that
Hi, Sheng
Now we can reproduce this CRC error.
client is running
/usr/bin/time btrfs-5.9 send --conn-addr 10.0.0.76 --tcp-port 8080
/archive/movie2
server is running
/usr/bin/time btrfs-5.9 receive --listen-addr :: --tcp-port 8080 --dump
On client, the command pstack 13623(pid
On Sun 03 Jan 2021 at 14:52, Qu Wenruo
wrote:
On 2021/1/3 下午1:01, Su Yue wrote:
while mounting the poc image user-provided, kernel panics due
to the
NULL deference of @tree->inode.
[ 109.663024] BTRFS error: found n
while mounting the poc image user-provided, kernel panics due to the
invalid chunk item whose end is less than start.
[ 66.387422] loop: module loaded
[ 66.389773] loop0: detected capacity change from 262144 to 0
[ 66.42
Some extent io trees are initialized with NULL private member(e.g., btrfs_devi
ce::alloc_state and btrfs_fs_info::excluded_extents). Dereference of a NULL
@tree->private as struct inode * will cause kernel panic.
Just pass @tree->fs_info as parameter to extent_io_tree_panic() directly.
Let it pani
The two patches fix issues found by the image which is provided by
Insu Yun at SSLab@Gatech.
patch 1 fixes a NULL pointer dereference in error handling path.
patch 2 enhances tree checker to detect chunk item end overflow.
Su Yue (2):
btrfs: prevent NULL pointer dereference in extent_io_tree_pa
12 matches
Mail list logo
