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;
MIME-Version: 1.0
References: <20191212145042.12694-1-labbott@redhat.com> <CAOi1vP9E2yLeFptg7o99usEi=x3kf=NnHYdURXPhX4vTXKCTCQ@mail.gmail.com>
 <fbe90a0b-cf24-8c0c-48eb-6183852dfbf1@redhat.com>
In-Reply-To: <fbe90a0b-cf24-8c0c-48eb-6183852dfbf1@redhat.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 12 Dec 2019 09:56:39 -0800
Message-ID: <CAHk-=wh7Wuk9QCP6oH5Qc1a89_X6H1CHRK_OyB4NLmX7nRYJeA@mail.gmail.com>
Subject: Re: [PATCH] vfs: Don't reject unknown parameters
To:     Laura Abbott <labbott@redhat.com>
Cc:     Ilya Dryomov <idryomov@gmail.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        David Howells <dhowells@redhat.com>,
        Jeremi Piotrowski <jeremi.piotrowski@gmail.com>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        Phillip Lougher <phillip@squashfs.org.uk>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: multipart/mixed; boundary="0000000000008e989005998578dc"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--0000000000008e989005998578dc
Content-Type: text/plain; charset="UTF-8"

On Thu, Dec 12, 2019 at 9:47 AM Laura Abbott <labbott@redhat.com> wrote:
>
> Good point, I think I missed how that code flow worked for printing
> out the error. I debated putting in a dummy parse_param but I
> figured that squashfs wouldn't be the only fs that didn't take
> arguments (it's in the minority but certainly not the only one).

I think printing out the error part is actually fine - it would act as
a warning for invalid parameters like this.

So I think a dummy parse_param that prints out a warning is likely the
right thing to do.

Something like the attached, perhaps? Totally untested.

               Linus

--0000000000008e989005998578dc
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_k430y16a0>
X-Attachment-Id: f_k430y16a0

IGZzL3NxdWFzaGZzL3N1cGVyLmMgfCA5ICsrKysrKysrKwogMSBmaWxlIGNoYW5nZWQsIDkgaW5z
ZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2ZzL3NxdWFzaGZzL3N1cGVyLmMgYi9mcy9zcXVhc2hm
cy9zdXBlci5jCmluZGV4IDBjYzRjZWVjMDU2Mi4uZmJkMWUwNWIzOWFhIDEwMDY0NAotLS0gYS9m
cy9zcXVhc2hmcy9zdXBlci5jCisrKyBiL2ZzL3NxdWFzaGZzL3N1cGVyLmMKQEAgLTM1NSw5ICsz
NTUsMTggQEAgc3RhdGljIGludCBzcXVhc2hmc19yZWNvbmZpZ3VyZShzdHJ1Y3QgZnNfY29udGV4
dCAqZmMpCiAJcmV0dXJuIDA7CiB9CiAKKy8qIFByaW50IHRoZSB3YXJuaW5nLCBidXQgaWdub3Jl
IGl0IGFzIGFuIGVycm9yICovCitzdGF0aWMgaW50IHNxdWFzaGZzX3BhcnNlX3BhcmFtKHN0cnVj
dCBmc19jb250ZXh0ICpmYywgc3RydWN0IGZzX3BhcmFtZXRlciAqcGFyYW0pCit7CisJaW52YWxm
KGZjLCAiJXM6IFVua25vd24gcGFyYW1ldGVyICclcyciLAorCQlmYy0+ZnNfdHlwZS0+bmFtZSwg
cGFyYW0tPmtleSk7CisJcmV0dXJuIDA7Cit9CisKIHN0YXRpYyBjb25zdCBzdHJ1Y3QgZnNfY29u
dGV4dF9vcGVyYXRpb25zIHNxdWFzaGZzX2NvbnRleHRfb3BzID0gewogCS5nZXRfdHJlZQk9IHNx
dWFzaGZzX2dldF90cmVlLAogCS5yZWNvbmZpZ3VyZQk9IHNxdWFzaGZzX3JlY29uZmlndXJlLAor
CS5wYXJzZV9wYXJhbQk9IHNxdWFzaGZzX3BhcnNlX3BhcmFtLAogfTsKIAogc3RhdGljIGludCBz
cXVhc2hmc19pbml0X2ZzX2NvbnRleHQoc3RydWN0IGZzX2NvbnRleHQgKmZjKQo=
--0000000000008e989005998578dc--