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:	Tue, 7 Oct 2008 11:39:58 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	jens.axboe@...cle.com, schwidefsky@...ibm.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH/RFC 0/4] Add stop_machine_get/put_threads to stop_machine infrastructrue.

On Tuesday 07 October 2008 07:16:50 Heiko Carstens wrote:
> > > Patch 2 introduces the new proposed interface
> >
> > Could we just encapsulate the threads etc. into a "struct stopmachine"
> > which is returned from stop_machine_prepare(), then implement everything
> > in terms of that?
>
> You mean that we put the pointers to the threads, the cpu mask, etc. in
> this structure, instead of wasting bss size?
> That would be just a kmalloc call in __stop_machine_get_threads().
> Or do you think of something different?

That's exactly my idea.  We kmalloc already because NR_CPUS might be too big 
for the stack.  This version would just kmalloc a struct containing 
everything we need.

I prefer _prepare() / _run() / _destroy() as nomenclature BTW.  prepare comes 
from wait.h's prepare_to_wait; I don't like alloc() since it does more than 
allocate memory, yet _get_threads unnecessarily reveals too much about the 
implementation.

Then we have the simple case:

static inline int stop_machine(int (*fn)(void *), void *data,
			       const struct cpumask *cpus)
{
	struct stop_machine *sm = stop_machine_prepare();
	int err;

	if (!sm)
		return -ENOMEM;

	err = stop_machine_run(sm, fn, data, cpus);
	stop_machine_destroy(sm);
	return err;
}

I think you want to be able to call stop_machine_run() with the same "sm" 
multiple times, but that should be pretty easy to ensure.

Cheers!
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