Re: [BUG] unable to handle kernel NULL pointer dereference at 000000000000006c (bch_insert_data)

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

 



>On Tue, Oct 15, 2013 at 12:41:02AM +0400, Vasiliy Tolstov wrote:
>> 2013/10/14 Gabriel de Perthuis <g2p.code@xxxxxxxxx>:
>> > That's the bug mentioned here:
>> > http://comments.gmane.org/gmane.linux.kernel.bcache.devel/2113
>> > http://comments.gmane.org/gmane.linux.kernel.bcache.devel/2109
>> > http://comments.gmane.org/gmane.linux.kernel.bcache.devel/2108
>> >
>> > It's a regression that stops writeback and made 3.11.4.
>> > The fix is in 3.12-rc5 and will be in 3.11.5.
>> 
>> 
>> does branche http://evilpiepirate.org/git/linux-bcache.git/log/?h=bcache-for-3.11
>> has all fixes and stable for use?
>
>No - but 3.11.5 is out and has the fix


color me miffed/mystified. Why should we be chasing Linux kernel releases to get fixed code? Shouldn't the GIT/tarball hosted at the bcache project HQ be !!CONSTANTLY!! up to date with appropriate fixes? Linux kernels depend on all kinds of people and is an "unreliable" means to get fully fixed code (eg. that last minute fix might not have made the cutoff)

Shouldn't the project's code repository have the utmost priority? 
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux