[GIT PULL] bcache changes for 3.17

[Kent Overstreet]

Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

The following changes since commit 4c834452aad01531db949414f94f817a86348d59:

Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)

are available in the git repository at:

http://evilpiepirate.org/git/linux-bcache.git for-jens

for you to fetch changes up to 0781c8748cf1ea2b0dcd966571103909528c4efa:

bcache: Drop unneeded blk_sync_queue() calls (2014-08-04 15:23:04 -0700)

----------------------------------------------------------------
Jianjian Huo (1):
bcache: add mutex lock for bch_is_open

Kent Overstreet (7):
bcache: Fix a bug when detaching
bcache: Fix a journal replay bug
bcache: Make sure to pass GFP_WAIT to mempool_alloc()
bcache: Allocate bounce buffers with GFP_NOWAIT
bcache: Fix an infinite loop in journal replay
bcache: Fix more early shutdown bugs
bcache: Drop unneeded blk_sync_queue() calls

Slava Pestov (12):
bcache allocator: send discards with correct size
bcache: fix lockdep warnings on shutdown
bcache: fix crash on shutdown in passthrough mode
bcache: wait for buckets when allocating new btree root
bcache: fix uninterruptible sleep in writeback thread
bcache: fix typo in bch_bkey_equal_header
bcache: bcache_write tracepoint was crashing
bcache: fix crash in bcache_btree_node_alloc_fail tracepoint
bcache: fix use-after-free in btree_gc_coalesce()
bcache: fix crash with incomplete cache set
bcache: fix memory corruption in init error path
bcache: try to set b->parent properly

Surbhi Palande (2):
bcache: Fix to remove the rcu_sched stalls.
bcache: Correct printing of btree_gc_max_duration_ms

drivers/md/bcache/alloc.c | 2 +-
drivers/md/bcache/bcache.h | 4 +++
drivers/md/bcache/bset.c | 2 +-
drivers/md/bcache/bset.h | 2 +-
drivers/md/bcache/btree.c | 50 ++++++++++++++++++++++---------------
drivers/md/bcache/btree.h | 5 ++--
drivers/md/bcache/extents.c | 13 +++++++---
drivers/md/bcache/extents.h | 1 +
drivers/md/bcache/journal.c | 24 +++++++++++-------
drivers/md/bcache/request.c | 3 ++-
drivers/md/bcache/super.c | 57 ++++++++++++++++++++++++++++---------------
drivers/md/bcache/util.h | 4 +--
drivers/md/bcache/writeback.c | 14 ++++++++---
drivers/md/bcache/writeback.h | 3 ++-
include/trace/events/bcache.h | 21 +++++++++-------
15 files changed, 131 insertions(+), 74 deletions(-)

[Jens Axboe]

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

[Peter Kieser]

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

-Peter

[Francis Moreau]

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?

If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

Thanks

[Jens Axboe]

Post by Francis Moreau

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?
If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

We need to do something about this. From this latest pull, looks like
all should go to stable:

5b1016e62f74c53e0330403025954c8d95384c03
9aa61a992acceeec0d1de2cd99938421498659d5
dbd810ab678d262d3772d29b65844d7b20dc47bc
8b326d3a2a76912dfed2f0ab937d59fae9512ca2
e5112201c1285841f8b565ece5d6ae7e0d7947a2
a664d0f05a2ec02c8f042db536d84d15d6e19e81
c5aa4a3157b55bdca18dd2a9d9f43314470b6d32
9e5c353510b26500bd6b8309823ac9ef2837b761
bcf090e0040e30f8409e6a535a01e6473afb096f
501d52a90cbe652b41336c206ff0e95799d5a9b5
8e0948080670f6330229718b15a6a1a011d441ce
60ae81eee86dd7a520db8c1e3d702b49fc0418b5
913dc33fb2720fb5f979011664294137ddd8b13b
6b708de64adb6dc8319e7aeac922b46904fbeeec
400ffaa2acd72274e2c7293a9724382383bebf3e
d83353b319d47ef8cce82467da6a25c2d558253f
bf0c55c986540483c34ca640f2eef4c3314388b1
c9a78332b42cbdcdd386a95192a716b67d1711a4
2452cc89063a2a6890368f185c4b6d7d8802175b
25abade29616d42d60f9bd5e6a5ad07f7314e39e
5b25abade29616d42d60f9bd5e6a5ad07f7314e3
789d21dbd9d8889e62c79ec19585fcc97e42ef07
0781c8748cf1ea2b0dcd966571103909528c4efa

