From patchwork Thu Dec 4 15:20:52 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rasmus Villemoes X-Patchwork-Id: 5438331 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id AAAEC9F319 for ; Thu, 4 Dec 2014 15:21:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C46202035C for ; Thu, 4 Dec 2014 15:21:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CC44420328 for ; Thu, 4 Dec 2014 15:21:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932116AbaLDPVO (ORCPT ); Thu, 4 Dec 2014 10:21:14 -0500 Received: from mail-la0-f43.google.com ([209.85.215.43]:59347 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753832AbaLDPVN (ORCPT ); Thu, 4 Dec 2014 10:21:13 -0500 Received: by mail-la0-f43.google.com with SMTP id ge10so9996053lab.30 for ; Thu, 04 Dec 2014 07:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=from:to:cc:subject:date:message-id; bh=YWZ9nPNC8Tfb8TKFBFOAgLIfUeJHWkgq8qS/459BGmU=; b=e5Xyjvg5Gwt+8k8FT0fvZT3aNnDFMcR/gU29J2Hh0Ux5LD0h8ub2+Xx+67kkD1vXBL jzQspdYldSyBwqxc2sL1gzOUxVmkEGX/8e6MPe6gSQfzNw41cEUUple/uio63ecH/9kV T0uDClZnijZH4UvuyL810+RNK0OlHDWUCCZvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=YWZ9nPNC8Tfb8TKFBFOAgLIfUeJHWkgq8qS/459BGmU=; b=m5WrbqLlrMhitkkQY86aroaueQnNUiQW0jYw7UHBW4YuaZCp2T4f0jJiQvBXAWY5p9 rpOM49W+WVQ5XK6YvELoLli2+gq5TYVt7+TQrq0ZA60TJqAjTUdAshBvKnYIgZrDoxXo 0t9lpmxE5w6rsUlSvk3YKYeku5b42Sli2vLTnespqin09lGRzXuVwbcIPN9mmk4dbnpZ D/0t9dDqp8MKbMFZvNeykAXtfRMu/0TXhUI28SG85FjnhqqAQNoogJRZxm22JtovPQlQ WCxTVuvrMVcPUXhR/YF5V4fZW+SMznRQMr0DF7xN64SbTyh8Pw0HqyAAPnxkT/8sjHZa InJg== X-Gm-Message-State: ALoCoQl1DIzP338Ale5lOrtM+wPc1AhihHfWwNxIR1Y0aXegHWo0IM7dDFmVegR39rvWqsQiGuU9 X-Received: by 10.152.2.41 with SMTP id 9mr9753045lar.47.1417706471915; Thu, 04 Dec 2014 07:21:11 -0800 (PST) Received: from spencer.imf.au.dk ([130.225.20.51]) by mx.google.com with ESMTPSA id a1sm505405lbi.11.2014.12.04.07.21.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 07:21:11 -0800 (PST) From: Rasmus Villemoes To: "J. Bruce Fields" Cc: Rasmus Villemoes , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] fs: nfsd: Fix bug in compare_blob Date: Thu, 4 Dec 2014 16:20:52 +0100 Message-Id: <1417706452-30204-1-git-send-email-linux@rasmusvillemoes.dk> X-Mailer: git-send-email 2.0.4 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_RP_MATCHES_RCVD,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 Bugs similar to the one in acbbe6fbb240 (kcmp: fix standard comparison bug) are in rich supply. In this variant, the problem is that struct xdr_netobj::len has type unsigned int, so the expression o1->len - o2->len _also_ has type unsigned int; it has completely well-defined semantics, and the result is some non-negative integer, which is always representable in a long long. But this means that if the conditional triggers, we are guaranteed to return a positive value from compare_blob. In this case it could be fixed by - res = o1->len - o2->len; + res = (long long)o1->len - (long long)o2->len; but I'd rather eliminate the usually broken 'return a - b;' idiom. Signed-off-by: Rasmus Villemoes Reviewed-by: Jeff Layton --- Notes: How this could ever have worked is beyond me - compare_blob seems to be used to maintain an rbtree, and I wouldn't expect rbtrees to behave well if the comparison function doesn't satisfy the basic invariant sign(cmp(a, b)) == -sign(cmp(b, a)). fs/nfsd/nfs4state.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index e9c3afe4b5d3..d504cd6927f8 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -1711,15 +1711,14 @@ static int copy_cred(struct svc_cred *target, struct svc_cred *source) return 0; } -static long long +static int compare_blob(const struct xdr_netobj *o1, const struct xdr_netobj *o2) { - long long res; - - res = o1->len - o2->len; - if (res) - return res; - return (long long)memcmp(o1->data, o2->data, o1->len); + if (o1->len < o2->len) + return -1; + if (o1->len > o2->len) + return 1; + return memcmp(o1->data, o2->data, o1->len); } static int same_name(const char *n1, const char *n2) @@ -1907,7 +1906,7 @@ add_clp_to_name_tree(struct nfs4_client *new_clp, struct rb_root *root) static struct nfs4_client * find_clp_in_name_tree(struct xdr_netobj *name, struct rb_root *root) { - long long cmp; + int cmp; struct rb_node *node = root->rb_node; struct nfs4_client *clp;