linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Philipp Rumpf <prumpf@mandrakesoft.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.1-ac15
Date: Tue, 20 Feb 2001 00:15:58 +1100	[thread overview]
Message-ID: <30512.982588558@ocs3.ocs-net> (raw)
In-Reply-To: Your message of "Mon, 19 Feb 2001 06:15:22 MDT." <Pine.LNX.3.96.1010219055750.16489G-100000@mandrakesoft.mandrakesoft.com>

On Mon, 19 Feb 2001 06:15:22 -0600 (CST), 
Philipp Rumpf <prumpf@mandrakesoft.com> wrote:
>Unless I'm mistaken, we need both use counts and SMP magic (though not
>necessarily as extreme as what the "freeze all other CPUs during module
>unload" patch did).
>
>I think something like this would work (in addition to use counts)
>
>int callin_func(void *p)
>{
>	int *cpu = p;
>
>	while (*cpu != smp_processor_id()) {
>		current->cpus_allowed = 1 << *cpu;
>		schedule();
>	}
>
>	return 0;
>}
>
>void callin_other_cpus(void)
>{
>	int cpus[smp_num_cpus];
>	int i;
>
>	for (i=0; i<smp_num_cpus; i++) {
>		cpus[i] = i;
>
>		kernel_thread(callin_func, &cpus[i], ...);
>	}
>}
>
>and call callin_other_cpus() before unloading a module.
>
>I'm not sure how you could make exception handling safe without locking
>all accesses to the module list - but that sounds like the sane thing to
>do anyway.

No need for a callin routine, you can get this for free as part of
normal scheduling.  The sequence goes :-

if (use_count == 0) {
  module_unregister();
  wait_for_at_least_one_schedule_on_every_cpu();
  if (use_count != 0) {
    module_register();	/* lost the unregister race */
  }
  else {
    /* nobody can enter the module now */
    module_release_resources();
    unlink_module_from_list();
    wait_for_at_least_one_schedule_on_every_cpu();
    free_module_storage();
  }
}

wait_for_at_least_one_schedule_on_every_cpu() prevents the next
operation until at least one schedule has been executed on every cpu.
Whether this is done as a call back or a separate kernel thread that
schedules itself on every cpu or the current process scheduling itself
on every cpu is an implementation detail.  All that matters is that any
other cpu that might have been accessing the module has gone through
schedule and therefore is no longer accessing the module's data or
code.

The beauty of this approach is that the rest of the cpus can do normal
work.  No need to bring everything to a dead stop.


  reply	other threads:[~2001-02-19 13:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-15 23:15 Linux 2.4.1-ac15 Alan Cox
2001-02-19  9:47 ` Philipp Rumpf
2001-02-19 11:35   ` Alan Cox
2001-02-19 11:54     ` Philipp Rumpf
2001-02-19 16:03       ` Alan Cox
2001-02-19 16:21         ` Philipp Rumpf
2001-02-19 16:27           ` Alan Cox
2001-02-19 16:34             ` Philipp Rumpf
2001-02-19 16:41               ` Alan Cox
2001-02-19 16:48                 ` Philipp Rumpf
2001-02-19 17:03                   ` Alan Cox
2001-02-21  3:02       ` Rusty Russell
2001-02-21 12:01         ` Alan Cox
2001-02-22  2:05           ` Rusty Russell
2001-02-22 10:22             ` Alan Cox
2001-02-23  0:01               ` Philipp Rumpf
2001-02-22  2:27           ` Linus Torvalds
2001-02-22 10:29             ` Alan Cox
2001-02-23 20:40               ` Andrea Arcangeli
2001-02-23 21:09                 ` Linus Torvalds
2001-02-24  4:04                   ` Andrea Arcangeli
2001-02-24  4:54                     ` Andrea Arcangeli
2001-02-19 11:54     ` Keith Owens
2001-02-19 12:15       ` Philipp Rumpf
2001-02-19 13:15         ` Keith Owens [this message]
2001-02-19 13:25           ` Christoph Hellwig
2001-02-19 21:32             ` Keith Owens
2001-02-19 13:36           ` Philipp Rumpf
2001-02-19 15:23           ` Manfred Spraul
2001-02-19 16:04       ` Alan Cox
2001-02-19 21:52         ` Keith Owens
2001-02-20 12:29           ` Philipp Rumpf

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=30512.982588558@ocs3.ocs-net \
    --to=kaos@ocs.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prumpf@mandrakesoft.com \
    /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;
as well as URLs for NNTP newsgroup(s).