This new one should be better. Using the spinlock for the SMP serialization is
ok because that's an extremely slow path.
diff -urN -X /home/andrea/bin/dontdiff 2.4.2/arch/i386/mm/fault.c
2.4.2aa/arch/i386/mm/fault.c
--- 2.4.2/arch/i386/mm/fault.c Thu Feb 22 03:44:53 2001
+++ 2.4.2aa/arch/i386/m
On Fri, Feb 23, 2001 at 01:09:02PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 23 Feb 2001, Andrea Arcangeli wrote:
> >
> > I think that can't happen. Infact I think the whole section:
> >
> > pmd = pmd_offset(pgd, address);
> > pmd_k = pmd_offset(pgd_k, address);
> >
>
On Fri, 23 Feb 2001, Andrea Arcangeli wrote:
>
> I think that can't happen. Infact I think the whole section:
>
> pmd = pmd_offset(pgd, address);
> pmd_k = pmd_offset(pgd_k, address);
>
> if (pmd_present(*pmd) || !pmd_present(*pmd_k))
>
On Thu, Feb 22, 2001 at 10:29:58AM +, Alan Cox wrote:
> > >We can take page faults in interrupt handlers in 2.4 so I had to use a
> > >spinlock, but that sounds the same
> >
> > Umm? The above doesn't really make sense.
> >
> > We can take a page fault on the kernel region with the lazy pag
On Thu, Feb 22, 2001 at 10:22:56AM +, Alan Cox wrote:
> > > We can take page faults in interrupt handlers in 2.4 so I had to use a
> > > spinlock, but that sounds the same
> >
> > We can? Woah, please explain.
>
> vmalloc does a lazy load of the tlb. That can lead to the exception table
>
> >We can take page faults in interrupt handlers in 2.4 so I had to use a
> >spinlock, but that sounds the same
>
> Umm? The above doesn't really make sense.
>
> We can take a page fault on the kernel region with the lazy page
> directory filling, but that code will just set the PGD entry and e
> > We can take page faults in interrupt handlers in 2.4 so I had to use a
> > spinlock, but that sounds the same
>
> We can? Woah, please explain.
vmalloc does a lazy load of the tlb. That can lead to the exception table
being walked on an IRQ
-
To unsubscribe from this list: send the line
In message <[EMAIL PROTECTED]> you write:
> > This is a while back, but I thought the solution Philipp and I came up
> > with was to simply used a rw semaphore for this, which was taken (read
> > only) on page fault if we have to scan the exception table.
>
> We can take page faults in interrupt
In article <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]> wrote:
>> This is a while back, but I thought the solution Philipp and I came up
>> with was to simply used a rw semaphore for this, which was taken (read
>> only) on page fault if we have to scan the exception table.
>
>We can take pag
> This is a while back, but I thought the solution Philipp and I came up
> with was to simply used a rw semaphore for this, which was taken (read
> only) on page fault if we have to scan the exception table.
We can take page faults in interrupt handlers in 2.4 so I had to use a
spinlock, but tha
In message <[EMAIL PROTECTED]
.com> you write:
> > We unlink the module
> > We free the memory
> >
> > At the same time another cpu may be walking the exception table that we fre
e.
>
> True.
>
> Rusty had a patch that locked the module list properly IIRC.
This is a while back, but I thought t
On Tue, 20 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 16:04:07 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> Using wait_for_at_least_one_schedule_on_every_cpu() has no penalty
> except on the process running rmmod. It does not require yet more
> spinlocks and is architecture indep
On Mon, 19 Feb 2001 16:04:07 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>My spinlock based fix has almost no contention and doesnt require 64 processors
>grind to a halt on a big machine just to handle a module list change. Sorry
>I don't think it supports your argument
I am not proposing
On Mon, 19 Feb 2001 14:25:39 +0100,
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>You just reinvented the read-copy-update model
>(http://www.rdrop.com/users/paulmck/rclock/intro/rclock_intro.html)...
>
>The mail proposing that locking model for module unloading is not yet
>in the arvhices, sorry
> You can have exceptions while initializing. not
> MOD_RUNNING|MOD_INITIALIZING should work though.
True.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
P
On Mon, 19 Feb 2001, Alan Cox wrote:
> > So you fixed the nonexistent race only. The real race is that the module
>
> Umm I fixed the small race. You are right that there is a second race.
There's just one race. The small race is nonexistent since
put_mod_name always acts as a memory barrier.
> So you fixed the nonexistent race only. The real race is that the module
Umm I fixed the small race. You are right that there is a second race.
> uninitialized vmalloc'd (module_map'd) memory), then the module data
> (including the exception table) gets copied.
> The race window is from the f
On Mon, 19 Feb 2001, Alan Cox wrote:
> > so you hold a spinlock during copy_from_user ? Or did you change
> > sys_init_module/sys_create_modules semantics ?
>
> The only points I need to hold a spinlock are editing the chain and
> walking it in a case where I dont hold the kernel lock.
>
> So I
> so you hold a spinlock during copy_from_user ? Or did you change
> sys_init_module/sys_create_modules semantics ?
The only points I need to hold a spinlock are editing the chain and
walking it in a case where I dont hold the kernel lock.
So I spin_lock_irqsave the two ops updating the list li
On Mon, 19 Feb 2001, Alan Cox wrote:
> > Rusty had a patch that locked the module list properly IIRC.
>
> So does -ac now. I just take a spinlock for the modify cases that race
> against faults (including vmalloc faults from irq context)
so you hold a spinlock during copy_from_user ? Or did you
> >At the same time another cpu may be walking the exception table that we free.
>
> Another good reason why locking modules via use counts from external
> code is not the right fix. We definitely need a quiesce model for
> module removal.
My spinlock based fix has almost no contention and does
> Rusty had a patch that locked the module list properly IIRC.
So does -ac now. I just take a spinlock for the modify cases that race
against faults (including vmalloc faults from irq context)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Keith Owens wrote:
> wait_for_at_least_one_schedule_on_every_cpu();
what about
spin_unlock_wait(&global_exception_lock);
The actual exception table waker uses
spin_lock_irqsave(&global_exception_lock);
spin_unlock_irqsave(&global_exception_lock);
Or a simple spinlock
On Tue, 20 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 06:15:22 -0600 (CST),
> Philipp Rumpf <[EMAIL PROTECTED]> wrote:
> 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();
> wa
In article <[EMAIL PROTECTED]> you wrote:
> 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_reg
On Mon, 19 Feb 2001 06:15:22 -0600 (CST),
Philipp Rumpf <[EMAIL PROTECTED]> 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 ad
On Mon, 19 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 11:35:08 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >The problem isnt running module code. What happens in this case
> >
> >mod->next = module_list;
> >module_list = mod; /* link it in */
> >
> >Note no w
On Mon, 19 Feb 2001 11:35:08 + (GMT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>The problem isnt running module code. What happens in this case
>
>mod->next = module_list;
>module_list = mod; /* link it in */
>
>Note no write barrier.
It works on ix86 so the code must be righ
On Mon, 19 Feb 2001, Alan Cox wrote:
> mod->next = module_list;
put_mod_name() here.
> module_list = mod; /* link it in */
>
> Note no write barrier.
put_mod_name calls free_page which always implies a memory barrier. This
isn't beautiful but it won't blow up either.
Act
> The module list is modified atomically, so either we search the new table
> or we don't, but we never see intermediate states. Not searching the new
> table shouldn't be a problem as we shouldn't run module code until
> sys_init_module time.
The problem isnt running module code. What happens i
On Thu, 15 Feb 2001, Alan Cox wrote:
> Question of the day for the VM folks:
> If CPU1 is loading the exception tables for a module and
> CPU2 faults.. what happens 8)
"loading" == in sys_create_module ?
The module list is modified atomically, so either we search the new table
Ok this one should fix the non booting CPUs problem.
Question of the day for the VM folks:
If CPU1 is loading the exception tables for a module and
CPU2 faults.. what happens 8)
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
2.4.1-ac15
o F
32 matches
Mail list logo
