Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp4872386rwb; Tue, 20 Sep 2022 23:01:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4XIz6eJ1IecJfzN4b6YgYYe+q6TyW1KJNRHRoSPs73kYrRejReQNQBJLZ/rXBVS/xLp9UJ X-Received: by 2002:a17:902:c702:b0:178:9fb3:419a with SMTP id p2-20020a170902c70200b001789fb3419amr3176953plp.35.1663740110981; Tue, 20 Sep 2022 23:01:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663740110; cv=none; d=google.com; s=arc-20160816; b=ECWFGQdTY2gmSB5DGBDql9sRAp/wQ2Y5OmDy2a8VJpJ1JXnlqTwr0df/nNHUtx7bnA sQE57LgTQMfQN95gJtnEJElKnomdjeI1u8N/wkA9S3NAS/FxzC9Q9RYe1N0UqrAH6jDM 5xbdeeGQDdSoT0NJSsWKmpCOrzSI1FREtsROgxiKGMot86NiuWg8AE4Q5L9zp4YVNjy7 CwHs9s8zPpp0toYIUPKZXqlBAdFxu904JlsWmt0oEZEwaSItP6kbyOec+fy6n44C965j k6CTNrCllzZaG36O3kuttP5O54z3Nf1UJDbUwLkuOJQSRYyWnbFu35KkEurWEyuAeHYE Fxmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id:feedback-id:dkim-signature:dkim-signature; bh=2UULJx/vem16HYHhCNkienz2tAyT+A6FYxpwNK2en5g=; b=TANNyAjzR3YX0wtMU60smD63hG0EC5vSMfgBCZhyvaxCOJOGfDcjiLYyH74ewuKmjv Hu9eHOdcJLiMb5Ijs+pCvYkwWNC5ECbMXYpkwgJwxclYa3daCwRSsqpDETtuDyN+3pb9 p1IZv0Syep7PxJ0DrurXimEY6v0yhkEyVDCJ5nToY8TmRVAbqpUDGyBfY4aPlML3nRsv H+19ulWLmlR/rwm8NED9/q3eHHPW96n4Tx6UNCYHSoweCBvaQqAm0LX+JHPfBw6T/ly0 nFGo0Sjb7qhuB1Gi2Y3whfWb560Cmm6l1V0yWUm8WDwUkwqDXt7eZ/ujNkh6GmExZJ3I aZQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm1 header.b=Z7FrXqF3; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="AW7G/31Z"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w21-20020a631615000000b00439cc644c03si1645059pgl.228.2022.09.20.23.01.39; Tue, 20 Sep 2022 23:01:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@themaw.net header.s=fm1 header.b=Z7FrXqF3; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b="AW7G/31Z"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229766AbiIUFf7 (ORCPT + 99 others); Wed, 21 Sep 2022 01:35:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229563AbiIUFf6 (ORCPT ); Wed, 21 Sep 2022 01:35:58 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 874166B8F6; Tue, 20 Sep 2022 22:35:57 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 539EE5C00E5; Wed, 21 Sep 2022 01:35:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 21 Sep 2022 01:35:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1663738554; x= 1663824954; bh=2UULJx/vem16HYHhCNkienz2tAyT+A6FYxpwNK2en5g=; b=Z 7FrXqF3T4L4cjkmA0xf7FNtYEM5M0l+9LCxsurqg+7XhF2fmCiXG2+6u3XRrjfNJ n3VtU/KkbeFkaTKjYM5qACfrObzixk8FqE7A1xBmoupIrNeWaAkTArG12MP3dhdv NVoRAPqnUmGdOdEEkT7DwMphpZd5ozdBGEY26+KU7gUnQA/k30cda/xotZi9DA03 Ny18QcMQdPC2oJFmXMurEUY8itrAe0wb91NBR1AXWsXOlMMIg9967Q42iV7Ue9cQ d8iSL4wsZCzxDQHR9GzvlRtoz/JadozZ4bMdenWaI8TaGafrognGhhllso/eq67R w1DL0TPOmsmOcFztu730A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1663738554; x= 1663824954; bh=2UULJx/vem16HYHhCNkienz2tAyT+A6FYxpwNK2en5g=; b=A W7G/31ZwSKdqKXrWzqN/39PJMXAbEzCTg3Wil7w/82nM27DoPxdjUxLfx3wO/FhK 0yYMbspzFwD5La1ot9T6LekKkWnEzhmZu1QebnufV23M2ciEzNuNfstgPfjmcEJb ce5uOzmvsSv8SRpduLtiF7RYftZZEv30tsNllsqEeEwe5f5LIvm4JArgtNdySMQK I6epc7e/15Aq1PWJjviVyskIBe/gd/P1LdAqw5gvyuiFFg2bfqJaPUP09vt/ZU5J xHeK6vfif3SnFiueJ+fiEy9zKOKgWWsNeCnpz/GXSQ55qbjKnJn8m9MuwYcZ8bbL hJgPIoDWgJfdzsQQI5kpQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeftddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffhvfevfhgjtgfgsehtjeertddtfeejnecuhfhrohhmpefkrghn ucfmvghnthcuoehrrghvvghnsehthhgvmhgrfidrnhgvtheqnecuggftrfgrthhtvghrnh epjeehvdetgeejteeuleeigeefieduudfgteelgefggeetvdefveethfdtjeevledtnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhgrvhgvnh esthhhvghmrgifrdhnvght X-ME-Proxy: Feedback-ID: i31e841b0:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 21 Sep 2022 01:35:50 -0400 (EDT) Message-ID: Date: Wed, 21 Sep 2022 13:35:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [REPOST PATCH v3 0/2] vfs: fix a mount table handling problem Content-Language: en-US From: Ian Kent To: Theodore Ts'o Cc: Al Viro , Andrew Morton , Siddhesh Poyarekar , David Howells , Miklos Szeredi , Carlos Maiolino , linux-fsdevel , Kernel Mailing List References: <166365872189.39016.10771273319597352356.stgit@donald.themaw.net> <7064c4cc-4098-6744-298d-fddb3621ca41@themaw.net> In-Reply-To: <7064c4cc-4098-6744-298d-fddb3621ca41@themaw.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/9/22 12:38, Ian Kent wrote: > > On 21/9/22 09:20, Theodore Ts'o wrote: >> On Tue, Sep 20, 2022 at 03:26:17PM +0800, Ian Kent wrote: >>> Whenever a mount has an empty "source" (aka mnt_fsname), the glibc >>> function getmntent incorrectly parses its input, resulting in reporting >>> incorrect data to the caller. >>> >>> The problem is that the get_mnt_entry() function in glibc's >>> misc/mntent_r.c assumes that leading whitespace on a line can always >>> be discarded because it will always be followed by a # for the case >>> of a comment or a non-whitespace character that's part of the value >>> of the first field. However, this assumption is violated when the >>> value of the first field is an empty string. >>> >>> This is fixed in the mount API code by simply checking for a pointer >>> that contains a NULL and treating it as a NULL pointer. >> Why not simply have the mount API code disallow a zero-length "source" >> / mnt_fsname? > > Hi Ted, > > > I suppose but it seems to me that, for certain file systems, mostly > > pseudo file systems, the source isn't needed and is left out ... so > > disallowing a zero length source could lead to quite a bit of breakage. There's handling consistency too. Ideally any empty string parameter will print "(none)" when listing the proc mount tables. Mostly that happens in the proc code because the field is NULL so if an empty string is specified due to having to provide a positional parameter or for some other reason then handling it by setting the zero length string to NULL in the mount API is conveniently central. We could fix it in the proc code too but then we might see cases get missed over time and we sacrifice an opportunity to improve consistency. To my mind continuing to allow it and dealing with what needs to be done to make that work consistently seemed like the better long term approach. So based on that logic, sticky speaking, the ext patch shouldn't retain the zero length string check but for now ... > > > Ian >