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
31 matches
Mail list logo
