From patchwork Tue Jun 30 02:25:43 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Naohiro Aota X-Patchwork-Id: 6692631 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D3D4FC05AC for ; Tue, 30 Jun 2015 02:27:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E0A642055B for ; Tue, 30 Jun 2015 02:27:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EF5FE20459 for ; Tue, 30 Jun 2015 02:27:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752627AbbF3C0E (ORCPT ); Mon, 29 Jun 2015 22:26:04 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:35343 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752102AbbF3C0B (ORCPT ); Mon, 29 Jun 2015 22:26:01 -0400 Received: by pactm7 with SMTP id tm7so113861787pac.2; Mon, 29 Jun 2015 19:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id; bh=vQTJy+ZXZMzS0wW0DtGicSNHOpuqMY7nPxDt9JgG4Ic=; b=ROsFR3EMhtmhBBe5iXDKWXkEGmFe0E2VqcbroUA7e3TCqgvvt0CGHb+CU73534V2ws PCeFBeg3zLyNNfmgDWpDcwW0qulD2w1wHxpPfRgz1urBlorCFxs8rsvFglozfVO1+Wq+ dm1yyKoQKG/r+H2mf43cUKWV4yfq/+GiL65UM7dvi4rnFBK/B+DrWHK25OwYY3iV2ETH ldluDORO7U/wazdynBJiX0zIektPUfJPR/4YwXKGylnoSyNbQzq0TmCrqRaLviYNZ95i W248J4AIQ5DvnS981cpT22D3y4kufwknu63ZynUcyqGrDPqtCtMTZTtku594gxnqnEpQ yuKg== X-Received: by 10.66.144.40 with SMTP id sj8mr37805137pab.55.1435631160765; Mon, 29 Jun 2015 19:26:00 -0700 (PDT) Received: from ako.i.sslab.ics.keio.ac.jp (sslab-relay.ics.keio.ac.jp. [131.113.126.173]) by mx.google.com with ESMTPSA id or7sm43687846pdb.9.2015.06.29.19.25.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Jun 2015 19:25:59 -0700 (PDT) From: Naohiro Aota To: linux-btrfs@vger.kernel.org Cc: Naohiro Aota , Chris Mason , Josef Bacik , David Sterba , linux-kernel@vger.kernel.org (open list) Subject: [PATCH][RESEND] btrfs: fix search key advancing condition Date: Tue, 30 Jun 2015 11:25:43 +0900 Message-Id: <1435631143-12247-1-git-send-email-naota@elisp.net> X-Mailer: git-send-email 2.4.4 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The search key advancing condition used in copy_to_sk() is loose. It can advance the key even if it reaches sk->max_*: e.g. when the max key = (512, 1024, -1) and the current key = (512, 1025, 10), it increments the offset by 1, continues hopeless search from (512, 1025, 11). This issue make ioctl() to take unexpectedly long time scanning all the leaf a blocks one by one. This commit fix the problem using standard way of key comparison: btrfs_comp_cpu_keys() Signed-off-by: Naohiro Aota Reviewed-by: Filipe Manana --- fs/btrfs/ioctl.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 1c22c65..07dc01d 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1932,6 +1932,7 @@ static noinline int copy_to_sk(struct btrfs_root *root, u64 found_transid; struct extent_buffer *leaf; struct btrfs_ioctl_search_header sh; + struct btrfs_key test; unsigned long item_off; unsigned long item_len; int nritems; @@ -2015,12 +2016,17 @@ static noinline int copy_to_sk(struct btrfs_root *root, } advance_key: ret = 0; - if (key->offset < (u64)-1 && key->offset < sk->max_offset) + test.objectid = sk->max_objectid; + test.type = sk->max_type; + test.offset = sk->max_offset; + if (btrfs_comp_cpu_keys(key, &test) >= 0) + ret = 1; + else if (key->offset < (u64)-1) key->offset++; - else if (key->type < (u8)-1 && key->type < sk->max_type) { + else if (key->type < (u8)-1) { key->offset = 0; key->type++; - } else if (key->objectid < (u64)-1 && key->objectid < sk->max_objectid) { + } else if (key->objectid < (u64)-1) { key->offset = 0; key->type = 0; key->objectid++;