lkml.org 
[lkml]   [2012]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] btrfs/extent_io.c: return -ENOMEM instead of BUG_ON on allocation failure in set_extent_bit if __GFP_WAIT is set in the mask
On 2012年04月04日 21:29, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/31/2012 03:25 AM, Wang Sheng-Hui wrote:
>> If __GFP_WAIT is set in the mask, set_extent_bit should return
>> -ENOMEM to its caller to decide what to do on allocation failure,
>> instead of BUG_ON.
>>
>> Signed-off-by: Wang Sheng-Hui <shhuiw@gmail.com> ---
>> fs/btrfs/extent_io.c | 3 ++- 1 files changed, 2 insertions(+), 1
>> deletions(-)
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index
>> b67814c..fd2411e 100644 --- a/fs/btrfs/extent_io.c +++
>> b/fs/btrfs/extent_io.c @@ -720,7 +720,8 @@ int
>> set_extent_bit(struct extent_io_tree *tree, u64 start, u64 end,
>> again: if (!prealloc && (mask & __GFP_WAIT)) { prealloc =
>> alloc_extent_state(mask); - BUG_ON(!prealloc); + if (!prealloc) +
>> return -ENOMEM; }
>>
>> spin_lock(&tree->lock);
>
> Hi Sheng-Hui -
>
> Do you have a follow-on series to this? With the exception of the
> set_extent_dirty call in end_bio_extent_readpage, every set_extent_bit
> caller uses GFP_NOFS, which includes __GFP_WAIT. If we return a
> failure here, we need to catch the failure in the call sites.
> Otherwise, the failure will just be ignored and we'll end up with an
> inconsistent extent state tree.
>
> - -Jeff
>

Hi Jeff,

I'll review the code and provide a list of patches later.
Currently we can skip it, I think.

Thanks,
Sheng-Hui

> - --
> Jeff Mahoney
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPfEzIAAoJEB57S2MheeWyqcoP/RagYePToMYOdgjjxVz2cwkf
> BLT5B0KWWaJa0KtEOpgQATmldmA4CCq6WmC7R/Omy1q9RD75rheKxaxuQY35NTFe
> czBSfVr3VeMy1A6dIK+wHOiAfheuT90xSgXJJMpdkjHmNjEA1g2nupAFltUE/L70
> +xFxotBuoYuTe8u++QES0JGqnw8YI6FW0z3Z4buyoqRhgiX7TukNfXXgx4c2HI0/
> cOkxyvYpDi2WF9EtESn/ekwf4Rjx9kNUX/9owmDWYgHD4MLjwSQsRbwZ7BrZEM3k
> aBe8yZGpgr3UuL9nGiPbWHsyBeAskvXaL6Y2YIczJSvsoP/DM+9SsHAwnqkVaBHv
> 8qQiQqUhF1mrdl3GBSvKJarGczrSmbWZ5X94oYq4MCKyi3SeTN/bcJS+p5EV1Tvs
> LMRqqj26leHnl+bYKGWIfJqQRuYcfbkzTOADbn54iMYj2aG2raUjI9D53TUIInuV
> Csm2hhKJn+HDwu2+gZX1F99W0ehs1ps86oGfkT4WA/H7fTmugiEYxsM1Dk71Ti7/
> eadns62DYFZyzKk4/jP/8Rjygc4YM/T2F9qb+SX3hWGhIIZiz5qOxjgBZy91i+84
> W+DDUHjZPU+O14nNlKFA3INGS9823ENklRkzpNUhLx7ffrCLOAS73O2rzHcaSmtk
> FSDWO4EqxIAi4t3LoL14
> =Pxwh
> -----END PGP SIGNATURE-----

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-04-05 04:13    [W:3.236 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site