[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250206-seestern-amtsmissbrauch-f72509002083@brauner>
Date: Thu, 6 Feb 2025 10:46:52 +0100
From: Christian Brauner <brauner@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: viro@...iv.linux.org.uk, jack@...e.cz, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 0/3] CONFIG_VFS_DEBUG at last
On Wed, Feb 05, 2025 at 07:57:07PM +0100, Mateusz Guzik wrote:
> On Wed, Feb 5, 2025 at 7:38 PM Mateusz Guzik <mjguzik@...il.com> wrote:
> >
> > This adds a super basic version just to get the mechanism going and
> > adds sample usage.
> >
> > The macro set is incomplete (e.g., lack of locking macros) and
> > dump_inode routine fails to dump any state yet, to be implemented(tm).
> >
> > I think despite the primitive state this is complete enough to start
> > sprinkling warns as necessary.
> >
> > Mateusz Guzik (3):
> > vfs: add initial support for CONFIG_VFS_DEBUG
> > vfs: catch invalid modes in may_open
> > vfs: use the new debug macros in inode_set_cached_link()
> >
> > fs/namei.c | 2 ++
> > include/linux/fs.h | 16 +++----------
> > include/linux/vfsdebug.h | 50 ++++++++++++++++++++++++++++++++++++++++
> > lib/Kconfig.debug | 9 ++++++++
> > 4 files changed, 64 insertions(+), 13 deletions(-)
> > create mode 100644 include/linux/vfsdebug.h
> >
> > --
> > 2.43.0
> >
>
> The produced warn is ugly as sin:\, for example for that bad size:
> [ 51.433206] VFS_WARN_ON_INODE(__builtin_choose_expr((sizeof(int) ==
> sizeof(*(8 ? ((void *)((long)(__builtin_strlen(link)) * 0l)) : (int
> *)8))), __builtin_strlen(link), __fortify_strlen(link)) != linklen)
> failed for inode ff32f7c350c8aec8
>
> maybe there is a way to work it around, the code is literally lifted
> out of mmdebug.h so they presumably have the same problem
>
> apart from that the assert in may_open is backwards, the code normally
> is not reached.
>
> anyhow I expect to send a v2, but will wait for feedback before I do
I think it is overdue that we do something like this. Being able to be
more liberal with _meaningful_ asserts can help us in the long run.
So I'm supportive.
Powered by blists - more mailing lists