Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1474040ybi; Wed, 17 Jul 2019 16:08:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqxmDbmiKGazkoT+ibA8ntPj8hZ15P91g+rY99IrnZp+xh4odN7pKOzRMF6Bc3bZIYEglo4U X-Received: by 2002:a17:90b:8d8:: with SMTP id ds24mr46539957pjb.135.1563404885210; Wed, 17 Jul 2019 16:08:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563404885; cv=none; d=google.com; s=arc-20160816; b=KcAqLmhtYzGbsEqedFjSPfeJgcZ1/3ZiK65Z6DWbqqUAeY+BsncxTr/OvWh8rMFkL0 lk8HAO96xvMxsmVHyYkY6CtrvaCEJKcy9pobbrlLuoR2DUd/Foo6am6LCHbsUXe9JpWi 6xUybl8uKhtGfTlrn48I5CXtHvMKv/kktYFbbcae+MUAXWwe8alLDjrQ32ObjzNGas98 t4jTSzCrnrNkWt5VnEZSEoR/ZhVTfvScappm1G027WqWrMqLixuhnSkzonNv2cJufeQV UjX3gpov1ifk3JC+FXwwJbz9HrojAsh58EoAVCUBKQExA5mQ9ZhHULXbURAZLOOKxM4y zIUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:from:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date; bh=vgI/iWmPdSDhlYitU2w2w3gniksmnkbALDluJ9JOhL4=; b=kOCZpz1VM5YWAQh/aZPew9ImckY+16Z2Oq9Dg9tezRViFyLdL6yP1AB5qWJwY+Qxdz HcvmPz/A0BIjCFEwNMIW4tiF+ZLZz50FUiKWvyMAHiQfdwZGnZppALMZKxnInT5ulGz8 TpcX0g3Bw2kcD/GwBWxg15hBpF5esVmLizLUwkmbCsuLiJJGnGkWcrDv5hvjO70IFc0L sPZDPIWr3M5MyqFTtK8MNz8J0TZPmZi/3ND+P77jB8Hu3ya34muXgLt0DA7++k8Vf5oE HHC/zTw5M1qSdFaslP8z1iepDTONIOfwZ4ON1Sg64L3DBenCW9Zu64gQYaYNSUMn2XVc BTEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-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 70si462380plc.253.2019.07.17.16.07.38; Wed, 17 Jul 2019 16:08:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-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-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728049AbfGQXH1 (ORCPT + 99 others); Wed, 17 Jul 2019 19:07:27 -0400 Received: from fieldses.org ([173.255.197.46]:59414 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727769AbfGQXH1 (ORCPT ); Wed, 17 Jul 2019 19:07:27 -0400 Received: by fieldses.org (Postfix, from userid 2815) id C7A431C95; Wed, 17 Jul 2019 19:07:26 -0400 (EDT) Date: Wed, 17 Jul 2019 19:07:26 -0400 To: Olga Kornievskaia Cc: bfields@redhat.com, linux-nfs@vger.kernel.org Subject: Re: [PATCH v4 4/8] NFSD add COPY_NOTIFY operation Message-ID: <20190717230726.GA26801@fieldses.org> References: <20190708192352.12614-1-olga.kornievskaia@gmail.com> <20190708192352.12614-5-olga.kornievskaia@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190708192352.12614-5-olga.kornievskaia@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Jul 08, 2019 at 03:23:48PM -0400, Olga Kornievskaia wrote: > @@ -726,24 +727,53 @@ struct nfs4_stid *nfs4_alloc_stid(struct nfs4_client *cl, struct kmem_cache *sla > /* > * Create a unique stateid_t to represent each COPY. > */ > -int nfs4_init_cp_state(struct nfsd_net *nn, struct nfsd4_copy *copy) > +static int nfs4_init_cp_state(struct nfsd_net *nn, void *ptr, stateid_t *stid) > { > int new_id; > > idr_preload(GFP_KERNEL); > spin_lock(&nn->s2s_cp_lock); > - new_id = idr_alloc_cyclic(&nn->s2s_cp_stateids, copy, 0, 0, GFP_NOWAIT); > + new_id = idr_alloc_cyclic(&nn->s2s_cp_stateids, ptr, 0, 0, GFP_NOWAIT); > spin_unlock(&nn->s2s_cp_lock); > idr_preload_end(); > if (new_id < 0) > return 0; > - copy->cp_stateid.si_opaque.so_id = new_id; > - copy->cp_stateid.si_opaque.so_clid.cl_boot = nn->boot_time; > - copy->cp_stateid.si_opaque.so_clid.cl_id = nn->s2s_cp_cl_id; > + stid->si_opaque.so_id = new_id; > + stid->si_opaque.so_clid.cl_boot = nn->boot_time; > + stid->si_opaque.so_clid.cl_id = nn->s2s_cp_cl_id; > return 1; > } > > -void nfs4_free_cp_state(struct nfsd4_copy *copy) > +int nfs4_init_copy_state(struct nfsd_net *nn, struct nfsd4_copy *copy) > +{ > + return nfs4_init_cp_state(nn, copy, ©->cp_stateid); > +} This little bit of refactoring could go into a seperate patch. It's easier for me to review lots of smaller patches. But I don't understand why you're doing it. Also, I'm a little suspicious of code that doesn't initialize an object till after it's been added to a global structure. The more typical pattern is: initialize foo take locks, add foo global structure, drop locks. This prevents anyone doing a lookup from finding "foo" while it's still in a partially initialized state. --b.