From patchwork Fri May 27 07:00:34 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feifei Xu X-Patchwork-Id: 9137817 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 566A66075A for ; Fri, 27 May 2016 07:50:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 48C0027CCD for ; Fri, 27 May 2016 07:50:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3D72627D10; Fri, 27 May 2016 07:50:50 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 31E6127CCD for ; Fri, 27 May 2016 07:50:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932539AbcE0Huk (ORCPT ); Fri, 27 May 2016 03:50:40 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:59038 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932077AbcE0Huj (ORCPT ); Fri, 27 May 2016 03:50:39 -0400 Received: from pps.filterd (m0049461.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u4R7n7I1033516 for ; Fri, 27 May 2016 03:50:38 -0400 Message-Id: <201605270750.u4R7n7I1033516@mx0a-001b2d01.pphosted.com> Received: from e28smtp09.in.ibm.com (e28smtp09.in.ibm.com [125.16.236.9]) by mx0a-001b2d01.pphosted.com with ESMTP id 236ayma0j0-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 27 May 2016 03:50:37 -0400 Received: from localhost by e28smtp09.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 27 May 2016 13:20:34 +0530 Received: from d28dlp02.in.ibm.com (9.184.220.127) by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 27 May 2016 13:20:32 +0530 X-IBM-Helo: d28dlp02.in.ibm.com X-IBM-MailFrom: xufeifei@linux.vnet.ibm.com X-IBM-RcptTo: linux-btrfs@vger.kernel.org Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id AFD9A394005E for ; Fri, 27 May 2016 13:20:31 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u4R7oGcK19661182 for ; Fri, 27 May 2016 13:20:16 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u4R7kjps007781 for ; Fri, 27 May 2016 13:20:29 +0530 Received: from tester-VirtualBox.cn.ibm.com (tester-virtualbox.cn.ibm.com [9.123.229.4]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u4R70rlN020526; Fri, 27 May 2016 12:31:10 +0530 From: Feifei Xu To: linux-btrfs@vger.kernel.org Cc: steve.capper@linaro.org, chandan@mykolab.com, jbacik@fb.com, dsterba@suse.com, feifeixu.sh@gmail.com, Feifei Xu Subject: [PATCH 1/5] Btrfs: test_check_exists: Fix infinite loop when searching for free space entries Date: Fri, 27 May 2016 15:00:34 +0800 X-Mailer: git-send-email 2.7.4 In-Reply-To: <1464332438-19119-1-git-send-email-xufeifei@linux.vnet.ibm.com> References: <1464332438-19119-1-git-send-email-xufeifei@linux.vnet.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16052707-0060-0000-0000-00000090E0B9 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16052707-0061-0000-0000-00000D5C9745 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-27_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=38 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605270089 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On a ppc64 machine using 64K as the block size, assume that the RB tree at btrfs_free_space_ctl->free_space_offset contains following two entries: 1. A bitmap entry having an offset value of 0 and having the bits corresponding to the address range [128M+512K, 128M+768K] set. 2. An extent entry corresponding to the address range [128M-256K, 128M-128K] In such a scenario, test_check_exists() invoked for checking the existence of address range [128M+768K, 256M] can lead to an infinite loop as explained below: - Checking for the extent entry fails. - Checking for a bitmap entry results in the free space info in range [128M+512K, 128M+768K] beng returned. - rb_prev(info) returns NULL because the bitmap entry starting from offset 0 comes first in the RB tree. - current_node = bitmap node. - while (current_node) tmp = rb_next(bitmap_node);/*tmp is extent based free space entry*/ Since extent based free space entry's last address is smaller than the address being searched for (i.e. 128M+768K) we incorrectly again obtain the extent node as the "next right node" of the RB tree and thus end up looping infinitely. This patch fixes the issue by updating "info" variable to point to the most recently searched free space node. Reviewed-by: Chandan Rajendra Signed-off-by: Feifei Xu --- fs/btrfs/free-space-cache.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index 5e6062c..05c9ef8 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -3662,6 +3662,7 @@ have_info: if (tmp->offset + tmp->bytes < offset) break; if (offset + bytes < tmp->offset) { + info = tmp; n = rb_prev(&info->offset_index); continue; } @@ -3676,6 +3677,7 @@ have_info: if (offset + bytes < tmp->offset) break; if (tmp->offset + tmp->bytes < offset) { + info = tmp; n = rb_next(&info->offset_index); continue; }