From patchwork Wed May 13 12:55:47 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kinglong Mee X-Patchwork-Id: 6396811 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id B719B9F1C2 for ; Wed, 13 May 2015 12:56:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 90635203EB for ; Wed, 13 May 2015 12:56:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5970A203FB for ; Wed, 13 May 2015 12:56:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934281AbbEMMz5 (ORCPT ); Wed, 13 May 2015 08:55:57 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:35473 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933410AbbEMMz4 (ORCPT ); Wed, 13 May 2015 08:55:56 -0400 Received: by pabtp1 with SMTP id tp1so50079689pab.2; Wed, 13 May 2015 05:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EytCruwG1kXAcbcNiKY32y2SQssG2Z4eqB2dpcaBtko=; b=rsWbFuEpxqvyHdqOoDlz42m/BrGqF+eHsA2OrCHFqWWEnTtlaz5hds/XQqjBntI+yu 7wjGvXrxpM8pUVqmEvVJzub00nj3UQSTcScYkce0OoNyTv5R6nuyEPgeRfstAMrvISyl F0GoPMoWOC8T7hMoV2w5po66cVPv/6hpWcDRNq9NMugOM5+zfu/rqRoD02LqRyrvdyTX dBiSFt7eoLiosEzgEg476QvkWc/2gcjXoJZBWSdU7670T1YqJXN314aa70ZsMNlK5x6+ s+L9G+POpY6mSX6itNzzOOjkm04cPlvH4EBcGDKuVV6LeRl2UW5PiawxQxbo4iZJtjCh Dp5g== X-Received: by 10.66.119.239 with SMTP id kx15mr37881620pab.156.1431521755769; Wed, 13 May 2015 05:55:55 -0700 (PDT) Received: from [192.168.99.11] ([104.143.38.59]) by mx.google.com with ESMTPSA id pa1sm19320590pdb.73.2015.05.13.05.55.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 05:55:55 -0700 (PDT) Message-ID: <555349D3.1020903@gmail.com> Date: Wed, 13 May 2015 20:55:47 +0800 From: Kinglong Mee User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: NeilBrown CC: "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, "linux-nfs@vger.kernel.org" , Al Viro , Trond Myklebust Subject: Re: [PATCH 4/4] nfsd: Pin to vfsmnt instead of mntget References: <554A149B.5060102@gmail.com> <554A154B.6040103@gmail.com> <20150508144031.6f0d3cda@notabene.brown> <20150508134744.GA23753@fieldses.org> <5550A9DF.1070908@gmail.com> <20150513142515.6bd881c8@notabene.brown> <555343CA.6010307@gmail.com> In-Reply-To: <555343CA.6010307@gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable 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 On 5/13/2015 8:30 PM, Kinglong Mee wrote: > On 5/13/2015 12:25 PM, NeilBrown wrote: >> On Mon, 11 May 2015 21:08:47 +0800 Kinglong Mee wrote: >> >>> On 5/8/2015 9:47 PM, J. Bruce Fields wrote: >>>> On Fri, May 08, 2015 at 02:40:31PM +1000, NeilBrown wrote: >>>>> Thanks for this patch. It looks good! >>>>> >>>>> My only comment on the code is that I would really like to see a >>>>> "path_get_pin()" and "path_put_unpin()" rather than open coding: >>>>> >>>>>> + dget(item->ek_path.dentry); >>>>>> + pin_insert_group(&new->ek_pin, item->ek_path.mnt, NULL); >>>>> >>>>> and >>>>> >>>>>> + dput(key->ek_path.dentry); >>>>>> + pin_remove(&key->ek_pin); >>>>> >>>>> >>>>> But the question you raise is an important one: Exactly which filesystems >>>>> should be allowed to be unmounted? >>>>> This is a change in behaviour - is it one that people uniformly would want? >>>>> >>>>> The kernel doesn't currently know which file systems were explicitly listed >>>>> in /etc/exports, and which were found by following a 'crossmnt'. >>>>> It could guess and allow the unmounting of anything below a 'crossmnt', but I >>>>> wouldn't be comfortable with that - it is error prone. >>>>> >>>>> mountd does know what is in /etc/exports, and could tell the kernel. >>>>> For the expkey cache, we could always use path_get_pin. >>>>> For the export cache (where flags are available) we could use path_get >>>>> or path_get_pin depending on some new flag. >>>>> >>>>> I'm not really sure it is worth it. I would rather the filesystems could >>>>> always be unmounted. But doing that could possibly break someone's work >>>>> flow. Maybe. >>>>> >>>>> Or maybe I'm seeing problems where there aren't any. >>>>> >>>>> Anyone else have an opinion? >>>> >>>> The undisputed bug here was negative cache entries preventing unmount. >>>> So most conservative might be just to purge negative entries. >>> >>> I'd like this, >>> if the cache is valid, user should not be allowed to umount the filesystem. >>> >>>> >>>> Otherwise, the only guarantees I think we've really had is that we won't >>>> allow unmount if you hold any actual state on the filesystem (NLM locks, >>>> NFSv4 locks, opens, or delegations). >>> >>> Those resources hold the reference of vfsmnt. >>> >>>> >>>> If a filesystem is exported but no clients hold state on it, then it's >>>> currently mostly chance whether the unmount succeeds or not. So we're >>>> probably free to change the behavior in this case. I'd be inclined to >>>> allow the unmount, but haven't thought this through carefully. >>> >>> If client mount a nfsserver succeed without holds state, >>> nfs server umounts the exported filesystem, >>> client also think the filesystem is valid, but it is umounted. >> >> This is no different from "exportfs -au" being run on the server, thus >> unexporting the filesystem and making in unavailable to the client, even >> though the client has it mounted. > > No, I don't think so. > If user using "exportfs -au" to flush caches, I think he known > what the influence of he does, but an umount of filesystem, > maybe he doesn't known that contains flushing nfsd's exports cache. > > For an using of nfsd exports, I'd like an error of an umount, > because I don't realize the exports for nfsd. > > I also think nfsd should allowing umount of unexported filesystem, > because user has the right to umount it. The following is a diff draft of umounting an unexported filesystem. thanks, Kinglong Mee ------------------------------------------------------------------------ --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c index f79521a..bcaa914 100644 --- a/fs/nfsd/export.c +++ b/fs/nfsd/export.c @@ -309,11 +309,17 @@ static void nfsd4_fslocs_free(struct nfsd4_fs_locations *fsloc) static void svc_export_put(struct kref *ref) { struct svc_export *exp = container_of(ref, struct svc_export, h.ref); - path_put(&exp->ex_path); + + if (exp->ex_pin.kill) { + dput(exp->ex_path.dentry); + pin_remove(&exp->ex_pin); + } else + path_put(&exp->ex_path); + auth_domain_put(exp->ex_client); nfsd4_fslocs_free(&exp->ex_fslocs); kfree(exp->ex_uuid); - kfree(exp); + kfree_rcu(exp, rcu_head); } static void svc_export_request(struct cache_detail *cd, @@ -699,6 +705,7 @@ static void svc_export_init(struct cache_head *cnew, struct cache_head *citem) struct svc_export *new = container_of(cnew, struct svc_export, h); struct svc_export *item = container_of(citem, struct svc_export, h); + init_fs_pin(&new->ex_pin, NULL); kref_get(&item->ex_client->ref); new->ex_client = item->ex_client; new->ex_path = item->ex_path; @@ -738,6 +745,24 @@ static void export_update(struct cache_head *cnew, struct cache_head *citem) } } +static void export_pin_kill(struct fs_pin *pin) +{ + struct svc_export *exp = container_of(pin, struct svc_export, ex_pin); + cache_force_expire(exp->cd, &exp->h); +} + +static void export_update_negative(struct cache_head *cnew, struct cache_head *citem) +{ + struct svc_export *new = container_of(cnew, struct svc_export, h); + + if (!test_bit(CACHE_NEGATIVE, &new->h.flags)) + return ; + + init_fs_pin(&new->ex_pin, export_pin_kill); + pin_insert_group(&new->ex_pin, new->ex_path.mnt, NULL); + mntput(new->ex_path.mnt); +} + static struct cache_head *svc_export_alloc(void) { struct svc_export *i = kmalloc(sizeof(*i), GFP_KERNEL); @@ -758,6 +783,7 @@ static struct cache_detail svc_export_cache_template = { .match = svc_export_match, .init = svc_export_init, .update = export_update, + .update_negative= export_update_negative, .alloc = svc_export_alloc, }; diff --git a/fs/nfsd/export.h b/fs/nfsd/export.h index 1f52bfc..c764a8e 100644 --- a/fs/nfsd/export.h +++ b/fs/nfsd/export.h @@ -4,6 +4,7 @@ #ifndef NFSD_EXPORT_H #define NFSD_EXPORT_H +#include #include #include @@ -46,6 +47,8 @@ struct exp_flavor_info { struct svc_export { struct cache_head h; + struct cache_detail *cd; + struct auth_domain * ex_client; int ex_flags; struct path ex_path; @@ -58,7 +61,9 @@ struct svc_export { struct exp_flavor_info ex_flavors[MAX_SECINFO_LIST]; enum pnfs_layouttype ex_layout_type; struct nfsd4_deviceid_map *ex_devid_map; - struct cache_detail *cd; + + struct fs_pin ex_pin; + struct rcu_head rcu_head; }; /* an "export key" (expkey) maps a filehandlefragement to an diff --git a/include/linux/sunrpc/cache.h b/include/linux/sunrpc/cache.h index 437ddb6..39b31b5 100644 --- a/include/linux/sunrpc/cache.h +++ b/include/linux/sunrpc/cache.h @@ -101,6 +101,7 @@ struct cache_detail { int (*match)(struct cache_head *orig, struct cache_head *new); void (*init)(struct cache_head *orig, struct cache_head *new); void (*update)(struct cache_head *orig, struct cache_head *new); + void (*update_negative)(struct cache_head *orig, struct cache_head *new); /* fields below this comment are for internal use * and should not be touched by cache owners diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c index 2928aff..4a95dee 100644 --- a/net/sunrpc/cache.c +++ b/net/sunrpc/cache.c @@ -149,9 +149,11 @@ struct cache_head *sunrpc_cache_update(struct cache_detail *detail, if (!test_bit(CACHE_VALID, &old->flags)) { write_lock(&detail->hash_lock); if (!test_bit(CACHE_VALID, &old->flags)) { - if (test_bit(CACHE_NEGATIVE, &new->flags)) + if (test_bit(CACHE_NEGATIVE, &new->flags)) { set_bit(CACHE_NEGATIVE, &old->flags); - else + if (detail->update_negative) + detail->update_negative(old, new); + } else detail->update(old, new); cache_fresh_locked(old, new->expiry_time); write_unlock(&detail->hash_lock); @@ -171,9 +173,11 @@ struct cache_head *sunrpc_cache_update(struct cache_detail *detail, head = &detail->hash_table[hash]; write_lock(&detail->hash_lock); - if (test_bit(CACHE_NEGATIVE, &new->flags)) + if (test_bit(CACHE_NEGATIVE, &new->flags)) { set_bit(CACHE_NEGATIVE, &tmp->flags); - else + if (detail->update_negative) + detail->update_negative(old, new); + } else detail->update(tmp, new); tmp->next = *head; *head = tmp;