AgeCommit message (Collapse)Author
2011-08-29Linux 3.0.4v3.0.4Greg Kroah-Hartman
2011-08-29Add a personality to report 2.6.x version numbersAndi Kleen
commit be27425dcc516fd08245b047ea57f83b8f6f0903 upstream. I ran into a couple of programs which broke with the new Linux 3.0 version. Some of those were binary only. I tried to use LD_PRELOAD to work around it, but it was quite difficult and in one case impossible because of a mix of 32bit and 64bit executables. For example, all kind of management software from HP doesnt work, unless we pretend to run a 2.6 kernel. $ uname -a Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux $ hpacucli ctrl all show Error: No controllers detected. $ rpm -qf /usr/sbin/hpacucli hpacucli-8.75-12.0 Another notable case is that Python now reports "linux3" from sys.platform(); which in turn can break things that were checking sys.platform() == "linux2": It seems pretty clear to me though it's a bug in the apps that are using '==' instead of .startswith(), but this allows us to unbreak broken programs. This patch adds a UNAME26 personality that makes the kernel report a 2.6.40+x version number instead. The x is the x in 3.x. I know this is somewhat ugly, but I didn't find a better workaround, and compatibility to existing programs is important. Some programs also read /proc/sys/kernel/osrelease. This can be worked around in user space with mount --bind (and a mount namespace) To use: wget gcc -o uname26 uname26.c ./uname26 program Signed-off-by: Andi Kleen <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29igb: Fix lack of flush after register write and before delayCarolyn Wyborny
commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream. Register writes followed by a delay are required to have a flush before the delay in order to commit the values to the register. Without the flush, the code following the delay may not function correctly. Reported-by: Tong Ho <> Reported-by: Guenter Roeck <> Signed-off-by: Carolyn Wyborny <> Tested-by: Aaron Brown <> Signed-off-by: Jeff Kirsher <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29mmc: sdhci: fix retuning timer wrongly deleted in sdhci_tasklet_finishAaron Lu
commit 78869618a886d33d8cdfcb78cf9b245b5250e465 upstream. Currently, the retuning timer for retuning mode 1 will be deleted in function sdhci_tasklet_finish after a mmc request done, which will make retuning timing never trigger again. This patch fixed this problem. Signed-off-by: Aaron Lu <> Reviewed-by: Philip Rakity <> Signed-off-by: Chris Ball <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29rt2x00: fix order of entry flags modificationStanislaw Gruszka
commit df71c9cfceea801e7e26e2c74241758ef9c042e5 upstream. In rt2800usb_work_txdone we check flags in order: - ENTRY_OWNER_DEVICE_DATA - ENTRY_DATA_STATUS_PENDING - ENTRY_DATA_IO_FAILED Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid processing entries in _txdone with wrong flags or skip processing ready entries. Reported-by: Justin Piszcz <> Signed-off-by: Stanislaw Gruszka <> Acked-by: Ivo van Doorn <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29fuse: check size of FUSE_NOTIFY_INVAL_ENTRY messageMiklos Szeredi
commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream. FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the message processing could overrun and result in a "kernel BUG at fs/fuse/dev.c:629!" Reported-by: Han-Wen Nienhuys <> Signed-off-by: Miklos Szeredi <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1100 ↵Thomas Reim
HDMI-A Connector commit f2b60717e692550bf753a5d64a5b69ea430fc832 upstream. Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data to i2c bus for a HDMI connector that is not implemented/existent on the notebook's board. Fix by applying extented DDC probing for this connector. Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook BugLink: Signed-off-by: Thomas Reim <> Acked-by: Chris Routh <> Reviewed-by: Alex Deucher <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29drm/ttm: fix ttm_bo_add_ttm(user) failure pathMarcin Slusarz
commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream. ttm_tt_destroy kfrees passed object, so we need to nullify a reference to it. Signed-off-by: Marcin Slusarz <> Reviewed-by: Thomas Hellstrom <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29x86, UV: Remove UV delay in starting slave cpusJack Steiner
commit 05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream. Delete the 10 msec delay between the INIT and SIPI when starting slave cpus. I can find no requirement for this delay. BIOS also has similar code sequences without the delay. Removing the delay reduces boot time by 40 sec. Every bit helps. Signed-off-by: Jack Steiner <> Link: Signed-off-by: Ingo Molnar <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29x86-32, vdso: On system call restart after SYSENTER, use int $0x80H. Peter Anvin
commit 7ca0758cdb7c241cb4e0490a8d95f0eb5b861daf upstream. When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle the arguments to match the int $0x80 calling convention. This was probably a design mistake, but it's what it is now. This causes errors if the system call as to be restarted. For SYSENTER, we have to invoke the instruction from the vdso as the return address is hardcoded. Accordingly, we can simply replace the jump in the vdso with an int $0x80 instruction and use the slower entry point for a post-restart. Suggested-by: Linus Torvalds <> Signed-off-by: H. Peter Anvin <> Link: Signed-off-by: Greg Kroah-Hartman <>
2011-08-29x86, olpc: Wait for last byte of EC command to be acceptedPaul Fox
commit a3ea14df0e383f44dcb2e61badb71180dbffe526 upstream. When executing EC commands, only waiting when there are still more bytes to write is usually fine. However, if the system suspends very quickly after a call to olpc_ec_cmd(), the last data byte may not yet be transferred to the EC, and the command will not complete. This solves a bug where the SCI wakeup mask was not correctly written when going into suspend. It means that sometimes, on XO-1.5 (but not XO-1), the devices that were marked as wakeup sources can't wake up the system. e.g. you ask for wifi wakeups, suspend, but then incoming wifi frames don't wake up the system as they should. Signed-off-by: Paul Fox <> Signed-off-by: Daniel Drake <> Acked-by: Andres Salomon <> Signed-off-by: Ingo Molnar <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29xen: Do not enable PV IPIs when vector callback not presentStefano Stabellini
commit 3c05c4bed4ccce3f22f6d7899b308faae24ad198 upstream. Fix regression for HVM case on older (<4.1.1) hypervisors caused by commit 99bbb3a84a99cd04ab16b998b20f01a72cfa9f4f Author: Stefano Stabellini <> Date: Thu Dec 2 17:55:10 2010 +0000 xen: PV on HVM: support PV spinlocks and IPIs This change replaced the SMP operations with event based handlers without taking into account that this only works when the hypervisor supports callback vectors. This causes unexplainable hangs early on boot for HVM guests with more than one CPU. BugLink: Signed-off-by: Stefan Bader <> Signed-off-by: Stefano Stabellini <> Tested-and-Reported-by: Stefan Bader <> Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29xen/x86: replace order-based range checking of M2P table by linear oneJan Beulich
commit ccbcdf7cf1b5f6c6db30d84095b9c6c53043af55 upstream. The order-based approach is not only less efficient (requiring a shift and a compare, typical generated code looking like this mov eax, [machine_to_phys_order] mov ecx, eax shr ebx, cl test ebx, ebx jnz ... whereas a direct check requires just a compare, like in cmp ebx, [machine_to_phys_nr] jae ... ), but also slightly dangerous in the 32-on-64 case - the element address calculation can wrap if the next power of two boundary is sufficiently far away from the actual upper limit of the table, and hence can result in user space addresses being accessed (with it being unknown what may actually be mapped there). Additionally, the elimination of the mistaken use of fls() here (should have been __fls()) fixes a latent issue on x86-64 that would trigger if the code was run on a system with memory extending beyond the 44-bit boundary. Signed-off-by: Jan Beulich <> [v1: Based on Jeremy's feedback] Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29xen-blkfront: Fix one off warning about name clashStefan Bader
commit 89153b5cae9f40c224a5d321665a97bf14220c2c upstream. Avoid telling users to use xvde and onwards when using xvde. Acked-by: Stefano Stabellini <> Signed-off-by: Stefan Bader <> Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29xen-blkfront: Drop name and minor adjustments for emulated scsi devicesStefan Bader
commit 196cfe2ae8fcdc03b3c7d627e7dfe8c0ce7229f9 upstream. These were intended to avoid the namespace clash when representing emulated IDE and SCSI devices. However that seems to confuse users more than expected (a disk defined as sda becomes xvde). So for now go back to the scheme which does no adjustments. This will break when mixing IDE and SCSI names in the configuration of guests but should be by now expected. Acked-by: Stefano Stabellini <> Signed-off-by: Stefan Bader <> Signed-off-by: Konrad Rzeszutek Wilk <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ext4: fix nomblk_io_submit option so it correctly converts uninit blocksTheodore Ts'o
commit 9dd75f1f1a02d656a11a7b9b9e6c2759b9c1e946 upstream. Bug discovered by Jan Kara: Finally, commit 1449032be17abb69116dbc393f67ceb8bd034f92 returned back the old IO submission code but apparently it forgot to return the old handling of uninitialized buffers so we unconditionnaly call block_write_full_page() without specifying end_io function. So AFAICS we never convert unwritten extents to written in some cases. For example when I mount the fs as: mount -t ext4 -o nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600); char buf[1024]; memset(buf, 'a', sizeof(buf)); fallocate(fd, 0, 0, 16384); write(fd, buf, sizeof(buf)); I get a file full of zeros (after remounting the filesystem so that pagecache is dropped) instead of seeing the first KB contain 'a's. Signed-off-by: "Theodore Ts'o" <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ext4: Resolve the hang of direct i/o read in handling EXT4_IO_END_UNWRITTEN.Tao Ma
commit 32c80b32c053dc52712dedac5e4d0aa7c93fc353 upstream. EXT4_IO_END_UNWRITTEN flag set and the increase of i_aiodio_unwritten should be done simultaneously since ext4_end_io_nolock always clear the flag and decrease the counter in the same time. We don't increase i_aiodio_unwritten when setting EXT4_IO_END_UNWRITTEN so it will go nagative and causes some process to wait forever. Part of the patch came from Eric in his e-mail, but it doesn't fix the problem met by Michael actually. Reported-and-Tested-by: Michael Tokarev<> Signed-off-by: Eric Sandeen <> Signed-off-by: Tao Ma <> Signed-off-by: "Theodore Ts'o" <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ext4: call ext4_ioend_wait and ext4_flush_completed_IO in ext4_evict_inodeJiaying Zhang
commit 2581fdc810889fdea97689cb62481201d579c796 upstream. Flush inode's i_completed_io_list before calling ext4_io_wait to prevent the following deadlock scenario: A page fault happens while some process is writing inode A. During page fault, shrink_icache_memory is called that in turn evicts another inode B. Inode B has some pending io_end work so it calls ext4_ioend_wait() that waits for inode B's i_ioend_count to become zero. However, inode B's ioend work was queued behind some of inode A's ioend work on the same cpu's ext4-dio-unwritten workqueue. As the ext4-dio-unwritten thread on that cpu is processing inode A's ioend work, it tries to grab inode A's i_mutex lock. Since the i_mutex lock of inode A is still hold before the page fault happened, we enter a deadlock. Also moves ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode() to ext4_evict_inode(). During inode deleteion, ext4_evict_inode() is called before ext4_destroy_inode() and in ext4_evict_inode(), we may call ext4_truncate() without holding i_mutex lock. As a result, there is a race between flush_completed_IO that is called from ext4_ext_truncate() and ext4_end_io_work, which may cause corruption on an io_end structure. This change moves ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode() to ext4_evict_inode() to resolve the race between ext4_truncate() and ext4_end_io_work during inode deletion. Signed-off-by: Jiaying Zhang <> Signed-off-by: "Theodore Ts'o" <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ext4: Fix ext4_should_writeback_data() for no-journal modeCurt Wohlgemuth
commit 441c850857148935babe000fc2ba1455fe54a6a9 upstream. ext4_should_writeback_data() had an incorrect sequence of tests to determine if it should return 0 or 1: in particular, even in no-journal mode, 0 was being returned for a non-regular-file inode. This meant that, in non-journal mode, we would use ext4_journalled_aops for directories, symlinks, and other non-regular files. However, calling journalled aop callbacks when there is no valid handle, can cause problems. This would cause a kernel crash with Jan Kara's commit 2d859db3e4 ("ext4: fix data corruption in inodes with journalled data"), because we now dereference 'handle' in ext4_journalled_write_end(). I also added BUG_ONs to check for a valid handle in the obviously journal-only aops callbacks. I tested this running xfstests with a scratch device in these modes: - no-journal - data=ordered - data=writeback - data=journal All work fine; the data=journal run has many failures and a crash in xfstests 074, but this is no different from a vanilla kernel. Signed-off-by: Curt Wohlgemuth <> Signed-off-by: "Theodore Ts'o" <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ALSA: ac97: Add HP Compaq dc5100 SFF(PT003AW) to Headphone Jack Sense whitelistDaniel T Chen
commit eade7b281c9fc18401b989c77d5e5e660b25a3b7 upstream. BugLink: The original reporter needs 'Headphone Jack Sense' enabled to have audible audio, so add his PCI SSID to the whitelist. Reported-and-tested-by: Muhammad Khurram Khan Signed-off-by: Daniel T Chen <> Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ALSA: snd_usb_caiaq: track submitted output urbsDaniel Mack
commit da6094ea7d3c2295473d8f5134279307255d6ebf upstream. The snd_usb_caiaq driver currently assumes that output urbs are serviced in time and doesn't track when and whether they are given back by the USB core. That usually works fine, but due to temporary limitations of the XHCI stack, we faced that urbs were submitted more than once with this approach. As it's no good practice to fire and forget urbs anyway, this patch introduces a proper bit mask to track which requests have been submitted and given back. That alone however doesn't make the driver work in case the host controller is broken and doesn't give back urbs at all, and the output stream will stop once all pre-allocated output urbs are consumed. But it does prevent crashes of the controller stack in such cases. See for more details. Signed-off-by: Daniel Mack <> Reported-and-tested-by: Matej Laitl <> Cc: Sarah Sharp <> Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29ALSA: usb-audio - Fix missing mixer dB informationTakashi Iwai
commit 38b65190c6ab0be8ce7cff69e734ca5b5e7fa309 upstream. The recent fix for testing dB range at the mixer creation time seems to cause regressions in some devices. In such devices, reading the dB info at probing time gives an error, thus both dBmin and dBmax are still zero, and TLV flag isn't set although the later read of dB info succeeds. This patch adds a workaround for such a case by assuming that the later read will succeed. In future, a similar test should be performed in a case where a wrong dB range is seen even in the later read. Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29Btrfs: fix an oops of log replayliubo
commit 34f3e4f23ca3d259fe078f62a128d97ca83508ef upstream. When btrfs recovers from a crash, it may hit the oops below: ------------[ cut here ]------------ kernel BUG at fs/btrfs/inode.c:4580! [...] RIP: 0010:[<ffffffffa03df251>] [<ffffffffa03df251>] btrfs_add_link+0x161/0x1c0 [btrfs] [...] Call Trace: [<ffffffffa03e7b31>] ? btrfs_inode_ref_index+0x31/0x80 [btrfs] [<ffffffffa04054e9>] add_inode_ref+0x319/0x3f0 [btrfs] [<ffffffffa0407087>] replay_one_buffer+0x2c7/0x390 [btrfs] [<ffffffffa040444a>] walk_down_log_tree+0x32a/0x480 [btrfs] [<ffffffffa0404695>] walk_log_tree+0xf5/0x240 [btrfs] [<ffffffffa0406cc0>] btrfs_recover_log_trees+0x250/0x350 [btrfs] [<ffffffffa0406dc0>] ? btrfs_recover_log_trees+0x350/0x350 [btrfs] [<ffffffffa03d18b2>] open_ctree+0x1442/0x17d0 [btrfs] [...] This comes from that while replaying an inode ref item, we forget to check those old conflicting DIR_ITEM and DIR_INDEX items in fs/file tree, then we will come to conflict corners which lead to BUG_ON(). Signed-off-by: Liu Bo <> Tested-by: Andy Lutomirski <> Signed-off-by: Chris Mason <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29loop: fix deadlock when sysfs and LOOP_CLR_FD race against each otherKay Sievers
commit 05eb0f252b04aa94ace0794f73d56c6a02351d80 upstream. LOOP_CLR_FD takes lo->lo_ctl_mutex and tries to remove the loop sysfs files. Sysfs calls show() and waits for lo->lo_ctl_mutex. LOOP_CLR_FD waits for show() to finish to remove the sysfs file. cat /sys/class/block/loop0/loop/backing_file mutex_lock_nested+0x176/0x350 ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop] ? loop_attr_do_show_backing_file+0x2f/0xd0 [loop] loop_attr_do_show_backing_file+0x2f/0xd0 [loop] dev_attr_show+0x1b/0x60 ? sysfs_read_file+0x86/0x1a0 ? __get_free_pages+0x12/0x50 sysfs_read_file+0xaf/0x1a0 ioctl(LOOP_CLR_FD): wait_for_common+0x12c/0x180 ? try_to_wake_up+0x2a0/0x2a0 wait_for_completion+0x18/0x20 sysfs_deactivate+0x178/0x180 ? sysfs_addrm_finish+0x43/0x70 ? sysfs_addrm_start+0x1d/0x20 sysfs_addrm_finish+0x43/0x70 sysfs_hash_and_remove+0x85/0xa0 sysfs_remove_group+0x59/0x100 loop_clr_fd+0x1dc/0x3f0 [loop] lo_ioctl+0x223/0x7a0 [loop] Instead of taking the lo_ctl_mutex from sysfs code, take the inner lo->lo_lock, to protect the access to the backing_file data. Thanks to Tejun for help debugging and finding a solution. Cc: Milan Broz <> Cc: Tejun Heo <> Signed-off-by: Kay Sievers <> Signed-off-by: Jens Axboe <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29Btrfs: detect wether a device supports discardJosef Bacik
commit d5e2003c2bcda93a8f2e668eb4642d70c9c38301 upstream. We have a problem where if a user specifies discard but doesn't actually support it we will return EOPNOTSUPP from btrfs_discard_extent. This is a problem because this gets called (in a fashion) from the tree log recovery code, which has a nice little BUG_ON(ret) after it, which causes us to fail the tree log replay. So instead detect wether our devices support discard when we're adding them and then don't issue discards if we know that the device doesn't support it. And just for good measure set ret = 0 in btrfs_issue_discard just in case we still get EOPNOTSUPP so we don't screw anybody up like this again. Thanks, Signed-off-by: Josef Bacik <> Signed-off-by: Chris Mason <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29x86, mtrr: lock stop machine during MTRR rendezvous sequenceSuresh Siddha
commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 upstream. MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially happen in parallel with another system wide rendezvous using stop_machine(). This can lead to deadlock (The order in which works are queued can be different on different cpu's. Some cpu's will be running the first rendezvous handler and others will be running the second rendezvous handler. Each set waiting for the other set to join for the system wide rendezvous, leading to a deadlock). MTRR rendezvous sequence is not implemented using stop_machine() as this gets called both from the process context aswell as the cpu online paths (where the cpu has not come online and the interrupts are disabled etc). stop_machine() works with only online cpus. For now, take the stop_machine mutex in the MTRR rendezvous sequence that gets called from an online cpu (here we are in the process context and can potentially sleep while taking the mutex). And the MTRR rendezvous that gets triggered during cpu online doesn't need to take this stop_machine lock (as the stop_machine() already ensures that there is no cpu hotplug going on in parallel by doing get_online_cpus()) TBD: Pursue a cleaner solution of extending the stop_machine() infrastructure to handle the case where the calling cpu is still not online and use this for MTRR rendezvous sequence. fixes: Reported-by: Vadim Kotelnikov <> Signed-off-by: Suresh Siddha <> Link: Signed-off-by: H. Peter Anvin <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29NFSv4.1: Return NFS4ERR_BADSESSION to callbacks during session resetsTrond Myklebust
commit 910ac68a2b80c7de95bc8488734067b1bb15d583 upstream. If the client is in the process of resetting the session when it receives a callback, then returning NFS4ERR_DELAY may cause a deadlock with the DESTROY_SESSION call. Basically, if the client returns NFS4ERR_DELAY in response to the CB_SEQUENCE call, then the server is entitled to believe that the client is busy because it is already processing that call. In that case, the server is perfectly entitled to respond with a NFS4ERR_BACK_CHAN_BUSY to any DESTROY_SESSION call. Fix this by having the client reply with a NFS4ERR_BADSESSION in response to the callback if it is resetting the session. Signed-off-by: Trond Myklebust <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29NFSv4.1: Fix the callback 'highest_used_slotid' behaviourTrond Myklebust
commit 55a673990ec04cf63005318bcf08c2b0046e5778 upstream. Currently, there is no guarantee that we will call nfs4_cb_take_slot() even though nfs4_callback_compound() will consistently call nfs4_cb_free_slot() provided the cb_process_state has set the 'clp' field. The result is that we can trigger the BUG_ON() upon the next call to nfs4_cb_take_slot(). This patch fixes the above problem by using the slot id that was taken in the CB_SEQUENCE operation as a flag for whether or not we need to call nfs4_cb_free_slot(). It also fixes an atomicity problem: we need to set tbl->highest_used_slotid atomically with the check for NFS4_SESSION_DRAINING, otherwise we end up racing with the various tests in nfs4_begin_drain_session(). Signed-off-by: Trond Myklebust <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29pnfs-obj: Bug when we are running out of bioBoaz Harrosh
commit 20618b21da0796115e81906d24ff1601552701b7 upstream. When we have a situation that the number of pages we want to encode is bigger then the size of the bio. (Which can currently happen only when all IO is going to a single device .e.g group_width==1) then the IO is submitted short and we report back only the amount of bytes we actually wrote/read and all is fine. BUT ... There was a bug that the current length counter was advanced before the fail to add the extra page, and we come to a situation that the CDB length was one-page longer then the actual bio size, which is of course rejected by the osd-target. While here also fix the bio size calculation, in the case that we received more then one group of devices. Signed-off-by: Boaz Harrosh <> Signed-off-by: Trond Myklebust <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29pnfs-obj: Fix the comp_index != 0 caseBoaz Harrosh
commit 9af7db3228acc286c50e3a0f054ec982efdbc6c6 upstream. There were bugs in the case of partial layout where olo_comp_index is not zero. This used to work and was tested but one of the later cleanup SQUASHMEs broke it and was not tested since. Also add a dprint that specify those received layout parameters. Everything else was already printed. Signed-off-by: Boaz Harrosh <> Signed-off-by: Trond Myklebust <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS messageLen Brown
commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 upstream. Fix the printk_once() so that it actually prints (didn't print before due to a stray comma.) [ hpa: changed to an incremental patch and adjusted the description accordingly. ] Signed-off-by: Len Brown <> Link: Signed-off-by: H. Peter Anvin <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29possible memory corruption on mountSteve French
commit 13589c437daf4c8e429b3236c0b923de1c9420d8 upstream. CIFS cleanup_volume_info_contents() looks like having a memory corruption problem. When UNCip is set to "&vol->UNC[2]" in cifs_parse_mount_options(), it should not be kfree()-ed in cleanup_volume_info_contents(). Introduced in commit b946845a9dc523c759cae2b6a0f6827486c3221a Signed-off-by: J.R. Okajima <> Reviewed-by: Jeff Layton <> Signed-off-by: Steve French <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29i7core_edac: fixed typo in error count calculationMathias Krause
commit 8cf2d2399ab60842f55598bc1b00fd15503b9950 upstream. Based on a patch from the PaX Team, found during a clang analysis pass. Signed-off-by: Mathias Krause <> Acked-by: Mauro Carvalho Chehab <> Cc: PaX Team <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29befs: Validate length of long symbolic links.Timo Warns
commit 338d0f0a6fbc82407864606f5b64b75aeb3c70f2 upstream. Signed-off-by: Timo Warns <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29cifs: demote cERROR in build_path_from_dentry to cFYIJeff Layton
commit fa71f447065f676157ba6a2c121ba419818fc559 upstream. Running the cthon tests on a recent kernel caused this message to pop occasionally: CIFS VFS: did not end path lookup where expected namelen is 0 Some added debugging showed that namelen and dfsplen were both 0 when this occurred. That means that the read_seqretry returned true. Assuming that the comment inside the if statement is true, this should be harmless and just means that we raced with a rename. If that is the case, then there's no need for alarm and we can demote this to cFYI. While we're at it, print the dfsplen too so that we can see what happened here if the message pops during debugging. Cc: Al Viro <> Signed-off-by: Jeff Layton <> Signed-off-by: Steve French <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-29genirq: Fix wrong bit
commit 1dd75f91ae713049eb6baaa640078f3a6549e522 upstream. (!msk & 0x01) should be !(msk & 0x01) Signed-off-by: Jonghwan Choi <> Link: Signed-off-by: Thomas Gleixner <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17Linux 3.0.3v3.0.3Greg Kroah-Hartman
2011-08-17perf tools: do not look at ./config for configurationJonathan Nieder
commit aba8d056078e47350d85b06a9cabd5afcc4b72ea upstream. In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for configuration in the file ./config, imitating git which looks at $GIT_DIR/config. If ./config is not a perf configuration file, it fails, or worse, treats it as a configuration file and changes behavior in some unexpected way. "config" is not an unusual name for a file to be lying around and perf does not have a private directory dedicated for its own use, so let's just stop looking for configuration in the cwd. Callers needing context-sensitive configuration can use the PERF_CONFIG environment variable. Requested-by: Christian Ohm <> Cc: Cc: Ben Hutchings <> Cc: Christian Ohm <> Cc: Ingo Molnar <> Cc: Paul Mackerras <> Cc: Peter Zijlstra <> Link: Signed-off-by: Jonathan Nieder <> Signed-off-by: Arnaldo Carvalho de Melo <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17drm/radeon/kms: don't try to be smart in the hpd handlerAlex Deucher
commit d5811e8731213f80c80d89e980505052f16aca1c upstream. Attempting to try and turn off disconnected display hw in the hotput handler lead to more problems than it helped. For now just register an event and only attempt the do something interesting with DP. Other connectors are just too problematic: - Some systems have an HPD pin assigned to LVDS, but it's rarely if ever connected properly and we don't really care about hpd events on LVDS anyway since it's always connected. - The HPD pin is wired up correctly for eDP, but we don't really have to do anything since the events since it's always connected. - Some HPD pins fire more than once when you connect/disconnect - etc. Fixes: Signed-off-by: Alex Deucher <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17drm/radeon/kms: fix regression is handling >2 heads on cedar/caicosAlex Deucher
commit 33ae1827d6c3c79c5957536ec29d5a8780623147 upstream. Need to add support for 4 crtcs when setting the possible crtcs for the encoders. Signed-off-by: Alex Deucher <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17drm/radeon/kms: don't enable connectors that are off in the hotplug handlerAlex Deucher
commit 73104b5cfe3067d68f2c2de3f3d4d4964c55873e upstream. If we get a hotplug event on an connector that is off, don't attempt to turn it on or off, it should already be off. Fixes: Signed-off-by: Alex Deucher <> Signed-off-by: Dave Airlie <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17lguest: allow booting guest with CONFIG_RELOCATABLE=yRusty Russell
commit e22a539824e8ddb82c87b4f415165ede82e6ab56 upstream. The CONFIG_RELOCATABLE code tries to align the unpack destination to the value of 'kernel_alignment' in the setup_hdr. If that's 0, it tries to unpack to address 0, which in fact causes the gunzip code to call 'error("Out of memory while allocating output buffer")'. The bootloader (ie. the lguest Launcher in this case) should be doing setting this field; the normal bzImage is 16M, we can use the same. Reported-by: Stefanos Geraggelos <> Signed-off-by: Rusty Russell <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17mm: fix wrong vmap address calculations with odd NR_CPUS valuesClemens Ladisch
commit f982f91516fa4cfd9d20518833cd04ad714585be upstream. Commit db64fe02258f ("mm: rewrite vmap layer") introduced code that does address calculations under the assumption that VMAP_BLOCK_SIZE is a power of two. However, this might not be true if CONFIG_NR_CPUS is not set to a power of two. Wrong vmap_block index/offset values could lead to memory corruption. However, this has never been observed in practice (or never been diagnosed correctly); what caught this was the BUG_ON in vb_alloc() that checks for inconsistent vmap_block indices. To fix this, ensure that VMAP_BLOCK_SIZE always is a power of two. BugLink: Reported-by: Pavel Kysilka <> Reported-by: Matias A. Fonzo <> Signed-off-by: Clemens Ladisch <> Signed-off-by: Stefan Richter <> Cc: Nick Piggin <> Cc: Jeremy Fitzhardinge <> Cc: Krzysztof Helt <> Cc: Andrew Morton <> Signed-off-by: Linus Torvalds <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17ath5k: fix error handling in ath5k_beacon_sendBob Copeland
commit bdc71bc59231f5542af13b5061b9ab124d093050 upstream. This cleans up error handling for the beacon in case of dma mapping failure. We need to free the skb when dma mapping fails instead of nulling and leaking the pointer, and we should bail out to avoid giving the hardware the bad descriptor. Finally, we need to perform the null check after trying to update the beacon, or else beacons will never be sent after a single mapping failure. Signed-off-by: Bob Copeland <> Signed-off-by: John W. Linville <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17ASoC: Tegra: wm8903 machine driver: Allow re-insertion of moduleStephen Warren
commit 29591ed4ac6fe00e3ff23b5be0cdc7016ef9c47e upstream. Two issues were preventing module snd-soc-tegra-wm8903.ko from being removed and re-inserted: a) The speaker-enable GPIO is hosted by the WM8903 chip. This GPIO must be freed before snd_soc_unregister_card() is called, because that triggers wm8903.c:wm8903_remove(), which calls gpiochip_remove(), which then fails if any of the GPIOs are in use. To solve this, free all GPIOs first, so the code doesn't care where they come from. b) We need to call snd_soc_jack_free_gpios() to match the call to snd_soc_jack_add_gpios() during initialization. Without this, the call to snd_soc_jack_add_gpios() fails during any subsequent modprobe and initialization, since the GPIO and IRQ are already registered. In turn, this causes the headphone state not to be monitored, so the headphone is assumed not to be plugged in, and the audio path to it is never enabled. Signed-off-by: Stephen Warren <> Signed-off-by: Mark Brown <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17ASoC: Tegra: tegra_pcm_deallocate_dma_buffer: Don't OOPSStephen Warren
commit a96edd59b2bc88b3d1ea47e0ba48076d65db9302 upstream. Not all PCM devices have all sub-streams. Specifically, the SPDIF driver only supports playback and hence has no capture substream. Check whether a substream exists before dereferencing it, when de-allocating DMA buffers in tegra_pcm_deallocate_dma_buffer. Signed-off-by: Stephen Warren <> Acked-by: Liam Girdwood <> Signed-off-by: Mark Brown <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17ASoC: Fix binding of WM8750 on JiveMark Brown
commit 6678050442e90a4e9511a9ed14b9bdfc5e393323 upstream. The I2C address is misformatted and would never match. Signed-off-by: Mark Brown <> Acked-by: Liam Girdwood <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17ALSA: snd-usb-caiaq: Correct offset fields of outbound iso_frame_descDaniel Mack
commit 15439bde3af7ff88459ea2b5520b77312e958df2 upstream. This fixes faulty outbount packets in case the inbound packets received from the hardware are fragmented and contain bogus input iso frames. The bug has been there for ages, but for some strange reasons, it was only triggered by newer machines in 64bit mode. Signed-off-by: Daniel Mack <> Reported-and-tested-by: William Light <> Reported-by: Pedro Ribeiro <> Signed-off-by: Takashi Iwai <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17hwmon: (ibmaem) add missing kfreeJulia Lawall
commit 66a89b2164e2d30661edbd1953eacf0594d8203a upstream. rs_resp is dynamically allocated in aem_read_sensor(), so it should be freed before exiting in every case. This collects the kfree and the return at the end of the function. Signed-off-by: Julia Lawall <> Signed-off-by: Guenter Roeck <> Signed-off-by: Greg Kroah-Hartman <>
2011-08-17atm: br2864: sent packets truncated in VC routed modeChas Williams
commit a08af810cdc29d2ca930e8a869d3d01744c392d8 upstream. Reported-by: Pascal Hambourg <> Signed-off-by: Chas Williams <> Signed-off-by: David S. Miller <> Signed-off-by: Greg Kroah-Hartman <>