Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5620627ybp; Tue, 8 Oct 2019 05:59:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqw4LzCfnW1hZu6Ja8YO5x8BuBEsAsVTdN/Sf+1FuNO6GE4K91gtp3nmM6qx5URwSjy4+tvW X-Received: by 2002:a17:906:4cc3:: with SMTP id q3mr25150072ejt.176.1570539545974; Tue, 08 Oct 2019 05:59:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570539545; cv=none; d=google.com; s=arc-20160816; b=Fu2wxT6BRQ8vo+aueXeq9Hcxm9sKbxTzOX/g0OP5m4P3/gV+q4fhHsfWVmdFyh0z4b coS8dvtzTyUKvJV5FQfUUJ2JCDoEiCFhVKoVNvez2HJVFGT8s+1+n99dLeovmjfJeT4c WdDbr/Bsiqie9TGLEuOUm7Pxo0GIlTJsar2T2Nw2jhus+0wZaExEIOMV2dn4I3/qregD 8F+MpDQ24rvBqp3tF8XtWAU6bkNP1H6we3Px6yzfA7oRSmRnVX9Gq6+seZ5XXoval34M sQa5IboPbqmypmy+v1DRGmDu8pz7UzelTVh96xkx57Za6ehZi56Sb5jR1OHUwAcMPpWn C9fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xk6eB4s1D2RUOdljgUS9gS57tLkR6ZsPKxbcTze3Vmk=; b=RQCeBxLIPqvFJZtNCc563Q8BDYqlIJDoZIYHo7qa3rQZ4lhqG463CYwT6QpaxOnShX 6E95dNsOd6VVGCVkRqk4DU6DW5McMisAT33nDtKsXPx820Pb8T2QvlyXaAevmMf2D211 kNBuw9QeFt1hN79h4qbI2J/553j4kP5rBahsiNVR4fDaaAQlRb+elpkmWtb6dywDbaM+ 6ennBx+ZCFjoywQc8GZC/+KKu/5s2SJ7On9BlKFja8V9xPx2uh4Er8TAfG8I9CWOEIGy 1XKgIjWhmfRAWwx/bxkhuezJJpoV1F4OlPvlNpI+N9eRqWqWyJ6T4A0wYe+M9+/fKjEk wJag== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q30si11125178eda.5.2019.10.08.05.58.42; Tue, 08 Oct 2019 05:59:05 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731029AbfJHM4U (ORCPT + 99 others); Tue, 8 Oct 2019 08:56:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52458 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730670AbfJHM4U (ORCPT ); Tue, 8 Oct 2019 08:56:20 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1074AA26682; Tue, 8 Oct 2019 12:56:20 +0000 (UTC) Received: from 10.255.255.10 (unknown [10.40.205.32]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7EE285DA2C; Tue, 8 Oct 2019 12:56:13 +0000 (UTC) Date: Tue, 8 Oct 2019 14:56:10 +0200 From: Karel Zak To: Ian Kent Cc: Hugh Dickins , Laura Abbott , David Howells , Alexander Viro , Linux-MM , Linux Kernel Mailing List , linux-fsdevel@vger.kernel.org Subject: Re: mount on tmpfs failing to parse context option Message-ID: <20191008125610.s4fgnnba7yhclb3z@10.255.255.10> References: <59784f8ac4d458a09d40706b554432b283083938.camel@themaw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <59784f8ac4d458a09d40706b554432b283083938.camel@themaw.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Tue, 08 Oct 2019 12:56:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 08, 2019 at 08:38:18PM +0800, Ian Kent wrote: > > That's because the options in shmem_parse_options() are > > "size=4G,nr_inodes=0", which indeed looks like an attempt to > > retroactively limit size; but the user never asked "size=4G" there. > > I believe that's mount(8) doing that. > I don't think it's specific to the new mount api. > > AFAIK it's not new but it does mean the that things that come > through that have been found in mtab by mount(8) need to be > checked against the current value before failing or ignored if > changing them is not allowed. > > I wonder if the problem has been present for quite a while but > gone unnoticed perhaps. > > IIUC the order should always be command line options last and it > must be that way to honour the last specified option takes > precedence convention. > > I thought this was well known, but maybe I'm wrong ... and TBH > I wasn't aware of it until recently myself. Yep, the common behavior is "the last option wins". See man mount, remount option: remount functionality follows the standard way the mount command works with options from fstab. This means that mount does not read fstab (or mtab) only when both device and dir are specified. mount -o remount,rw /dev/foo /dir After this call all old mount options are replaced and arbitrary stuff from fstab (or mtab) is ignored, except the loop= option which is internally generated and maintained by the mount command. mount -o remount,rw /dir After this call, mount reads fstab and merges these options with the options from the command line (-o). If no mountpoint is found in fstab, then a remount with unspeciā€ fied source is allowed. If you do not like this classic behavior than recent mount(8) versions provide --options-mode={ignore,append,prepend,replace} to keep it in your hands. Karel > > > > > Hugh > -- Karel Zak http://karelzak.blogspot.com