crash in rb_insert_color()

>i_mutex) in vfs_readdir() enough to protect the tree? I guess yes. I have got no idea how it can happen. Has something been corrected since? Regards, Zoltan Menyhart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PR

crash in rb_insert_color()

yes. (I have not seen any modification in rb_insert_color() since my 2.6.18.8.) Is mutex_lock(inode-i_mutex) in vfs_readdir() enough to protect the tree? I guess yes. I have got no idea how it can happen. Has something been corrected since? Regards, Zoltan Menyhart -- To unsubscribe from

__down() fails to provide with acquisition semantics

lable... Another question: is there any reason keeping an ia64 version when lib/semaphore-sleepers.c and arch/ia64/kernel/semaphore.c do not really differ? Thanks, Zoltan Menyhart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [

__down() fails to provide with acquisition semantics

/kernel/semaphore.c do not really differ? Thanks, Zoltan Menyhart - 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: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

Luck, Tony wrote: This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get "lucky" on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? Ditto. The only reason

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

Jim Hull wrote: Not just crazy, but wrong - this *can* happen on pre-Montecito. Even though L1D is write-through and L2 was mixed I/D, the L1 I-cache could contain stale instrutions if there are missing flushes. I cannot agree with you. In order to consider an L1 I-cache entry as valid, a

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

Jim Hull wrote: Not just crazy, but wrong - this *can* happen on pre-Montecito. Even though L1D is write-through and L2 was mixed I/D, the L1 I-cache could contain stale instrutions if there are missing flushes. I cannot agree with you. In order to consider an L1 I-cache entry as valid, a

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

Luck, Tony wrote: This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get lucky on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? Ditto. The only reason

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

KAMEZAWA Hiroyuki wrote: Could we discuss this in other thread as "optimization for some cpus" and push bug-fix patches first ? If take5 or part of take6(patch 1,2) are not acceptable, I'll continue this work on -rc2. Thanks, -Kame Sure. Thanks, Zoltan - To unsubscribe from this list:

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

David Mosberger-Tang wrote: This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get "lucky" on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? --david

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

David Mosberger-Tang wrote: This seems crazy to me. Flushing should occur according to the *architecture*, not model-by-model. Even if we happen to get lucky on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you really want to debug this *again* come next CPU? --david O.K.

Re: [PATCH] flush icache before set_pte take6. [4/4] optimization for cpus other than montecito

KAMEZAWA Hiroyuki wrote: Could we discuss this in other thread as optimization for some cpus and push bug-fix patches first ? If take5 or part of take6(patch 1,2) are not acceptable, I'll continue this work on -rc2. Thanks, -Kame Sure. Thanks, Zoltan - To unsubscribe from this list: send

Re: [PATCH] flush icache before set_pte() take 5.

KAMEZAWA Hiroyuki wrote: Considerations: - I can add CONFIG_MONTECITO if necessary. But it will be confusing, I think. What about this trick below? identify_cpu() finds out the "c->family". If any of the CPUs has c->family==32 (and the future versions...) then set a global flag. And:

Re: [PATCH] flush icache before set_pte() take 5.

KAMEZAWA Hiroyuki wrote: Considerations: - I can add CONFIG_MONTECITO if necessary. But it will be confusing, I think. What about this trick below? identify_cpu() finds out the c-family. If any of the CPUs has c-family==32 (and the future versions...) then set a global flag. And: static

Re: [PATCH] flush cache fixes for ia64 [2/2] sync icache dcache

Do you really need a "sync_icache_dcache()" in "do_wp_page()"? I guess it is only needed when the EXEC bit of the PTE gets turned on. --- linux-2.6.23-rc1.test.orig/mm/migrate.c +++ linux-2.6.23-rc1.test/mm/migrate.c @@ -172,6 +172,7 @@ static void remove_migration_pte(struct pte =

Re: [PATCH] flush cache fixes for ia64 [2/2] sync icache dcache

Do you really need a sync_icache_dcache() in do_wp_page()? I guess it is only needed when the EXEC bit of the PTE gets turned on. --- linux-2.6.23-rc1.test.orig/mm/migrate.c +++ linux-2.6.23-rc1.test/mm/migrate.c @@ -172,6 +172,7 @@ static void remove_migration_pte(struct pte =

Re: [PATCH] flush icache before set_pte on ia64 take3

KAMEZAWA Hiroyuki wrote: Thank you for advise. Hmm..how about this ? == /* * synchronize icache and dcache if the hardware doesn't do it automatically * and the page is executable. */ static inline arch_sync_icache_dcache(pte_t pte, page) { } Why not? I just wanted to see if you

Race condition around flush_cache_page() ?

ar as I can understand, there is a contradiction: - either we keep the valid translation while flushing, and the other CPU can re-fetch the data - or we nuke the PTE first, and the flush wont work Can someone please explain me how it is assumed to work? Thanks, Zoltan Menyhart - To unsubscribe from this list: send

Re: [PATCH] flush icache before set_pte on ia64 take3

I do not think changing the semantics of flush_cache_page() is a good idea. Please have a look at Documentation/cachetlb.txt. This is for virtual address tagged caches. The doc. does not say much about flush_icache_page(). It is used in: install_page(): can release any previously existing

Re: [PATCH] flush icache before set_pte on ia64 take3

KAMEZAWA Hiroyuki wrote: Thank you for advise. Hmm..how about this ? == /* * synchronize icache and dcache if the hardware doesn't do it automatically * and the page is executable. */ static inline arch_sync_icache_dcache(pte_t pte, page) { } Why not? I just wanted to see if you

Re: [PATCH] flush icache before set_pte on ia64 take3

I do not think changing the semantics of flush_cache_page() is a good idea. Please have a look at Documentation/cachetlb.txt. This is for virtual address tagged caches. The doc. does not say much about flush_icache_page(). It is used in: install_page(): can release any previously existing

Race condition around flush_cache_page() ?

: - either we keep the valid translation while flushing, and the other CPU can re-fetch the data - or we nuke the PTE first, and the flush wont work Can someone please explain me how it is assumed to work? Thanks, Zoltan Menyhart - To unsubscribe from this list: send the line unsubscribe linux

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: Hmm...but the current code flushes the page. just do it in "lazy" way. much difference ? I agree the current code flushes the I-cache for all kinds of file systems (for PTEs with the exec bit on). The error is that it does it after the PTE is written. In addition, I

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: A bit new idea. How about this ? == - Set PG_arch_1 if "icache is *not* coherent" page-flags.h: * PG_arch_1 is an architecture specific page state bit. The generic code * guarantees that this bit is cleared for a page when it first is entered into * the page cache.

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: But is it too costly that flushing icache page only if a page is newly installed into the system (PG_arch1) && it is mapped as executable ? Well it was a bit long time ago, I measured on a Tiger box with CPUs of 1.3 GHz: Flushing a page of 64 Kbytes, with modified

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

Back to do_no_page(): if the new PTE includes the exec bit and PG_arch_1 is set, the page has to be flushed from the I-cache before the PTE is made globally visible. Sorry, I wanted to say: if the new PTE includes the exec bit and PG_arch_1 is NOT set Thanks, Zoltan - To unsubscribe from

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: Then, what should I do more for fixing this SIGILL problem ? -Kame I can think of a relatively cheap solution: New pages are allocated with the bit PG_arch_1 off, see page_cache_read() ... prep_new_page(), i.e. the I-cache is not coherent with the D-cache.

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: Then, what should I do more for fixing this SIGILL problem ? -Kame I can think of a relatively cheap solution: New pages are allocated with the bit PG_arch_1 off, see page_cache_read() ... prep_new_page(), i.e. the I-cache is not coherent with the D-cache.

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

Back to do_no_page(): if the new PTE includes the exec bit and PG_arch_1 is set, the page has to be flushed from the I-cache before the PTE is made globally visible. Sorry, I wanted to say: if the new PTE includes the exec bit and PG_arch_1 is NOT set Thanks, Zoltan - To unsubscribe from

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: But is it too costly that flushing icache page only if a page is newly installed into the system (PG_arch1) it is mapped as executable ? Well it was a bit long time ago, I measured on a Tiger box with CPUs of 1.3 GHz: Flushing a page of 64 Kbytes, with modified data

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: A bit new idea. How about this ? == - Set PG_arch_1 if icache is *not* coherent page-flags.h: * PG_arch_1 is an architecture specific page state bit. The generic code * guarantees that this bit is cleared for a page when it first is entered into * the page cache.

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

KAMEZAWA Hiroyuki wrote: Hmm...but the current code flushes the page. just do it in lazy way. much difference ? I agree the current code flushes the I-cache for all kinds of file systems (for PTEs with the exec bit on). The error is that it does it after the PTE is written. In addition, I

Re: [BUGFIX]{PATCH] flush icache on ia64 take2

d export a macro for the file systems... Thanks, Zoltan Menyhart - 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: [BUGFIX]{PATCH] flush icache on ia64 take2

for the file systems... Thanks, Zoltan Menyhart - 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: Fw: [PATCH] ia64: race flushing icache in do_no_page path

KAMEZAWA Hiroyuki wrote: On Wed, 04 Jul 2007 16:24:38 +0200 Zoltan Menyhart <[EMAIL PROTECTED]> wrote: Machines star up whit bit 5 = 0, reading instruction pages via NFS has to flush them from L2I. In our test, we confirmed that this can be fixed by flushing L2I just before SetPageUp

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

KAMEZAWA Hiroyuki wrote: On Wed, 04 Jul 2007 16:24:38 +0200 Zoltan Menyhart [EMAIL PROTECTED] wrote: Machines star up whit bit 5 = 0, reading instruction pages via NFS has to flush them from L2I. In our test, we confirmed that this can be fixed by flushing L2I just before SetPageUptodate

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

onsibility of a file system to make sure it supports instruction pages correctly. The base kernel should provide such file systems with an architecture dependent macro... Thanks, Zoltan Menyhart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a mes

Re: Fw: [PATCH] ia64: race flushing icache in do_no_page path

to make sure it supports instruction pages correctly. The base kernel should provide such file systems with an architecture dependent macro... Thanks, Zoltan Menyhart - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

copy_one_pte()

ioproc_update_page() says that every time when a PTE is created / modified... Thanks, Zoltan Menyhart - 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.h

copy_one_pte()

ioproc_update_page() says that every time when a PTE is created / modified... Thanks, Zoltan Menyhart - 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

Re: Mprotect needs arch hook for updated PTE settings

uot; instruction. (Who cares for a debugger ? It should know what it does ;-).) I think there is no need for any extra flushes. Thanks, Zoltan Menyhart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo i

Re: Mprotect needs arch hook for updated PTE settings

for a debugger ? It should know what it does ;-).) I think there is no need for any extra flushes. Thanks, Zoltan Menyhart - 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