Received: by 10.192.165.156 with SMTP id m28csp1230004imm; Wed, 11 Apr 2018 15:05:00 -0700 (PDT) X-Google-Smtp-Source: AIpwx4++KHY8ALF227O0r4y10y7bdE3XHAdYk48Zq2ZmYdflHQGBpwqEBX5AHNbgkaNalds8dJAy X-Received: by 10.99.181.13 with SMTP id y13mr4608374pge.279.1523484299994; Wed, 11 Apr 2018 15:04:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523484299; cv=none; d=google.com; s=arc-20160816; b=jOGtlZQj1ZkJPIiKfXIK3oOvHslwZYT65oKH7hn6lciUr0vRbbFSj9G9/DHiJDZG/r zjIs3RwQy0OX4ERhufACJaHZdnqIlD7CSMXqVAzz1B+aKo+63puH3CZiLbJg2Cw0/jTx GH8ed4c+3PrqugMHbtzuUn5b49QVRlS324a0NY0UPwigxs4Kys/0gMePkWSZ8W+zD9uP ooWWDJY3aT9qU5Xpjawkgvxtu1GWU4SK7I9qgZ1jrj7SaIBel21TIxZRGaKcRpVYoz3B VSSGlnp4oW4iUBIJ5PrZVB2U4CqrdIhky6wR31DiqJVJ9tkNJvlygDhpL4TjjhwpQXLX +wqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:cc:subject:date:to :from:arc-authentication-results; bh=AqrHDDFOqZKYSkJMc+bb7OUm9j4uZn3PXmbjePT3oJw=; b=C0hfUulK6djlHW1ygCkGNgOelJVZAs7ZUdOBrBjY2p2kjD7BWPsMeeKz4Sm7gX754/ JELK6UdzyzlagLD2rnf6Ey2AEYUWwfimRZvODn+MawkrnuMhqXn+LNVyEprVUGo3qjq+ UK7SIEzea2xAfkuGia4UDdds7/gkZJJEi95m2jOcxlEj95yvKZyR8Ma92SNySd6DItzz zVv/au8LrsuR9MiznBLZ3OSd1QjH2pPwcwD7FSa3th/XdTBRwmCOScH3qInhOWmyhLp1 Gm9EDoaIlLnX8L7eb77ib6qWqkn1TKpTSq3IeR5OHXXWUJjJfuohnmrq4vVP+ZTJXP5M 4XVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t18si1541479pfj.217.2018.04.11.15.04.23; Wed, 11 Apr 2018 15:04:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754229AbeDKV5D (ORCPT + 99 others); Wed, 11 Apr 2018 17:57:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:45983 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752783AbeDKV5B (ORCPT ); Wed, 11 Apr 2018 17:57:01 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 83F1FAFAF; Wed, 11 Apr 2018 21:57:00 +0000 (UTC) From: NeilBrown To: Oleg Drokin , Greg Kroah-Hartman , James Simmons , Andreas Dilger Date: Thu, 12 Apr 2018 07:54:49 +1000 Subject: [PATCH 14/20] staging: lustre: fold lu_object_new() into lu_object_find_at() Cc: Linux Kernel Mailing List , Lustre Development List Message-ID: <152348368902.12394.3830171785672683813.stgit@noble> In-Reply-To: <152348312863.12394.11915752362061083241.stgit@noble> References: <152348312863.12394.11915752362061083241.stgit@noble> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org lu_object_new() duplicates a lot of code that is in lu_object_find_at(). There is no real need for a separate function, it is simpler just to skip the bits of lu_object_find_at() that we don't want in the LOC_F_NEW case. Signed-off-by: NeilBrown --- drivers/staging/lustre/lustre/obdclass/lu_object.c | 44 +++++--------------- 1 file changed, 12 insertions(+), 32 deletions(-) diff --git a/drivers/staging/lustre/lustre/obdclass/lu_object.c b/drivers/staging/lustre/lustre/obdclass/lu_object.c index bf505a9463a3..18019f41c7a8 100644 --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c @@ -691,29 +691,6 @@ static void lu_object_limit(const struct lu_env *env, struct lu_device *dev) false); } -static struct lu_object *lu_object_new(const struct lu_env *env, - struct lu_device *dev, - const struct lu_fid *f, - const struct lu_object_conf *conf) -{ - struct lu_object *o; - struct cfs_hash *hs; - struct cfs_hash_bd bd; - - o = lu_object_alloc(env, dev, f, conf); - if (IS_ERR(o)) - return o; - - hs = dev->ld_site->ls_obj_hash; - cfs_hash_bd_get_and_lock(hs, (void *)f, &bd, 1); - cfs_hash_bd_add_locked(hs, &bd, &o->lo_header->loh_hash); - cfs_hash_bd_unlock(hs, &bd, 1); - - lu_object_limit(env, dev); - - return o; -} - /** * Much like lu_object_find(), but top level device of object is specifically * \a dev rather than top level device of the site. This interface allows @@ -749,18 +726,18 @@ struct lu_object *lu_object_find_at(const struct lu_env *env, * just alloc and insert directly. * */ - if (conf && conf->loc_flags & LOC_F_NEW) - return lu_object_new(env, dev, f, conf); - s = dev->ld_site; hs = s->ls_obj_hash; - cfs_hash_bd_get_and_lock(hs, (void *)f, &bd, 0); - o = htable_lookup(s, &bd, f, &version); - cfs_hash_bd_unlock(hs, &bd, 0); - if (!IS_ERR(o) || PTR_ERR(o) != -ENOENT) - return o; + cfs_hash_bd_get(hs, f, &bd); + if (!(conf && conf->loc_flags & LOC_F_NEW)) { + cfs_hash_bd_lock(hs, &bd, 0); + o = htable_lookup(s, &bd, f, &version); + cfs_hash_bd_unlock(hs, &bd, 0); + if (!IS_ERR(o) || PTR_ERR(o) != -ENOENT) + return o; + } /* * Allocate new object. This may result in rather complicated * operations, including fld queries, inode loading, etc. @@ -773,7 +750,10 @@ struct lu_object *lu_object_find_at(const struct lu_env *env, cfs_hash_bd_lock(hs, &bd, 1); - shadow = htable_lookup(s, &bd, f, &version); + if (conf && conf->loc_flags & LOC_F_NEW) + shadow = ERR_PTR(-ENOENT); + else + shadow = htable_lookup(s, &bd, f, &version); if (likely(PTR_ERR(shadow) == -ENOENT)) { cfs_hash_bd_add_locked(hs, &bd, &o->lo_header->loh_hash); cfs_hash_bd_unlock(hs, &bd, 1);