public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-kernel@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [GIT PULL] Btrfs changes for 4.15
Date: Wed, 15 Nov 2017 19:59:31 +0000 (UTC)	[thread overview]
Message-ID: <pan$a87f7$14ce08a6$44fb79ac$83820ead@cox.net> (raw)
In-Reply-To: abc907f7-b4de-c999-95cd-b241589a5305@gmx.com

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

      parent reply	other threads:[~2017-11-15 19:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 15:35 [GIT PULL] Btrfs changes for 4.15 David Sterba
2017-11-13 23:39 ` Qu Wenruo
2017-11-14 14:50   ` David Sterba
2017-11-15 19:59   ` Duncan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$a87f7$14ce08a6$44fb79ac$83820ead@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox