[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <pan$a87f7$14ce08a6$44fb79ac$83820ead@cox.net>
Date: Wed, 15 Nov 2017 19:59:31 +0000 (UTC)
From: Duncan <1i5t5.duncan@....net>
To: linux-kernel@...r.kernel.org
Cc: linux-btrfs@...r.kernel.org
Subject: Re: [GIT PULL] Btrfs changes for 4.15
Qu Wenruo posted on Tue, 14 Nov 2017 07:39:11 +0800 as excerpted:
>> New features:
>>
>> - extend mount options to specify zlib compression level, -o
>> compress=zlib:9
>
> However the support for it has a big problem, it will cause wild memory
> access for "-o compress" mount option.
>
> Kernel ASAN can detect it easily and we already have user report about
> it. Btrfs/026 could also easily trigger it.
>
> The fixing patch is submitted some days ago:
> https://patchwork.kernel.org/patch/10042553/
>
> And the default compression level when not specified is zero, which
> means no compression but directly memory copy.
When not specified means ???
There's a couple possibilities:
* -o compress (zlib as default, no compression level specified)
* -o compress=zlib (zlib specified, no compression level specified)
Maybe both are considered unspecified and thus no compression, now?
Regardless, defaulting to zero compression changes current behavior,
doesn't it? It's also entirely unintuitive that specifying compression
means _no_ compression.
With both that and the wild memory access being known issues, why is this
being merged without the known fix (at least to the wild memory access)
folded in, potentially breaking bisects even if people are more careful
than to start testing pre-rc1.
-o compress=lzo continues to work as expected, I hope?
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Powered by blists - more mailing lists