Received: by 10.192.165.148 with SMTP id m20csp4497847imm; Mon, 30 Apr 2018 20:54:23 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqAwaQRrEyfS1UbR9U8va4mCH3usQLcx+mlgGD1E8zNlijgBi+wj/VAnaQ5RJOumHPF1kxV X-Received: by 2002:a17:902:529:: with SMTP id 38-v6mr14877364plf.64.1525146863603; Mon, 30 Apr 2018 20:54:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525146863; cv=none; d=google.com; s=arc-20160816; b=cj8E8Wbux5hSHhuhVpnMnZOEaZs17d7PnK2I2bO7gH3b9T6Xg+J9upf47M0BHqRxc0 QI0XcoP6+Z8QEa8iRcCJh46Mvbo2SYGWr3PEIiwrO3waOnB/yukeg4qF5bs5z2cm3dmn LRTLeC2pqR0vOfRxIoisMp3zGZSfypf6TSZR4ANcXt40PnlnfDS3yqM8PK6cX+J6jTuF kCMeNbd1Ck9oQILlVqUok85s2au+kI7STZqgl6e+4SM5aU0N83qgGcrGXUY0IhVy3ruM cX9X3A0FmOkFoo8L0if7bZiNTmadkxY9tBtwlIahSxC//mSo0hZhE/mAMoMvAOqUWYyT 0E7A== 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=ElYuDjiU/1d9muKnlYt4RGRaxZ/J+eXcXFKVcmp6ouA=; b=xOYSHaI8C4FC2VuSPI+khsFJ7ovzSSD06/GERq+HYSClCFnUOoZWyDcc4s2j4Ze3a8 mBW2ud7liOU2POs2y+rhg5Ga2Z5O1ArKK3i/xdJqbyqLQQtMjGCEA6Co15niGqu28BKe NqqxqJqZKUp63PiL+Nk5HX0Oqw2jJ/mdwL6cMp26eCaWFRAwR5JZ0EAh+xfgll3uaiQn OIZuU98fEcQdGUMBQsIzhVuyrzFOAApmznQC4TgTcARAKykf3e6F9Y71jBERdQ7PKQ5x ldRjJbO3Xc5p5j63Pa0xymSlXJvcmMxfYlGcj4UCozVzcg/r+kHM8Ch0/55fuHt+7lXU sa4w== 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 r14-v6si8862528plj.341.2018.04.30.20.54.09; Mon, 30 Apr 2018 20:54:23 -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 S1755245AbeEADxl (ORCPT + 99 others); Mon, 30 Apr 2018 23:53:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:59207 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755151AbeEADxi (ORCPT ); Mon, 30 Apr 2018 23:53:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D441EAD2D; Tue, 1 May 2018 03:53:36 +0000 (UTC) From: NeilBrown To: Oleg Drokin , Greg Kroah-Hartman , James Simmons , Andreas Dilger Date: Tue, 01 May 2018 13:52:39 +1000 Subject: [PATCH 05/10] staging: lustre: fold lu_object_new() into lu_object_find_at() Cc: Linux Kernel Mailing List , Lustre Development List Message-ID: <152514675900.17843.13720388713238865482.stgit@noble> In-Reply-To: <152514658325.17843.11455067361317157487.stgit@noble> References: <152514658325.17843.11455067361317157487.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 93daa52e2535..9721b3af8ea8 100644 --- a/drivers/staging/lustre/lustre/obdclass/lu_object.c +++ b/drivers/staging/lustre/lustre/obdclass/lu_object.c @@ -678,29 +678,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 @@ -736,18 +713,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. @@ -760,7 +737,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);