Re: [Linux-stable-mirror] Patch "bcache: only permit to recovery read error when cache device is clean" has been added to the 4.9-stable tree
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
On 11/27/2017 09:45 AM, Eddie Chapman wrote:
On 27/11/17 16:06, gregkh@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
bcache: only permit to recovery read error when cache device isclean
Hi Greg,
This patch is an important fix for a possible data corruption issue, but it also introduces a bug that can produce read errors under certain circumstances. The issue introduced by this patch is not as severe as the issue it fixes, but can lead to e.g. upper layer fs remounting read only. In my environment upper layer handled it badly and indirectly resulted in data loss (not directly bcache's fault of course).
Michael Lyle CC'd the stable list with a follow up fix for the issue introduced by this patch, on 24th Nov, subject "bcache: recover data from backing when data is clean".
However, the followup fix is not in Linus' tree yet, only in Michael's. I guess that means you can't pick it up yet. Never-the-less I felt it important to point this out here.
It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will go upstream shortly - but yes, probably should not add this one, before both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
thanks,
greg k-h
On Tue, Nov 28, 2017 at 10:06:24AM +0100, Greg KH wrote:
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
On 11/27/2017 09:45 AM, Eddie Chapman wrote:
On 27/11/17 16:06, gregkh@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
bcache: only permit to recovery read error when cache device isclean
Hi Greg,
This patch is an important fix for a possible data corruption issue, but it also introduces a bug that can produce read errors under certain circumstances. The issue introduced by this patch is not as severe as the issue it fixes, but can lead to e.g. upper layer fs remounting read only. In my environment upper layer handled it badly and indirectly resulted in data loss (not directly bcache's fault of course).
Michael Lyle CC'd the stable list with a follow up fix for the issue introduced by this patch, on 24th Nov, subject "bcache: recover data from backing when data is clean".
However, the followup fix is not in Linus' tree yet, only in Michael's. I guess that means you can't pick it up yet. Never-the-less I felt it important to point this out here.
It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will go upstream shortly - but yes, probably should not add this one, before both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
Both now queued up, thanks.
greg k-h
On 04/12/17 10:27, Greg KH wrote:
On Tue, Nov 28, 2017 at 10:06:24AM +0100, Greg KH wrote:
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
On 11/27/2017 09:45 AM, Eddie Chapman wrote:
On 27/11/17 16:06, gregkh@linuxfoundation.org wrote:
This is a note to let you know that I've just added the patch titled
bcache: only permit to recovery read error when cache device isclean
Hi Greg,
This patch is an important fix for a possible data corruption issue, but it also introduces a bug that can produce read errors under certain circumstances. The issue introduced by this patch is not as severe as the issue it fixes, but can lead to e.g. upper layer fs remounting read only. In my environment upper layer handled it badly and indirectly resulted in data loss (not directly bcache's fault of course).
Michael Lyle CC'd the stable list with a follow up fix for the issue introduced by this patch, on 24th Nov, subject "bcache: recover data from backing when data is clean".
However, the followup fix is not in Linus' tree yet, only in Michael's. I guess that means you can't pick it up yet. Never-the-less I felt it important to point this out here.
It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will go upstream shortly - but yes, probably should not add this one, before both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
Both now queued up, thanks.
greg k-h
Hi Greg,
I only see those two queued up for 4.14 and not any earlier kernels. You originally added the first patch to 3.18, 4.4 and 4.9. Are you still planning to add them both to those kernels?
thanks, Eddie
On Mon, Dec 04, 2017 at 11:45:18PM +0000, Eddie Chapman wrote:
On 04/12/17 10:27, Greg KH wrote:
On Tue, Nov 28, 2017 at 10:06:24AM +0100, Greg KH wrote:
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
On 11/27/2017 09:45 AM, Eddie Chapman wrote:
On 27/11/17 16:06, gregkh@linuxfoundation.org wrote: > > This is a note to let you know that I've just added the patch titled > > bcache: only permit to recovery read error when cache device is
clean
Hi Greg,
This patch is an important fix for a possible data corruption issue, but it also introduces a bug that can produce read errors under certain circumstances. The issue introduced by this patch is not as severe as the issue it fixes, but can lead to e.g. upper layer fs remounting read only. In my environment upper layer handled it badly and indirectly resulted in data loss (not directly bcache's fault of course).
Michael Lyle CC'd the stable list with a follow up fix for the issue introduced by this patch, on 24th Nov, subject "bcache: recover data from backing when data is clean".
However, the followup fix is not in Linus' tree yet, only in Michael's. I guess that means you can't pick it up yet. Never-the-less I felt it important to point this out here.
It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will go upstream shortly - but yes, probably should not add this one, before both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
Both now queued up, thanks.
greg k-h
Hi Greg,
I only see those two queued up for 4.14 and not any earlier kernels. You originally added the first patch to 3.18, 4.4 and 4.9. Are you still planning to add them both to those kernels?
Ah, I forgot about that. I'll go queue those up for the next round after these kernels are released in a day or so.
thanks,
greg k-h
On Tue, Dec 05, 2017 at 08:49:56AM +0100, Greg KH wrote:
On Mon, Dec 04, 2017 at 11:45:18PM +0000, Eddie Chapman wrote:
On 04/12/17 10:27, Greg KH wrote:
On Tue, Nov 28, 2017 at 10:06:24AM +0100, Greg KH wrote:
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
On 11/27/2017 09:45 AM, Eddie Chapman wrote: > On 27/11/17 16:06, gregkh@linuxfoundation.org wrote: > > > > This is a note to let you know that I've just added the patch titled > > > > bcache: only permit to recovery read error when cache device is clean
> Hi Greg, > > This patch is an important fix for a possible data corruption issue, but > it also introduces a bug that can produce read errors under certain > circumstances. The issue introduced by this patch is not as severe as > the issue it fixes, but can lead to e.g. upper layer fs remounting read > only. In my environment upper layer handled it badly and indirectly > resulted in data loss (not directly bcache's fault of course). > > Michael Lyle CC'd the stable list with a follow up fix for the issue > introduced by this patch, on 24th Nov, subject "bcache: recover data > from backing when data is clean". > > However, the followup fix is not in Linus' tree yet, only in Michael's. > I guess that means you can't pick it up yet. Never-the-less I felt it > important to point this out here.
It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will go upstream shortly - but yes, probably should not add this one, before both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
Both now queued up, thanks.
greg k-h
Hi Greg,
I only see those two queued up for 4.14 and not any earlier kernels. You originally added the first patch to 3.18, 4.4 and 4.9. Are you still planning to add them both to those kernels?
Ah, I forgot about that. I'll go queue those up for the next round after these kernels are released in a day or so.
All now queued up.
greg k-h
Cool, thank you very much. -mpl
On Tue, Dec 5, 2017 at 6:30 AM, Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Dec 05, 2017 at 08:49:56AM +0100, Greg KH wrote:
On Mon, Dec 04, 2017 at 11:45:18PM +0000, Eddie Chapman wrote:
On 04/12/17 10:27, Greg KH wrote:
On Tue, Nov 28, 2017 at 10:06:24AM +0100, Greg KH wrote:
On Mon, Nov 27, 2017 at 09:35:02AM -0800, Michael Lyle wrote:
On Mon, Nov 27, 2017 at 9:01 AM, Jens Axboe axboe@kernel.dk wrote:
> On 11/27/2017 09:45 AM, Eddie Chapman wrote: > > On 27/11/17 16:06, gregkh@linuxfoundation.org wrote: > > > > > > This is a note to let you know that I've just added the patch titled > > > > > > bcache: only permit to recovery read error when cache device is > clean >
> > Hi Greg, > > > > This patch is an important fix for a possible data corruption issue, but > > it also introduces a bug that can produce read errors under certain > > circumstances. The issue introduced by this patch is not as severe as > > the issue it fixes, but can lead to e.g. upper layer fs remounting read > > only. In my environment upper layer handled it badly and indirectly > > resulted in data loss (not directly bcache's fault of course). > > > > Michael Lyle CC'd the stable list with a follow up fix for the issue > > introduced by this patch, on 24th Nov, subject "bcache: recover data > > from backing when data is clean". > > > > However, the followup fix is not in Linus' tree yet, only in Michael's. > > I guess that means you can't pick it up yet. Never-the-less I felt it > > important to point this out here. > > It's commit e393aa2446150536929140739f09c6ecbcbea7f0 in my tree and will > go upstream shortly - but yes, probably should not add this one, before > both can be pulled in.
Thanks everyone for the quick reply on this. I agree.
Ok, I've dropped this patch from all of the stable queues for now.
Both now queued up, thanks.
greg k-h
Hi Greg,
I only see those two queued up for 4.14 and not any earlier kernels. You originally added the first patch to 3.18, 4.4 and 4.9. Are you still planning to add them both to those kernels?
Ah, I forgot about that. I'll go queue those up for the next round after these kernels are released in a day or so.
All now queued up.
greg k-h
linux-stable-mirror@lists.linaro.org
-
Eddie Chapman -
Greg KH -
Michael Lyle