Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp290557pxb; Mon, 16 Aug 2021 05:38:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqaaXKuV8NaNBquD1+HfGE3WblJf3ke6Fl5JRGkYqhvIg+xGcxvQQv2b/i/0rKcx0UNGb1 X-Received: by 2002:a17:906:5d6:: with SMTP id t22mr15628220ejt.98.1629117528748; Mon, 16 Aug 2021 05:38:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629117528; cv=none; d=google.com; s=arc-20160816; b=ZNlEHOXWLE8YiFbTDdF8xZpGCHhM2mYOEvVwimNGMZIwG+AnxXg1fiomWbvyDkDSiX n6G9Z42TH+VayOAd72/iE6zwx+YpbCpApW/lCRj4jXqkxEac0n6y+7Ae3EP7Fo72g74h HycN27Ncc3+eaAiIG1Roq7OObgQd0UiCsBuc6VJpDf3O5qWyIdXOB5/v7tYrh67W2yQE As+3mhU+zM+7zZIb5uAyZz3HEnq+loX9ch+uFbKMdf3/NMFlvKPKroS5NNijBF+O/dW2 JcVYriTKULnTYyzTien/xQcRwM9TecHf/X+BqruSqIFdxEzM3Y2xcuqMRllrggUFTJdk m/Bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=nBWNrLXF0vV78ArIKUc3JmBk7AyqnVb1RiWUuwN+5pU=; b=m9Cb9laSbuvkC0JL/jFgFL8jWBeAw6hdMqtEYK/5WJPj5h7AEAIMekwkVSMpNyetyW QtvJM82hFwC7c+PPgWh+qlJgyfOEUbu5p0kuuN0/FIiG7fA1CWgLCpdO0+mbJg2T541n G4Jm7cOmmb+TrvdCz9DD+LvsGcHW3RYkTTgvovlK++ZYKsKk9HNhCC2oqFsM1ieXlukW jWHyDzFqYPY80nZHu3ma3abwbdTKtkwB22uZc0XL167HyHxBmOx0qqXY1K9RZ4frbZVS M7P+ViGxLn0EcOUCDN4eQMBScrJcw/pq7QrXsW2PsMtOwKMbA8DgXupa88IoegyeMAUS 5o5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v4si10247380edq.318.2021.08.16.05.38.25; Mon, 16 Aug 2021 05:38:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229801AbhHPMhC (ORCPT + 99 others); Mon, 16 Aug 2021 08:37:02 -0400 Received: from verein.lst.de ([213.95.11.211]:54252 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbhHPMgy (ORCPT ); Mon, 16 Aug 2021 08:36:54 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id EC5286736F; Mon, 16 Aug 2021 14:36:19 +0200 (CEST) Date: Mon, 16 Aug 2021 14:36:19 +0200 From: Christoph Hellwig To: Kari Argillander Cc: Konstantin Komarov , Christoph Hellwig , ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Pali =?iso-8859-1?Q?Roh=E1r?= , Matthew Wilcox Subject: Re: [RFC PATCH 1/4] fs/ntfs3: Use new api for mounting Message-ID: <20210816123619.GB17355@lst.de> References: <20210816024703.107251-1-kari.argillander@gmail.com> <20210816024703.107251-2-kari.argillander@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210816024703.107251-2-kari.argillander@gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +/* > + * ntfs_load_nls > + * No need to state the function name here. > + * Load nls table or if @nls is utf8 then return NULL because > + * nls=utf8 is totally broken. > + */ > +static struct nls_table *ntfs_load_nls(char *nls) > +{ > + struct nls_table *ret; > + > + if (!nls) > + return ERR_PTR(-EINVAL); > + if (strcmp(nls, "utf8")) > + return NULL; > + if (strcmp(nls, CONFIG_NLS_DEFAULT)) > + return load_nls_default(); > + > + ret = load_nls(nls); > + if (!ret) > + return ERR_PTR(-EINVAL); > + > + return ret; > +} This looks like something quite generic and not file system specific. But I haven't found time to look at the series from Pali how this all fits together. > +// clang-format off Please don't use C++ comments. And we also should not put weird formatter annotations into the kernel source anyway. > +static void ntfs_default_options(struct ntfs_mount_options *opts) > { > opts->fs_uid = current_uid(); > opts->fs_gid = current_gid(); > + opts->fs_fmask_inv = ~current_umask(); > + opts->fs_dmask_inv = ~current_umask(); > + opts->nls = ntfs_load_nls(CONFIG_NLS_DEFAULT); > +} This function seems pretty pointless with a single trivial caller. > +static int ntfs_fs_parse_param(struct fs_context *fc, struct fs_parameter *param) Please avoid the overly long line. > + break; > + case Opt_showmeta: > + opts->showmeta = result.negated ? 0 : 1; > + break; > + case Opt_nls: > + unload_nls(opts->nls); > + > + opts->nls = ntfs_load_nls(param->string); > + if (IS_ERR(opts->nls)) { > + return invalf(fc, "ntfs3: Cannot load nls %s", > + param->string); > } So instead of unloading here, why not set keep a copy of the string in the mount options structure and only load the actual table after option parsing has finished? > + struct ntfs_mount_options *new_opts = fc->s_fs_info; Does this rely on the mount_options being the first member in struct ntfs_sb_info? If so that is a landmine for future changes. > +/* > + * Set up the filesystem mount context. > + */ > +static int ntfs_init_fs_context(struct fs_context *fc) > +{ > + struct ntfs_sb_info *sbi; > + > + sbi = ntfs_zalloc(sizeof(struct ntfs_sb_info)); Not related to your patch, but why does ntfs3 have kmalloc wrappers like this?