- 01 Apr, 2010 40 commits
-
-
Colin Ian King authored
commit 8c2eb480 upstream. Ensure additions on touch_ts do not overflow. This can occur when the top 32 bits of the TSC reach 0xffffffff causing additions to touch_ts to overflow and this in turn generates spurious softlockup warnings. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Eric Dumazet <eric.dumazet@gmail.com> LKML-Reference: <1268994482.1798.6.camel@lenovo> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Miao Xie authored
commit 5ab116c9 upstream. cpuset_mem_spread_node() returns an offline node, and causes an oops. This patch fixes it by initializing task->mems_allowed to node_states[N_HIGH_MEMORY], and updating task->mems_allowed when doing memory hotplug. Signed-off-by:
Miao Xie <miaox@cn.fujitsu.com> Acked-by:
David Rientjes <rientjes@google.com> Reported-by:
Nick Piggin <npiggin@suse.de> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Felix Fietkau authored
commit 4fdec031 upstream. When I initially stumbled upon sequence number problems with PAE frames in ath9k, I submitted a patch to remove all special cases for PAE frames and let them go through the normal transmit path. Out of concern about crypto incompatibility issues, this change was merged instead: commit 6c8afef5 Author: Sujith <Sujith.Manoharan@atheros.com> Date: Tue Feb 9 10:07:00 2010 +0530 ath9k: Fix sequence numbers for PAE frames After a lot of testing, I'm able to reliably trigger a driver crash on rekeying with current versions with this change in place. It seems that the driver does not support sending out regular MPDUs with the same TID while an A-MPDU session is active. This leads to duplicate entries in the TID Tx buffer, which hits the following BUG_ON in ath_tx_addto_baw(): index = ATH_BA_INDEX(tid->seq_start, bf->bf_seqno); cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1); BUG_ON(tid->tx_buf[cindex] != NULL); I believe until we actually have a reproducible case of an incompatibility with another AP using no PAE special cases, we should simply get rid of this mess. This patch completely fixes my crash issues in STA mode and makes it stay connected without throughput drops or connectivity issues even when the AP is configured to a very short group rekey interval. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ben Hutchings authored
John Halton wrote in <http://bugs.debian.org/575726>: > Whenever wpa_supplicant is deactivated (whether by killing the process or > during a normal shutdown) I am getting a kerneloops that prevents the > computer from completing shutdown. Here is the relevant syslog output: The backtrace points to an incorrect call from RTMPFreeTxRxRingMemory() into linux_pci_unmap_single(). This appears to have been fixed in Linux 2.6.33 by this change: commit ca97b838 Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Tue Sep 22 20:44:07 2009 +0200 Staging: rt28x0: updates from vendor's V2.1.0.0 drivers For stable-2.6.32, just fix this one function call. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Dean Nelson authored
commit 7c9e2b1c upstream. pcix_get_mmrbc() returns the maximum memory read byte count (mmrbc), if successful, or an appropriate error value, if not. Distinguishing errors from correct values and understanding the meaning of an error can be somewhat confusing in that: correct values: 512, 1024, 2048, 4096 errors: -EINVAL -22 PCIBIOS_FUNC_NOT_SUPPORTED 0x81 PCIBIOS_BAD_VENDOR_ID 0x83 PCIBIOS_DEVICE_NOT_FOUND 0x86 PCIBIOS_BAD_REGISTER_NUMBER 0x87 PCIBIOS_SET_FAILED 0x88 PCIBIOS_BUFFER_TOO_SMALL 0x89 The PCIBIOS_ errors are returned from the PCI functions generated by the PCI_OP_READ() and PCI_OP_WRITE() macros. In a similar manner, pcix_set_mmrbc() also returns the PCIBIOS_ error values returned from pci_read_config_[word|dword]() and pci_write_config_word(). Following pcix_get_max_mmrbc()'s example, the following patch simply returns -EINVAL for all PCIBIOS_ errors encountered by pcix_get_mmrbc(), and -EINVAL or -EIO for those encountered by pcix_set_mmrbc(). This simplification was chosen in light of the fact that none of the current callers of these functions are interested in the specific type of error encountered. In the future, should this change, one could simply create a function that maps each PCIBIOS_ error to a corresponding unique errno value, which could be called by pcix_get_max_mmrbc(), pcix_get_mmrbc(), and pcix_set_mmrbc(). Additionally, this patch eliminates some unnecessary variables. Signed-off-by:
Dean Nelson <dnelson@redhat.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Dean Nelson authored
commit bdc2bda7 upstream. An e1000 driver on a system with a PCI-X bus was always being returned a value of 135 from both pcix_get_mmrbc() and pcix_set_mmrbc(). This value reflects an error return of PCIBIOS_BAD_REGISTER_NUMBER from pci_bus_read_config_dword(,, cap + PCI_X_CMD,). This is because for a dword, the following portion of the PCI_OP_READ() macro: if (PCI_##size##_BAD) return PCIBIOS_BAD_REGISTER_NUMBER; expands to: if (pos & 3) return PCIBIOS_BAD_REGISTER_NUMBER; And is always true for 'cap + PCI_X_CMD', which is 0xe4 + 2 = 0xe6. ('cap' is the result of calling pci_find_capability(, PCI_CAP_ID_PCIX).) The same problem exists for pci_bus_write_config_dword(,, cap + PCI_X_CMD,). In both cases, instead of calling _dword(), _word() should be called. Signed-off-by:
-
Dean Nelson authored
commit 25daeb55 upstream. For the PCI_X_STATUS register, pcix_get_max_mmrbc() is returning an incorrect value, which is based on: (stat & PCI_X_STATUS_MAX_READ) >> 12 Valid return values are 512, 1024, 2048, 4096, which correspond to a 'stat' (masked and right shifted by 21) of 0, 1, 2, 3, respectively. A right shift by 11 would generate the correct return value when 'stat' (masked and right shifted by 21) has a value of 1 or 2. But for a value of 0 or 3 it's not possible to generate the correct return value by only right shifting. Fix is based on pcix_get_mmrbc()'s similar dealings with the PCI_X_CMD register. Signed-off-by:
-
OGAWA Hirofumi authored
commit 8e0cc811 upstream. Smaller size than a minimum blocksize can't be used, after all it's handled like 0 size. For extended partition itself, this makes sure to use bigger size than one logical sector size at least. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Daniel Taylor <Daniel.Taylor@wdc.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Daniel Taylor authored
commit 3fbf586c upstream. In order to use disks larger than 2TiB on Windows XP, it is necessary to use 4096-byte logical sectors in an MBR. Although the kernel storage and functions called from msdos.c used "sector_t" internally, msdos.c still used u32 variables, which results in the ability to handle XP-compatible large disks. This patch changes the internal variables to "sector_t". Daniel said: "In the near future, WD will be releasing products that need this patch". [hirofumi@mail.parknet.co.jp: tweaks and fix] Signed-off-by:
Daniel Taylor <daniel.taylor@wdc.com> Signed-off-by:
-
Paulius Zaleckas authored
commit 9bf35c8d upstream. When compiling userspace application which includes if_tunnel.h and uses GRE_* defines you will get undefined reference to __cpu_to_be16. Fix this by adding missing #include <asm/byteorder.h> Signed-off-by:
Paulius Zaleckas <paulius.zaleckas@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dan Carpenter authored
commit f1f0abe1 upstream. __rpc_lookup_create() can return ERR_PTR(-ENOMEM). Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit cdead7cf upstream. The function alloc_enc_pages() currently fails to release the pointer rqstp->rq_enc_pages in the error path. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by:
-
Adel Gadllah authored
commit c8406ea8 upstream. Commit a239a8b4 introduced a noisy message, that fills up the log very fast. The error seems not to be fatal (the connection is stable and performance is ok), so make it IWL_DEBUG_TX rather than IWL_ERR. Signed-off-by:
Adel Gadllah <adel.gadllah@gmail.com> Acked-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit f36d04ab upstream. Change pci_alloc_consistent() to dma_alloc_coherent() so we can use GFP_KERNEL flag. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Borislav Petkov authored
commit 5b89d2f9 upstream. Print the CPU associated with the error only when the field is valid. Signed-off-by:
Borislav Petkov <borislav.petkov@amd.com> Signed-off-by:
-
Guo-Fu Tseng authored
commit bf5e5360 upstream. Temporary stop the RX IRQ, and disable (sync) tasklet or napi. And restore it after finished the vlgrp pointer assignment. Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Signed-off-by:
-
Guo-Fu Tseng authored
commit 17da69b8 upstream. Fix memory leak while receiving 8021q tagged packet which is not registered by user. Signed-off-by:
-
Grazvydas Ignotas authored
commit 3f60ebc9 upstream. In case debugfs does not init for some reason (or is disabled on older kernels) driver does not allocate stats.fw_stats structure, but tries to clear it later and trips on a NULL pointer: Unable to handle kernel NULL pointer dereference at virtual address 00000000 PC is at __memzero+0x24/0x80 Backtrace: [<bf0ddb88>] (wl1251_debugfs_reset+0x0/0x30 [wl1251]) [<bf0d6a2c>] (wl1251_op_stop+0x0/0x12c [wl1251]) [<bf0bc228>] (ieee80211_stop_device+0x0/0x74 [mac80211]) [<bf0b0d10>] (ieee80211_stop+0x0/0x4ac [mac80211]) [<c02deeac>] (dev_close+0x0/0xb4) [<c02deac0>] (dev_change_flags+0x0/0x184) [<c031f478>] (devinet_ioctl+0x0/0x704) [<c0320720>] (inet_ioctl+0x0/0x100) Add a NULL pointer check to fix this. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Acked-by:
Kalle Valo <kalle.valo@iki.fi> Signed-off-by:
-
Yoshihiro Shimoda authored
commit d8359334 upstream. fix the problem that when a USB hub is attached to the r8a66597-hcd and a device is removed from that hub, it's likely that a kernel panic follows. Reported-by:
Markus Pietrek <Markus.Pietrek@emtrion.de> Signed-off-by:
Yoshihiro Shimoda <shimoda.yoshihiro@renesas.com> Signed-off-by:
-
Nathaniel McCallum authored
commit 3b04872a upstream. Signed-off-by:
Nathaniel McCallum <nathaniel@natemccallum.com> Signed-off-by:
-
Nathaniel McCallum authored
commit bb73ed2a upstream. Signed-off-by:
-
Nathaniel McCallum authored
commit eaff4cdc upstream. Signed-off-by:
-
Daniel Sangorrin authored
commit dee5658b upstream. This is a patch to ftdi_sio_ids.h and ftdi_sio.c that adds identifiers for CONTEC USB serial converter. I tested it with the device COM-1(USB)H [akpm@linux-foundation.org: keep the VIDs sorted a bit] Signed-off-by:
Daniel Sangorrin <daniel.sangorrin@gmail.com> Cc: Andreas Mohr <andi@lisas.de> Cc: Radek Liboska <liboska@uochb.cas.cz> Signed-off-by:
-
Andiry Xu authored
commit 1d68064a upstream. When a signal interrupts a Configure Endpoint command, the cmd_completion used in xhci_configure_endpoint() is not re-initialized and the wait_for_completion_interruptible_timeout() will return failure. Initialize cmd_completion in xhci_configure_endpoint(). Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Bernhard Rosenkraenzer authored
commit 0725e95e upstream. This patch adds various USB device IDs for Gobi 2000 devices, as found in the drivers available at https://www.codeaurora.org/wiki/GOBI_ReleasesSigned-off-by:
Bernhard Rosenkraenzer <bero@arklinux.org> Signed-off-by:
-
Clemens Ladisch authored
commit 1082f57a upstream. The EHCI driver stores in usb_host_endpoint.hcpriv a pointer to either an ehci_qh or an ehci_iso_stream structure, and uses the contents of the hw_info1 field to distinguish the two cases. After ehci_qh was split into hw and sw parts, ehci_iso_stream must also be adjusted so that it again looks like an ehci_qh structure. This fixes a NULL pointer access in ehci_endpoint_disable() when it tries to access qh->hw->hw_info1. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Reported-by:
Colin Fletcher <colin.m.fletcher@googlemail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Clemens Ladisch authored
commit 92bc3648 upstream. When isochronous URBs are shorter than one frame and when more than one ITD in a frame has been completed before the interrupt can be handled, scan_periodic() completes the URBs in the order in which they are found in the descriptor list. Therefore, the descriptor list must contain the ITDs in the correct order, i.e., a new ITD must be linked in after any previous ITDs of the same endpoint. This should fix garbled capture data in the USB audio drivers. Signed-off-by:
-
Alan Stern authored
commit 7152b592 upstream. This patch (as1352) fixes a bug in the way isochronous input data is returned to userspace for usbfs transfers. The entire buffer must be copied, not just the first actual_length bytes, because the individual packets will be discontiguous if any of them are short. Reported-by:
Markus Rechberger <mrechberger@gmail.com> Signed-off-by:
-
Mel Gorman authored
commit 352fa6ad upstream. The TTY layer takes some care to ensure that only sub-page allocations are made with interrupts disabled. It does this by setting a goal of "TTY_BUFFER_PAGE" to allocate. Unfortunately, while TTY_BUFFER_PAGE takes the size of tty_buffer into account, it fails to account that tty_buffer_find() rounds the buffer size out to the next 256 byte boundary before adding on the size of the tty_buffer. This patch adjusts the TTY_BUFFER_PAGE calculation to take into account the size of the tty_buffer and the padding. Once applied, tty_buffer_alloc() should not require high-order allocations. Signed-off-by:
Mel Gorman <mel@csn.ul.ie> Signed-off-by:
-
Alan Cox authored
commit d9661adf upstream. We allocate during interrupts so while our buffering is normally diced up small anyway on some hardware at speed we can pressure the VM excessively for page pairs. We don't really need big buffers to be linear so don't try so hard. In order to make this work well we will tidy up excess callers to request_room, which cannot itself enforce this break up. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Trond Myklebust authored
commit d812e575 upstream. We should not attempt to free the page if __GFP_FS is not set. Otherwise we can deadlock as per http://bugzilla.kernel.org/show_bug.cgi?id=15578Signed-off-by:
-
Trond Myklebust authored
commit bb6fbc45 upstream. J.R. Okajima reports the following deadlock: INFO: task kswapd0:305 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kswapd0 D 0000000000000001 0 305 2 0x00000000 ffff88001f21d4f0 0000000000000046 ffff88001fdea680 ffff88001f21c000 ffff88001f21dfd8 ffff88001f21c000 ffff88001f21dfd8 ffff88001f21dfd8 ffff88001fdea040 0000000000014c00 0000000000000001 ffff88001fdea040 Call Trace: [<ffffffff8146155d>] io_schedule+0x4d/0x70 [<ffffffff810d2be5>] sync_page+0x65/0xa0 [<ffffffff81461b12>] __wait_on_bit_lock+0x52/0xb0 [<ffffffff810d2b80>] ? sync_page+0x0/0xa0 [<ffffffff810d2b64>] __lock_page+0x64/0x70 [<ffffffff81070ce0>] ? wake_bit_function+0x0/0x40 [<ffffffff810df1d4>] truncate_inode_pages_range+0x344/0x4a0 [<ffffffff810df340>] truncate_inode_pages+0x10/0x20 [<ffffffff8112cbfe>] generic_delete_inode+0x15e/0x190 [<ffffffff8112cc8d>] generic_drop_inode+0x5d/0x80 [<ffffffff8112bb88>] iput+0x78/0x80 [<ffffffff811bc908>] nfs_dentry_iput+0x38/0x50 [<ffffffff811285f4>] dentry_iput+0x84/0x110 [<ffffffff811286ae>] d_kill+0x2e/0x60 [<ffffffff8112912a>] dput+0x7a/0x170 [<ffffffff8111e925>] path_put+0x15/0x40 [<ffffffff811c3a44>] __put_nfs_open_context+0xa4/0xb0 [<ffffffff811cb5d0>] ? nfs_free_request+0x0/0x50 [<ffffffff811c3b0b>] put_nfs_open_context+0xb/0x10 [<ffffffff811cb5f9>] nfs_free_request+0x29/0x50 [<ffffffff81234b7e>] kref_put+0x8e/0xe0 [<ffffffff811cb594>] nfs_release_request+0x14/0x20 [<ffffffff811cf769>] nfs_find_and_lock_request+0x89/0xa0 [<ffffffff811d1180>] nfs_wb_page+0x80/0x110 [<ffffffff811c0770>] nfs_release_page+0x70/0x90 [<ffffffff810d18ee>] try_to_release_page+0x5e/0x80 [<ffffffff810e1178>] shrink_page_list+0x638/0x860 [<ffffffff810e19de>] shrink_zone+0x63e/0xc40 We can fix this by making the call to put_nfs_open_context() happen when we actually remove the write request from the inode (which is done by the nfsiod thread in this case). Signed-off-by:
-
Trond Myklebust authored
commit b4d2314b upstream. If the NFS_INO_REVAL_FORCED flag is set, that means that we don't yet have an up to date attribute cache. Even if we hold a delegation, we must put a GETATTR on the wire. Signed-off-by:
-
Gal Rosen authored
commit 0d9dc7c8 upstream. The issue occur while deleting 60 virtual ports through the sys interface /sys/class/fc_vports/vport-X/vport_delete. It happen while in a mistake each request sent twice for the same vport. This interface is asynchronous, entering the delete request into a work queue, allowing more than one request to enter to the delete work queue. The result is a NULL pointer. The first request already delete the vport, while the second request got a pointer to the vport before the device destroyed. Re-create vport later cause system freeze. Solution: Check vport flags before entering the request to the work queue. [jejb: fixed int<->long problem on spinlock flags variable] Signed-off-by:
Gal Rosen <galr@storwize.com> Acked-by:
James Smart <james.smart@emulex.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
KOSAKI Motohiro authored
commit 55741696 upstream. commit 3f226aa1 (mempolicy: support mpol=local tmpfs mount option) added new mpol=local mount option. but it didn't add a documentation. This patch does it. Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Ravikiran Thirumalai <kiran@scalex86.org> Cc: Christoph Lameter <cl@linux-foundation.org> Cc: Mel Gorman <mel@csn.ul.ie> Acked-by:
Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
-
KOSAKI Motohiro authored
commit 926f2ae0 upstream. mpol_parse_str() made lots 'err' variable related bug. Because it is ugly and reviewing unfriendly. This patch simplifies it. Signed-off-by:
-
KOSAKI Motohiro authored
commit 12821f5f upstream. commit 71fe804b (mempolicy: use struct mempolicy pointer in shmem_sb_info) added mpol=local mount option. but its feature is broken since it was born. because such code always return 1 (i.e. mount failure). This patch fixes it. Signed-off-by:
-
KOSAKI Motohiro authored
commit d69b2e63 upstream. Currently, following mount operation cause mount error. % mount -t tmpfs -ompol=bind:0 none /tmp Because commit 71fe804b (mempolicy: use struct mempolicy pointer in shmem_sb_info) corrupted MPOL_BIND parse code. This patch restore the needed one. Signed-off-by:
-
Ravikiran G Thirumalai authored
commit 413b43de upstream. Fix an 'oops' when a tmpfs mount point is mounted with the mpol=default mempolicy. Upon remounting a tmpfs mount point with 'mpol=default' option, the mount code crashed with a null pointer dereference. The initial problem report was on 2.6.27, but the problem exists in mainline 2.6.34-rc as well. On examining the code, we see that mpol_new returns NULL if default mempolicy was requested. This 'NULL' mempolicy is accessed to store the node mask resulting in oops. The following patch fixes it. Signed-off-by:
Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by:
-
Paul Mackerras authored
commit 220b140b upstream. Anton Blanchard found that he could reliably make the kernel hit a BUG_ON in the slab allocator by taking a cpu offline and then online while a system-wide perf record session was running. The reason is that when the cpu comes up, we completely reinitialize the ctx field of the struct perf_cpu_context for the cpu. If there is a system-wide perf record session running, then there will be a struct perf_event that has a reference to the context, so its refcount will be 2. (The perf_event has been removed from the context's group_entry and event_entry lists by perf_event_exit_cpu(), but that doesn't remove the perf_event's reference to the context and doesn't decrement the context's refcount.) When the cpu comes up, perf_event_init_cpu() gets called, and it calls __perf_event_init_context() on the cpu's context. That resets the refcount to 1. Then when the perf record session finishes and the perf_event is closed, the refcount gets decremented to 0 and the context gets kfreed after an RCU grace period. Since the context wasn't kmalloced -- it's part of a per-cpu variable -- bad things happen. In fact we don't need to completely reinitialize the context when the cpu comes up. It's sufficient to initialize the context once at boot, but we need to do it for all possible cpus. This moves the context initialization to happen at boot time. With this, we don't trash the refcount and the context never gets kfreed, and we don't hit the BUG_ON. Reported-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Paul Mackerras <paulus@samba.org> Tested-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
-