(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

[Vasiliy Tolstov]

Post by Jens Axboe
We need to do something about this. From this latest pull, looks like
5b1016e62f74c53e0330403025954c8d95384c03
9aa61a992acceeec0d1de2cd99938421498659d5
dbd810ab678d262d3772d29b65844d7b20dc47bc
8b326d3a2a76912dfed2f0ab937d59fae9512ca2
e5112201c1285841f8b565ece5d6ae7e0d7947a2
a664d0f05a2ec02c8f042db536d84d15d6e19e81
c5aa4a3157b55bdca18dd2a9d9f43314470b6d32
9e5c353510b26500bd6b8309823ac9ef2837b761
bcf090e0040e30f8409e6a535a01e6473afb096f
501d52a90cbe652b41336c206ff0e95799d5a9b5
8e0948080670f6330229718b15a6a1a011d441ce
60ae81eee86dd7a520db8c1e3d702b49fc0418b5
913dc33fb2720fb5f979011664294137ddd8b13b
6b708de64adb6dc8319e7aeac922b46904fbeeec
400ffaa2acd72274e2c7293a9724382383bebf3e
d83353b319d47ef8cce82467da6a25c2d558253f
bf0c55c986540483c34ca640f2eef4c3314388b1
c9a78332b42cbdcdd386a95192a716b67d1711a4
2452cc89063a2a6890368f185c4b6d7d8802175b
25abade29616d42d60f9bd5e6a5ad07f7314e39e
5b25abade29616d42d60f9bd5e6a5ad07f7314e3
789d21dbd9d8889e62c79ec19585fcc97e42ef07
0781c8748cf1ea2b0dcd966571103909528c4efa
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

I'm interesting on backporting this to 3.14.y

[Jens Axboe]

Post by Vasiliy Tolstov

Post by Jens Axboe
We need to do something about this. From this latest pull, looks like
5b1016e62f74c53e0330403025954c8d95384c03
9aa61a992acceeec0d1de2cd99938421498659d5
dbd810ab678d262d3772d29b65844d7b20dc47bc
8b326d3a2a76912dfed2f0ab937d59fae9512ca2
e5112201c1285841f8b565ece5d6ae7e0d7947a2
a664d0f05a2ec02c8f042db536d84d15d6e19e81
c5aa4a3157b55bdca18dd2a9d9f43314470b6d32
9e5c353510b26500bd6b8309823ac9ef2837b761
bcf090e0040e30f8409e6a535a01e6473afb096f
501d52a90cbe652b41336c206ff0e95799d5a9b5
8e0948080670f6330229718b15a6a1a011d441ce
60ae81eee86dd7a520db8c1e3d702b49fc0418b5
913dc33fb2720fb5f979011664294137ddd8b13b
6b708de64adb6dc8319e7aeac922b46904fbeeec
400ffaa2acd72274e2c7293a9724382383bebf3e
d83353b319d47ef8cce82467da6a25c2d558253f
bf0c55c986540483c34ca640f2eef4c3314388b1
c9a78332b42cbdcdd386a95192a716b67d1711a4
2452cc89063a2a6890368f185c4b6d7d8802175b
25abade29616d42d60f9bd5e6a5ad07f7314e39e
5b25abade29616d42d60f9bd5e6a5ad07f7314e3
789d21dbd9d8889e62c79ec19585fcc97e42ef07
0781c8748cf1ea2b0dcd966571103909528c4efa
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

I'm interesting on backporting this to 3.14.y

Before that can happen, you would probably need to comb the 3.15 and
3.16 bcache inclusions and dig out any potential stable candidates there
too.

[Francis Moreau]

Post by Jens Axboe
We need to do something about this. From this latest pull, looks like
5b1016e62f74c53e0330403025954c8d95384c03
9aa61a992acceeec0d1de2cd99938421498659d5
dbd810ab678d262d3772d29b65844d7b20dc47bc
8b326d3a2a76912dfed2f0ab937d59fae9512ca2
e5112201c1285841f8b565ece5d6ae7e0d7947a2
a664d0f05a2ec02c8f042db536d84d15d6e19e81
c5aa4a3157b55bdca18dd2a9d9f43314470b6d32
9e5c353510b26500bd6b8309823ac9ef2837b761
bcf090e0040e30f8409e6a535a01e6473afb096f
501d52a90cbe652b41336c206ff0e95799d5a9b5
8e0948080670f6330229718b15a6a1a011d441ce
60ae81eee86dd7a520db8c1e3d702b49fc0418b5
913dc33fb2720fb5f979011664294137ddd8b13b
6b708de64adb6dc8319e7aeac922b46904fbeeec
400ffaa2acd72274e2c7293a9724382383bebf3e
d83353b319d47ef8cce82467da6a25c2d558253f
bf0c55c986540483c34ca640f2eef4c3314388b1
c9a78332b42cbdcdd386a95192a716b67d1711a4
2452cc89063a2a6890368f185c4b6d7d8802175b
25abade29616d42d60f9bd5e6a5ad07f7314e39e
5b25abade29616d42d60f9bd5e6a5ad07f7314e3
789d21dbd9d8889e62c79ec19585fcc97e42ef07
0781c8748cf1ea2b0dcd966571103909528c4efa
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Then if it's too much work, it just confirmed what was asked previously:
bcache is still experimental so mark it such for stable kernels.

I wouldn't have used bcache in that case.

Thanks

[Greg KH]

Post by Francis Moreau

Post by Jens Axboe
We need to do something about this. From this latest pull, looks like
5b1016e62f74c53e0330403025954c8d95384c03
9aa61a992acceeec0d1de2cd99938421498659d5
dbd810ab678d262d3772d29b65844d7b20dc47bc
8b326d3a2a76912dfed2f0ab937d59fae9512ca2
e5112201c1285841f8b565ece5d6ae7e0d7947a2
a664d0f05a2ec02c8f042db536d84d15d6e19e81
c5aa4a3157b55bdca18dd2a9d9f43314470b6d32
9e5c353510b26500bd6b8309823ac9ef2837b761
bcf090e0040e30f8409e6a535a01e6473afb096f
501d52a90cbe652b41336c206ff0e95799d5a9b5
8e0948080670f6330229718b15a6a1a011d441ce
60ae81eee86dd7a520db8c1e3d702b49fc0418b5
913dc33fb2720fb5f979011664294137ddd8b13b
6b708de64adb6dc8319e7aeac922b46904fbeeec
400ffaa2acd72274e2c7293a9724382383bebf3e
d83353b319d47ef8cce82467da6a25c2d558253f
bf0c55c986540483c34ca640f2eef4c3314388b1
c9a78332b42cbdcdd386a95192a716b67d1711a4
2452cc89063a2a6890368f185c4b6d7d8802175b
25abade29616d42d60f9bd5e6a5ad07f7314e39e
5b25abade29616d42d60f9bd5e6a5ad07f7314e3
789d21dbd9d8889e62c79ec19585fcc97e42ef07
0781c8748cf1ea2b0dcd966571103909528c4efa
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

bcache is still experimental so mark it such for stable kernels.

You seem to have a misunderstanding of just exactly what the stable
kernels are, and what they are for. See my other email for details.

greg k-h

[Eddie Chapman]

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in
production on 3.10! Shame I don't have the knowledge to try and backport
these though :-)

