From: Mathias Krause <minipli@grsecurity.net>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Ajay Kaher" <ajay.kaher@broadcom.com>,
linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
"Ilkka Naulapää" <digirigawa@gmail.com>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Brad Spengler" <spender@grsecurity.net>
Subject: Re: [PATCH 2/2] tracefs: Don't overlay 'struct inode'
Date: Wed, 7 Aug 2024 22:19:46 +0200 [thread overview]
Message-ID: <178d8e10-1dd8-48de-858f-1a04c419c331@grsecurity.net> (raw)
In-Reply-To: <20240807093545.4ec51d61@gandalf.local.home>
On 07.08.24 15:35, Steven Rostedt wrote:
> On Wed, 7 Aug 2024 13:51:39 +0200
> Mathias Krause <minipli@grsecurity.net> wrote:
>
>> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
>> index f704d8348357..a7769857962a 100644
>> --- a/fs/tracefs/internal.h
>> +++ b/fs/tracefs/internal.h
>> @@ -10,10 +10,8 @@ enum {
>> };
>>
>> struct tracefs_inode {
>> - union {
>> - struct inode vfs_inode;
>> - struct rcu_head rcu;
>> - };
>> + struct inode vfs_inode;
>> + struct rcu_head rcu;
>
> I rather not make this structure any bigger for the rcu element that is not
> used until freed.
Uhm, at least for my config, it won't consume more memory, as the slab
object is big enough to cover up for the additional two machine words:
root@deb11-amd64:~# slabinfo tracefs_inode_cache
Slabcache: tracefs_inode_cache Aliases: 0 Order : 3 Objects: 144
** Reclaim accounting active
Sizes (bytes) Slabs Debug Memory
------------------------------------------------------------------------
Object : 1200 Total : 6 Sanity Checks : Off Total: 196608
SlabObj: 1328 Full : 4 Redzoning : Off Used : 172800
SlabSiz: 32768 Partial: 0 Poisoning : Off Loss : 23808
Loss : 128 CpuSlab: 2 Tracking : Off Lalig: 18432
Align : 8 Objects: 24 Tracing : Off Lpadd: 5376
[...]
While the size of 'struct tracefs_inode' is 1200 bytes for my kernel
build (LOCKDEP bloats it quite a lot), the slab object size is 1328
bytes, i.e. 128 bytes wasted per object which can, for sure, cover up
for these additional members.
>
>> /* The below gets initialized with memset_after(ti, 0, vfs_inode) */
>> struct list_head list;
>> unsigned long flags;
>
> Perhaps:
>
> diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
> index f704d8348357..ab6d6c3d835d 100644
> --- a/fs/tracefs/internal.h
> +++ b/fs/tracefs/internal.h
> @@ -10,12 +10,12 @@ enum {
> };
>
> struct tracefs_inode {
> + struct inode vfs_inode;
> + /* The below gets initialized with memset_after(ti, 0, vfs_inode) */
> union {
> - struct inode vfs_inode;
> + struct list_head list;
> struct rcu_head rcu;
> };
> - /* The below gets initialized with memset_after(ti, 0, vfs_inode) */
> - struct list_head list;
> unsigned long flags;
> void *private;
> };
I'd rather not exchange trashing one RCU-walked list for another. Or how
will this play out for the RCU walk in tracefs_apply_options() if
there's a concurrent call to tracefs_free_inode() which will now trash
the list_head tracefs_apply_options() is walking over?
Thanks,
Mathias
next prev parent reply other threads:[~2024-08-07 20:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-07 11:51 [PATCH 0/2] tracefs: inode alloc/free related fixes Mathias Krause
2024-08-07 11:51 ` [PATCH 1/2] tracefs: Fix inode allocation Mathias Krause
2024-08-07 11:51 ` [PATCH 2/2] tracefs: Don't overlay 'struct inode' Mathias Krause
2024-08-07 13:35 ` Steven Rostedt
2024-08-07 13:44 ` Al Viro
2024-08-07 15:49 ` Steven Rostedt
2024-08-07 20:27 ` Mathias Krause
2024-08-07 20:24 ` Mathias Krause
2024-08-07 20:19 ` Mathias Krause [this message]
2024-08-07 13:34 ` [PATCH 0/2] tracefs: inode alloc/free related fixes Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=178d8e10-1dd8-48de-858f-1a04c419c331@grsecurity.net \
--to=minipli@grsecurity.net \
--cc=ajay.kaher@broadcom.com \
--cc=digirigawa@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=spender@grsecurity.net \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox