- 29 Aug, 2011 14 commits
-
-
liubo authored
commit 34f3e4f2 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 <liubo2009@cn.fujitsu.com> Tested-by:
Andy Lutomirski <luto@mit.edu> Signed-off-by:
Chris Mason <chris.mason@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kay Sievers authored
commit 05eb0f25 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 <mbroz@redhat.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Josef Bacik authored
commit d5e2003c 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 <josef@redhat.com> Signed-off-by:
-
Suresh Siddha authored
commit 6d3321e8 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: https://bugzilla.novell.com/show_bug.cgi?id=672008Reported-by:
Vadim Kotelnikov <vadimuzzz@inbox.ru> Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Trond Myklebust authored
commit 910ac68a 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 <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit 55a67399 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:
-
Boaz Harrosh authored
commit 20618b21 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 <bharrosh@panasas.com> Signed-off-by:
-
Boaz Harrosh authored
commit 9af7db32 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:
-
Len Brown authored
commit 17edf2d7 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 <len.brown@intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980Signed-off-by:
-
Steve French authored
commit 13589c43 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 b946845aSigned-off-by:
J.R. Okajima <hooanon05@yahoo.co.jp> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Mathias Krause authored
commit 8cf2d239 upstream. Based on a patch from the PaX Team, found during a clang analysis pass. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Acked-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Cc: PaX Team <pageexec@freemail.hu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Timo Warns authored
commit 338d0f0a upstream. Signed-off-by:
Timo Warns <warns@pre-sense.de> Signed-off-by:
-
Jeff Layton authored
commit fa71f447 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 <viro@ZenIV.linux.org.uk> Signed-off-by:
-
jhbird.choi@samsung.com authored
commit 1dd75f91 upstream. (!msk & 0x01) should be !(msk & 0x01) Signed-off-by:
Jonghwan Choi <jhbird.choi@samsung.com> Link: http://lkml.kernel.org/r/1311229754-6003-1-git-send-email-jhbird.choi@samsung.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- 17 Aug, 2011 26 commits
-
-
Greg Kroah-Hartman authored
-
Jonathan Nieder authored
commit aba8d056 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 <chr.ohm@gmx.net> Cc: 632923@bugs.debian.org Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Christian Ohm <chr.ohm@gmx.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/20110805165838.GA7237@elie.gateway.2wire.netSigned-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit d5811e87 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: https://bugs.freedesktop.org/show_bug.cgi?id=39882Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 33ae1827 upstream. Need to add support for 4 crtcs when setting the possible crtcs for the encoders. Signed-off-by:
-
Alex Deucher authored
commit 73104b5c 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: https://bugzilla.redhat.com/show_bug.cgi?id=728228Signed-off-by:
-
Rusty Russell authored
commit e22a5398 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 <sgerag@cslab.ece.ntua.gr> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Clemens Ladisch authored
commit f982f915 upstream. Commit db64fe02 ("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: https://bugzilla.kernel.org/show_bug.cgi?id=31572Reported-by:
Pavel Kysilka <goldenfish@linuxsoft.cz> Reported-by:
Matias A. Fonzo <selk@dragora.org> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Nick Piggin <npiggin@suse.de> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Bob Copeland authored
commit bdc71bc5 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 <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Stephen Warren authored
commit 29591ed4 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 <swarren@nvidia.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Stephen Warren authored
commit a96edd59 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:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Mark Brown authored
commit 66780504 upstream. The I2C address is misformatted and would never match. Signed-off-by:
-
Daniel Mack authored
commit 15439bde 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 <zonque@gmail.com> Reported-and-tested-by:
William Light <wrl@illest.net> Reported-by:
Pedro Ribeiro <pedrib@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Julia Lawall authored
commit 66a89b21 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 <julia@diku.dk> Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by:
-
Chas Williams authored
commit a08af810 upstream. Reported-by:
Pascal Hambourg <pascal@plouf.fr.eu.org> Signed-off-by:
Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Andrew Bird authored
commit 35e9e21f upstream. This patch adds the product ID of Huawei's Vodafone K4511 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by:
Andrew Bird <ajb@spheresystems.co.uk> Signed-off-by:
-
Andrew Bird authored
commit 0930bb46 upstream. This patch adds the product ID of Huawei's Vodafone K4510 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by:
-
Andrew Bird authored
commit e2949080 upstream. This patch adds the product ID of Huawei's Vodafone K3771 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by:
-
Andrew Bird authored
commit 07b21fd8 upstream. This patch adds the product ID of Huawei's Vodafone K3770 mobile broadband modem to option.c. This is necessary so that the driver gets loaded on demand without the intervention of usb_modeswitch. This has the benefit of it becoming available faster and also ensures that the option driver is not bound to a network interface that should be claimed by cdc_ether. Signed-off-by:
-
Vijay Chavan authored
commit e4685617 upstream. A new device ID pair is added for Qualcomm Modem present in Sagemcom's HiLo3G module. Signed-off-by:
Vijay Chavan <VijayChavan007@gmail.com> Signed-off-by:
-
Nick Bowler authored
commit a871e4f5 upstream. Connecting the V2M to a Linux host results in a constant stream of errors spammed to the console, all of the form sd 1:0:0:0: ioctl_internal_command return code = 8070000 : Sense Key : 0x4 [current] : ASC=0x0 ASCQ=0x0 The errors appear to be otherwise harmless. Add an unusual_devs entry which eliminates all of the error messages. Signed-off-by:
Nick Bowler <nbowler@elliptictech.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Ionut Nicu authored
commit 1862cdd5 upstream. Even if it's unlikely for this to cause an error, there is a typo in the code that uses the bitwise-AND operator instead of the logical one. Signed-off-by:
Ionut Nicu <ionut.nicu@cloudbit.ro> Signed-off-by:
-
Maxim Nikulin authored
commit 4f1a7a3e upstream. Assign operator instead of equality test in the usbtmc_ioctl_abort_bulk_in() function. Signed-off-by:
Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-off-by:
-
John Stultz authored
commit 72c487df upstream. an 'unhandled fault' is causes when a gadget driver calls usb_gadget_connect() while the USB cable isn't plugged into the OTG port. the fault is caused by an access to MUSB's memory space while its clock is turned off due to pm_runtime kicking in. in order to fix the fault, we enclose musb_gadget_pullup() with pm_runtime_get_sync() ... pm_runtime_put() calls to be sure we will always reach that path with clock turned on. [ balbi@ti.com : simplified commit log; removed few things which didn't belong there ] Reported-by:
Zach Pfeffer <zach.pfeffer@linaro.org> Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 7de7c7d2 upstream. wMaxPacketSize is __le16 and should be accessed as such. Also fix the wBytesPerInterval assignment while here. v2: also fix the wBytesPerInterval assigment, noticed by Matt Evans This patch should be backported to the 3.0 kernel. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by:
Matt Evans <matt@ozlabs.org> Signed-off-by:
-
Sarah Sharp authored
commit 7bd89b40 upstream. Commit fccf4e86 "USB: Free bandwidth when usb_disable_device is called" caused a bit of an issue when the xHCI host controller driver is unloaded. It changed the USB core to remove all endpoints when a USB device is disabled. When the driver is unloaded, it will remove the SuperSpeed split root hub, which will disable all devices under that roothub and then halt the host controller. When the second High Speed split roothub is removed, the USB core will attempt to disable the endpoints, which will submit a Configure Endpoint command to a halted host controller. The command will eventually time out, but it makes the xHCI driver unload take *minutes* if there are a couple of USB 1.1/2.0 devices attached. We must halt the host controller when the SuperSpeed roothub is removed, because we can't allow any interrupts from things like port status changes. Make several different functions not submit commands or URBs to the host controller when the host is halted, by adding a check in xhci_check_args(). xhci_check_args() is used by these functions: xhci.c-int xhci_urb_enqueue() xhci.c-int xhci_drop_endpoint() xhci.c-int xhci_add_endpoint() xhci.c-int xhci_check_bandwidth() xhci.c-void xhci_reset_bandwidth() xhci.c-static int xhci_check_streams_endpoint() xhci.c-int xhci_discover_or_reset_device() It's also used by xhci_free_dev(). However, we have to take special care in that case, because we want the device memory to be freed if the host controller is halted. This patch should be backported to the 2.6.39 and 3.0 kernel. Signed-off-by:
-
JiSheng Zhang authored
commit 6768458b upstream. Software should set XHCI_HC_OS_OWNED bit to request ownership of xHC. This patch should be backported to kernels as far back as 2.6.31. Signed-off-by:
JiSheng Zhang <jszhang3@gmail.com> Signed-off-by:
-