Eddie

[Peter Kieser]

Post by Eddie Chapman

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in
production on 3.10! Shame I don't have the knowledge to try and
backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.

-Peter

[Arne Wiebalck]

Post by Peter Kieser

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in production on 3.10! Shame I don't have the knowledge to try and backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.
-Peter

More "piping up": we currently use bcache on a few nodes in production, on 3.14 and 3.15, and plan to roll it out on a wider scale now.
If necessary we'll go with these kernels, but we'd certainly prefer our usual 3.10-based CentOS kernel.

Cheers,
Arne

--
Arne Wiebalck
CERN IT

[Jens Axboe]

Post by Arne Wiebalck

Post by Peter Kieser

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in production on 3.10! Shame I don't have the knowledge to try and backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.
-Peter

More "piping up": we currently use bcache on a few nodes in production, on 3.14 and 3.15, and plan to roll it out on a wider scale now.
If necessary we'll go with these kernels, but we'd certainly prefer our usual 3.10-based CentOS kernel.

OK, so we definitely have people using it in production. My concern was
that whomever does the backport of the appropriate patches to 3.10/14/15
stable would have an audience for getting some amount of testing of such
a patch series.

Now we just need someone to line up to do the work...

[Kent Overstreet]

Post by Jens Axboe

Post by Arne Wiebalck

