On Sun, Oct 23, 2016 at 05:32:21PM -0400, Chris Mason wrote:
>
>
> On 10/22/2016 11:20 AM, Dave Jones wrote:
> > On Fri, Oct 21, 2016 at 04:02:45PM -0400, Dave Jones wrote:
> >
> > > > It could be worth trying this, too:
> > > >
> > > >
> > https://git.kernel.org/cgit/linux/kernel
At 10/24/2016 10:43 AM, Qu Wenruo wrote:
Ebs and pointers are allocated, but if any of the allocation failed, we
should free the allocated memory.
Reported-by: David Sterba
Resolves-Coverity-CID: 1296749
Sorry, wrong CID here,
Correct ones are:
Resolves-Coverity-CID: 1374101
Resolves-Coveri
In get_running_kernel_version() function, we directly pass return
pointer from strtok_r() to string_is_numberical().
Return pointer from strok_r() can be NULL, but string_is_numberical()
can't handle it and will cause NULL pointer derefernces.
Fix it by check if it's a NULL pointer first.
Report
Ebs and pointers are allocated, but if any of the allocation failed, we
should free the allocated memory.
Reported-by: David Sterba
Resolves-Coverity-CID: 1296749
Signed-off-by: Qu Wenruo
---
volumes.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/volumes.c b/volumes.c
We didn't check 'path' allocated in check_root_ref(), which can cause
NULL pointer dereference if the memory allocation failed.
Fix it by using stack memory, since the function should return error
bitmap not minus error code, we don't want memory allocation to be an
exception.
Reported-by: David
Allocated 'path' in check_fs_first_inode() is not checked and for
btrfs_search_slot() error, it will leak 'path'.
Fix it.
Reported-by: David Sterba
Resolves-Coverity-CID: 1374098
Resolves-Coverity-CID: 1374099
Signed-off-by: Qu Wenruo
---
cmds-check.c | 5 -
1 file changed, 4 insertions(+)
You could try to use --mode lowmem, which doesn't ever use any loop to
get next block, but iterating trees.
Current in mainline btrfs-progs, the low memory mode code only checks
extent/chunk trees, file/subvolume trees are still checked by original mode.
You could try the devel branch from Da
You must have moved HEAD from previous version, and didn't run make clean.
It is the *.o.d telling gcc which headers they need.
And those *.o.d files are ignored by git, so it won't be cleaned by git
reset.
So the correct work flow is:
0) make clean
1) autogen
2) configure
3) make
Thanks,
Qu
On 10/22/2016 11:20 AM, Dave Jones wrote:
On Fri, Oct 21, 2016 at 04:02:45PM -0400, Dave Jones wrote:
> > It could be worth trying this, too:
> >
> >
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=174531fef4e8
> >
> > It occurred to me that t
Hello,
I have the following bug
https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is
there a way to recover my filesystem in clean state without formatting
or using btrsfck ? Of course, the point is no longer need the files
which are damaged.
So is there a way to recover a btr
Hello list,
just wanted to report that my ENOSPC errors are gone. Thanks to wang for
his great patches.
but the space_info corruption still occours.
On every umount i see:
[93022.166222] BTRFS: space_info 4 has 208952672256 free, is not full
[93022.166224] BTRFS: space_info total=363998478336, u
Hello list,
just want to report again that i've seen not a single ENOSPC msg with
this series applied.
Now working fine since 18 days.
Stefan
Am 14.10.2016 um 15:09 schrieb Stefan Priebe - Profihost AG:
>
> Am 06.10.2016 um 04:51 schrieb Wang Xiaoguang:
>> This issue was revealed by modifying
12 matches
Mail list logo
