[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <084d7ef4-15a8-1d4e-6b20-5a848102ac03@suse.cz>
Date: Fri, 16 Sep 2022 23:02:17 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Maurizio Lombardi <mlombard@...hat.com>
Cc: linux-mm@...ck.org, rientjes@...gle.com, penberg@...nel.org,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, bigeasy@...utronix.de,
Hyeonggon Yoo <42.hyeyoo@...il.com>
Subject: Re: [PATCH V2] mm: slub: fix flush_cpu_slab()/__free_slab()
invocations in task context.
On 9/12/22 18:11, Maurizio Lombardi wrote:
> @@ -2730,7 +2735,7 @@ static void flush_all_cpus_locked(struct kmem_cache *s)
> INIT_WORK(&sfw->work, flush_cpu_slab);
> sfw->skip = false;
> sfw->s = s;
> - schedule_work_on(cpu, &sfw->work);
> + queue_work_on(cpu, flushwq, &sfw->work);
> }
>
> for_each_online_cpu(cpu) {
> @@ -4858,6 +4863,8 @@ void __init kmem_cache_init(void)
>
> void __init kmem_cache_init_late(void)
> {
> + flushwq = create_workqueue("slub_flushwq");
> + BUG_ON(!flushwq);
Adding new BUG_ON is essentially prohibited these days, so please use WARN_ON().
Other than that deprecation issue, looks fine to me.
> }
>
> struct kmem_cache *
Powered by blists - more mailing lists