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;
MIME-Version: 1.0
References: <20220422134308.1613610-1-svens@linux.ibm.com> <202204221052.85D0C427@keescook>
 <CAHk-=wjahn2fZtMxmc4D9UOUGWVws1wZ=X46jrTV=_tEpzXeoA@mail.gmail.com>
 <202206081404.F98F5FC53E@keescook> <CAHk-=wiFn-_OaWKY=nXt3YSiy=obrNoQW_u7zKO7qoArez=GUw@mail.gmail.com>
 <AEEBCF5D-8402-441D-940B-105AA718C71F@chromium.org> <CAHk-=wh6+KUi+T8Ncn6BWTHDTJCzrJxgT47SWbq-ZWs1_vbvHA@mail.gmail.com>
 <4147483.1654784079@warthog.procyon.org.uk>
In-Reply-To: <4147483.1654784079@warthog.procyon.org.uk>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu, 9 Jun 2022 11:20:02 -0700
Message-ID: <CAHk-=wj5hoE19YNniN+cquGT6H2z1BefbBo7UwE4-oySW86BxA@mail.gmail.com>
Subject: Re: [PATCH] s390: disable -Warray-bounds
To:     David Howells <dhowells@redhat.com>
Cc:     Dave Chinner <dchinner@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        Sven Schnelle <svens@linux.ibm.com>,
        Heiko Carstens <hca@linux.ibm.com>,
        Vasily Gorbik <gor@linux.ibm.com>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jun 9, 2022 at 7:14 AM David Howells <dhowells@redhat.com> wrote:
>
> Note that Dave Chinner would rather I converted code like:
>
>         struct myfs_inode *myfsinode = xyz;
>         myfsinode->netfs.inode.i_ino = 123;
>
> to something like:
>
>         struct myfs_inode *myfsinode = xyz;
>         struct inode *inode = VFS_I(myfsinode);
>         inode->i_ino = 123;
>
> where the translation is wrapped inside a VFS_I() macro in every filesystem
> and wants this across all filesystems.

What? No. That's absolutely disgusting.

Maybe I'm mis-undestanding.

The usual way filesystems should handle this is that they have their
own inode information that contains a 'struct inode', and then they
have an inline function to go from that generic VFS inode to their one
using "container_of()".

And yeah, maybe they call that container_of() thing MYINODE() or
something, although I think an inline function without the ugly
all-uppercase is right.

But the way they go the other way is literally to just dereference the
inode that they have, ie they just use a

        if (S_ISREG(inode->vfs_inode.i_mode)) ..

kind pattern. There's no reason or excuse to try to "wrap" that, and
it would be a big step backwards to introduce some kind of VFS_I()
macro.

There's also no reason to make that generic. At no point should you
ever go from "random filesystem inode" to "actual generic VFS inode"
in some uncontrolled manner.

But maybe Dave is talking about something else, and I'm missing the point.

            Linus