Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why isn't memset() async-signal-safe?

boston.conman.org

Post reply on HN
Print view View original

11–20 of 98 posts

Re: Why isn't memset() async-signal-safe?

#11

Post by geocar »

wfunction wrote: post #4

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

When the number of state variables gets bigger, that buffer needs to get bigger. Need some cooperation from the operating system to increase the size of the buffers, that's all.

Re: Why isn't memset() async-signal-safe?

#12

Post by wfunction »

JoshTriplett wrote: post #9
wfunction wrote: post #4

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

They do, now. On current Intel CPUs, you can use xsave and xrstor to save and load the complete state, including all new state information. Ring 0 code can ask the CPU for the size of that state (via CPUID leaf 0xd), and allocate the appropriate amount of space per task.

Oh wow. When did this change? I vaguely seem to remember that as recently as Windows 7 (or was it 8.0?) there was trouble with AVX2 or something, but I can't find the info anywhere at the moment.

Re: Why isn't memset() async-signal-safe?

#14

Post by wfunction »

geocar wrote: post #11
wfunction wrote: post #4

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

When the number of state variables gets bigger, that buffer needs to get bigger. Need some cooperation from the operating system to increase the size of the buffers, that's all.

That doesn't mean the CPU can't report the size necessary using another instruction though. There's no need for the OS code to change.

Re: Why isn't memset() async-signal-safe?

#16

Post by colanderman »

wfunction wrote: post #4

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

After some careful reading of the linked bug report, apparently saving the direction flag wasn't the issue. Rather, clearing it upon entering a signal handler was the issue.

Re: Why isn't memset() async-signal-safe?

#17

Post by quotemstr »

nine_k wrote: post #8

Related: Unix signals are deemed "unfixable" by some: https://lwn.net/Articles/414618/

That's an extreme perspective. I've made extensive use of signals in programs that have shipped to hundreds of millions of users. If you're careful, they work fine. Yes, POSIX needs something like NT's vectored exception handlers that could allow multiple users of the same signal to cooperate: but that's an API problem, not something inherently "unfixable" about a program being interrupted and temporarily doing something else for a bit.

Re: Why isn't memset() async-signal-safe?

#18

Post by spc476 »

wfunction wrote: post #4

Something that's always baffled me: why don't CPUs have a "save ALL state" and "restore ALL state" instructions? Why does every new set of CPU registers seem to require an OS update to save them on context switches?

The more state you save, the larger the latency in handling the interrupt. And the amount of state in modern CPUs can be quite large indeed.

Re: Why isn't memset() async-signal-safe?

#19

Post by JoshTriplett »

wfunction wrote: post #12
JoshTriplett wrote: post #9

Earlier quoted context omitted.

They do, now. On current Intel CPUs, you can use xsave and xrstor to save and load the complete state, including all new state information. Ring 0 code can ask the CPU for the size of that state (via CPUID leaf 0xd), and allocate the appropriate amount of space per task.

Oh wow. When did this change? I vaguely seem to remember that as recently as Windows 7 (or was it 8.0?) there was trouble with AVX2 or something, but I can't find the info anywhere at the moment.

An OS can still use xsave incorrectly, such as by hardcoding the expected size rather than detecting it at runtime, or by getting some aspect of the CPUID leaf 0xd enumeration wrong. I wouldn't find it surprising if an initial implementation got one of the details wrong, resulting in a bug that wouldn't manifest until the next time the xsave layout changed.
Post reply on HN