Alpha compile problem solved by Andrea (pte_alloc)

Alpha compile problem solved by Andrea (pte_alloc)

[Magnus Naeslund(f)]

Hello yesterday i installed redhat6.2 on our little alpha server over here.
It's an Ruffian EV56 system, and a hand upgraded redhat to be able to cope
with 2.4.

I got an compile error that told me that pte_alloc was declared wrong in
some files..
Then in the back of my mind i figured that Andrea does a lot of alpha work,
so i grepped after pte_alloc in his patches.

I found:
ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/alpha
-numa-2

Now my kernel compiled, and it works great. (Thanks Andrea :))
Just a little gotcha if anyone gets this problem (now it's in the mail
archives, where i didnt find it).

Andrea:
Is that patch harmless, or is it experimental?
Is there any other patches you recommend me to apply to my kernel?


Regards

Magnus Naeslund

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Fri, Apr 27, 2001 at 05:34:01AM +0200, Magnus Naeslund(f) wrote:
> Hello yesterday i installed redhat6.2 on our little alpha server over here.
> It's an Ruffian EV56 system, and a hand upgraded redhat to be able to cope
> with 2.4.
> 
> I got an compile error that told me that pte_alloc was declared wrong in
> some files..
> Then in the back of my mind i figured that Andrea does a lot of alpha work,
> so i grepped after pte_alloc in his patches.
> 
> I found:
> ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.3/alpha
> -numa-2
> 
> Now my kernel compiled, and it works great. (Thanks Andrea :))
> Just a little gotcha if anyone gets this problem (now it's in the mail
> archives, where i didnt find it).
> 
> Andrea:
> Is that patch harmless, or is it experimental?

The patch is ready for production. I just submitted it two times to
Linus but no luck so far. However alternate patches are been merged in
Linus's tree recently and they fix the compile problems at least.

> Is there any other patches you recommend me to apply to my kernel?

specifically for the alpha (but of course ok for x86 kernels too) in
order against pre7:

	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-numa-6
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_numa-sched-5
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_alpha-tlb-page-sym-1
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_softirq-SMP-fixes-2
	ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre7aa1/00_rwsem-10

Andrea

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Magnus Naeslund(f)]

From: "Andrea Arcangeli" <andrea@suse.de>

[snip]

> > Is there any other patches you recommend me to apply to my kernel?
>
> specifically for the alpha (but of course ok for x86 kernels too) in
> order against pre7:
>
>
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre
7aa1/00_alpha-numa-6
>
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre
7aa1/00_numa-sched-5
>
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre
7aa1/00_alpha-tlb-page-sym-1
>
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre
7aa1/00_softirq-SMP-fixes-2
>
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.4pre
7aa1/00_rwsem-10
>
> Andrea
>

Thanks...
Will apply them..

Magnus

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Eric W. Biederman]

Do you know if anyone has fixed the lazy vmalloc code?  I know of
as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
have time to persue it, but before I forget to even put in a bug
report I thought I'd ask if you know anything about it?

Eric

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote:
> 
> Do you know if anyone has fixed the lazy vmalloc code?  I know of
> as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
> have time to persue it, but before I forget to even put in a bug
> report I thought I'd ask if you know anything about it?

On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
that as you don't need it). As long as you use only 1 entry of the pgd
for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
safe.

OTOH x86 is racy and there's no workaround available at the moment.

Andrea

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Eric W. Biederman]

Andrea Arcangeli <andrea@suse.de> writes:

> On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote:
> > 
> > Do you know if anyone has fixed the lazy vmalloc code?  I know of
> > as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
> > have time to persue it, but before I forget to even put in a bug
> > report I thought I'd ask if you know anything about it?
> 
> On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> that as you don't need it). As long as you use only 1 entry of the pgd
> for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> safe.

Hmm. I was having problems reproducible with
CONFIG_ALPHA_LARGE_VMALLOC n.

Enabling the large vmalloc was my work around, because the large
vmalloc whet back to the prelazy allocation code.

I was getting repeatable problems inside of an mtd driver.  The
problem I had was entries failed to propagate across different tasks.
I think it was something like the first pgd was lazily allocated and
not propagated.   

I don't have a SRM on my 264 alpha so alpha (for reference on which
code paths were followed.

> 
> OTOH x86 is racy and there's no workaround available at the moment.

GH

Well racy is easier to work with than just plain non-functional. 

Eric

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Sun, Apr 29, 2001 at 09:55:06PM -0600, Eric W. Biederman wrote:
> Hmm. I was having problems reproducible with
> CONFIG_ALPHA_LARGE_VMALLOC n.
> 
> Enabling the large vmalloc was my work around, because the large
> vmalloc whet back to the prelazy allocation code.

I don't have a clue about your problems but certainly the
CONFIG_ALPHA_LARGE_VMALLOC n is not racy while the
CONFIG_ALPHA_LARGE_VMALLOC y is racy.

> problem I had was entries failed to propagate across different tasks.

With CONFIG_ALPHA_LARGE_VMALLOC n the entry is propagated before
starting using the new pgd so it cannot race, there's no special page
fault case for that beacuse you will never get a page fault because of
an unmapped pgd entry in the vmalloc space in first place.

Andrea

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Alan Cox]

