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;
Date:   Fri, 28 Oct 2022 12:54:04 -0400
From:   Jan Harkes <jaharkes@cs.cmu.edu>
To:     Bagas Sanjaya <bagasdotme@gmail.com>
Cc:     =?utf-8?B?0L3QsNCx?= <nabijaczleweli@nabijaczleweli.xyz>,
        Jonathan Corbet <corbet@lwn.net>,
        Federico Vaga <federico.vaga@vaga.pv.it>,
        Alex Shi <alexs@kernel.org>,
        Yanteng Si <siyanteng@loongson.cn>,
        Hu Haowen <src.res@email.cn>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-doc-tw-discuss@lists.sourceforge.net
Subject: Re: [PATCH 05/15] coda: remove CODA_MAGIC
Message-ID: <20221028165404.hzslvndpg26wop6k@cs.cmu.edu>
References: <9a453437b5c3b4b1887c1bd84455b0cc3d1c40b2.1666822928.git.nabijaczleweli@nabijaczleweli.xyz>
 <a6eb2dae62abf49b351760a4f55031d1c6f4ea01.1666822928.git.nabijaczleweli@nabijaczleweli.xyz>
 <b65541bf-ad17-b465-0f77-66d9e9c242fb@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b65541bf-ad17-b465-0f77-66d9e9c242fb@gmail.com>
Precedence: bulk

On Fri, Oct 28, 2022 at 08:23:38PM +0700, Bagas Sanjaya wrote:
> On 10/27/22 05:42, наб wrote:
> > We have largely moved away from this approach,
> > and we have better debugging tooling nowadays: kill it
> > 
> 
> Again, see [1] and [2].
> 
> [1]: https://lore.kernel.org/linux-doc/47c2bffb-6bfe-7f5d-0d2d-3cbb99d31019@gmail.com/
> [2]: https://lore.kernel.org/linux-doc/9d96c96d-dfc7-7749-07d4-2601c00661c2@gmail.com/

I guess I must be old-school because I appreciate magic numbers and
assertions to catch situations that should obviously never happen.

This https://lkml.org/lkml/2019/4/2/923 bug would have been caught a lot
sooner if ext4 had happened to check a magic number in vma->vm_file. As
it was, we ended up passing a Coda file instead of a file handle for the
the underlying filesystem which then ended up with the wrong inode and
their mmap_sem happened to scribble the spinlock on the Coda inode.

This wasn't really ext4's fault, it wasn't expecting to get a mmapped
region with another file system's file handle, but that is exactly the
point of these magic numbers, to catch the unexpected. Not sure what
better debug tooling would catch that unless you were already expecting
the problem.

Jan