On 06/08/2011 04:21 AM, Arne Jansen wrote:
> On 11.05.2011 23:35, Josef Bacik wrote:
>> If we have particularly full nodes, we could call btrfs_node_blockptr up to 32
>> times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the
>> extent buffer while we look for readahead targets. Thanks,
>>
>> Signed-off-by: Josef Bacik <josef@xxxxxxxxxx>
>> ---
>> fs/btrfs/ctree.c | 23 +++++++++++++++++++++--
>> 1 files changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
>> index 84d7ca1..009bcf7 100644
>> --- a/fs/btrfs/ctree.c
>> +++ b/fs/btrfs/ctree.c
>> @@ -1229,6 +1229,7 @@ static void reada_for_search(struct btrfs_root *root,
>> u64 search;
>> u64 target;
>> u64 nread = 0;
>> + u64 gen;
>> int direction = path->reada;
>> struct extent_buffer *eb;
>> u32 nr;
>> @@ -1256,6 +1257,15 @@ static void reada_for_search(struct btrfs_root *root,
>> nritems = btrfs_header_nritems(node);
>> nr = slot;
>> while (1) {
>> + if (!node->map_token) {
>> + unsigned long offset = btrfs_node_key_ptr_offset(nr);
>> + map_private_extent_buffer(node, offset,
>> + sizeof(struct btrfs_key_ptr),
>> + &node->map_token,
>> + &node->kaddr,
>> + &node->map_start,
>> + &node->map_len, KM_USER1);
>
> You can't do that. It puts us in atomic context, and the following
> readahead_tree_block will try a memory allocation with GFP_NOFS,
> which leads to a BUG: sleeping function called from invalid context.
> It didn't fall on our feet earlier because you also turned off
> readahead, but scrub still uses it.
We don't make any memory allocations within the area that we've
kmap_atomic()'ed, something else is going wrong, this patch is fine.
Thanks,
Josef
--
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
