)]}'
{
  "commit": "3b5750644b2ffa2a76fdfe7b4e00e4af2ecf3539",
  "tree": "491ea9a2d4c091abadc1d39f694fe13e70390d63",
  "parents": [
    "d9f2f3f537acb8aa04280509b2eed50c855fd3ef"
  ],
  "author": {
    "name": "Paul Mackerras",
    "email": "paulus@samba.org",
    "time": "Fri May 02 14:29:12 2008 +1000"
  },
  "committer": {
    "name": "Paul Mackerras",
    "email": "paulus@samba.org",
    "time": "Fri May 02 15:00:45 2008 +1000"
  },
  "message": "[POWERPC] Bolt in SLB entry for kernel stack on secondary cpus\n\nThis fixes a regression reported by Kamalesh Bulabel where a POWER4\nmachine would crash because of an SLB miss at a point where the SLB\nmiss exception was unrecoverable.  This regression is tracked at:\n\nhttp://bugzilla.kernel.org/show_bug.cgi?id\u003d10082\n\nSLB misses at such points shouldn\u0027t happen because the kernel stack is\nthe only memory accessed other than things in the first segment of the\nlinear mapping (which is mapped at all times by entry 0 of the SLB).\nThe context switch code ensures that SLB entry 2 covers the kernel\nstack, if it is not already covered by entry 0.  None of entries 0\nto 2 are ever replaced by the SLB miss handler.\n\nWhere this went wrong is that the context switch code assumes it\ndoesn\u0027t have to write to SLB entry 2 if the new kernel stack is in the\nsame segment as the old kernel stack, since entry 2 should already be\ncorrect.  However, when we start up a secondary cpu, it calls\nslb_initialize, which doesn\u0027t set up entry 2.  This is correct for\nthe boot cpu, where we will be using a stack in the kernel BSS at this\npoint (i.e. init_thread_union), but not necessarily for secondary\ncpus, whose initial stack can be allocated anywhere.  This doesn\u0027t\ncause any immediate problem since the SLB miss handler will just\ncreate an SLB entry somewhere else to cover the initial stack.\n\nIn fact it\u0027s possible for the cpu to go quite a long time without SLB\nentry 2 being valid.  Eventually, though, the entry created by the SLB\nmiss handler will get overwritten by some other entry, and if the next\naccess to the stack is at an unrecoverable point, we get the crash.\n\nThis fixes the problem by making slb_initialize create a suitable\nentry for the kernel stack, if we are on a secondary cpu and the stack\nisn\u0027t covered by SLB entry 0.  This requires initializing the\nget_paca()-\u003ekstack field earlier, so I do that in smp_create_idle\nwhere the current field is initialized.  This also abstracts a bit of\nthe computation that mk_esid_data in slb.c does so that it can be used\nin slb_initialize.\n\nSigned-off-by: Paul Mackerras \u003cpaulus@samba.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "be35ffae10f0726b5e2ac3746b80f464f976222c",
      "old_mode": 33188,
      "old_path": "arch/powerpc/kernel/smp.c",
      "new_id": "1457aa0a08f136355347adcbe122a3d2c1692ba2",
      "new_mode": 33188,
      "new_path": "arch/powerpc/kernel/smp.c"
    },
    {
      "type": "modify",
      "old_id": "497ec059bc82b741665835a1280dcd1203eb20f9",
      "old_mode": 33188,
      "old_path": "arch/powerpc/mm/slb.c",
      "new_id": "cf8705e32d607b9692d0213f543ac84e092afe7b",
      "new_mode": 33188,
      "new_path": "arch/powerpc/mm/slb.c"
    }
  ]
}