On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > So what kind of signal was leading to your "stomping on the memory"? > Was it user generated or something like SIGIO, SIGPIPE or a RT signal? It was sometimes SIGHUP (for reopening log files) and sometimes SIGALARM (for various periodic things). > To get around the SG_IO ioctl restart problem (for non idempotent > SCSI commands) could we replace a -ERESTARTSYS return value > with -EINTR ? > > As I noted in a previous post, for robust user space code using the > SG_IO ioctl, masking signals during the IO may help. Yes, absolutely. But process A should be able to keep its memory uncorrupted even if process B is coded wrong :) > And what about bsg? Is it any better or worse than sg in the case > of interrupted SG_IO ioctls? Apart from the interface (sg_io_hdr > v3 versus v4) it should be a drop in replacement for sg. As far as I can tell bsg looks much better w.r.t. signals -- I don't see anywhere that it schedules work onto a workqueue or other kernel thread, and it looks like the SG_IO ioctl there actually has nowhere that checks for signals. All sleeps will be uninterruptible, which I guess may be better or worse depending on your perspective. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
