From: Roland Dreier <roland@kernel.org>
To: David Milburn <dmilburn@redhat.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
"Doug Gilbert" <dgilbert@interlog.com>,
"James Bottomley" <JBottomley@parallels.com>,
"Costa Sapuntzakis" <costa@purestorage.com>,
"Jörn Engel" <joern@purestorage.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
"David Jeffery" <djeffery@redhat.com>
Subject: Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
Date: Wed, 7 Aug 2013 08:50:13 -0700 [thread overview]
Message-ID: <CAL1RGDW_nPZPBH=X-fOM4sddhVNkojEp4gUQseSJJaJAxfNqqQ@mail.gmail.com> (raw)
In-Reply-To: <52025BE3.5020002@redhat.com>
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn <dmilburn@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 :)
- R.
next prev parent reply other threads:[~2013-08-07 15:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 22:02 [PATCH] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal Roland Dreier
2013-08-05 23:31 ` James Bottomley
2013-08-05 23:38 ` Roland Dreier
2013-08-05 23:43 ` James Bottomley
2013-08-06 0:55 ` [PATCH v2] " Roland Dreier
2013-08-07 14:38 ` David Milburn
2013-08-07 15:50 ` Roland Dreier [this message]
2013-08-07 16:17 ` David Milburn
2013-08-07 16:31 ` Douglas Gilbert
2013-08-08 18:27 ` Roland Dreier
2013-08-15 16:45 ` Roland Dreier
2013-08-15 17:01 ` Douglas Gilbert
2013-08-06 0:19 ` [PATCH] " Douglas Gilbert
2013-08-06 3:54 ` Peter Chang
2013-08-06 14:56 ` Douglas Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL1RGDW_nPZPBH=X-fOM4sddhVNkojEp4gUQseSJJaJAxfNqqQ@mail.gmail.com' \
--to=roland@kernel.org \
--cc=JBottomley@parallels.com \
--cc=axboe@kernel.dk \
--cc=costa@purestorage.com \
--cc=dgilbert@interlog.com \
--cc=djeffery@redhat.com \
--cc=dmilburn@redhat.com \
--cc=joern@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.