Have a look at section 9.8.8 of the 80386 programmer's reference manual - it will tell you which exceptions can cause a double fault and which can't.

I already have that implemented, with the faults after the task switch(loaded incoming TSS) continuing to compare. So the fault before the task was switched is taken as the first(left column), while any faults after the incoming TSS is loaded into the registers(loading descriptors and TSS checks) being taken as the second column. Only starting to fetch a new instruction (first opcode byte) clears the fault level(level 0 being no fault, level 1 being normal faults and those valid combinations in that table, level 2 being double fault(when raised only) and level 2+(actually still level 2, when looking at the code, basically any fault during level 2 becomes shutdown) being triggered on any fault raised before the double fault handler starts fetching the first instruction opcode).

Level 2 makes the CPU abort the current fault handling and instruction execution. Level 1 just makes it abort the execution of the instruction. Level 0 proceeds the current execution path.

So, basically, what you're saying is that even when task switching to a fault handler, it doesn't affect the double fault logic in anyway(compared to plain trap fault or other interrupt types)?