Back in April there were discussions about the race in establish_pte with
the flush_tlb before the set_pte. Many options were discussed, but due in
part to a concern about S/390 having introduced the code, no patch ever
appeared. I talked with Martin Schwidefsky of the S/390 Linux development
team and he said that:
>the establish_pte was in fact introduced because of Linux/390. We wanted
to use the special S/390 instruction ipte (invalidate page >table entry).
In the meantime we found out that we need a lot more changes to be able to
use this instruction, so we disabled it again. >Until we have a proper
patch you should revoke the establish_pte change if you found it to be
faulty. I too think there is a race >condition.
So while there may be a more elegant solution down the road, I would like
to see the simple fix put back into 2.4. Here is the patch to essential
put the code back to the way it was before the S/390 merge. Patch is
against 2.4.0-test10pre6.
--- linux/mm/memory.c Fri Oct 27 15:26:14 2000
+++ linux-2.4.0-test10patch/mm/memory.c Fri Oct 27 15:45:54 2000
@@ -781,8 +781,8 @@
*/
static inline void establish_pte(struct vm_area_struct * vma, unsigned long address, pte_t *page_table, pte_t entry)
{
- flush_tlb_page(vma, address);
set_pte(page_table, entry);
+ flush_tlb_page(vma, address);
update_mmu_cache(vma, address, entry);
}
Linux Technology Center - IBM Corporation
11400 Burnet Road
Austin, TX 78758
(512) 838-9763 EMAIL: [email protected]
>
> So while there may be a more elegant solution down the road, I would like
> to see the simple fix put back into 2.4. Here is the patch to essential
> put the code back to the way it was before the S/390 merge. Patch is
> against 2.4.0-test10pre6.
>
> --- linux/mm/memory.c Fri Oct 27 15:26:14 2000
> +++ linux-2.4.0-test10patch/mm/memory.c Fri Oct 27 15:45:54 2000
> @@ -781,8 +781,8 @@
> */
> static inline void establish_pte(struct vm_area_struct * vma, unsigned long address, pte_t *page_table, pte_t entry)
> {
> - flush_tlb_page(vma, address);
> set_pte(page_table, entry);
> + flush_tlb_page(vma, address);
> update_mmu_cache(vma, address, entry);
> }
>
Great, lets do it. Definitely solves one race.
Kanoj
On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote:
> [..] no patch ever
> appeared. [..]
You didn't followed l-k closely enough as the strict fix was submitted two
times but it got not merged. (maybe because it had an #ifdef __s390__ that was
_necessary_ by that time?)
You can find the old and now useless patch here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test5/tlb-flush-smp-race-1
Andrea
Andrea Arcangeli wrote:
>
> On Mon, Oct 30, 2000 at 03:31:22PM -0600, Steve Pratt/Austin/IBM wrote:
> > [..] no patch ever
> > appeared. [..]
>
> You didn't followed l-k closely enough as the strict fix was submitted two
> times but it got not merged. (maybe because it had an #ifdef __s390__ that was
> _necessary_ by that time?)
>
> You can find the old and now useless patch here:
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test5/tlb-flush-smp-race-1
I stand corrected, I missed this is my searching. Hopefully this will
get in this time.
Steve
On Tue, Oct 31, 2000 at 10:23:12AM -0600, Steven Pratt wrote:
> I stand corrected, I missed this is my searching. [..]
Never mind, it's nearly impossible to track every single message to l-k.
It was only informational.
> [..] Hopefully this will
> get in this time.
I hope too indeed :).
Andrea