- 12 Feb, 2011 12 commits
-
-
Venkata Siva Vijayendra Bhamidipati authored
Fix memory leak arising due to incorrect freeing of allocated memory for vnic stats when unregistering a vnic. Signed-off-by:
Abhijeet Joglekar <abjoglek@cisco.com> Signed-off-by:
Venkata Siva Vijayendra Bhamidipati <vbhamidi@cisco.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de>
-
Dan Carpenter authored
If we goto out, then it tries to call kfree_skb() on an ERR_PTR which will oops. Just return directly. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Hillf Danton authored
This patch makes it so that we only have one call to fc_rport_error. This patch does not completely consolidate return statements, there is still one return used when not calling fc_rport_error, but alternative solutions made the code more confusing. [ Patch modified by Robert Love ] [ Patch title and commit message edited by Robert Love to make it more relevant ] Signed-off-by:
Hillf Danton <dhillf@gmail.com> Signed-off-by:
-
Hillf Danton authored
Here ticks_left is added to record the result of wait_for_completion_timeout(). [ Patch title and description edited by Robert Love to make it more descriptive ] Signed-off-by:
-
Yi Zou authored
The fsp's xfer_ddp is used as indication of the exchange id for the DDPed I/O. We should always initialize it as FC_XID_UNKNOWN for a newly allocated fsp, otherwise the fsp allocated in fc_fcp, i.e., not from queuecommand like LUN RESET that is not doing DDP may still think DDP is setup for it since xid 0 is valid and goes on to call fc_fcp_ddp_done() in fc_fcp_resp() from fc_tm_done(). So, set xfer_ddp as FC_XID_UNKNOWN in fc_fcp_pkt_alloc() now. Also removes the setting of fsp->lp as it's already done when fsp is allocated. Signed-off-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
-
Hannes Reinecke authored
Classify severity of I/O errors for target, nexus, and transport errors. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Acked-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Hannes Reinecke authored
DM now has more information about the nature of the underlying storage failure. Path failure is avoided if a request failed due to a target error. Instead the target error is immediately passed up the stack. Discard requests that fail due to non-target errors may now be retried. Errors restricted to the path will be retried or returned if no paths are available, irregarding the no_path_retry setting. Signed-off-by:
Alasdair G Kergon <agk@redhat.com> Signed-off-by:
-
Hannes Reinecke authored
Instead of just passing 'EIO' for any I/O error we should be notifying the upper layers with more details about the cause of this error. Update the possible I/O errors to: - ENOLINK: Link failure between host and target - EIO: Retryable I/O error - EREMOTEIO: Non-retryable I/O error - EBADE: I/O error restricted to the I_T_L nexus 'Retryable' in this context means that an I/O error _might_ be restricted to the I_T_L nexus (vulgo: path), so retrying on another nexus / path might succeed. 'Non-retryable' in general refers to a target failure, so this error will always be generated regardless of the I_T_L nexus it was send on. I/O errors restricted to the I_T_L nexus might be retried on another nexus / path, but they should _not_ be queued if no paths are available. Signed-off-by:
-
Mike Snitzer authored
The use of blk_execute_rq_nowait() implies __blk_put_request() is needed in start_stop_endio() rather than blk_put_request() -- blk_finish_request() is called with queue lock already held. Signed-off-by:
-
Bjørn Mork authored
The ioc->sgl[i].iov_len value is supplied by the ioctl caller, and can be zero in some cases. Assume that's valid and continue without error. Fixes (multiple individual reports of the same problem for quite a while): http://marc.info/?l=linux-ide&m=128941801715301 http://bugs.debian.org/604627 http://www.mail-archive.com/linux-poweredge@dell.com/msg02575.html megasas: Failed to alloc kernel SGL buffer for IOCTL and [ 69.162538] ------------[ cut here ]------------ [ 69.162806] kernel BUG at /build/buildd/linux-2.6.32/lib/swiotlb.c:368! [ 69.163134] invalid opcode: 0000 [#1] SMP [ 69.163570] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map [ 69.163975] CPU 0 [ 69.164227] Modules linked in: fbcon tileblit font bitblit softcursor vga16fb vgastate ioatdma radeon ttm drm_kms_helper shpchp drm i2c_algo_bit lp parport floppy pata_jmicron megaraid_sas igb dca [ 69.167419] Pid: 1206, comm: smartctl Tainted: G W 2.6.32-25-server #45-Ubuntu X8DTN [ 69.167843] RIP: 0010:[<ffffffff812c4dc5>] [<ffffffff812c4dc5>] map_single+0x255/0x260 [ 69.168370] RSP: 0018:ffff88081c0ebc58 EFLAGS: 00010246 [ 69.168655] RAX: 000000000003bffc RBX: 00000000ffffffff RCX: 0000000000000002 [ 69.169000] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88001dffe000 [ 69.169346] RBP: ffff88081c0ebcb8 R08: 0000000000000000 R09: ffff880000030840 [ 69.169691] R10: 0000000000100000 R11: 0000000000000000 R12: 0000000000000000 [ 69.170036] R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000200000 [ 69.170382] FS: 00007fb8de189720(0000) GS:ffff88001de00000(0000) knlGS:0000000000000000 [ 69.170794] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 69.171094] CR2: 00007fb8dd59237c CR3: 000000081a790000 CR4: 00000000000006f0 [ 69.171439] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 69.171784] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 69.172130] Process smartctl (pid: 1206, threadinfo ffff88081c0ea000, task ffff88081a760000) [ 69.194513] Stack: [ 69.205788] 0000000000000034 00000002817e3390 0000000000000000 ffff88081c0ebe00 [ 69.217739] <0> 0000000000000000 000000000003bffc 0000000000000000 0000000000000000 [ 69.241250] <0> 0000000000000000 00000000ffffffff ffff88081c5b4080 ffff88081c0ebe00 [ 69.277310] Call Trace: [ 69.289278] [<ffffffff812c52ac>] swiotlb_alloc_coherent+0xec/0x130 [ 69.301118] [<ffffffff81038b31>] x86_swiotlb_alloc_coherent+0x61/0x70 [ 69.313045] [<ffffffffa002d0ce>] megasas_mgmt_fw_ioctl+0x1ae/0x690 [megaraid_sas] [ 69.336399] [<ffffffffa002d748>] megasas_mgmt_ioctl_fw+0x198/0x240 [megaraid_sas] [ 69.359346] [<ffffffffa002f695>] megasas_mgmt_ioctl+0x35/0x50 [megaraid_sas] [ 69.370902] [<ffffffff81153b12>] vfs_ioctl+0x22/0xa0 [ 69.382322] [<ffffffff8115da2a>] ? alloc_fd+0x10a/0x150 [ 69.393622] [<ffffffff81153cb1>] do_vfs_ioctl+0x81/0x410 [ 69.404696] [<ffffffff8155cc13>] ? do_page_fault+0x153/0x3b0 [ 69.415761] [<ffffffff811540c1>] sys_ioctl+0x81/0xa0 [ 69.426640] [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b [ 69.437491] Code: fe ff ff 48 8b 3d 74 38 76 00 41 bf 00 00 20 00 e8 51 f5 d7 ff 83 e0 ff 48 05 ff 07 00 00 48 c1 e8 0b 48 89 45 c8 e9 13 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 55 48 89 e5 48 83 ec 20 4c 89 [ 69.478216] RIP [<ffffffff812c4dc5>] map_single+0x255/0x260 [ 69.489668] RSP <ffff88081c0ebc58> [ 69.500975] ---[ end trace 6a2181b634e2abc7 ]--- Reported-by:
Bokhan Artem <aptem@ngs.ru> Reported by: Marc-Christian Petersen <m.c.p@gmx.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: "Benz, Michael" <Michael.Benz@lsi.com> Signed-off-by:
-
Tejun Heo authored
pm8001 manages its own list of pending works and cancel them on device free. It is unnecessarily complex and has a race condition - the works are canceled but not synced, so the work could still be running during and after the data structures are freed. This patch simplifies workqueue usage. * A driver specific workqueue pm8001_wq is created to serve these work items. * To avoid confusion, the "queue" suffixes are dropped from work items and functions. * Delayed queueing was never used. pm8001_work now uses work_struct instead. * The driver no longer keeps track of pending works. All pm8001_works are queued to pm8001_wq and the workqueue is flushed as necessary. flush_scheduled_work() usage is removed during conversion. Signed-off-by:
Tejun Heo <tj@kernel.org> Acked-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
-
Tejun Heo authored
Simple conversions to drop flush_scheduled_work() usages in drivers/scsi. More involved ones will be done in separate patches. * NCR5380, megaraid_sas: cancel_delayed_work() + flush_scheduled_work() -> cancel_delayed_work_sync(). * mpt2sas_scsih: drop unnecessary flush_scheduled_work(). * arcmsr_hba, ipr, pmcraid: flush the used work explicitly instead of using flush_scheduled_work(). Signed-off-by:
-
- 24 Jan, 2011 28 commits
-
-
Douglas Gilbert authored
As discussed in a thread on this list titled: "RFC: short reads on block devices" this patch adds recommendations for LLDs to set resid when there might be uncertainty about how much data has been returned by a device. This patch inline and attached] is against scsi-misc-2.6.git Signed-off-by:Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Boaz Harrosh authored
Since sg-read is a bidi operation, it is a gain to convert a single sg entry into a regular read. Better do this in the generic layer then force each caller to do so. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
James Bottomley authored
Originally, libata required the illusion that it could access the sata control register. Now, however, it can run perfectly well without them, so remove the dummy routines from libsas which tried to emulate them (but only ended up causing confusion). Signed-off-by: -
James Bottomley authored
Instead of using a config option for debugging, just dump the messages with KERN_DEBUG. Signed-off-by: -
James Bottomley authored
ATAPI check condition needs to be treated the same as a success or protocol return. The register returns from the PACKET command are all correctly positioned in the device to host register FIS and so we should collect them properly. Right at the moment this doesn't matter because libata sends a request sense always for ATAPI errors, but if it ever checked the registers, we should have the correct contents just in case. Signed-off-by: -
Peter Jones authored
Previously we were using strncmp in order to avoid having to include whitespace in the devlist, but this means "HSV1000" matches a device list entry that says "HSV100", which is wrong. This patch changes scsi_dh.c to use scsi_devinfo's matching functions instead, since they handle these cases correctly. Signed-off-by: -
Peter Jones authored
For scsi_dh.c to use devinfo lists, we have to be able to remove entries before rmmod. Signed-off-by: -
kxie@chelsio.com authored
fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface. Signed-off-by:
Karen Xie <kxie@chelsio.com> Reviewed-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Christof Schmitt authored
Steffen will take over the zfcp maintainer work. Update the MAINTAINERS entry accordingly. Acked-by:
Steffen Maier <maier@linux.vnet.ibm.com> Acked-by:
Swen Schillig <swen@vnet.ibm.com> Signed-off-by:
Christof Schmitt <christof.schmitt@de.ibm.com> Signed-off-by:
-
Jesper Juhl authored
A 'kfree(karg)' is missing in a failure path in mptctl.c::mptctl_getiocinfo() which can cause a memory leak. Signed-off-by:
Jesper Juhl <jj@chaosbits.net> Acked-by:
"Desai, Kashyap" <Kashyap.Desai@lsi.com> Signed-off-by:
-
Eddie Wai authored
The nopout's reserved field was not being initialized to zero before being reused. Stale CDB values from previous SCSI cmds of the same BHS offset was the cause of the disconnection initiated by the Lefthand target. Signed-off-by:
Eddie Wai <eddie.wai@broadcom.com> Reviewed-by:
-
kxie@chelsio.com authored
Remove gl_skb from cxgbi_ddp_info as it is only used by cxgb3i. Signed-off-by:
-
kxie@chelsio.com authored
There is no need to set ulpmode on the tx skbs if no digest is enabled. Signed-off-by:
-
Vasiliy Kulikov authored
memset arg64 to zero in the passthrough ioctls to avoid leaking contents of kernel stack memory to userland via uninitialized padding fields inserted by the compiler for alignment reasons. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Thanks to Scott Teel for noticing this. Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Stephen M. Cameron authored
Need to take the lock while accessing the register to check to see if config table changes have taken effect. Signed-off-by:
-
Stephen M. Cameron authored
This is to prevent hpsa from resetting older boards which the cciss driver may be controlling. Signed-off-by:
-
Stephen M. Cameron authored
This is to conserve memory in a memory-limited kdump scenario Signed-off-by:
-
Stephen M. Cameron authored
and use the doorbell reset method if available (which doesn't lock up the controller if you properly save and restore all the PCI registers that you're supposed to.) Signed-off-by:
-
Stephen M. Cameron authored
After a reset, we should first wait for the board to become "not ready", and then wait for it to become "ready", instead of immediately waiting for it to become "ready", and do this waiting *after* restoring PCI config space registers. Also, only wait 10 secs for board to become "not ready" after a reset (it should quickly become not ready.) Signed-off-by:
-
Stephen M. Cameron authored
They are defined in hpsa_cmd.h Signed-off-by:
-
Stephen M. Cameron authored
Some low bits might have been set by the driver, causing a message like this to come out: [ 13.288062] ------------[ cut here ]------------ [ 13.293211] WARNING: at lib/dma-debug.c:803 check_unmap+0x1a1/0x654() [ 13.300387] Hardware name: ProLiant DL180 G6 [ 13.305335] hpsa 0000:06:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x000000007f81e001] [size=640 bytes] Signed-off-by:
-
Stephen M. Cameron authored
Signed-off-by:
-
Mike Snitzer authored
Currently NetApp's VID/PID details in the INQUIRY response shows up as 'NETAPP' and 'LUN'. With upcoming scalable SAN ONTAP version on NetApp controllers, the PID entry alone is being modified to 'LUN C-Mode' (to distinguish current ONTAP LUNs from scalable ONTAP LUNs). 'LUN' would still suffice for matching 'LUN C-Mode' but best to explicitly add these new NetApp LUNs to the device list. Reported-by:
Martin George <marting@netapp.com> Acked-by:
-
