Hi Randy,
commit 6a7252fd ([SCSI] lpfc: fix up Kconfig dependencies) added a
select of GENERIC_CSUM. This seems strange to me - it's an architecture
specific detail if the checksum routines are implemented in assembly or
if they pull in lib/checksum.c.
The networking code doesn't select GENERIC_
With RDAC mode, mode select is batched together for multiple LUNs and sent to
one of the path for failover.
Currently Modeselect is logged without details of LUNs batched together.
Modeselect command can be logged
with batched lun id information so that failover command can be tracked on per
LUN
From: Julia Lawall
Adjust code alignment so that each statement is lined up with its neighbor.
In the second case, it could be desirable to put the call to
lpfc_destroy_vport_work_array under the if. The call, is, however, safe
in case vports is NULL, so the patch just adjusts the indentation t
On 13-08-04 10:19 PM, vaughan wrote:
On 08/03/2013 01:25 PM, Douglas Gilbert wrote:
On 13-08-01 01:01 AM, Douglas Gilbert wrote:
On 13-07-22 01:03 PM, Jörn Engel wrote:
On Mon, 22 July 2013 12:40:29 +0800, Vaughan Cao wrote:
There is a race when open sg with O_EXCL flag. Also a race may
happ
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 w
On Mon, 2013-08-05 at 15:02 -0700, 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.
>
On Mon, Aug 5, 2013 at 4:31 PM, James Bottomley
wrote:
> I agree with the analysis. The fix is a bit draconian, though. A
> workqueue actually runs in a kernel thread and there's a simple test for
> that (!current->mm), so how about this instead (which is much less
> intrusive)
> ---
> diff --
On Mon, 2013-08-05 at 16:38 -0700, Roland Dreier wrote:
> On Mon, Aug 5, 2013 at 4:31 PM, James Bottomley
> wrote:
> > I agree with the analysis. The fix is a bit draconian, though. A
> > workqueue actually runs in a kernel thread and there's a simple test for
> > that (!current->mm), so how abo
Roland,
When this sg code was originally designed, there wasn't a bio
in sight :-)
Now I'm trying to get my head around this. We have launched
a "data-in" SCSI command like READ(10) and the DMA is underway
so we are waiting for a "done" indication. Instead we receive
a signal interruption. It is
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 w
> "Giuliano" == Giuliano Pochini writes:
Giuliano,
Giuliano> My Toshiba 1TB Stor.e basics does not work anymore since
Giuliano> 3.10.3. I have another USB3 disk which works fine.
Do the following two patches fix your problem?
http://marc.info/?l=linux-scsi&m=137523956310061&w=2
http://mar
2013/8/5 Roland Dreier :
> 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:
>
12 matches
Mail list logo
