On 12.08.19 г. 21:14 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> At ctree.c:get_old_root(), we are accessing a root's header owner field
> after we have freed the respective extent buffer. This results in an
> use-after-free that can lead to crashes, and when CONFIG_DEBUG_PAGEALLO
On 12.08.19 г. 17:36 ч., Vladimir Panteleev wrote:
> Hi Nikolay,
>
> Thank you for looking at my patch!
>
> You are completely correct in that this pampers over a bug I do not
> understand. And, I would very much like to understand and fix the
> underlying bug instead of settling for a workaro
On Mon, Aug 12, 2019 at 7:48 PM Omar Sandoval wrote:
>
> On Mon, Aug 12, 2019 at 12:38:55PM +0100, Filipe Manana wrote:
> > On Tue, Aug 6, 2019 at 6:48 PM Omar Sandoval wrote:
> > >
> > > From: Omar Sandoval
> > >
> > > We hit a the following very strange deadlock on a system with Btrfs on a
> >
On Mon, Aug 12, 2019 at 12:38:55PM +0100, Filipe Manana wrote:
> On Tue, Aug 6, 2019 at 6:48 PM Omar Sandoval wrote:
> >
> > From: Omar Sandoval
> >
> > We hit a the following very strange deadlock on a system with Btrfs on a
> > loop device backed by another Btrfs filesystem:
> >
> > 1. The top
From: Filipe Manana
At ctree.c:get_old_root(), we are accessing a root's header owner field
after we have freed the respective extent buffer. This results in an
use-after-free that can lead to crashes, and when CONFIG_DEBUG_PAGEALLOC
is set, results in a stack trace like the following:
[ 3876.
On 12.08.19 г. 20:38 ч., Diego Calleja wrote:
> extent_io.c:__extent_writepage_io has this code:
>
> if (!compressed)
> ...
> else if (compressed)
>
>
> Signed-off-by: Diego Calleja
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/extent_io.c | 2 +-
> 1 file changed, 1 insertion(+),
extent_io.c:__extent_writepage_io has this code:
if (!compressed)
...
else if (compressed)
Signed-off-by: Diego Calleja
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1ff438fd5bc2..a53fb7b8a
On Sun, Aug 11, 2019 at 11:43 PM Qu Wenruo wrote:
>
>
>
> On 2019/8/12 上午10:27, Chris Murphy wrote:
> > I'm not sure this is a bug, but I'm also not sure if the behavior is
> > expected.
> >
> > Test system as follows:
> >
> > Intel i7-2820QM, 4/8 cores
> > 8 GiB RAM, 8 GiB swap on SSD plain part
Hi Nikolay,
Thank you for looking at my patch!
You are completely correct in that this pampers over a bug I do not
understand. And, I would very much like to understand and fix the
underlying bug instead of settling for a workaround.
Unfortunately, after three days of looking at BTRFS code (and
On 8/3/19 3:30 AM, Goldwyn Rodrigues wrote:
From: Goldwyn Rodrigues
Add btrfs_dio_iomap_ops for iomap.begin() function. In order to
accomodate dio reads, add a new function btrfs_file_read_iter()
which would call btrfs_dio_iomap_read() for DIO reads and
fallback to generic_file_read_iter othe
On Tue, Aug 6, 2019 at 6:48 PM Omar Sandoval wrote:
>
> From: Omar Sandoval
>
> We hit a the following very strange deadlock on a system with Btrfs on a
> loop device backed by another Btrfs filesystem:
>
> 1. The top (loop device) filesystem queues an async_cow work item from
>cow_file_range
On 25.07.19 г. 12:34 ч., Johannes Thumshirn wrote:
> update_block_csum() in btrfs-sb-mod.c is always called with the 'is_sb'
> argument set to 1.
>
> Get rid of the special case for is_sb == 0.
>
> Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
> ---
> btrfs-sb-mod.c | 19
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
So patches 12/13 have identical titles, different contents and
absolutely no commit messages :( . How about no... Squash 13 into 12 and
put a commit explaining your change. And by the way the patch's title
doesn't correspond to the content of t
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> Add the checksum type to csum_tree_block_size(), __csum_tree_block_size()
> and verify_tree_block_csum_silent().
>
> Signed-off-by: Johannes Thumshirn
> ---
> btrfs-corrupt-block.c | 3 ++-
> cmds/rescue-chunk-recover.c | 3 ++-
> c
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> Pass in a btrfs_mkfs_config to write_temp_extent_buffer(), this is needed
> so we can grab the checksum type for checksum buffer verification in later
> patches.
>
> Signed-off-by: Johannes Thumshirn
Reviewed-by: Nikolay Borisov
> ---
>
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> Cache the super-block's checksum type field in 'struct recover_control'.
> This will be needed for further refactoring the checksum handling.
>
> Signed-off-by: Johannes Thumshirn
> ---
Reviewed-by: Nikolay Borisov
> cmds/rescue-chunk-r
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> The callers of csum_tree_block_size() blindly assume we're only having
> crc32c as a possible checksum and thus pass in
> btrfs_csum_sizes[BTRFS_CSUM_TYPE_CRC32] for the size argument of
> csum_tree_block_size().
>
> Signed-off-by: Johannes T
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> Add an option to mkfs to specify which checksum algorithm will be used for
> the filesystem.
>
> XXX this patch should go last in the series.
>
> Signed-off-by: Johannes Thumshirn
> --- a/mkfs/main.c
> +++ b/mkfs/main.c
> @@ -346,6 +346,
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> From: David Sterba
>
> Export supported checksum algorithms via sysfs.
>
> Signed-off-by: David Sterba
> Signed-off-by: Johannes Thumshirn
> ---
> fs/btrfs/sysfs.c | 35 +++
> 1 file changed, 35 insertions
On 25.07.19 г. 12:33 ч., Johannes Thumshirn wrote:
> Create a structure to encode the type and length for the known on-disk
> checksums. Also add a table and a convenience macro for adding the
> checksum types to the table.
>
> This makes it easier to add new checksums later.
>
> Signed-off-by
On 10.08.19 г. 15:41 ч., Vladimir Panteleev wrote:
> In some circumstances (filesystems with many extents and backrefs),
> the global reserve gets overrun causing balance and device deletion
> operations to fail with -ENOSPC. Providing a way for users to increase
> the global reserve size can al
On 9.08.19 г. 17:55 ч., David Sterba wrote:
> The maximum and default levels do not change and can be defined
> directly. The set_level callback was a temporary solution and will be
> removed.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/compression.h | 4
> fs/btrfs/lzo.c |
On 12.08.19 г. 9:34 ч., Qu Wenruo wrote:
> Kernel is going to reject invalid root generation.
>
> Consider the existing checks are causing some error reports, we should
> handle such problem in advance, so that's the patchset is going to do,
> check and repair such invalid root generation.
>
>
23 matches
Mail list logo
