Re: Patch "bcache: only permit to recovery read error when cache device is clean" has been added to the 4.9-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Cool, thank you very much.  -mpl

On Tue, Dec 5, 2017 at 6:30 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>> > > > >
>> > > > > > On 11/27/2017 09:45 AM, Eddie Chapman wrote:
>> > > > > > > On 27/11/17 16:06, gregkh@xxxxxxxxxxxxxxxxxxx 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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]