Excerpts from Tsutomu Itoh's message of 2011-01-31 21:15:32 -0500:

Hi Chris,

(2011/01/29 6:53), Chris Mason wrote:

quoted

Excerpts from Tsutomu Itoh's message of 2011-01-21 01:06:29 -0500:

quoted

(2011/01/21 8:47), Tsutomu Itoh wrote:

quoted

(2011/01/21 1:09), Josef Bacik wrote:

quoted

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.

quoted

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