On 13-08-15 12:45 PM, Roland Dreier wrote:
Jens / James, do you guys plan to send this to Linus for 3.11?
Triggering this bug is a bit esoteric but the impact is pretty nasty
(corrupting an unrelated process).
The patch is fine with me. Even though the sg driver is
named in the patch title, I
Jens / James, do you guys plan to send this to Linus for 3.11?
Triggering this bug is a bit esoteric but the impact is pretty nasty
(corrupting an unrelated process).
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Jens / James, do you guys plan to send this to Linus for 3.11?
Triggering this bug is a bit esoteric but the impact is pretty nasty
(corrupting an unrelated process).
Thanks,
Roland
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 13-08-15 12:45 PM, Roland Dreier wrote:
Jens / James, do you guys plan to send this to Linus for 3.11?
Triggering this bug is a bit esoteric but the impact is pretty nasty
(corrupting an unrelated process).
The patch is fine with me. Even though the sg driver is
named in the patch title, I
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert 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
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert dgilb...@interlog.com 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
On 13-08-07 11:50 AM, Roland Dreier wrote:
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn 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
Roland Dreier wrote:
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn 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
On Wed, Aug 7, 2013 at 7:38 AM, David Milburn 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
Roland Dreier wrote:
From: Roland Dreier
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
Roland Dreier wrote:
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the
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
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
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
From: Roland Dreier
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process issues an SG_IO ioctl
From: Roland Dreier rol...@purestorage.com
There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances
leads to one process writing data into the address space of some other
random unrelated process if the ioctl is interrupted by a signal.
What happens is the following:
- A process
16 matches
Mail list logo