Post by Peter Kieser

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in production on 3.10! Shame I don't have the knowledge to try and backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.
-Peter

More "piping up": we currently use bcache on a few nodes in production, on 3.14 and 3.15, and plan to roll it out on a wider scale now.
If necessary we'll go with these kernels, but we'd certainly prefer our usual 3.10-based CentOS kernel.

OK, so we definitely have people using it in production. My concern was
that whomever does the backport of the appropriate patches to 3.10/14/15
stable would have an audience for getting some amount of testing of such
a patch series.
Now we just need someone to line up to do the work...

I can try and make some time for backporting; if we've got people lined up for
testing that will help a lot.

Backporting fixes to 3.10 will be harder, but if memory serves there hasn't been
as much churn since 3.14 so backporting fixes to then shouldn't be too bad. If
Stefan wants to post what he's got for 3.10 though I can try and backport some
more fixes on top of that, though

[Stefan Priebe]

Post by Kent Overstreet

Post by Jens Axboe

Post by Arne Wiebalck

Post by Peter Kieser

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3, going
all the way back to 3.10 would be a lot of work. If there's anyone that
cares about bcache on stable kernels (and actually use it), now would be
a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in production on 3.10! Shame I don't have the knowledge to try and backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.
-Peter

More "piping up": we currently use bcache on a few nodes in production, on 3.14 and 3.15, and plan to roll it out on a wider scale now.
If necessary we'll go with these kernels, but we'd certainly prefer our usual 3.10-based CentOS kernel.

OK, so we definitely have people using it in production. My concern was
that whomever does the backport of the appropriate patches to 3.10/14/15
stable would have an audience for getting some amount of testing of such
a patch series.
Now we just need someone to line up to do the work...

I can try and make some time for backporting; if we've got people lined up for
testing that will help a lot.
Backporting fixes to 3.10 will be harder, but if memory serves there hasn't been
as much churn since 3.14 so backporting fixes to then shouldn't be too bad. If
Stefan wants to post what he's got for 3.10 though I can try and backport some
more fixes on top of that, though

You'll find them here:
https://github.com/profihost/linux-stable/commits/bcache_latest_fixes

Most probably you don't want the last four.

Stefan

Post by Kent Overstreet
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Chuck Ebbert]

On Fri, 5 Sep 2014 17:03:57 +0000

Post by Arne Wiebalck

Post by Peter Kieser

Post by Eddie Chapman

Post by Jens Axboe
(from oldest to newest). And that's just from 3.16 to 3.17-rc3,
going all the way back to 3.10 would be a lot of work. If there's
anyone that cares about bcache on stable kernels (and actually
use it), now would be a good time to pipe up.

Just "piping up" as I care about bcache and actually use it in
production on 3.10! Shame I don't have the knowledge to try and
backport these though :-)
Eddie

I'm "piping up" as well, I use bcache on 3.10 in production.
-Peter

More "piping up": we currently use bcache on a few nodes in
production, on 3.14 and 3.15, and plan to roll it out on a wider
scale now. If necessary we'll go with these kernels, but we'd
certainly prefer our usual 3.10-based CentOS kernel.