> On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> that as you don't need it). As long as you use only 1 entry of the pgd
> for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> safe.

Its racy for all cases on the Alpha because the exception table fixes are
not done.

> OTOH x86 is racy and there's no workaround available at the moment.

-ac fixes all known problems there 

Alan

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote:
> > On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> > that as you don't need it). As long as you use only 1 entry of the pgd
> > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> > safe.
> 
> Its racy for all cases on the Alpha because the exception table fixes are
> not done.

you're talking about the module races, I was only talking only about
vmalloc lazy pgd mapping, they're different things even if they are
both related to the page fault hanlder.

I don't use modules on the alpha so...

> > OTOH x86 is racy and there's no workaround available at the moment.
> 
> -ac fixes all known problems there 

I will check that shortly, thanks. (so far all the fixes I seen floating
around for such races were wrong)

Andrea

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Mon, Apr 30, 2001 at 07:07:47PM +0200, Andrea Arcangeli wrote:
> On Mon, Apr 30, 2001 at 05:56:41PM +0100, Alan Cox wrote:
> > > On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> > > that as you don't need it). As long as you use only 1 entry of the pgd
> > > for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> > > safe.
> > 
> > Its racy for all cases on the Alpha because the exception table fixes are
> > not done.
> 
> you're talking about the module races, I was only talking only about

here the fix for your module race (still untested though):

diff -urN 2.4.4/arch/alpha/mm/extable.c alpha-modrace/arch/alpha/mm/extable.c
--- 2.4.4/arch/alpha/mm/extable.c	Thu Nov 16 15:37:26 2000
+++ alpha-modrace/arch/alpha/mm/extable.c	Mon Apr 30 19:28:21 2001
@@ -45,20 +45,25 @@
 	/* There is only the kernel to search.  */
 	ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
 			       addr - gp);
-	if (ret) return ret;
 #else
+	unsigned long flags;
 	/* The kernel is the last "module" -- no need to treat it special. */
 	struct module *mp;
+
+	ret = 0;
+	spin_lock_irqsave(&modlist_lock, flags);
 	for (mp = module_list; mp ; mp = mp->next) {
-		if (!mp->ex_table_start)
+		if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
 			continue;
 		ret = search_one_table(mp->ex_table_start,
 				       mp->ex_table_end - 1, addr - mp->gp);
-		if (ret) return ret;
+		if (ret)
+			break;
 	}
+	spin_unlock_irqrestore(&modlist_lock, flags);
 #endif
 
-	return 0;
+	return ret;
 }
 
 unsigned

For the large-vmalloc races I'd take a very lazy approch:

--- alpha-modrace/arch/alpha/config.in.~1~	Sat Apr 28 05:24:29 2001
+++ alpha-modrace/arch/alpha/config.in	Mon Apr 30 19:31:24 2001
@@ -211,13 +211,15 @@
 
 # The machine must be able to support more than 8GB physical memory
 # before large vmalloc might even pretend to be an issue.
-if [ "$CONFIG_ALPHA_GENERIC" = "y" -o "$CONFIG_ALPHA_DP264" = "y" \
-	-o "$CONFIG_ALPHA_WILDFIRE" = "y" -o "$CONFIG_ALPHA_TITAN" = "y" ]
-then
-	bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
-else
-	define_bool CONFIG_ALPHA_LARGE_VMALLOC n
-fi
+#if [ "$CONFIG_ALPHA_GENERIC" = "y" -o "$CONFIG_ALPHA_DP264" = "y" \
+#	-o "$CONFIG_ALPHA_WILDFIRE" = "y" -o "$CONFIG_ALPHA_TITAN" = "y" ]
+#then
+#	bool 'Large VMALLOC support' CONFIG_ALPHA_LARGE_VMALLOC
+#else
+#	define_bool CONFIG_ALPHA_LARGE_VMALLOC n
+#fi
+# LARGE_VMALLOC is racy, if you *really* need it then fix it first
+define_bool CONFIG_ALPHA_LARGE_VMALLOC n
 
 source drivers/pci/Config.in
 

I mean: I certainly don't need it, not even on the 256G boxes, the non
LARGE_VMALLOC is simpler and _faster_ (it drops a branch from the page
fault handler fast path) and so I'd prefer to spend my time on other
things than fixing LARGE_VMALLOC races, but still the above will avoid
people to get bitten by such race until somebody fixes it.  If anybody
has a rasonable example for which I may need more than 8giga of kernel
vmalloc memory then I can change my mind of course.

Andrea

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Hubert Mantel]

Hi,

On Mon, Apr 30, Alan Cox wrote:

> > OTOH x86 is racy and there's no workaround available at the moment.
> 
> -ac fixes all known problems there 

Is there some place from where one can download all the patches in -ac 
kernels as separate patches, not just one monster patch (same way Andrea 
is doing)?

I assume you are maintaining them as separate patches anyway in order to 
be able to feed them to Linus.

> Alan
                                                                  -o)
    Hubert Mantel              Goodbye, dots...                   /\\
                                                                 _\_v

Re: Alpha compile problem solved by Andrea (pte_alloc)

[Alan Cox]

> I assume you are maintaining them as separate patches anyway in order to 
> be able to feed them to Linus.

Nope - the dependancies between them are too complex