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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL 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 182EDECE58C for ; Tue, 8 Oct 2019 19:51:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CA2B921871 for ; Tue, 8 Oct 2019 19:51:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sUYZuEYp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA2B921871 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 628118E0006; Tue, 8 Oct 2019 15:51:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D90F8E0003; Tue, 8 Oct 2019 15:51:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C7948E0006; Tue, 8 Oct 2019 15:51:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 24FE68E0003 for ; Tue, 8 Oct 2019 15:51:30 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id D55D855FB7 for ; Tue, 8 Oct 2019 19:51:29 +0000 (UTC) X-FDA: 76021661898.04.earth18_2a1cb54777e0d X-HE-Tag: earth18_2a1cb54777e0d X-Filterd-Recvd-Size: 6790 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 8 Oct 2019 19:51:29 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id t3so5022956pga.8 for ; Tue, 08 Oct 2019 12:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=tVOdpEM8zYwr6A95fEdbiKaAHkoR1ATc1z7R9NfKBdo=; b=sUYZuEYpMdnPU86NNv4TwIXjcaisunOJqKKRXDOVPRzLOM0ZJpMy5SNmT0gSKgUOyj 5ezid2WQ3js3yBhJmf1kh0drLSkVNcKBhuQuQif4BT4PNVvd5yBA41trFJ7CXFA46rLM OmnsWOrSqsJS2puQZPUpkxk8FM1p3Lh9P1KHQXlQ5JRbXyzYAxTV+nPOi9P+r+e+VBhp iBWO5EreivSZJ8KQnnrHb5AGL1wsXBUfzkNVDQo2/iY/+FILPhS44AIm0eAZnuphuFoA ONsS0sC9LlY1eGreXLFO2Y9OP/RImUnNF6o8HXY4XdzYw/wPZ0diFgeHWQrl7fJJJHLu tQXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=tVOdpEM8zYwr6A95fEdbiKaAHkoR1ATc1z7R9NfKBdo=; b=aP/z76dk542YDVEAm/37tU34L1SAxrGeg+af8N5pTMQJHwsp38+w4bUBRY/tI3Sgr3 5/0OAApJCkF6k5Nj+H67/4ZVXFV2TIeumFmHMiBjbNAS0cuTq4szXHBGmxMqF/Ql5kdn hDhtFNR7+HVuUWRPcjQcCav/HRCW9HjEuHBSDymJX7Zg/2pTHmDwOcJPqzD5JG9f5f8N 2lah92QcTspcNmCUGMm5S5TyKZBrZ5XwqTTUgn/7D/Qyw2B0PibkAah1hXxfiS9grzIW t24XXECcy/z4WO1E8sNPV7b1r2WNe/aXw5auKVoIHKQ369zK0Sgxgg2KXGKmxFKI1oFp +QPQ== X-Gm-Message-State: APjAAAU8egYKB2vQDgYLQMDmEfVigSmDAs2mfBRHGDU+E+YLviQ6V7WP SPViLuYuuS9nueR6c/dLk/9lNQ== X-Google-Smtp-Source: APXvYqw9rAK3pDOLRvbw0RQBkzSPpf/ogRjpf7rLxuQ1K92wrUhZlfrQXFPSd5BeidMsSu9S83VfvA== X-Received: by 2002:aa7:800d:: with SMTP id j13mr41082251pfi.187.1570564287334; Tue, 08 Oct 2019 12:51:27 -0700 (PDT) Received: from [100.112.64.176] ([104.133.9.96]) by smtp.gmail.com with ESMTPSA id t13sm17427284pfh.12.2019.10.08.12.51.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Oct 2019 12:51:26 -0700 (PDT) Date: Tue, 8 Oct 2019 12:51:02 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Ian Kent , Karel Zak 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 In-Reply-To: <20191008125610.s4fgnnba7yhclb3z@10.255.255.10> Message-ID: References: <59784f8ac4d458a09d40706b554432b283083938.camel@themaw.net> <20191008125610.s4fgnnba7yhclb3z@10.255.255.10> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1683574798-1570564286=:1204" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1683574798-1570564286=:1204 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 8 Oct 2019, Karel Zak wrote: > On Tue, Oct 08, 2019 at 08:38:18PM +0800, Ian Kent wrote: > > > That's because the options in shmem_parse_options() are > > > "size=3D4G,nr_inodes=3D0", which indeed looks like an attempt to > > > retroactively limit size; but the user never asked "size=3D4G" there. > >=20 > > I believe that's mount(8) doing that. > > I don't think it's specific to the new mount api. > >=20 > > 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. > >=20 > > I wonder if the problem has been present for quite a while but > > gone unnoticed perhaps. > >=20 > > 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. > >=20 > > I thought this was well known, but maybe I'm wrong ... and TBH > > I wasn't aware of it until recently myself. >=20 > Yep, the common behavior is "the last option wins". See man mount, > remount option: >=20 > 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. >=20 > mount -o remount,rw /dev/foo /dir >=20 > After this call all old mount options are replaced and arbitrary > stuff from fstab (or mtab) is ignored, except the loop=3D option which > is internally generated and maintained by the mount command. >=20 > mount -o remount,rw /dir >=20 > 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=E2=80=90 fied source is allowed. >=20 >=20 > If you do not like this classic behavior than recent mount(8) versions > provide --options-mode=3D{ignore,append,prepend,replace} to keep it in > your hands. Ian, Karel, many thanks for your very helpful education. I've not yet digested all of it, but the important thing is... Yes, you're right: my unexpectedly failing remount sequence fails equally on a v5.3 kernel, and I'll hazard a guess that it has failed like that ever since v2.4.8. I just never noticed (and nobody else ever complained) until I tried testing the new mount API: which at least has the courtesy to put an error message reflecting the final decision in dmesg, when the older kernels just silently EINVALed. (And it's not impossible to remount thereafter: one just has to add a "size=3D0" into the options, to allow the other options through.) So, I've no more worries for v5.4 tmpfs mount, and if there's anything that can be improved, that's a background job for me to look into later, once I've spent more time understanding the info you've given me. And Laura has confirmed that Al's security_sb_eat_lsm_opts() patch fixes the "context" issue: thanks. Hugh --0-1683574798-1570564286=:1204--