On 13-08-07 11:50 AM, Roland Dreier wrote:
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn <dmilb...@redhat.com> wrote:
I was able to succesfully test this patch overnight, I had been experimenting
with the
sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a
orphan process
which prevented the corruption, but your solution seems much better.
Very cool, thanks for the testing.
I actually looked at using BIO_NULL_MAPPED as well, but it seemed a
bit too fragile to me -- it had the right effect of skipping
__bio_copy_iov(), and skipping the __free_pages() stuff in there is OK
because sg owns its pages rather than the bio layer, but all that
seemed vulnerable to being broken by an unrelated change.
Out of curiousity, were you already working on this bug? Because if
you had fixed it a few weeks earlier we might not have spent so long
wondering WTF was stomping on the memory of one of our processes :)
Roland,
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?
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.
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.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
