Excerpts from Tsutomu Itoh's message of 2011-01-31 21:15:32 -0500: > Hi Chris, > > (2011/01/29 6:53), Chris Mason wrote: > > Excerpts from Tsutomu Itoh's message of 2011-01-21 01:06:29 -0500: > >> (2011/01/21 8:47), Tsutomu Itoh wrote: > >>> (2011/01/21 1:09), Josef Bacik wrote: > >>>> I'd rather we go through and have these things return an error than do a > >>>> BUG_ON(). We're moving towards a more stable BTRFS, not one that panics more > >>>> often :). > >>> > >>> Yes, I also think so. > >>> This patch is my first step. > >>> > >>> My modification policy is as follows: > >>> > >>> 1. short term > >>> - To more stable BTRFS, the part that should be corrected is clarified. > >>> - The panic is not done by the NULL pointer reference etc. > >> This means, even if temporary increase BUG_ON()... > >> > >> In addition, I think that an important memory allocation should retry several times. > >> So, I propose the following patches as this sample. > >> > >>> > >>> 2. long term > >>> - BUG_ON() is decreased by using the forced-readonly framework(already posted by Liu Bo), > >>> etc. > >> > >> > >> This patch retries kmem_cache_alloc() in start_transaction() several times. > > > > Thanks for working on these, it's really good to see these error checks > > going on. > > > > We don't want to loop on kmem_cache_alloc(), for allocations less than > > 4KB, the allocator only returns NULL if the box has gone into OOM > > anyway. By the time we get these, things have gone horribly wrong. > > > > If we really can't fail, we can use GFP_NOFAIL, which loops for us. > > I agree to your opinion, and please ignore following patch. > But, please apply http://marc.info/?l=linux-btrfs&m=129550441505242&w=2 Thanks, I have this one now as well. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
