On Wed, 31 Jul 2024 at 16:21, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Wed, Jul 31, 2024 at 03:32:52PM +0100, Peter Maydell wrote: > > This is why we have the RETRY_ON_EINTR() macro, right? > > > > Currently we have some places that call qemu_open_old() inside > > RETRY_ON_EINTR -- we should decide whether we want to > > handle EINTR inside the qemu_open family of functions, > > or make the caller deal with it, and put the macro uses > > in the right place consistently. > > It is incredibly arbitrary where we use RETRY_ON_EINTR, which I think > points towards it being a sub-optimal solution to the general problem.
Agreed (and agreed that SA_RESTART is the usual approach to avoid this mess). Partly I just vaguely recall discussions about this back when we added/improved the RETRY_ON_EINTR macro in the first place: maybe there's a reason we have it still... > > I agree that it would be nicer if we could use SA_RESTART, > > but presumably there's a reason why we don't. (At any > > rate code that's shared with the user-mode emulation > > has to be EINTR-resistant, because we can't force the > > user-mode guest code to avoid registering signal handlers > > that aren't SA_RESTART.) > > For user mode emulation isn't it valid to just propagage the > EINTR back up to the application, since EINTR is a valid errno > they have to be willing to handle unless the app has itself > use SA_RESTART. Yes, that's what we must do for cases where we are doing some syscall on behalf of the guest. But for cases where we're doing a syscall because of something QEMU itself needs to do, we may need to retry, because we might not be in a position to be able to back out of what we're doing (or we might not even be inside the "handle a guest syscall" codepath at all). -- PMM
