linux-kernel - Re: [PATCH/RFC v2 0/6] Convert stop

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]

Date:	Thu, 16 Oct 2008 21:38:42 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	jens.axboe@...cle.com, mingo@...e.hu, akpm@...ux-foundation.org,
	schwidefsky@...ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC v2 0/6] Convert stop_machine to use a workqueue

On Tuesday 14 October 2008 08:50:07 Heiko Carstens wrote:
> Version 2: This is version 2 which converts stop_machine to a workqueue
> based implementation as suggested by Rusty instead of trying to extend the
> current kernel thread approach.
>
> This patch series would allow to convert s390 to the generic IPI interface.
> We can't to that currently since our etr/stp code relies on the old
> semantics of smp_call_function that guarantee that the function only
> returns after all receiving cpus have acknowledged the IPI. That way it is
> known that all other cpus are running in an interrupt handler with
> interrupts disabled. This is not true anymore with the generic IPI
> infrastructure.
>
> So one idea was to use stop_machine in order to synchronize all cpus. Rusty
> was kind enough to extend it so that it is now possible to run a function
> on several cpus, instead of just one.
> However we need to be able to do that without allocating any memory. That's
> what this patch set is about: it changes the current stop_machine code to
> use a workqueue instead of kernel threads to synchronize all cpus.
> This has the advantage that all per cpu workqueue threads are already
> running when stop_machine gets called and therefore no memory needs to be
> allocated. In addition stop_machine cant't fail anymore (free_module()
> relies on that).
>
> A few things that need to be addressed:
> - stop_machine gets called from initcalls, so we need to make sure that it
>   is already initialized and has its workqueue started before that. For
> that a pre_smp initcall (early_initcall) is used to initialize it.
> - the stop_machine kernel threads used to be rt kernel threads. Workqueues
>   are normal threads. To get high priority threads a new interface
>   create_rt_workqueue is introduced.
>
> Patch 1 Moves the call to init_workqueue before pre smp initcalls
> Patch 2 introduces create_rt_workqueue
> Patch 3 converts stop_machine to use an rt workqueue

OK, I've taken 1-3.  Hope for Ingo's ack on 1 and 2.  I'm holding out on 4, 
and hopefully s390 can merge after this is done.

Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/