- 28 Jan, 2010 40 commits
-
-
Serge E. Hallyn authored
commit 7d6feeb2 upstream. We have apparently had a memory leak since 7ca7e564 "ipc: store ipcs into IDRs" in 2007. The idr of which 3 exist for each ipc namespace is never freed. This patch simply frees them when the ipcns is freed. I don't believe any idr_remove() are done from rcu (and could therefore be delayed until after this idr_destroy()), so the patch should be safe. Some quick testing showed no harm, and the memory leak fixed. Caught by kmemleak. Signed-off-by:
Serge E. Hallyn <serue@us.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Acked-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ursula Braun authored
commit 998221c2 upstream. tx_bytes value must be updated by skb length before skb is freed. Signed-off-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Acked-by:
John Jolly <jjolly@suse.de> Signed-off-by:
-
Peter Oberparleiter authored
commit 16b9a057 upstream. Remove the call to BUG() for situations which are unexpected but do not cause actual problems. Signed-off-by:
Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Peter Oberparleiter authored
commit 48e4c385 upstream. io_subchannel_probe() frees memory for sch->private which is later freed again when io_subchannel_remove() is called. Fix this problem by removing the cleanup in io_subchannel_probe(). Signed-off-by:
-
Laurent Pinchart authored
commit 385097e0 upstream. The control blacklisting code erroneously used usb_match_id() by passing a pointer to a usb_device_id structure instead of an array of such structures. Replace the usb_match_id() call by usb_match_id_one(). Thanks to Paulo Assis for diagnosing the bug and providing an initial fix. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
NeilBrown authored
commit 0f9552b5 upstream. The start_ro modules parameter can be used to force arrays to be started in 'auto-readonly' in which they are read-only until the first write. This ensures that no resync/recovery happens until something else writes to the device. This is important for resume-from-disk off an md array. However if an array is started 'readonly' (by writing 'readonly' to the 'array_state' sysfs attribute) we want it to be really 'readonly', not 'auto-readonly'. So strengthen the condition to only set auto-readonly if the array is not already read-only. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit 69385943 upstream. Fix erroneous check for ap->udma_mask in do_pata_set_dmamode() resulting in controller not being programmed properly for MWDMA. Signed-off-by:
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Shaohua Li authored
commit 1b677afd upstream. I obseved there is a sata_async_notification() for every ahci interrupt. But the async notification does nothing (this is hard disk drive and no pmp). This cause cpu wastes some time on sntf register access. It appears ICH AHCI doesn't support SNotification register, but the controller reports it does. After quirking it, the async notification disappears. PS. it appears all ICH don't support SNotification register from ICH manual, don't know if we need quirk all ICH. I don't have machines with all kinds of ICH. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
-
Seth Heasley authored
commit 3c9d8ecc upstream. This patch adds the Intel Cougar Point and PCH DeviceIDs for iTCO Watchdog. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Imre Kaloz authored
commit 4946f835 upstream. add PCI ID for the Intel EP80579 (Tolapai) SoC Signed-off-by:
Imre Kaloz <kaloz@openwrt.org> Signed-off-by:
-
Wim Van Sebroeck authored
commit cb711a19 upstream. Cleanup the documentation about the supported chipsets. [needed for further device ids to add to this driver - gkh] Signed-off-by:
-
Takashi Iwai authored
commit 23033b2b upstream. Realtek codecs may have "PCM" and "Line-Out" playback switches, and they can be slaves for vmaster. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 2fef62c8 upstream. Works fine with the auto-parser. Reference: Novell bnc#564940 https://bugzilla.novell.com/show_bug.cgi?id=564940Signed-off-by:
-
Wu Fengguang authored
commit 739b47f1 upstream. An earlier patch merely adds id for 0x80862804. It has 2/3 cvt/pin nodes and shall be tied to the IbexPeak handler. Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
Elliott Sales de Andrade authored
commit e6edbdc5 upstream. Signed-off-by:
Elliott Sales de Andrade <quantum.analyst@gmail.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Dmitry Torokhov authored
commit a61cd038 upstream. Gigabyte netbook model M1022M requires i8042.noloop, otherwise AUX port will not detected and the touchpad will not work. Unfortunately chassis type in DMI set to "Other" and thus generic laptop entry does not fire on it. Reported-by:
Darryl Bond <dbond@nrggos.com.au> Signed-off-by:
-
Dmitry Torokhov authored
commit f909b1df upstream. The driver does not reference identification strings in DMI tables and since these strings are no longer required by DMI core we can safely remove them and save some memory. Signed-off-by:
-
Dmitry Torokhov authored
commit 75757507 upstream. The purpose of dmi->ident is twofold - it may be used by DMI callback functions when composing log messages; it is also used to determine end of DMI table in dmi_check_system() and dmi_first_match(). However, in case when callbacks are not interested in using ident at all it just wastes memory. Let's make entries with empty first match slot serve as end-of-table markers instead. [needed for DMI table changes that need to be done by later patches - gkh] Acked-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Song Youquan authored
commit 46256f83 upstream. If the BIOS does not export _OSC to allow OS take over the PCIe AER, the pcie aer driver will not initialize the aer service. However, the aer_inject driver does not check this scenario, which results in a kernel oops when injecting an aer error into OS. For example: BUG: unable to handle kernel NULL pointer dereference at 0000000000000350 IP: [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23 PGD 155c41067 PUD 157fe0067 PMD 0 Oops: 0002 [#1] SMP Pid: 5119, comm: aer-inject Not tainted 2.6.32-rc8-mce #2 RIP: 0010:[<ffffffff812e08f7>] [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23 RSP: 0018:ffff880157f81e28 EFLAGS: 00010096 RAX: 0000000000000296 RBX: 0000000000000000 RCX: 0000000000000100 RDX: 0000000000010000 RSI: 0000000000000246 RDI: 0000000000000350 RBP: ffff880157f81e28 R08: 0000000000000004 R09: ffff880157f81dac R10: ffff88015a666f60 R11: ffff88015a666f40 R12: ffff88015758cc00 R13: 0000000000000350 R14: 0000000000000000 R15: 0000000000000100 FS: 00007f4d4a66e6f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000350 CR3: 000000015661a000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process aer-inject (pid: 5119, threadinfo ffff880157f80000, task ffff8801585f4340) Stack: ffff880157f81e78 ffffffff811b1615 ffff880157f81e78 ffffffff81222823 Call Trace: [<ffffffff811b1615>] aer_irq+0x38/0x117 [<ffffffff81222823>] ? device_for_each_child+0x5f/0x6f [<ffffffffa00967bf>] aer_inject_write+0x409/0x45e [aer_inject] [<ffffffff810eb80e>] vfs_write+0xae/0x16a [<ffffffff810eb98e>] sys_write+0x47/0x6e [<ffffffff8100ba2b>] system_call_fastpath+0x16/0x1b RIP [<ffffffff812e08f7>] _spin_lock_irqsave+0xc/0x23 RSP <ffff880157f81e28> CR2: 0000000000000350 So check the _OSC before assuming that AER is available to the OS. Signed-off-by:
Song Youquan <youquan.song@intel.com> Acked-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Thomas Renninger <trenn@suse.de> Signed-off-by:
-
Ron Mercer authored
commit 63ae93a1 upstream. Allow MAC address to be changed even if device is not up. Signed-off-by:
Ron Mercer <ron.mercer@qlogic.com> Signed-off-by:
Brandon Philips <bphilips@suse.de> Signed-off-by:
-
Ron Mercer authored
commit 91ced682 upstream. The driver has nothing to do, but this marker prevents the event from showing up 'not handled'. Signed-off-by:
-
Ron Mercer authored
commit 80928860 upstream. Signed-off-by:
-
Ron Mercer authored
commit bc9167f3 upstream. Signed-off-by:
-
Ron Mercer authored
commit 1d1023d0 upstream. Remove explicit setting of error reporting bits. Signed-off-by:
-
Yi Zou authored
commit 5bab87e6 upstream. Make sure we are get the SAN MAC address from the real netdev if the input netdev is a VLAN device. Signed-off-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
Yi Zou authored
commit bf361707 upstream. This was fixed before in 7a7f0c7f but it's introduced again recently. Signed-off-by:
-
Vasu Dev authored
commit 14caf44c upstream. The cmd_per_lun value is used by scsi-ml as fall back lowest queue_depth value but in case of libfc cmd_per_lun is set to same value as max queue_depth = 32. So this patch reduces cmd_per_lun value to 3 and configures each lun with default max queue_depth 32 in fc_slave_alloc. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Acked-by:
-
Abhijeet Joglekar authored
commit 5543c72e upstream. We ran into a scenario where a remote port goes into RESTART state, but never gets added to scsi transport. The running vmcore showed the following: a) Port was in RESTART state b) rdata->event was STOP c) no work gets scheduled for the remote work to fc_rport_work After this point, shut/no-shut of the remote port did not cause the port to get re-discovered. The port would move betwen DELETE and RESTART states, but the event would always be STOP, no work would get scheduled to fc_rport_work and the port would not get added to scsi_transport. The problem is that rdata->event is not set to NONE after a port is restarted. After this point, no more work gets scheduled for the remote port since new work is scheduled only if rdata->event is non-NONE. So, the event and state keep changing, but fc_rport_work does not get scheduled to actually handle the event. Here's a transition of states that explains the above observation: ) Port is first in READY State, event is NONE 2) RSCN on shut, port goes to DELETED, event is stop 3) Before fc_rport_work runs, RSCN on no-shut, port goes to RESTART, event is still STOP 4) fc_rport_work gets scheduled, removes the port from transport, sees state as RESTART, begins the PLOGI state machine, event remains as STOP (event NOT changed to NONE, this is the bug) 5) Plogi state machine completes, port state goes to READY, event goes to READY, but no work is scheduled since event was STOP (non-NONE) before. Fc_rport_work is not scheduled, port remains in READY state, but is not added to transport. Things are broken at this point. Libfc rport is ready, but no transport rport created. 6) now a shut causes port state to change to DELETE, event to change to STOP, no work gets scheduled 7) no-shut causes port state to change to RESTART, event remains at STOP, no work gets scheduled (6) and (7) now get repeated everytime we do shut/no-shut. No way to get out of this state. Fcc reset does not help too. Only way to get out is to load/unload module. Fix is to set rdata->event to NONE while processing the STOP/LOGO/FAILED events, inside the discovery and rport locks. Signed-off-by:
Abhijeet Joglekar <abjoglek@cisco.com> Signed-off-by:
-
Joe Eykholt authored
commit b4a9c7ed upstream. Timer crashes were caused by freeing a struct fc_rport_priv with a timer pending, causing the timer facility list to be corrupted. This was during FC uplink flap tests with a lot of targets. After discovery, we were doing an PLOGI on an rdata that was in DELETE state but not yet removed from the lookup list. This moved the rdata from DELETE state to PLOGI state. If the PLOGI exchange allocation failed and needed to be retried, the timer scheduling could race with the free being done by fc_rport_work(). When fc_rport_login() is called on a rport in DELETE state, move it to a new state RESTART. In fc_rport_work, when handling a LOGO, STOPPED or FAILED event, look for restart state. In the RESTART case, don't take the rdata off the list and after the transport remote port is deleted and exchanges are reset, re-login to the remote port. Note that the new RESTART state also corrects a problem we had when re-discovering a port that had moved to DELETE state. In that case, a new rdata was created, but the old rdata would do an exchange manager reset affecting the FC_ID for both the new rdata and old rdata. With the new state, the new port isn't logged into until after any old exchanges are reset. Signed-off-by:
Joe Eykholt <jeykholt@cisco.com> Signed-off-by:
-
Chris Leech authored
commit 8f550f93 upstream. I was running into several different panics under stress, which I traced down to a few different possible slab corruption issues in error handling paths. I have not yet looked into why these exchange sends fail, but with these fixes my test system is much more stable under stress than before. fc_elsct_send() could fail and either leave the passed in frame intact (failure in fc_ct/els_fill) or the frame could have been freed if the failure was is fc_exch_seq_send(). The caller had no way of knowing, and there was a potential double free in the error handling in fc_fcp_rec(). Make fc_elsct_send() always free the frame before returning, and remove the fc_frame_free() call in fc_fcp_rec(). While fc_exch_seq_send() did always consume the frame, there were double free bugs in the error handling of fc_fcp_cmd_send() and fc_fcp_srr() as well. Numerous calls to error handling routines (fc_disc_error(), fc_lport_error(), fc_rport_error_retry() ) were passing in a frame pointer that had already been freed in the case of an error. I have changed the call sites to pass in a NULL pointer, but there may be more appropriate error codes to use. Question: Why do these error routines take a frame pointer anyway? I understand passing in a pointer encoded error to the response handlers, but the error routines take no action on a valid pointer and should never be called that way. Signed-off-by:
Chris Leech <christopher.leech@intel.com> Signed-off-by:
-
Yi Zou authored
commit d37322a4 upstream. In case of sequence offload, in fc_fcp_send_data(), the skb_fill_page_info() called may end up adding more frags to the skb_shinfo(fp_skb(fp))->frags[], exceeding SKB_MAX_FRAGS, this eventually corrupts the memory. I am adding the FR_FRAME_SG_LEN back, but as SKB_MAX_FRAGS -1, leaving 1 for our fcoe_eof_crc page. And send will be broken into multiple large sends if the frame already contains more frags than skb handle. Signed-off-by:
-
Mike Christie authored
commit 8eca355f upstream. When doing echo ethX > /sys..../destroy I am getting errors when the tear down succeeds. It looks like the reason for this is because the rc var is not getting set when the destruction works. This just sets it to zero. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
-
Joe Eykholt authored
commit 22655ac2 upstream. It's possible and harmless to get FLOGI timeouts while in RESET state. Don't do a WARN_ON in that case. Also, split out the other WARN_ONs in fc_lport_timeout, so we can tell which one is hit by its line number. Signed-off-by:
-
Joe Eykholt authored
commit 1b69bc06 upstream. Fix minor errors. A debug message said an RLIR was received instead of ECHO. "Expected" was misspelled in several places. Fix a type cast from u32 to __be32. Rob, Some of these may have been also taken care of in your other doc cleanup patch. Feel free to fold them in. Signed-off-by:
-
Yi Zou authored
commit 4347fa66 upstream. This bug is exposed when there is a link flap in LLD. Particularly, when it happens right after a SCSI write command is sent out, no FCP_DATA is sent, causing fsp->status_code to be set as FC_DATA_UNDRUN in fc_fcp_complete_locked even no SCSI status is received. Consequently, fc_io_compl treats this as DID_OK. This results in SCSI returning successful to the initial I/O request even there is no DATA actually sent. Particularly, if you run an I/O tool w/ data verification on, the read back for verification is gonna fail. This is fixed here by checking when FC_DATA_UNDRUN happens, SCSI status is received w/ FC_SRB_RCV_STATUS set in fsp->state. Signed-off-by:
-
Yi Zou authored
commit b04d023c upstream. Remove the redundant checking of netdev->netdev_ops as it will never be NULL. Signed-off-by:
-
Yi Zou authored
commit 5e472d07 upstream. xid 0 was used as an indication of invalid xid before but now xid 0 can be used as a valid exchange i. This patch fixes the ddp completion in fcp layer, i.e., in fc_fcp.c:fc_fcp_ddp_done() function, to make sure it does not use xid 0 for indication of an invalid xid, instead, it now uses use FC_XID_UNKNOWN for such indication. Signed-off-by:
-
Joe Eykholt authored
commit 85b5893c upstream. A received Fibre Channel ELS PRLI request contains a bit that indicates whether the remote port supports certain retry processing sequences. The test for this bit was somehow coded to use multiply instead of AND! This case would apply only for target mode operation, and it is unlikely to be noticed as an initiator. Signed-off-by:
-
Michael Reed authored
commit 8e68597d upstream. In testing 2.6.31 on one of our ia64 platforms I've encountered a hang due to the driver using hardware ATEs which are a limited resource. This is because the driver does not set the dma consistent mask to 64 bits. Signed-off-by:
Michael Reed <mdr@sgi.com> Acked-by:
James Smart <James.Smart@Emulex.Com> Signed-off-by:
-
Michael Reed authored
commit 8798a694 upstream. I was doing some large lun count testing with 2.6.31 and hit a BUG_ON() in fc_timeout_deleted_rport(), and it seems like it should have been just a matter of time before someone did. It seems invalid to set port_state under lock, then expect it to remain set after releasing the lock. Another thread called fc_remote_port_add() when the lock was released, changing the port_state. This patch removes the BUG_ON and moves the test of the port_state to inside the host_lock. It's been running for several weeks now with no ill effect. Signed-off-by:
-
