- 02 Aug, 2010 40 commits
-
-
Theodore Ts'o authored
commit cc3e1bea upstream (as of v2.6.33-rc3) This is a bit complicated because we are trying to optimize when we send barriers to the fs data disk. We could just throw in an extra barrier to the data disk whenever we send a barrier to the journal disk, but that's not always strictly necessary. We only need to send a barrier during a commit when there are data blocks which are must be written out due to an inode written in ordered mode, or if fsync() depends on the commit to force data blocks to disk. Finally, before we drop transactions from the beginning of the journal during a checkpoint operation, we need to guarantee that any blocks that were flushed out to the data disk are firmly on the rust platter before we drop the transaction from the journal. Thanks to Oleg Drokin for pointing out this flaw in ext3/ext4. Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Surbhi Palande authored
commit 034fb4c9 upstream (as of v2.6.33-rc3) This patch fixes the Kernel BZ #14286. When the address of an extent corresponding to a valid block is corrupted, a -EIO should be reported instead of a BUG(). This situation should not normally not occur except in the case of a corrupted filesystem. If however it does, then the system should not panic directly but depending on the mount time options appropriate action should be taken. If the mount options so permit, the I/O should be gracefully aborted by returning a -EIO. http://bugzilla.kernel.org/show_bug.cgi?id=14286Signed-off-by:
Surbhi Palande <surbhi.palande@canonical.com> Signed-off-by:
-
Dmitry Monakhov authored
commit d21cd8f1 upstream (as of v2.6.33-rc2) We have to delay vfs_dq_claim_space() until allocation context destruction. Currently we have following call-trace: ext4_mb_new_blocks() /* task is already holding ac->alloc_semp */ ->ext4_mb_mark_diskspace_used ->vfs_dq_claim_space() /* acquire dqptr_sem here. Possible deadlock */ ->ext4_mb_release_context() /* drop ac->alloc_semp here */ Let's move quota claiming to ext4_da_update_reserve_space() ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.32-rc7 #18 ------------------------------------------------------- write-truncate-/3465 is trying to acquire lock: (&s->s_dquot.dqptr_sem){++++..}, at: [<c025e73b>] dquot_claim_space+0x3b/0x1b0 but task is already holding lock: (&meta_group_info[i]->alloc_sem){++++..}, at: [<c02ce962>] ext4_mb_load_buddy+0xb2/0x370 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&meta_group_info[i]->alloc_sem){++++..}: [<c017d04b>] __lock_acquire+0xd7b/0x1260 [<c017d5ea>] lock_acquire+0xba/0xd0 [<c0527191>] down_read+0x51/0x90 [<c02ce962>] ext4_mb_load_buddy+0xb2/0x370 [<c02d0c1c>] ext4_mb_free_blocks+0x46c/0x870 [<c029c9d3>] ext4_free_blocks+0x73/0x130 [<c02c8cfc>] ext4_ext_truncate+0x76c/0x8d0 [<c02a8087>] ext4_truncate+0x187/0x5e0 [<c01e0f7b>] vmtruncate+0x6b/0x70 [<c022ec02>] inode_setattr+0x62/0x190 [<c02a2d7a>] ext4_setattr+0x25a/0x370 [<c022ee81>] notify_change+0x151/0x340 [<c021349d>] do_truncate+0x6d/0xa0 [<c0221034>] may_open+0x1d4/0x200 [<c022412b>] do_filp_open+0x1eb/0x910 [<c021244d>] do_sys_open+0x6d/0x140 [<c021258e>] sys_open+0x2e/0x40 [<c0103100>] sysenter_do_call+0x12/0x32 -> #2 (&ei->i_data_sem){++++..}: [<c017d04b>] __lock_acquire+0xd7b/0x1260 [<c017d5ea>] lock_acquire+0xba/0xd0 [<c0527191>] down_read+0x51/0x90 [<c02a5787>] ext4_get_blocks+0x47/0x450 [<c02a74c1>] ext4_getblk+0x61/0x1d0 [<c02a7a7f>] ext4_bread+0x1f/0xa0 [<c02bcddc>] ext4_quota_write+0x12c/0x310 [<c0262d23>] qtree_write_dquot+0x93/0x120 [<c0261708>] v2_write_dquot+0x28/0x30 [<c025d3fb>] dquot_commit+0xab/0xf0 [<c02be977>] ext4_write_dquot+0x77/0x90 [<c02be9bf>] ext4_mark_dquot_dirty+0x2f/0x50 [<c025e321>] dquot_alloc_inode+0x101/0x180 [<c029fec2>] ext4_new_inode+0x602/0xf00 [<c02ad789>] ext4_create+0x89/0x150 [<c0221ff2>] vfs_create+0xa2/0xc0 [<c02246e7>] do_filp_open+0x7a7/0x910 [<c021244d>] do_sys_open+0x6d/0x140 [<c021258e>] sys_open+0x2e/0x40 [<c0103100>] sysenter_do_call+0x12/0x32 -> #1 (&sb->s_type->i_mutex_key#7/4){+.+...}: [<c017d04b>] __lock_acquire+0xd7b/0x1260 [<c017d5ea>] lock_acquire+0xba/0xd0 [<c0526505>] mutex_lock_nested+0x65/0x2d0 [<c0260c9d>] vfs_load_quota_inode+0x4bd/0x5a0 [<c02610af>] vfs_quota_on_path+0x5f/0x70 [<c02bc812>] ext4_quota_on+0x112/0x190 [<c026345a>] sys_quotactl+0x44a/0x8a0 [<c0103100>] sysenter_do_call+0x12/0x32 -> #0 (&s->s_dquot.dqptr_sem){++++..}: [<c017d361>] __lock_acquire+0x1091/0x1260 [<c017d5ea>] lock_acquire+0xba/0xd0 [<c0527191>] down_read+0x51/0x90 [<c025e73b>] dquot_claim_space+0x3b/0x1b0 [<c02cb95f>] ext4_mb_mark_diskspace_used+0x36f/0x380 [<c02d210a>] ext4_mb_new_blocks+0x34a/0x530 [<c02c83fb>] ext4_ext_get_blocks+0x122b/0x13c0 [<c02a5966>] ext4_get_blocks+0x226/0x450 [<c02a5ff3>] mpage_da_map_blocks+0xc3/0xaa0 [<c02a6ed6>] ext4_da_writepages+0x506/0x790 [<c01de272>] do_writepages+0x22/0x50 [<c01d766d>] __filemap_fdatawrite_range+0x6d/0x80 [<c01d7b9b>] filemap_flush+0x2b/0x30 [<c02a40ac>] ext4_alloc_da_blocks+0x5c/0x60 [<c029e595>] ext4_release_file+0x75/0xb0 [<c0216b59>] __fput+0xf9/0x210 [<c0216c97>] fput+0x27/0x30 [<c02122dc>] filp_close+0x4c/0x80 [<c014510e>] put_files_struct+0x6e/0xd0 [<c01451b7>] exit_files+0x47/0x60 [<c0146a24>] do_exit+0x144/0x710 [<c0147028>] do_group_exit+0x38/0xa0 [<c0159abc>] get_signal_to_deliver+0x2ac/0x410 [<c0102849>] do_notify_resume+0xb9/0x890 [<c01032d2>] work_notifysig+0x13/0x21 other info that might help us debug this: 3 locks held by write-truncate-/3465: #0: (jbd2_handle){+.+...}, at: [<c02e1f8f>] start_this_handle+0x38f/0x5c0 #1: (&ei->i_data_sem){++++..}, at: [<c02a57f6>] ext4_get_blocks+0xb6/0x450 #2: (&meta_group_info[i]->alloc_sem){++++..}, at: [<c02ce962>] ext4_mb_load_buddy+0xb2/0x370 stack backtrace: Pid: 3465, comm: write-truncate- Not tainted 2.6.32-rc7 #18 Call Trace: [<c0524cb3>] ? printk+0x1d/0x22 [<c017ac9a>] print_circular_bug+0xca/0xd0 [<c017d361>] __lock_acquire+0x1091/0x1260 [<c016bca2>] ? sched_clock_local+0xd2/0x170 [<c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0 [<c017d5ea>] lock_acquire+0xba/0xd0 [<c025e73b>] ? dquot_claim_space+0x3b/0x1b0 [<c0527191>] down_read+0x51/0x90 [<c025e73b>] ? dquot_claim_space+0x3b/0x1b0 [<c025e73b>] dquot_claim_space+0x3b/0x1b0 [<c02cb95f>] ext4_mb_mark_diskspace_used+0x36f/0x380 [<c02d210a>] ext4_mb_new_blocks+0x34a/0x530 [<c02c601d>] ? ext4_ext_find_extent+0x25d/0x280 [<c02c83fb>] ext4_ext_get_blocks+0x122b/0x13c0 [<c016bca2>] ? sched_clock_local+0xd2/0x170 [<c016be60>] ? sched_clock_cpu+0x120/0x160 [<c016beef>] ? cpu_clock+0x4f/0x60 [<c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0 [<c052712c>] ? down_write+0x8c/0xa0 [<c02a5966>] ext4_get_blocks+0x226/0x450 [<c016be60>] ? sched_clock_cpu+0x120/0x160 [<c016beef>] ? cpu_clock+0x4f/0x60 [<c017908b>] ? trace_hardirqs_off+0xb/0x10 [<c02a5ff3>] mpage_da_map_blocks+0xc3/0xaa0 [<c01d69cc>] ? find_get_pages_tag+0x16c/0x180 [<c01d6860>] ? find_get_pages_tag+0x0/0x180 [<c02a73bd>] ? __mpage_da_writepage+0x16d/0x1a0 [<c01dfc4e>] ? pagevec_lookup_tag+0x2e/0x40 [<c01ddf1b>] ? write_cache_pages+0xdb/0x3d0 [<c02a7250>] ? __mpage_da_writepage+0x0/0x1a0 [<c02a6ed6>] ext4_da_writepages+0x506/0x790 [<c016beef>] ? cpu_clock+0x4f/0x60 [<c016bca2>] ? sched_clock_local+0xd2/0x170 [<c016be60>] ? sched_clock_cpu+0x120/0x160 [<c016be60>] ? sched_clock_cpu+0x120/0x160 [<c02a69d0>] ? ext4_da_writepages+0x0/0x790 [<c01de272>] do_writepages+0x22/0x50 [<c01d766d>] __filemap_fdatawrite_range+0x6d/0x80 [<c01d7b9b>] filemap_flush+0x2b/0x30 [<c02a40ac>] ext4_alloc_da_blocks+0x5c/0x60 [<c029e595>] ext4_release_file+0x75/0xb0 [<c0216b59>] __fput+0xf9/0x210 [<c0216c97>] fput+0x27/0x30 [<c02122dc>] filp_close+0x4c/0x80 [<c014510e>] put_files_struct+0x6e/0xd0 [<c01451b7>] exit_files+0x47/0x60 [<c0146a24>] do_exit+0x144/0x710 [<c017b163>] ? lock_release_holdtime+0x33/0x210 [<c0528137>] ? _spin_unlock_irq+0x27/0x30 [<c0147028>] do_group_exit+0x38/0xa0 [<c017babb>] ? trace_hardirqs_on+0xb/0x10 [<c0159abc>] get_signal_to_deliver+0x2ac/0x410 [<c0102849>] do_notify_resume+0xb9/0x890 [<c0178fd0>] ? trace_hardirqs_off_caller+0x20/0xd0 [<c017b163>] ? lock_release_holdtime+0x33/0x210 [<c0165b50>] ? autoremove_wake_function+0x0/0x50 [<c017ba54>] ? trace_hardirqs_on_caller+0x134/0x190 [<c017babb>] ? trace_hardirqs_on+0xb/0x10 [<c0300ba4>] ? security_file_permission+0x14/0x20 [<c0215761>] ? vfs_write+0x131/0x190 [<c0214f50>] ? do_sync_write+0x0/0x120 [<c0103115>] ? sysenter_do_call+0x27/0x32 [<c01032d2>] work_notifysig+0x13/0x21 CC: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Ben Hutchings authored
commit bf988435 upstream. struct ethtool_rxnfc was originally defined in 2.6.27 for the ETHTOOL_{G,S}RXFH command with only the cmd, flow_type and data fields. It was then extended in 2.6.30 to support various additional commands. These commands should have been defined to use a new structure, but it is too late to change that now. Since user-space may still be using the old structure definition for the ETHTOOL_{G,S}RXFH commands, and since they do not need the additional fields, only copy the originally defined fields to and from user-space. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Corey Minyard authored
commit fcc6cb78 upstream. RT Systems has put out bunch of ham radio cables based on the FT232RL chip. Each cable type has a unique PID, this adds one for the Yaesu VX-7 radios. Signed-off-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Oliver Neukum authored
commit 63ab71de upstream. This device needs to be reset when resuming Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
commit 20a12f00 upstream. Super speed is also fast enough to let sisusbvga operate. Therefor expand the checks. Signed-off-by:
-
Paul Mortier authored
commit 47f19c0e upstream. When an attempt is made to read the interface strings of the Artisman Watchdog USB dongle (idVendor:idProduct 04b4:0526) an error is written to the dmesg log (uhci_result_common: failed with status 440000) and the dongle resets itself, resulting in a disconnect/reconnect loop. Adding the dongle to the list of devices in quirks.c, with the same quirk Alan Stern's previous patch for the Saitek Cyborg Gold 3D joystick, stops the device from resetting and allows it to be used with no problems. Signed-off-by:
Paul Mortier <mortier@btinternet.com> Signed-off-by:
-
Dennis Jansen authored
commit 7595931c upstream. usbserial: Add AMOI Skypephone S2 support. This patch adds support for the AMOI Skypephone S2 to the usbserial module. Tested-by:
Dennis Jansen <Dennis.Jansen@web.de> Signed-off-by:
-
Colin Leitner authored
commit 77dbd74e upstream. ftdi_sio: support for Signalyzer tools based on FTDI chips This patch adds support for the Xverve Signalyzers. Signed-off-by:
Colin Leitner <colin.leitner@googlemail.com> Signed-off-by:
-
august huber authored
commit 9d72c81d upstream. Add VID/PID for Sierra Wireless 250U USB dongle to sierra.c Allows use of 3G radio only Signed-off-by:
August Huber <gus@pbx.org> Cc: Elina Pasheva <epasheva@sierrawireless.com> Signed-off-by:
-
Ömer Sezgin Ugurlu authored
commit 646d90e2 upstream. Signed-off-by:
Omer Sezgin Ugurlu <omer.ugurlu@a-kent.com> Signed-off-by:
-
Jon Povey authored
commit b23097b7 upstream. Call put_tty_driver() in cleanup function, to fix Oops when trying to open gadget serial char device after module unload. Signed-off-by:
Jon Povey <jon.povey@racelogic.co.uk> Acked-by:
David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Jon Povey authored
commit 44a0c019 upstream. No longer set low_latency flag as it causes this warning backtrace: WARNING: at kernel/mutex.c:207 __mutex_lock_slowpath+0x6c/0x288() Fix associated locking and wakeups. Signed-off-by:
-
Alan Stern authored
commit 48826626 upstream. This patch (as1403) is a partial reversion of an earlier change (commit 5f677f1d "USB: fix remote wakeup settings during system sleep"). After hearing from a user, I realized that remote wakeup should be enabled during system sleep whenever userspace allows it, and not only if a driver requests it too. Indeed, there could be a device with no driver, that does nothing but generate a wakeup request when the user presses a button. Such a device should be allowed to do its job. The problem fixed by the earlier patch -- device generating a wakeup request for no reason, causing system suspend to abort -- was also addressed by a later patch ("USB: don't enable remote wakeup by default", accepted but not yet merged into mainline). The device won't be able to generate the bogus wakeup requests because it will be disabled for remote wakeup by default. Hence this reversion will not re-introduce any old problems. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Pavel Roskin authored
commit c0087580 upstream. Signed-off-by:
Pavel Roskin <proski@gnu.org> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Stephane Glondu authored
commit 488d3749 upstream. The Hercules Wireless N USB mini (HWNUm-300) uses the RTL8191S chipset and seems to work with this driver. Signed-off-by:
Stephane Glondu <steph@glondu.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Stefano Stabellini authored
commit ff487808 upstream. hpet_disable is called unconditionally on machine reboot if hpet support is compiled in the kernel. hpet_disable only checks if the machine is hpet capable but doesn't make sure that hpet has been initialized. [ tglx: Made it a one liner and removed the redundant hpet_address check ] Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by:
Venkatesh Pallipadi <venki@google.com> LKML-Reference: <alpine.DEB.2.00.1007211726240.22235@kaball-desktop> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Nicolas Pitre authored
commit 0ebe25f9 upstream. From: Bin Yang <bin.yang@marvell.com> Signed-off-by:
Bin Yang <bin.yang@marvell.com> Signed-off-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Catalin Marinas authored
commit 2503a5ec upstream. RealView boards with certain revisions of the L220 cache controller (ARM11* processors only) may have issues (hardware deadlock) with the recent changes to the mb() barrier implementation (DSB followed by an L2 cache sync). The patch redefines the RealView ARM11MPCore mandatory barriers without the outer_sync() call. Tested-by:
Linus Walleij <linus.walleij@stericsson.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 3fea6026 upstream. The Nokia RX51 board code (arch/arm/mach-omap2/board-rx51-peripherals.c) defines a key map for the matrix keypad keyboard. The hardware seems to use all of the 8 rows and 8 columns of the keypad, although not all possible locations are used. The TWL4030 supports keypads with at most 8 rows and 8 columns. Most keys are defined with a row and column number between 0 and 7, except KEY(0xff, 2, KEY_F9), KEY(0xff, 4, KEY_F10), KEY(0xff, 5, KEY_F11), which represent keycodes that should be emitted when entire row is connected to the ground. since the driver handles this case as if we had an extra column in the key matrix. Unfortunately we do not allocate enough space and end up owerwriting some random memory. Reported-and-tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Kamal Mostafa authored
commit 3e1bbc8d upstream. Gigabyte "Spring Peak" notebook indicates wrong chassis-type, tripping up i8042 and breaking the touchpad. Add this model to i8042_dmi_noloop_table[] to resolve. BugLink: https://bugs.launchpad.net/bugs/580664Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Or Gerlitz authored
commit 7a52b34b upstream. Sumeet Lahorani <sumeet.lahorani@oracle.com> reported that the IPoIB child entries are world-writable; however we don't want ordinary users to be able to create and destroy child interfaces, so fix them to be writable only by root. Signed-off-by:
Or Gerlitz <ogerlitz@voltaire.com> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Yinghai Lu authored
commit fd19dce7 upstream. Found one x2apic system kexec loop test failed when CONFIG_NMI_WATCHDOG=y (old) or CONFIG_LOCKUP_DETECTOR=y (current tip) first kernel can kexec second kernel, but second kernel can not kexec third one. it can be duplicated on another system with BIOS preenabled x2apic. First kernel can not kexec second kernel. It turns out, when kernel boot with pre-enabled x2apic, it will not execute disable_local_APIC on shutdown path. when init_apic_mappings() is called in setup_arch, it will skip setting of apic_phys when x2apic_mode is set. ( x2apic_mode is much early check_x2apic()) Then later, disable_local_APIC() will bail out early because !apic_phys. So check !x2apic_mode in x2apic_mode in disable_local_APIC with !apic_phys. another solution could be updating init_apic_mappings() to set apic_phys even for preenabled x2apic system. Actually even for x2apic system, that lapic address is mapped already in early stage. BTW: is there any x2apic preenabled system with apicid of boot cpu > 255? Signed-off-by:
Yinghai Lu <yinghai@kernel.org> LKML-Reference: <4C3EB22B.3000701@kernel.org> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Mark Brown authored
commit 3c070939 upstream. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@slimlogic.co.uk> Signed-off-by:
-
Marek Szyprowski authored
commit 9d51a6b2 upstream. System will crash sooner or later once the memory with the code of the s3c-sdhci.ko module is reused for something else. I really have no idea how the lack of remove function went unnoticed into the mainline code. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Ben Hutchings authored
commit db048b69 upstream. On a 32-bit machine, info.rule_cnt >= 0x40000000 leads to integer overflow and the buffer may be smaller than needed. Since ETHTOOL_GRXCLSRLALL is unprivileged, this can presumably be used for at least denial of service. Signed-off-by:
-
Joakim Tjernlund authored
commit 96fc3a45 upstream. The ds1307 driver misreads the ds1388 registers when checking for 12 or 24 hour mode. Instead of checking the hour register it reads the minute register. Therefore the driver thinks minutes >= 40 has the 12HR bit set and resets the minute register by zeroing the high bits. This results in minutes are reset to 0-9, jumping back in time 40 or 50 minutes. The time jump is also written back to the RTC. Signed-off-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Paul Gortmaker <p_gortmaker@yahoo.com> Signed-off-by:
-
Ilpo Järvinen authored
commit 45e77d31 upstream. It can happen that there are no packets in queue while calling tcp_xmit_retransmit_queue(). tcp_write_queue_head() then returns NULL and that gets deref'ed to get sacked into a local var. There is no work to do if no packets are outstanding so we just exit early. This oops was introduced by 08ebd172 (tcp: remove tp->lost_out guard to make joining diff nicer). Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Reported-by:
Lennart Schulte <lennart.schulte@nets.rwth-aachen.de> Tested-by:
-
Doug Kehn authored
commit 91a72a70 upstream. When configuring DMVPN (GRE + openNHRP) and a GRE remote address is configured a kernel Oops is observed. The obserseved Oops is caused by a NULL header_ops pointer (neigh->dev->header_ops) in neigh_update_hhs() when void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *) = neigh->dev->header_ops->cache_update; is executed. The dev associated with the NULL header_ops is the GRE interface. This patch guards against the possibility that header_ops is NULL. This Oops was first observed in kernel version 2.6.26.8. Signed-off-by:
Doug Kehn <rdkehn@yahoo.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
-
Mikulas Patocka authored
commit 720fc22a upstream. When ide taskfile access is being used (for example with hdparm --security commands) and cfq scheduler is selected, the scheduler crashes on BUG in cfq_put_request. The reason is that the cfq scheduler is tracking counts of read and write requests separately; the ide-taskfile subsystem allocates a read request and then flips the flag to make it a write request. The counters in cfq will mismatch. This patch changes ide-taskfile to allocate the READ or WRITE request as required and don't change the flag later. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit a9ddabc5 upstream. When implementing the test_iqr() method, I forgot that this driver is not an ordinary PCI driver and also needs to support VLB variant of the chip. Moreover, 'hwif->dev' should be NULL, potentially causing oops in pci_read_config_byte(). Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by:
-
Dongdong Deng authored
commit 8cd774ad upstream. The cpm_uart_early_write() function which was used for console poll isn't implemented in the cpm uart driver. Implementing this function both fixes the build when CONFIG_CONSOLE_POLL is set and allows kgdboc to work via the cpm uart. Signed-off-by:
Dongdong Deng <dongdong.deng@windriver.com> Reviewed-by:
Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by:
-
Thomas Gleixner authored
commit 46732475 upstream. The set_type() function can change the chip implementation when the trigger mode changes. That might result in using an non-initialized irq chip when called from __setup_irq() or when called via set_irq_type() on an already enabled irq. The set_irq_type() function should not be called on an enabled irq, but because we forgot to put a check into it, we have a bunch of users which grew the habit of doing that and it never blew up as the function is serialized via desc->lock against all users of desc->chip and they never hit the non-initialized irq chip issue. The easy fix for the __setup_irq() issue would be to move the irq_chip_set_defaults(desc->chip) call after the trigger setting to make sure that a chip change is covered. But as we have already users, which do the type setting after request_irq(), the safe fix for now is to call irq_chip_set_defaults() from __irq_set_trigger() when desc->set_type() changed the irq chip. It needs a deeper analysis whether we should refuse to change the chip on an already enabled irq, but that'd be a large scale change to fix all the existing users. So that's neither stable nor 2.6.35 material. Reported-by:
Esben Haabendal <eha@doredevelopment.dk> Signed-off-by:
-
Alex,Shi authored
commit 3c93717c upstream. Commit e7097159 ("sched: Optimize unused cgroup configuration") introduced an imbalanced scheduling bug. If we do not use CGROUP, function update_h_load won't update h_load. When the system has a large number of tasks far more than logical CPU number, the incorrect cfs_rq[cpu]->h_load value will cause load_balance() to pull too many tasks to the local CPU from the busiest CPU. So the busiest CPU keeps going in a round robin. That will hurt performance. The issue was found originally by a scientific calculation workload that developed by Yanmin. With that commit, the workload performance drops about 40%. CPU before after 00 : 2 : 7 01 : 1 : 7 02 : 11 : 6 03 : 12 : 7 04 : 6 : 6 05 : 11 : 7 06 : 10 : 6 07 : 12 : 7 08 : 11 : 6 09 : 12 : 6 10 : 1 : 6 11 : 1 : 6 12 : 6 : 6 13 : 2 : 6 14 : 2 : 6 15 : 1 : 6 Reviewed-by:
Yanmin zhang <yanmin.zhang@intel.com> Signed-off-by:
Alex Shi <alex.shi@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1276754893.9452.5442.camel@debian> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Will Deacon authored
commit 0d98bb26 upstream. GCC 4.4.1 on ARM has been observed to replace the while loop in sched_avg_update with a call to uldivmod, resulting in the following build failure at link-time: kernel/built-in.o: In function `sched_avg_update': kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' make: *** [.tmp_vmlinux1] Error 1 This patch introduces a fake data hazard to the loop body to prevent the compiler optimising the loop away. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Darrick J. Wong authored
commit d596043d upstream. The x3950 family can have as many as 256 PCI buses in a single system, so change the limits to the maximum. Since there can only be 256 PCI buses in one domain, we no longer need the BUG_ON check. Signed-off-by:
Darrick J. Wong <djwong@us.ibm.com> LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Darrick J. Wong authored
commit 499a00e9 upstream. Newer systems (x3950M2) can have 48 PHBs per chassis and 8 chassis, so bump the limits up and provide an explanation of the requirements for each class. Signed-off-by:
Muli Ben-Yehuda <muli@il.ibm.com> Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com> LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com> [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ] Signed-off-by:
-
Andi Kleen authored
commit 12448293 upstream. This fixes the -Os breaks with gcc 4.5 bug. rdtsc_barrier needs to be force inlined, otherwise user space will jump into kernel space and kill init. This also addresses http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129 I believe. Signed-off-by:
Andi Kleen <ak@linux.intel.com> LKML-Reference: <20100618210859.GA10913@basil.fritz.box> Signed-off-by:
-
Frederic Weisbecker authored
commit 97aa1052 upstream. Initialize the callchain radix tree root correctly. When we walk through the parents, we must stop after the root, but since it wasn't well initialized, its parent pointer was random. Also the number of hits was random because uninitialized, hence it was part of the callchain while the root doesn't contain anything. This fixes segfaults and percentages followed by empty callchains while running: perf report -g flat Reported-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Signed-off-by:
-
