Link [ NetBSD | NetBSD OpenGrok source search | PR fulltext-search | Summary of daily snapshot builds | history of daily build result | pkgsrc commit viewer ]


   
        usage: [branch:branch] [user:user] [path@revision] keyword [... [-excludekeyword [...]]] (e.g. branch:MAIN sys/arch/arm, if_wm.c@1.234 )




switch to index mode

recent branches: MAIN (18m)  netbsd-10 (4d)  netbsd-9 (4d)  netbsd-8 (9d) 

2024-05-20 18:33:22 UTC Now

2017-03-25 17:19:32 UTC netbsd-6-1 commitmail json YAML

Pull up following revision(s) (requested by maxv in ticket #1446):
sys/arch/amd64/amd64/trap.c: revision 1.94
sys/arch/i386/i386/trap.c: revision 1.287
Mmh, allow iret to be handled when an #SS fault (T_STKFLT) happens. Even
if the sdm is far from being clear, it appears that iret can trigger an #SS
fault if %ss points to a writable but non-present segment; in which case
the kernel would panic, thinking the fault was internal to it.
In particular, userland can create a broken segment in the ldt with
USER_LDT, update its %ss with setcontext and trigger the panic. I don't
think amd64 is affected since USER_LDT does not exist there, and the
changes on tf_ss seem correct - but I'm still adding T_STKFLT for safety.

(snj)