{"push_id":1042826989,"size":1,"distinct_size":1,"ref":"refs/heads/Hari_Bathini-504-1","head":"43c87c905722443b70f4e962205b29d35adf0bc4","before":"53db5ada35189915b0c16754c1e2b3bb2e072ce8","commits":[{"sha":"43c87c905722443b70f4e962205b29d35adf0bc4","author":{"email":"8c08e0cbfdd898a4d11cb688ad22c29e30def136@linux.vnet.ibm.com","name":"Hari Bathini"},"message":"ppc64/book3s: fix branching to out of line handlers in relocation kernel\n\nSome of the interrupt vectors on 64-bit POWER server processors  are\nonly 32 bytes long (8 instructions), which is not enough for the full\nfirst-level interrupt handler. For these we need to branch to an out-\nof-line (OOL) handler. But when we are running a relocatable kernel,\ninterrupt vectors till __end_interrupts marker are copied down to real\naddress 0x100. So, branching to labels (read OOL handlers) outside this\nsection should be handled differently (see LOAD_HANDLER()), considering\nrelocatable kernel, which would need atleast 4 instructions.\n\nHowever, branching from interrupt vector means that we corrupt the CFAR\n(come-from address register) on POWER7 and later processors as mentioned\nin commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions) that contains\nthe part up to the point where the CFAR is saved in the PACA should be\npart of the short interrupt vectors before we branch out to OOL handlers.\n\nBut as mentioned already, there are interrupt vectors on 64-bit POWER server\nprocessors that are only 32 bytes long (like vectors 0x4f00, 0x4f20, etc.),\nwhich cannot accomodate the above two cases at the same time owing to space\nconstraint. Currently, in these interrupt vectors, we simply branch out to\nOOL handlers, without using LOAD_HANDLER(), which leaves us vulnerable when\nrunning a relocatable kernel (eg. kdump case). While this has been the case\nfor sometime now and kdump is used widely, we were fortunate not to see any\nproblems so far, for three reasons:\n\n    1. In almost all cases, production kernel (relocatable) is used for\n       kdump as well, which would mean that crashed kernel's OOL handler\n       would be at the same place where we endup branching to, from short\n       interrupt vector of kdump kernel.\n    2. Also, OOL handler was unlikely the reason for crash in almost all\n       the kdump scenarios, which meant we had a sane OOL handler from\n       crashed kernel that we branched to.\n    3. On most 64-bit POWER server processors, page size is large enough\n       that marking interrupt vector code as executable (see commit\n       429d2e83) leads to marking OOL handler code from crashed kernel,\n       that sits right below interrupt vector code from kdump kernel, as\n       executable as well.\n\nLet us fix this undependable code path by moving the __end_interrupts marker\ndown past OOL handlers to make sure that we also copy OOL handlers to real\naddress 0x100 when running a relocatable kernel. This helps in cases discussed\nabove, where interrupt vectors are not long enough to branch out to OOL handlers\nwith LOAD_HANDLER(). While we are here, let us remove the virtually insignificant\n__end_handlers marker.\n\nThis fix has been tested successfully in kdump scenario, on a lpar with 4K page\nsize by using different default/production kernel and kdump kernel.\n\nSigned-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>\nSigned-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>","distinct":true,"url":"https://api.github.com/repos/ruscur/linux/commits/43c87c905722443b70f4e962205b29d35adf0bc4"}]}