From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0607CC432BE for ; Thu, 26 Aug 2021 13:05:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D590F610A7 for ; Thu, 26 Aug 2021 13:05:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235852AbhHZNGD (ORCPT ); Thu, 26 Aug 2021 09:06:03 -0400 Received: from sandeen.net ([63.231.237.45]:42942 "EHLO sandeen.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbhHZNGC (ORCPT ); Thu, 26 Aug 2021 09:06:02 -0400 Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTPSA id 901597BD8; Thu, 26 Aug 2021 08:04:53 -0500 (CDT) To: Matthew Wilcox , Roberto Bergantinos Corpas Cc: viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org References: <20210721113057.993344-1-rbergant@redhat.com> From: Eric Sandeen Subject: Re: [PATCH] vfs: parse sloppy mount option in correct order Message-ID: Date: Thu, 26 Aug 2021 08:05:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 8/26/21 7:46 AM, Matthew Wilcox wrote: > On Wed, Jul 21, 2021 at 01:30:57PM +0200, Roberto Bergantinos Corpas wrote: >> With addition of fs_context support, options string is parsed >> sequentially, if 'sloppy' option is not leftmost one, we may >> return ENOPARAM to userland if a non-valid option preceeds sloopy >> and mount will fail : >> >> host# mount -o quota,sloppy 172.23.1.225:/share /mnt >> mount.nfs: an incorrect mount option was specified >> host# mount -o sloppy,quota 172.23.1.225:/share /mnt > > It isn't clear to me that this is incorrect behaviour. Perhaps the user > actually wants the options to the left parsed strictly and the options > to the right parsed sloppily? I don't think mount options have ever been order-dependent, at least not intentionally so, have they? And what matters most here is surely "how did it work before the mount API change?" And it seems to me that previously, invalid options were noted, and whether the mount would fail was left to the end, depending on whether sloppy was seen anywhere in the mount options string. This is the old option parsing: while ((p = strsep(&raw, ",")) != NULL) { ... switch (token) { ... case Opt_sloppy: sloppy = 1; dfprintk(MOUNT, "NFS: relaxing parsing rules\n"); break; ... default: invalid_option = 1; dfprintk(MOUNT, "NFS: unrecognized mount option " "'%s'\n", p); } } if (!sloppy && invalid_option) return 0; -Eric