Re: Alpha compile problem solved by Andrea (pte_alloc)
> 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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
> 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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
Andrea Arcangeli <[EMAIL PROTECTED]> 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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
From: "Andrea Arcangeli" <[EMAIL PROTECTED]> [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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Re: Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/
Alpha compile problem solved by Andrea (pte_alloc)
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 - 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 Please read the FAQ at http://www.tux.org/lkml/