Re: [PATCH] btrfs: fix return value check of btrfs_start_transaction()

[Chris Mason <chris.mason@Oracle.COM>]

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