CentOS does not ship bcache at all. In retrospect it's obvious why.

[Greg KH]

Post by Francis Moreau

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?
If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

WTF?

Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does _NOT_ mean the code is
"unstable/expreimental" at all.

That's not how stable kernel releases work. _IF_ a maintainer wants to
/ has the time to, they can mark patches for inclusion in stable kernel
releases. Given the huge list of patches that Jens just posted, I doubt
that those are really something I would ever take for a stable kernel
release.

Please read Documentation/stable_kernel_rules.txt for more details
please. And don't ask others to do backporting work for you, it's not
ok, and is something that I have always said is never required, and is
not going to be.

thanks,

greg k-h

[Jens Axboe]

Post by Greg KH

Post by Francis Moreau

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?
If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

WTF?
Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does _NOT_ mean the code is
"unstable/expreimental" at all.

That's not what he is saying at all. The code IS unstable in 3.10. And
the fact that nothing goes to stable for bcache, the situation wasn't
likely to change for 3.10. Nobody is saying "Oh nothing goes to stable,
lets mark it experimental".

Post by Greg KH
That's not how stable kernel releases work. _IF_ a maintainer wants to
/ has the time to, they can mark patches for inclusion in stable kernel
releases. Given the huge list of patches that Jens just posted, I doubt
that those are really something I would ever take for a stable kernel
release.

Actually, all of those are pretty much stable material, since they fix
actual bugs that people hit. Which is the definition of what should go
to stable.

[Greg KH]

Post by Jens Axboe

Post by Greg KH

Post by Francis Moreau

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?
If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

WTF?
Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does _NOT_ mean the code is
"unstable/expreimental" at all.

That's not what he is saying at all. The code IS unstable in 3.10. And
the fact that nothing goes to stable for bcache, the situation wasn't
likely to change for 3.10. Nobody is saying "Oh nothing goes to stable,
lets mark it experimental".

Sorry, but with only the context above which is what I was sent, you can
see how I can be confused here...

greg k-h

[Peter Kieser]

Post by Greg KH
Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does_NOT_ mean the code is
"unstable/expreimental" at all.

These are more bcache-ate-my-data unstable bugs. It's standard practice
to backport fixes that cause instability/data corruption to a 'stable'
release (otherwise, why would it be named 'stable')?

-Peter

[Greg KH]

Post by Greg KH
Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does_NOT_ mean the code is
"unstable/expreimental" at all.

These are more bcache-ate-my-data unstable bugs. It's standard practice to
backport fixes that cause instability/data corruption to a 'stable' release
(otherwise, why would it be named 'stable')?

That's fine, but it has nothing to do with what sounded like someone
wanting to go back and mark an older kernel feature as "unsupported".

greg k-h

[Francis Moreau]

Post by Greg KH

Post by Francis Moreau

Post by Peter Kieser

Post by Jens Axboe

Post by Kent Overstreet
Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

Normally I'd say no, but since it's basically just fixes, I guess we can
pull it in. But generally, it has to be in my hands a week before this,
so it can simmer a bit in for-next before going in...

Are these fixes going to be backported to 3.10 or other stable releases?

Could you please answer this question ?
If you don't want to maintain bcache for stable kernels (I can
understand that), can you mark it at least as unstable/experimental
stuff since it really is ?

WTF?
Just because a maintainer/developer doesn't want to do anything for the
stable kernel releases does _NOT_ mean the code is
"unstable/expreimental" at all.
That's not how stable kernel releases work. _IF_ a maintainer wants to
/ has the time to, they can mark patches for inclusion in stable kernel
releases. Given the huge list of patches that Jens just posted, I doubt
that those are really something I would ever take for a stable kernel
release.
Please read Documentation/stable_kernel_rules.txt for more details
please. And don't ask others to do backporting work for you, it's not
ok, and is something that I have always said is never required, and is
not going to be.

wow, not sure why I deserve such anger...

Looks like you haven't understood me well and specially I *never* asked
others to do the backporting for me.

Please reread the thread, perhaps peaceful music can help too.