linux-kernel - Re: [RFC PATCH 1/5] sched, fork: Wire BLOG contexts into task lifecycle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b46130d7e9232b3163db4299fdd09f73668f059a.camel@ibm.com>
Date: Wed, 29 Oct 2025 18:57:05 +0000
From: Viacheslav Dubeyko <Slava.Dubeyko@....com>
To: "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Alex Markuze
	<amarkuze@...hat.com>,
        "ceph-devel@...r.kernel.org"
	<ceph-devel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
        "rppt@...nel.org"
	<rppt@...nel.org>,
        "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
        Xiubo Li <xiubli@...hat.com>,
        "idryomov@...il.com" <idryomov@...il.com>,
        "david@...hat.com" <david@...hat.com>,
        "mgorman@...e.de" <mgorman@...e.de>, "vbabka@...e.cz" <vbabka@...e.cz>,
        "vincent.guittot@...aro.org"
	<vincent.guittot@...aro.org>,
        "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>,
        "Liam.Howlett@...cle.com"
	<Liam.Howlett@...cle.com>,
        Ingo Molnar <mingo@...hat.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "surenb@...gle.com"
	<surenb@...gle.com>,
        Valentin Schneider <vschneid@...hat.com>,
        "kees@...nel.org" <kees@...nel.org>,
        "peterz@...radead.org"
	<peterz@...radead.org>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "bsegall@...gle.com" <bsegall@...gle.com>,
        "juri.lelli@...hat.com"
	<juri.lelli@...hat.com>
Subject: Re:  [RFC PATCH 1/5] sched, fork: Wire BLOG contexts into task
 lifecycle

On Fri, 2025-10-24 at 08:42 +0000, Alex Markuze wrote:
> Extend struct task_struct with a blog_contexts array to hold per-module
> BLOG TLS pointers. Each task may have up to BLOG_MAX_MODULES (currently 8)
> distinct logging contexts, allowing multiple subsystems to attach binary
> loggers without interference.
> 
> The fork path (copy_process) initializes blog_contexts to NULL for new
> tasks, ensuring clean initial state. The exit path (do_exit) calls
> blog_tls_clear_task() to release any active contexts before task teardown,
> ensuring contexts are properly recycled to the magazine pool and preventing
> use-after-free scenarios.
> 
> These changes are conditional on CONFIG_BLOG. Kernels built without BLOG
> support incur no storage or runtime overhead in task_struct.
> 
> This commit establishes the foundation for per-task binary logging contexts
> but does not activate any logging functionality. The BLOG subsystem itself
> is introduced in subsequent commits.
> 
> Signed-off-by: Alex Markuze <amarkuze@...hat.com>
> ---
>  include/linux/sched.h |  7 +++++++
>  kernel/fork.c         | 37 +++++++++++++++++++++++++++++++++++++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 07576479c0ed..e381f8421a11 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1278,6 +1278,13 @@ struct task_struct {
>  	/* Journalling filesystem info: */
>  	void				*journal_info;
>  
> +/* BLOG support - max modules defined here for use by other headers */
> +#define BLOG_MAX_MODULES 8
> +
> +#ifdef CONFIG_BLOG
> +	struct blog_tls_ctx		*blog_contexts[BLOG_MAX_MODULES];
> +#endif
> +
>  	/* Stacked block device info: */
>  	struct bio_list			*bio_list;
>  
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 3da0f08615a9..b06843af05a9 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -24,6 +24,9 @@
>  #include <linux/sched/cputime.h>
>  #include <linux/sched/ext.h>
>  #include <linux/seq_file.h>
> +#ifdef CONFIG_BLOG
> +#include <linux/blog/blog.h>
> +#endif
>  #include <linux/rtmutex.h>
>  #include <linux/init.h>
>  #include <linux/unistd.h>
> @@ -186,6 +189,29 @@ static inline struct task_struct *alloc_task_struct_node(int node)
>  
>  static inline void free_task_struct(struct task_struct *tsk)
>  {
> +#ifdef CONFIG_BLOG
> +	/* Clean up any BLOG contexts */
> +	{
> +		struct blog_tls_ctx *contexts[BLOG_MAX_MODULES];
> +		int i;
> +
> +		/* Step 1: Atomically detach all contexts while holding lock */
> +		task_lock(tsk);
> +		for (i = 0; i < BLOG_MAX_MODULES; i++) {
> +			contexts[i] = tsk->blog_contexts[i];
> +			tsk->blog_contexts[i] = NULL;
> +		}
> +		task_unlock(tsk);
> +
> +		/* Step 2: Release contexts outside the lock */
> +		for (i = 0; i < BLOG_MAX_MODULES; i++) {
> +			struct blog_tls_ctx *ctx = contexts[i];
> +
> +			if (ctx && ctx->release)
> +				ctx->release(ctx);
> +		}
> +	}
> +#endif

It looks like a function that can hide this CONFIG_BLOG declarations. What's
about to introduce the function for this logic?

#ifdef CONFIG_BLOG
static inline void free_blog_context()
{
   <logic is here>
}
#else
static inline void free_blog_context() {}
#endif


>  	kmem_cache_free(task_struct_cachep, tsk);
>  }
>  
> @@ -2012,6 +2038,17 @@ __latent_entropy struct task_struct *copy_process(
>  	p = dup_task_struct(current, node);
>  	if (!p)
>  		goto fork_out;
> +
> +#ifdef CONFIG_BLOG
> +	/* Initialize BLOG contexts */
> +	{
> +		int i;
> +
> +		for (i = 0; i < BLOG_MAX_MODULES; i++)
> +			p->blog_contexts[i] = NULL;
> +	}
> +#endif
> +

The same here. What's about to introduce the function for this logic?

By the way, could memset() be used here instead of loop?

Thanks,
Slava.

>  	p->flags &= ~PF_KTHREAD;
>  	if (args->kthread)
>  		p->flags |= PF_KTHREAD;