2015-05-23 01:14:38

by Chris Mason

[permalink] [raw]
Subject: [GIT PULL] Btrfs

Hi Linus,

My for-linus-4.1 branch has three more fixes:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.1

I fixed up a regression from 4.0 where conversion between different raid
levels would sometimes bail out without converting.

Filipe tracked down a race where it was possible to double allocate
chunks on the drive.

Mark has a fix for fiemap. All three will get bundled off for stable as
well.

Chris Mason (1) commits (+18/-0):
Btrfs: fix regression in raid level conversion

Filipe Manana (1) commits (+3/-0):
Btrfs: fix racy system chunk allocation when setting block group ro

Mark Fasheh (1) commits (+17/-0):
btrfs: clear 'ret' in btrfs_check_shared() loop

Total: (3) commits

fs/btrfs/backref.c | 17 +++++++++++++++++
fs/btrfs/extent-tree.c | 20 ++++++++++++++++++++
fs/btrfs/volumes.c | 1 +
3 files changed, 38 insertions(+)


2015-05-26 12:35:01

by Josh Boyer

[permalink] [raw]
Subject: Re: [GIT PULL] Btrfs

On Fri, May 22, 2015 at 9:14 PM, Chris Mason <[email protected]> wrote:
> Hi Linus,
>
> My for-linus-4.1 branch has three more fixes:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.1
>
> I fixed up a regression from 4.0 where conversion between different raid
> levels would sometimes bail out without converting.
>
> Filipe tracked down a race where it was possible to double allocate
> chunks on the drive.
>
> Mark has a fix for fiemap. All three will get bundled off for stable as
> well.
>
> Chris Mason (1) commits (+18/-0):
> Btrfs: fix regression in raid level conversion

Shouldn't this be CC'd to stable since it fixes a broken commit in 4.0?

josh

2015-05-26 13:23:09

by Chris Mason

[permalink] [raw]
Subject: Re: [GIT PULL] Btrfs

On 05/26/2015 08:33 AM, Josh Boyer wrote:
> On Fri, May 22, 2015 at 9:14 PM, Chris Mason <[email protected]> wrote:
>> Hi Linus,
>>
>> My for-linus-4.1 branch has three more fixes:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.1
>>
>> I fixed up a regression from 4.0 where conversion between different raid
>> levels would sometimes bail out without converting.
>>
>> Filipe tracked down a race where it was possible to double allocate
>> chunks on the drive.
>>
>> Mark has a fix for fiemap. All three will get bundled off for stable as
>> well.
>>
>> Chris Mason (1) commits (+18/-0):
>> Btrfs: fix regression in raid level conversion
>
> Shouldn't this be CC'd to stable since it fixes a broken commit in 4.0?

Yes, I'm retesting two of these against 4.0

-chris

2015-06-02 14:02:57

by Josh Boyer

[permalink] [raw]
Subject: Re: [GIT PULL] Btrfs

On Tue, May 26, 2015 at 8:54 AM, Chris Mason <[email protected]> wrote:
> On 05/26/2015 08:33 AM, Josh Boyer wrote:
>> On Fri, May 22, 2015 at 9:14 PM, Chris Mason <[email protected]> wrote:
>>> Hi Linus,
>>>
>>> My for-linus-4.1 branch has three more fixes:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.1
>>>
>>> I fixed up a regression from 4.0 where conversion between different raid
>>> levels would sometimes bail out without converting.
>>>
>>> Filipe tracked down a race where it was possible to double allocate
>>> chunks on the drive.
>>>
>>> Mark has a fix for fiemap. All three will get bundled off for stable as
>>> well.
>>>
>>> Chris Mason (1) commits (+18/-0):
>>> Btrfs: fix regression in raid level conversion
>>
>> Shouldn't this be CC'd to stable since it fixes a broken commit in 4.0?
>
> Yes, I'm retesting two of these against 4.0

Did you finish up testing the two commits? I might have missed it,
but I haven't seen anything being requested to the 4.0.y stable tree
yet.

josh

2015-06-26 14:21:44

by David Sterba

[permalink] [raw]
Subject: Re: [GIT PULL] Btrfs

On Tue, Jun 02, 2015 at 10:02:49AM -0400, Josh Boyer wrote:
> >>> Chris Mason (1) commits (+18/-0):
> >>> Btrfs: fix regression in raid level conversion
> >>
> >> Shouldn't this be CC'd to stable since it fixes a broken commit in 4.0?
> >
> > Yes, I'm retesting two of these against 4.0
>
> Did you finish up testing the two commits? I might have missed it,
> but I haven't seen anything being requested to the 4.0.y stable tree
> yet.

JFYI, fixed in 4.0.6 .