f4e841da30
There are several tricky races involved with growing the TSB. So just use base-size TSBs for user contexts and we can revisit enabling this later. One part of the SMP problems is that tsb_context_switch() can see partially updated TSB configuration state if tsb_grow() is running in parallel. That's easily solved with a seqlock taken as a writer by tsb_grow() and taken as a reader to capture all the TSB config state in tsb_context_switch(). Then there is flush_tsb_user() running in parallel with a tsb_grow(). In theory we could take the seqlock as a reader there too, and just resample the TSB pointer and reflush but that looks really ugly. Lastly, I believe there is a case with threads that results in a TSB entry lock bit being set spuriously which will cause the next access to that TSB entry to wedge the cpu (since the TSB entry lock bit will never clear). It's either copy_tsb() or some bug elsewhere in the TSB assembly. Signed-off-by: David S. Miller <davem@davemloft.net> |
||
|---|---|---|
| .. | ||
| alpha | ||
| arm | ||
| arm26 | ||
| cris | ||
| frv | ||
| h8300 | ||
| i386 | ||
| ia64 | ||
| m32r | ||
| m68k | ||
| m68knommu | ||
| mips | ||
| parisc | ||
| powerpc | ||
| ppc | ||
| s390 | ||
| sh | ||
| sh64 | ||
| sparc | ||
| sparc64 | ||
| um | ||
| v850 | ||
| x86_64 | ||
| xtensa | ||