- 22 Jan, 2010 17 commits
-
-
Jan Kara authored
commit ec8e2f74 upstream. It can happen that write does not use all the blocks allocated in write_begin either because of some filesystem error (like ENOSPC) or because page with data to write has been removed from memory. We truncate these blocks so that we don't have dangling blocks beyond i_size. Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Roel Kluin authored
commit c60503c1 upstream. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Signed-off-by:
Jean-Francois Moine <moinejf@free.fr> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Takashi Iwai authored
commit c7a8eb10 upstream. The capture-related mixer elements are missing with ALC861/ALC660 codecs when quirks are present, due to missing call of set_capture_mixer(). Reference: Novell bnc#567340 http://bugzilla.novell.com/show_bug.cgi?id=567340Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Brown authored
commit 9dffe2a3 upstream. The constants used to specify ISINK ramp times for WM835x had the wrong shifts so that the on times applied to the off ramp and vice versa. The masks for the bitfields are correct. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Mark Brown authored
commit 8e6ba2df upstream. No need to set the security key when writing to it. Signed-off-by:
-
Mike Travis authored
commit fcfbb2b5 upstream. This fixes the problem of the initialization code not correctly mapping the entire MMIO space on a UV system. A side effect is the map_high() interface needed to be changed to accommodate different address and size shifts. Signed-off-by:
Mike Travis <travis@sgi.com> Reviewed-by:
Mike Habeck <habeck@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <4B479202.7080705@sgi.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Tamas Vincze authored
commit 118f3e1a upstream. EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4) Kernel panic - not syncing: EDAC MC0: Uncorrected Error (XEN) Domain 0 crashed: 'noreboot' set - not rebooting. This happens because FERR_NF_FBD bit 28 is not updated on i5000. Due to that, both bits 28 and 29 may be equal to one, returning channel = 3. As this value is invalid, EDAC core generates the panic. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14568Signed-off-by:
Tamas Vincze <tom@vincze.org> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Suresh Siddha authored
commit dfea91d5 upstream. Chris McDermott from IBM confirmed that hurricane chipset in IBM summit platforms doesn't support logical flat mode. Irrespective of the other things like apic_id's, total number of logical cpu's, Linux kernel should default to physical mode for this system. The 32-bit kernel does so using the OEM checks for the IBM summit platform. Add a similar OEM platform check for the 64bit kernel too. Otherwise the linux kernel boot can hang on this platform under certain bios/platform settings. Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Tested-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Cc: Chris McDermott <lcm@linux.vnet.ibm.com> Cc: Yinghai Lu <yinghai@kernel.org> Signed-off-by:
-
KOSAKI Motohiro authored
commit 6ccf80eb upstream. commit f2260e6b (page allocator: update NR_FREE_PAGES only as necessary) made one minor regression. if __rmqueue() was failed, NR_FREE_PAGES stat go wrong. this patch fixes it. Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mel@csn.ul.ie> Reviewed-by:
Minchan Kim <minchan.kim@gmail.com> Reported-by:
Huang Shijie <shijie8@gmail.com> Reviewed-by:
Christoph Lameter <cl@linux-foundation.org> Signed-off-by:
-
KOSAKI Motohiro authored
commit 7485d0d3 upstream. Currently, futexes have two problem: A) The current futex code doesn't handle private file mappings properly. get_futex_key() uses PageAnon() to distinguish file and anon, which can cause the following bad scenario: 1) thread-A call futex(private-mapping, FUTEX_WAIT), it sleeps on file mapping object. 2) thread-B writes a variable and it makes it cow. 3) thread-B calls futex(private-mapping, FUTEX_WAKE), it wakes up blocked thread on the anonymous page. (but it's nothing) B) Current futex code doesn't handle zero page properly. Read mode get_user_pages() can return zero page, but current futex code doesn't handle it at all. Then, zero page makes infinite loop internally. The solution is to use write mode get_user_page() always for page lookup. It prevents the lookup of both file page of private mappings and zero page. Performance concerns: Probaly very little, because glibc always initialize variables for futex before to call futex(). It means glibc users never see the overhead of this patch. Compatibility concerns: This patch has few compatibility issues. After this patch, FUTEX_WAIT require writable access to futex variables (read-only mappings makes EFAULT). But practically it's not a problem, glibc always initalizes variables for futexes explicitly - nobody uses read-only mappings. Reported-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
Darren Hart <dvhltc@us.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Ulrich Drepper <drepper@gmail.com> LKML-Reference: <20100105162633.45A2.A69D9226@jp.fujitsu.com> Signed-off-by:
-
Cyrill Gorcunov authored
commit 485a2e19 upstream. Add check if APIC is not disabled since thermal monitoring depends on it. As only apic gets disabled we should not try to install "thermal monitor" vector, print out that thermal monitoring is enabled and etc... Note that "Intel Correct Machine Check Interrupts" already has such a check. Also I decided to not add cpu_has_apic check into mcheck_intel_therm_init since even if it'll call apic_read on disabled apic -- it's safe here and allow us to save a few code bytes. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> LKML-Reference: <4B25FDC2.3020401@jp.fujitsu.com> Signed-off-by:
-
Martin K. Petersen authored
commit 81744ee4 upstream queue_sector_alignment_offset returned the wrong value which caused partitions to report an incorrect alignment_offset. Since offset calculation is needed several places it has been split into a separate helper function. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Tested-by:
Mike Snitzer <snitzer@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Zou Nan hai authored
commit c7c85101 upstream. On Ironlake, there is an interrupt master control bit. With the bit disabled before clearing IIR, we do not need to handle extra interrupt in a loop. This patch removes the loop in Ironlake interrupt handler. It fixed irq lost issue on some Ironlake platforms. Signed-off-by:
Zou Nan hai <Nanhai.zou@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daisuke Nishimura authored
commit fce66477 upstream. Current mem_cgroup_force_empty() only ensures mem->res.usage == 0 on success. But this doesn't guarantee memcg's LRU is really empty, because there are some cases in which !PageCgrupUsed pages exist on memcg's LRU. For example: - Pages can be uncharged by its owner process while they are on LRU. - race between mem_cgroup_add_lru_list() and __mem_cgroup_uncharge_common(). So there can be a case in which the usage is zero but some of the LRUs are not empty. OTOH, mem_cgroup_del_lru_list(), which can be called asynchronously with rmdir, accesses the mem_cgroup, so this access can cause a problem if it races with rmdir because the mem_cgroup might have been freed by rmdir. Actually, I saw a bug which seems to be caused by this race. [1530745.949906] BUG: unable to handle kernel NULL pointer dereference at 0000000000000230 [1530745.950651] IP: [<ffffffff810fbc11>] mem_cgroup_del_lru_list+0x30/0x80 [1530745.950651] PGD 3863de067 PUD 3862c7067 PMD 0 [1530745.950651] Oops: 0002 [#1] SMP [1530745.950651] last sysfs file: /sys/devices/system/cpu/cpu7/cache/index1/shared_cpu_map [1530745.950651] CPU 3 [1530745.950651] Modules linked in: configs ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp nfsd nfs_acl auth_rpcgss exportfs autofs4 hidp rfcomm l2cap crc16 bluetooth lockd sunrpc ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i cxgb3 mdio libiscsi_tcp libiscsi scsi_transport_iscsi dm_mirror dm_multipath scsi_dh video output sbs sbshc battery ac lp kvm_intel kvm sg ide_cd_mod cdrom serio_raw tpm_tis tpm tpm_bios acpi_memhotplug button parport_pc parport rtc_cmos rtc_core rtc_lib e1000 i2c_i801 i2c_core pcspkr dm_region_hash dm_log dm_mod ata_piix libata shpchp megaraid_mbox sd_mod scsi_mod megaraid_mm ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: freq_table] [1530745.950651] Pid: 19653, comm: shmem_test_02 Tainted: G M 2.6.32-mm1-00701-g2b04386 #3 Express5800/140Rd-4 [N8100-1065] [1530745.950651] RIP: 0010:[<ffffffff810fbc11>] [<ffffffff810fbc11>] mem_cgroup_del_lru_list+0x30/0x80 [1530745.950651] RSP: 0018:ffff8803863ddcb8 EFLAGS: 00010002 [1530745.950651] RAX: 00000000000001e0 RBX: ffff8803abc02238 RCX: 00000000000001e0 [1530745.950651] RDX: 0000000000000000 RSI: ffff88038611a000 RDI: ffff8803abc02238 [1530745.950651] RBP: ffff8803863ddcc8 R08: 0000000000000002 R09: ffff8803a04c8643 [1530745.950651] R10: 0000000000000000 R11: ffffffff810c7333 R12: 0000000000000000 [1530745.950651] R13: ffff880000017f00 R14: 0000000000000092 R15: ffff8800179d0310 [1530745.950651] FS: 0000000000000000(0000) GS:ffff880017800000(0000) knlGS:0000000000000000 [1530745.950651] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [1530745.950651] CR2: 0000000000000230 CR3: 0000000379d87000 CR4: 00000000000006e0 [1530745.950651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1530745.950651] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [1530745.950651] Process shmem_test_02 (pid: 19653, threadinfo ffff8803863dc000, task ffff88038612a8a0) [1530745.950651] Stack: [1530745.950651] ffffea00040c2fe8 0000000000000000 ffff8803863ddd98 ffffffff810c739a [1530745.950651] <0> 00000000863ddd18 000000000000000c 0000000000000000 0000000000000000 [1530745.950651] <0> 0000000000000002 0000000000000000 ffff8803863ddd68 0000000000000046 [1530745.950651] Call Trace: [1530745.950651] [<ffffffff810c739a>] release_pages+0x142/0x1e7 [1530745.950651] [<ffffffff810c778f>] ? pagevec_move_tail+0x6e/0x112 [1530745.950651] [<ffffffff810c781e>] pagevec_move_tail+0xfd/0x112 [1530745.950651] [<ffffffff810c78a9>] lru_add_drain+0x76/0x94 [1530745.950651] [<ffffffff810dba0c>] exit_mmap+0x6e/0x145 [1530745.950651] [<ffffffff8103f52d>] mmput+0x5e/0xcf [1530745.950651] [<ffffffff81043ea8>] exit_mm+0x11c/0x129 [1530745.950651] [<ffffffff8108fb29>] ? audit_free+0x196/0x1c9 [1530745.950651] [<ffffffff81045353>] do_exit+0x1f5/0x6b7 [1530745.950651] [<ffffffff8106133f>] ? up_read+0x2b/0x2f [1530745.950651] [<ffffffff8137d187>] ? lockdep_sys_exit_thunk+0x35/0x67 [1530745.950651] [<ffffffff81045898>] do_group_exit+0x83/0xb0 [1530745.950651] [<ffffffff810458dc>] sys_exit_group+0x17/0x1b [1530745.950651] [<ffffffff81002c1b>] system_call_fastpath+0x16/0x1b [1530745.950651] Code: 54 53 0f 1f 44 00 00 83 3d cc 29 7c 00 00 41 89 f4 75 63 eb 4e 48 83 7b 08 00 75 04 0f 0b eb fe 48 89 df e8 18 f3 ff ff 44 89 e2 <48> ff 4c d0 50 48 8b 05 2b 2d 7c 00 48 39 43 08 74 39 48 8b 4b [1530745.950651] RIP [<ffffffff810fbc11>] mem_cgroup_del_lru_list+0x30/0x80 [1530745.950651] RSP <ffff8803863ddcb8> [1530745.950651] CR2: 0000000000000230 [1530745.950651] ---[ end trace c3419c1bb8acc34f ]--- [1530745.950651] Fixing recursive fault but reboot is needed! The problem here is pages on LRU may contain pointer to stale memcg. To make res->usage to be 0, all pages on memcg must be uncharged or moved to another(parent) memcg. Moved page_cgroup have already removed from original LRU, but uncharged page_cgroup contains pointer to memcg withou PCG_USED bit. (This asynchronous LRU work is for improving performance.) If PCG_USED bit is not set, page_cgroup will never be added to memcg's LRU. So, about pages not on LRU, they never access stale pointer. Then, what we have to take care of is page_cgroup _on_ LRU list. This patch fixes this problem by making mem_cgroup_force_empty() visit all LRUs before exiting its loop and guarantee there are no pages on its LRU. Signed-off-by:
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Balbir Singh <balbir@linux.vnet.ibm.com> Signed-off-by:
-
Mark Brown authored
commit eb29a5cc upstream. Fix divide by zero and broken output. Commit 600ce1a0 ("fix clock setting for Samsung SoC Framebuffer") introduced a mandatory refresh parameter to the platform data for the S3C framebuffer but did not introduce any validation code, causing existing platforms (none of which have refresh set) to divide by zero whenever the framebuffer is configured, generating warnings and unusable output. Ben Dooks noted several problems with the patch: - The platform data supplies the pixclk directly and should already have taken care of the refresh rate. - The addition of a window ID parameter doesn't help since only the root framebuffer can control the pixclk. - pixclk is specified in picoseconds (rather than Hz) as the patch assumed. and suggests reverting the commit so do that. Without fixing this no mainline user of the driver will produce output. [akpm@linux-foundation.org: don't revert the correct bit] Signed-off-by:
-
Eric Paris authored
commit 976ae32b upstream. inotify will WARN() if it finds that the idr and the fsnotify internals somehow got out of sync. It was only supposed to do this once but due to this stupid bug it would warn every single time a problem was detected. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Eric Paris authored
commit 9e572cc9 upstream. Since commit 7e790dd5 ("inotify: fix error paths in inotify_update_watch") inotify changed the manor in which it gave watch descriptors back to userspace. Previous to this commit inotify acted like the following: inotify_add_watch(X, Y, Z) = 1 inotify_rm_watch(X, 1); inotify_add_watch(X, Y, Z) = 2 but after this patch inotify would return watch descriptors like so: inotify_add_watch(X, Y, Z) = 1 inotify_rm_watch(X, 1); inotify_add_watch(X, Y, Z) = 1 which I saw as equivalent to opening an fd where open(file) = 1; close(1); open(file) = 1; seemed perfectly reasonable. The issue is that quite a bit of userspace apparently relies on the behavior in which watch descriptors will not be quickly reused. KDE relies on it, I know some selinux packages rely on it, and I have heard complaints from other random sources such as debian bug 558981. Although the man page implies what we do is ok, we broke userspace so this patch almost reverts us to the old behavior. It is still slightly racey and I have patches that would fix that, but they are rather large and this will fix it for all real world cases. The race is as follows: - task1 creates a watch and blocks in idr_new_watch() before it updates the hint. - task2 creates a watch and updates the hint. - task1 updates the hint with it's older wd - task removes the watch created by task2 - task adds a new watch and will reuse the wd originally given to task2 it requires moving some locking around the hint (last_wd) but this should solve it for the real world and be -stable safe. As a side effect this patch papers over a bug in the lib/idr code which is causing a large number WARN's to pop on people's system and many reports in kerneloops.org. I'm working on the root cause of that idr bug seperately but this should make inotify immune to that issue. Signed-off-by:
-
- 18 Jan, 2010 23 commits
-
-
Greg Kroah-Hartman authored
-
David Woodhouse authored
commit fc619013 upstream. Some BIOSes fail to initialise the GTT, which will cause DMA faults when the IOMMU is enabled. We need to clear the whole thing to point at the scratch page, not just the part that Linux is going to use. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> [anholt: Note that this may also help with stability in the presence of driver bugs, by not drawing to memory we don't own] Signed-off-by:
-
David S. Miller authored
commit 2570a4f5 upstream. This fixes CERT-FI FICORA #341748 Discovered by Olli Jarva and Tuomo Untinen from the CROSS project at Codenomicon Ltd. Just like in CVE-2007-4567, we can't rely upon skb_dst() being non-NULL at this point. We fixed that in commit e76b2b25 ("[IPV6]: Do no rely on skb->dst before it is assigned.") However commit 483a47d2 ("ipv6: added net argument to IP6_INC_STATS_BH") put a new version of the same bug into this function. Complicating analysis further, this bug can only trigger when network namespaces are enabled in the build. When namespaces are turned off, the dev_net() does not evaluate it's argument, so the dereference would not occur. So, for a long time, namespaces couldn't be turned on unless SYSFS was disabled. Therefore, this code has largely been disabled except by people turning it on explicitly for namespace development. With help from Eugene Teo <eugene@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rusty Russell authored
commit d4703aef upstream. powerpc applies relocations to the kcrctab. They're absolute symbols, but it's not completely unreasonable: other archs may too, but the relocation is often 0. http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-November/077972.htmlInspired-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Tested-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Al Viro authored
commit b4c30aad upstream. Several leaks in audit_tree didn't get caught by commit 318b6d3d, including the leak on normal exit in case of multiple rules refering to the same chunk. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit 6f5d5114 upstream. ... aka "Al had badly fscked up when writing that thing and nobody noticed until Eric had fixed leaks that used to mask the breakage". The function essentially creates a copy of old array sans one element and replaces the references to elements of original (they are on cyclic lists) with those to corresponding elements of new one. After that the old one is fair game for freeing. First of all, there's a dumb braino: when we get to list_replace_init we use indices for wrong arrays - position in new one with the old array and vice versa. Another bug is more subtle - termination condition is wrong if the element to be excluded happens to be the last one. We shouldn't go until we fill the new array, we should go until we'd finished the old one. Otherwise the element we are trying to kill will remain on the cyclic lists... That crap used to be masked by several leaks, so it was not quite trivial to hit. Eric had fixed some of those leaks a while ago and the shit had hit the fan... Signed-off-by:
-
Johannes Berg authored
This is a backport of the mainline patches cf0277e7 045cfb71 b49bb574 Here is the description of the first of those patches (the other two just fixed bugs added by that patch): Since I removed the master netdev, we've been keeping internal queues only, and even before that we never told the networking stack above the virtual interfaces about congestion. This means that packets are queued in mac80211 and the upper layers never know, possibly leading to memory exhaustion and other problems. This patch makes all interfaces multiqueue and uses ndo_select_queue to put the packets into queues per AC. Additionally, when the driver stops a queue, we now stop all corresponding queues for the virtual interfaces as well. The injection case will use VO by default for non-data frames, and BE for data frames, but downgrade any data frames according to ACM. It needs to be fleshed out in the future to allow chosing the queue/AC in radiotap. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Cc: John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Mike Frysinger authored
Stable commit 0399123f didn't match the original upstream commit. The CONFIG_MMU check was added much too early in the list disabling a lot of proc entries in the process. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Samuel Ortiz authored
commit 659c8e52 upstream. There is no reason to signal a carrier off when doing a 802.11 scan. Cc: Holger Schurig <holgerschurig@gmail.com> Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Jesse Barnes authored
commit cda9d05c upstream. This code generally fails to adjust the render clock, and when it does, it conflicts with some other register settings and can cause problems. So remove this code altogether. I'm reworking it now to do the right thing, but the only bit it will share is the VBT check for whether reclocking is supported, so I'm leaving that bit. Reverts most of 652c393a ("add dynamic clock frequency control"), though for many the regressions showed up in the later 181a5336 ("Fix render reclock availability detection"). Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Felix Fietkau authored
commit d7907448 upstream. Various missing sanity checks caused rejected action frames to be interpreted as channel switch announcements, which can cause a client mode interface to switch away from its operating channel, thereby losing connectivity. This patch ensures that only spectrum management action frames are processed by the CSA handling function and prevents rejected action frames from getting processed by the MLME code. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Dan Carpenter authored
commit 8a9ac160 upstream. tid is used as an array offset. agg = &priv->stations[sta_id].tid[tid].agg; iwl4965_tx_status_reply_tx(priv, agg, tx_resp, txq_id, index); It should be limitted to MAX_TID_COUNT - 1; struct iwl_tid_data tid[MAX_TID_COUNT]; regards, dan carpenter Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit e12822e1 upstream. This fixes a syntax error when setting up the user regulatory hint. This change yields the same exact binary object though so it ends up just being a syntax typo fix, fortunately. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit 359207c6 upstream. Commit 8bf3d79b enabled EEPROM checksum checks to avoid bogus bug reports but failed to address updating the code to consider devices with custom EEPROM sizes. Devices with custom sized EEPROMs have the upper limit size stuffed in the EEPROM. Use this as the upper limit instead of the static default size. In case of a checksum error also provide back the max size and whether or not this was the default size or a custom one. If the EEPROM is busted we add a failsafe check to ensure we don't loop forever or try to read bogus areas of hardware. This closes bug 14874 http://bugzilla.kernel.org/show_bug.cgi?id=14874 Cc: David Quan <david.quan@atheros.com> Cc: Stephen Beahm <stephenbeahm@comcast.net> Reported-by:
Joshua Covington <joshuacov@googlemail.com> Signed-off-by:
-
Zhu Yi authored
commit c8106d76 upstream. When txq read_ptr equals to write_ptr, iwl_queue_used should always return false. Because there is no used TFD in this case. This is a complementary fix to the fix already included in commit "iwl3945: fix panic in iwl3945 driver". Both fixes are needed to address the panic below. This problem was discussed on linux-wireless in http://thread.gmane.org/gmane.linux.kernel.wireless.general/43568 <1>[ 7290.414172] IP: [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.414205] PGD 0 <1>[ 7290.414214] Thread overran stack, or stack corrupted <0>[ 7290.414229] Oops: 0002 [#1] PREEMPT SMP <0>[ 7290.414246] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input <4>[ 7290.414265] CPU 0 <4>[ 7290.414274] Modules linked in: af_packet nfsd usb_storage usb_libusual cpufreq_powersave exportfs cpufreq_conservative iwl3945 nfs cpufreq_userspace snd_hda_codec_realtek acpi_cpufreq uvcvideo lockd iwlcore snd_hda_intel joydev coretemp nfs_acl videodev snd_hda_codec mac80211 v4l1_compat snd_hwdep sbp2 v4l2_compat_ioctl32 uhci_hcd psmouse auth_rpcgss ohci1394 cfg80211 ehci_hcd video ieee1394 snd_pcm serio_raw battery ac nvidia(P) usbcore output sunrpc evdev lirc_ene0100 snd_page_alloc rfkill tg3 libphy fuse lzo lzo_decompress lzo_compress <6>[ 7290.414486] Pid: 0, comm: swapper Tainted: P 2.6.32-rc8-wl #213 Aspire 5720 <6>[ 7290.414507] RIP: 0010:[<ffffffffa0dd53a1>] [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <6>[ 7290.414541] RSP: 0018:ffff880002203d60 EFLAGS: 00010246 <6>[ 7290.414557] RAX: 000000000000004f RBX: ffff880064c11600 RCX: 0000000000000013 <6>[ 7290.414576] RDX: ffffffffa0ddcf20 RSI: ffff8800512b7008 RDI: 0000000000000038 <6>[ 7290.414596] RBP: ffff880002203dd0 R08: 0000000000000000 R09: 0000000000000100 <6>[ 7290.414616] R10: 0000000000000001 R11: 0000000000000000 R12: 00000000000000a0 <6>[ 7290.414635] R13: 0000000000000002 R14: 0000000000000013 R15: 0000000000020201 <6>[ 7290.414655] FS: 0000000000000000(0000) GS:ffff880002200000(0000) knlGS:0000000000000000 <6>[ 7290.414677] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b <6>[ 7290.414693] CR2: 0000000000000041 CR3: 0000000001001000 CR4: 00000000000006f0 <6>[ 7290.414712] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <6>[ 7290.414732] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 <4>[ 7290.414752] Process swapper (pid: 0, threadinfo ffffffff81524000, task ffffffff81528b60) <0>[ 7290.414772] Stack: <4>[ 7290.414780] ffff880002203da0 0000000000000046 0000000000000000 0000000000000046 <4>[ 7290.414804] <0> 0000000000000282 0000000000000282 0000000000000282 ffff880064c12010 <4>[ 7290.414830] <0> ffff880002203db0 ffff880064c11600 ffff880064c12e50 ffff8800512b7000 <0>[ 7290.414858] Call Trace: <0>[ 7290.414867] <IRQ> <4>[ 7290.414884] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.414910] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.414931] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.414950] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.414968] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.414986] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415003] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415020] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415038] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <0>[ 7290.415052] <EOI> <4>[ 7290.415067] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415087] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415107] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415130] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415149] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415168] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.415187] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.415206] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.415227] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb <0>[ 7290.415243] Code: 00 41 39 ce 0f 8d e8 01 00 00 48 8b 47 40 48 63 d2 48 69 d2 98 00 00 00 4c 8b 04 02 48 c7 c2 20 cf dd a0 49 8d 78 38 49 8d 40 4f <c6> 47 09 00 c6 47 0c 00 c6 47 0f 00 c6 47 12 00 c6 47 15 00 49 <1>[ 7290.415382] RIP [<ffffffffa0dd53a1>] iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415410] RSP <ffff880002203d60> <0>[ 7290.415421] CR2: 0000000000000041 <4>[ 7290.415436] ---[ end trace ec46807277caa515 ]--- <0>[ 7290.415450] Kernel panic - not syncing: Fatal exception in interrupt <4>[ 7290.415468] Pid: 0, comm: swapper Tainted: P D 2.6.32-rc8-wl #213 <4>[ 7290.415486] Call Trace: <4>[ 7290.415495] <IRQ> [<ffffffff8138c040>] panic+0x7d/0x13a <4>[ 7290.415519] [<ffffffff8101071a>] oops_end+0xda/0xe0 <4>[ 7290.415538] [<ffffffff8102e1ea>] no_context+0xea/0x250 <4>[ 7290.415557] [<ffffffff81038991>] ? select_task_rq_fair+0x511/0x780 <4>[ 7290.415578] [<ffffffff8102e475>] __bad_area_nosemaphore+0x125/0x1e0 <4>[ 7290.415597] [<ffffffff81038d0c>] ? __enqueue_entity+0x7c/0x80 <4>[ 7290.415616] [<ffffffff81039201>] ? enqueue_task_fair+0x111/0x150 <4>[ 7290.415636] [<ffffffff8102e53e>] bad_area_nosemaphore+0xe/0x10 <4>[ 7290.415656] [<ffffffff8102e8fa>] do_page_fault+0x26a/0x320 <4>[ 7290.415674] [<ffffffff813905df>] page_fault+0x1f/0x30 <4>[ 7290.415697] [<ffffffffa0dd53a1>] ? iwl3945_rx_reply_tx+0xc1/0x450 [iwl3945] <4>[ 7290.415723] [<ffffffffa0dc8c47>] iwl3945_irq_tasklet+0x657/0x1740 [iwl3945] <4>[ 7290.415746] [<ffffffff8138fc60>] ? _spin_unlock+0x30/0x60 <4>[ 7290.415764] [<ffffffff81049a21>] tasklet_action+0x101/0x110 <4>[ 7290.415783] [<ffffffff8104a3d0>] __do_softirq+0xc0/0x160 <4>[ 7290.415801] [<ffffffff8100d01c>] call_softirq+0x1c/0x30 <4>[ 7290.415818] [<ffffffff8100eff5>] do_softirq+0x75/0xb0 <4>[ 7290.415835] [<ffffffff81049ee5>] irq_exit+0x95/0xa0 <4>[ 7290.415852] [<ffffffff8100e547>] do_IRQ+0x77/0xf0 <4>[ 7290.415869] [<ffffffff8100c7d3>] ret_from_intr+0x0/0xf <4>[ 7290.415883] <EOI> [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415911] [<ffffffff81234f04>] ? acpi_idle_enter_bm+0x27a/0x2a5 <4>[ 7290.415931] [<ffffffff81234efa>] ? acpi_idle_enter_bm+0x270/0x2a5 <4>[ 7290.415952] [<ffffffff812c11f3>] ? cpuidle_idle_call+0x93/0xf0 <4>[ 7290.415971] [<ffffffff8100b0d7>] ? cpu_idle+0xa7/0x110 <4>[ 7290.415989] [<ffffffff8137b3d5>] ? rest_init+0x75/0x80 <4>[ 7290.416007] [<ffffffff8158cd0a>] ? start_kernel+0x3a7/0x3b3 <4>[ 7290.416026] [<ffffffff8158c315>] ? x86_64_start_reservations+0x125/0x129 <4>[ 7290.416047] [<ffffffff8158c3fd>] ? x86_64_start_kernel+0xe4/0xeb Reported-by:
Maxim Levitsky <maximlevitsky@gmail.com> Tested-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Ian Campbell authored
commit c5cae661 upstream. In 65f63384 "xen: improve error handling in do_suspend" I said: - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not nested in the obvious way. and changed the ordering of the calls as so: BEFORE AFTER xs_suspend dpm_suspend_noirq dpm_suspend_noirq xs_suspend *SUSPEND* *SUSPEND* dpm_resume_noirq dpm_resume_noirq xs_resume xs_resume Clearly this is not an improvement and I was talking rubbish. In particular the new ordering is susceptible to a hang if a xenstore write is in progress at the point at which the suspend kicks in. When the suspend process calls xs_suspend it tries to take the request_mutex but if a write is in progress it could be looping in xenbus_xs.c:read_reply() waiting for something to arrive on &xs_state.reply_list while holding the request_mutex (taken in the caller of read_reply). However if we have done dpm_suspend_noirq before xs_suspend then we won't get any more xenstore interrupts and process_msg() will never be woken up to add anything to the reply_list. Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq fails then make sure we go through the xs_suspend_cancel() code path. Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Acked-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Jan Kara authored
commit 05b5d898 upstream. Commit fd8fbfc1 modified the way we find amount of reserved space belonging to an inode. The amount of reserved space is checked from dquot_transfer and thus inode_reserved_space gets called even for filesystems that don't provide get_reserved_space callback which results in a BUG. Fix the problem by checking get_reserved_space callback and return 0 if the filesystem does not provide it. CC: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
-
Roger Blofeld authored
commit bb595c92 upstream. The ADT7462_PIN28_VOLT value is a 4-bit field, so the corresponding shift must be 4. Signed-off-by:
Roger Blofeld <blofeldus@yahoo.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Yong Wang authored
commit 1fe63ab4 upstream. The max junction temperature of Atom N450/D410/D510 CPUs is 100 degrees Celsius. Since these CPUs are always coupled with Intel NM10 chipset in one package, the best way to verify whether an Atom CPU is N450/D410/D510 is to check the host bridge device. Signed-off-by:
Yong Wang <yong.y.wang@intel.com> Acked-by:
Huaxu Wan <huaxu.wan@intel.com> Signed-off-by:
-
Patrick McHardy authored
commit aaff23a9 upstream. As noticed by Dan Carpenter <error27@gmail.com>, update_nl_seq() currently contains an out of bounds read of the seq_aft_nl array when looking for the oldest sequence number position. Fix it to only compare valid positions. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Florian Westphal authored
commit dce766af upstream. normal users are currently allowed to set/modify ebtables rules. Restrict it to processes with CAP_NET_ADMIN. Note that this cannot be reproduced with unmodified ebtables binary because it uses SOCK_RAW. Signed-off-by:
Florian Westphal <fwestphal@astaro.com> Signed-off-by:
-
Mark Brown authored
commit 5ee518ec upstream. We need to set the LRCLK inversion bit to select DSP mode. Signed-off-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Daniel T Chen authored
commit dfb12eeb upstream. BugLink: https://bugs.launchpad.net/ubuntu/+bug/498863 This mainboard needs ac97_codec=0. Tested-by:
Apoorv Parle <apparle@yahoo.co.in> Signed-off-by:
Daniel T Chen <crimsun@ubuntu.com> Signed-off-by:
-
