linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Ian Kent <raven@themaw.net>
Cc: Hugh Dickins <hughd@google.com>,
	Laura Abbott <labbott@redhat.com>,
	David Howells <dhowells@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Linux-MM <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: mount on tmpfs failing to parse context option
Date: Tue, 8 Oct 2019 14:56:10 +0200	[thread overview]
Message-ID: <20191008125610.s4fgnnba7yhclb3z@10.255.255.10> (raw)
In-Reply-To: <59784f8ac4d458a09d40706b554432b283083938.camel@themaw.net>

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  <kzak@redhat.com>
 http://karelzak.blogspot.com


  parent reply	other threads:[~2019-10-08 12:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 16:07 Laura Abbott
2019-10-07 14:45 ` Laura Abbott
2019-10-08  0:50   ` Hugh Dickins
2019-10-08  1:26     ` Al Viro
2019-10-08 16:33       ` Laura Abbott
2019-10-08 12:38     ` Ian Kent
2019-10-08 12:52       ` Ian Kent
2019-10-08 12:56       ` Karel Zak [this message]
2019-10-08 19:51         ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191008125610.s4fgnnba7yhclb3z@10.255.255.10 \
    --to=kzak@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=hughd@google.com \
    --cc=labbott@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=raven@themaw.net \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox