commit 57049bb1dd0461d8423c3feceea36148d4335317 Author: Greg Kroah-Hartman Date: Sat May 11 07:19:28 2013 -0700 Linux 3.9.2 commit bf9ccddf3c95f816b66ad5923d3304af99eec3ab Author: Chen Gang Date: Mon Apr 29 15:05:19 2013 -0700 kernel/audit_tree.c: tree will leak memory when failure occurs in audit_trim_trees() commit 12b2f117f3bf738c1a00a6f64393f1953a740bd4 upstream. audit_trim_trees() calls get_tree(). If a failure occurs we must call put_tree(). [akpm@linux-foundation.org: run put_tree() before mutex_lock() for small scalability improvement] Signed-off-by: Chen Gang Cc: Al Viro Cc: Eric Paris Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit dc994243d9f88f22eb2481867ea26a86cac24cbd Author: Trond Myklebust Date: Tue Apr 30 12:43:42 2013 -0400 NFSv4.x: Fix handling of partially delegated locks commit c5a2a15f8146fdfe45078df7873a6dc1006b3869 upstream. If a NFS client receives a delegation for a file after it has taken a lock on that file, we can currently end up in a situation where we mistakenly skip unlocking that file. The following patch swaps an erroneous check in nfs4_proc_unlck for whether or not the file has a delegation to one which checks whether or not we hold a lock stateid for that file. Reported-by: Chuck Lever Signed-off-by: Trond Myklebust Tested-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8441a6f427a545de73ef4e2ea2b815d2e5d8dafe Author: Dan Williams Date: Mon May 6 11:17:37 2013 +0000 qmi_wwan/cdc_ether: add device IDs for Dell 5804 (Novatel E371) WWAN card commit 7fdb7846c9ca6fc06e380de0976a1228703b498a upstream. A rebranded Novatel E371 for AT&T's LTE bands. qmi_wwan should drive this device, while cdc_ether should ignore it. Even though the USB descriptors are plain CDC-ETHER that USB interface is a QMI interface. Signed-off-by: Dan Williams Acked-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb22b7608a6b27cb585f0fc38c49c4e99e7d8038 Author: Yinghai Lu Date: Tue May 7 14:35:44 2013 -0600 PCI: Delay final fixups until resources are assigned commit e253aaf0af51c1e4dc7dd3b26ea8e666bf9a2d8d upstream. Commit 4f535093cf "PCI: Put pci_dev in device tree as early as possible" moved final fixups from pci_bus_add_device() to pci_device_add(). But pci_device_add() happens before resource assignment, so BARs may not be valid yet. Typical flow for hot-add: pciehp_configure_device pci_scan_slot pci_scan_single_device pci_device_add pci_fixup_device(pci_fixup_final, dev) # previous location # resource assignment happens here pci_bus_add_devices pci_bus_add_device pci_fixup_device(pci_fixup_final, dev) # new location [bhelgaas: changelog, move fixups to pci_bus_add_device()] Reference: https://lkml.kernel.org/r/20130415182614.GB9224@xanatos Reported-by: David Bulkow Tested-by: David Bulkow Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit f2e426a46a35a8cd30c7c7c39e099f7bd857ce0b Author: Srivatsa S. Bhat Date: Tue Apr 30 15:17:16 2013 +0530 EDAC: Don't give write permission to read-only files commit c8c64d165ccfd2274058ac84e0c680f9b48c4ec1 upstream. I get the following warning on boot: ------------[ cut here ]------------ WARNING: at drivers/base/core.c:575 device_create_file+0x9a/0xa0() Hardware name: -[8737R2A]- Write permission without 'store' ... Drilling down, this is related to dynamic channel ce_count attribute files sporting a S_IWUSR mode without a ->store() function. Looking around, it appears that they aren't supposed to have a ->store() function. So remove the bogus write permission to get rid of the warning. Signed-off-by: Srivatsa S. Bhat Cc: Mauro Carvalho Chehab [ shorten commit message ] Signed-off-by: Borislav Petkov Signed-off-by: Greg Kroah-Hartman commit d2775711193f1bad066bc5349969ec0bcc9dccb1 Author: Josef Bacik Date: Wed Apr 24 16:32:55 2013 -0400 Btrfs: fix extent logging with O_DIRECT into prealloc commit eb384b55ae9c2055ea00c5cc87971e182d47aefa upstream. This is the same as the fix from commit Btrfs: fix bad extent logging but for O_DIRECT. I missed this when I fixed the problem originally, we were still using the em for the orig_start and orig_block_len, which would be the merged extent. We need to use the actual extent from the on disk file extent item, which we have to lookup to make sure it's ok to nocow anyway so just pass in some pointers to hold this info. Thanks, Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit a2d8e3c7a2341da3fd6e65f87ef7712e5fa2a020 Author: Josef Bacik Date: Mon Apr 1 20:36:28 2013 -0400 Btrfs: compare relevant parts of delayed tree refs commit 41b0fc42800569f63e029549b75c4c9cb63f2dfd upstream. A user reported a panic while running a balance. What was happening was he was relocating a block, which added the reference to the relocation tree. Then relocation would walk through the relocation tree and drop that reference and free that block, and then it would walk down a snapshot which referenced the same block and add another ref to the block. The problem is this was all happening in the same transaction, so the parent block was free'ed up when we drop our reference which was immediately available for allocation, and then it was used _again_ to add a reference for the same block from a different snapshot. This resulted in something like this in the delayed ref tree add ref to 90234880, parent=2067398656, ref_root 1766, level 1 del ref to 90234880, parent=2067398656, ref_root 18446744073709551608, level 1 add ref to 90234880, parent=2067398656, ref_root 1767, level 1 as you can see the ref_root's don't match, because when we inc the ref we use the header owner, which is the original tree the block belonged to, instead of the data reloc tree. Then when we remove the extent we use the reloc tree objectid. But none of this matters, since it is a shared reference which means only the parent matters. When the delayed ref stuff runs it adds all the increments first, and then does all the drops, to make sure that we don't delete the ref if we net a positive ref count. But tree blocks aren't allowed to have multiple refs from the same block, so this panics when it tries to add the second ref. We need the add and the drop to cancel each other out in memory so we only do the final add. So to fix this we need to adjust how the delayed refs are added to the tree. Only the ref_root matters when it is a normal backref, and only the parent matters when it is a shared backref. So make our decision based on what ref type we have. This allows us to keep the ref_root in memory in case anybody wants to use it for something else, and it allows the delayed refs to be merged properly so we don't end up with this panic. With this patch the users image no longer panics on mount, and it has a clean fsck after a normal mount/umount cycle. Thanks, Reported-by: Roman Mamedov Signed-off-by: Josef Bacik Signed-off-by: Greg Kroah-Hartman commit 67d9d1c1a1d3f73cb9acfef7d38130d0ab1ea284 Author: Steven Rostedt (Red Hat) Date: Fri Mar 15 13:10:35 2013 -0400 tracing: Fix ftrace_dump() commit 7fe70b579c9e3daba71635e31b6189394e7b79d3 upstream. ftrace_dump() had a lot of issues. What ftrace_dump() does, is when ftrace_dump_on_oops is set (via a kernel parameter or sysctl), it will dump out the ftrace buffers to the console when either a oops, panic, or a sysrq-z occurs. This was written a long time ago when ftrace was fragile to recursion. But it wasn't written well even for that. There's a possible deadlock that can occur if a ftrace_dump() is happening and an NMI triggers another dump. This is because it grabs a lock before checking if the dump ran. It also totally disables ftrace, and tracing for no good reasons. As the ring_buffer now checks if it is read via a oops or NMI, where there's a chance that the buffer gets corrupted, it will disable itself. No need to have ftrace_dump() do the same. ftrace_dump() is now cleaned up where it uses an atomic counter to make sure only one dump happens at a time. A simple atomic_inc_return() is enough that is needed for both other CPUs and NMIs. No need for a spinlock, as if one CPU is running the dump, no other CPU needs to do it too. The tracing_on variable is turned off and not turned on. The original code did this, but it wasn't pretty. By just disabling this variable we get the result of not seeing traces that happen between crashes. For sysrq-z, it doesn't get turned on, but the user can always write a '1' to the tracing_on file. If they are using sysrq-z, then they should know about tracing_on. The new code is much easier to read and less error prone. No more deadlock possibility when an NMI triggers here. Reported-by: zhangwei(Jovi) Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Frederic Weisbecker Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 31c2a91a61dc997a2189e345694aa662dee09669 Author: Sachin Kamat Date: Sat Mar 2 15:53:06 2013 +0530 drm/tilcdc: Fix an incorrect condition commit 9e48854c58ca9a0f39e716dcb18247bfc21e2022 upstream. Instead of checking if num_encoders is zero, it is being assigned 0. Convert the assignment to a check. Signed-off-by: Sachin Kamat Acked-by: Rob Clark Signed-off-by: Dave Airlie Signed-off-by: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit f2bc8219dfb84879ea44b0e44c3590a4449065bd Author: Alex Deucher Date: Wed May 1 14:34:54 2013 -0400 drm/radeon: fix handling of v6 power tables commit 441e76ca83ac604eaf0f046def96d8e3a27eea28 upstream. The code was mis-handling variable sized arrays. Reported-by: Sylvain BERTRAND Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0496ac0e46866ec684e2eb105033f4b03b7016a0 Author: Alex Deucher Date: Thu Apr 25 14:06:05 2013 -0400 drm/radeon: add new richland pci ids commit 62d1f92e06aef9665d71ca7e986b3047ecf0b3c7 upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b591b21206d81fc51492c7dace09256a8be4c6b2 Author: Alex Deucher Date: Thu Apr 25 09:29:17 2013 -0400 drm/radeon: fix possible segfault when parsing pm tables commit f8e6bfc2ce162855fa4f9822a45659f4b542c960 upstream. If we have a empty power table, bail early and allocate the default power state. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=63865 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 3f943152df692c85b382fdb186e257c357272f77 Author: Alex Deucher Date: Wed Apr 24 14:39:31 2013 -0400 drm/radeon: fix endian bugs in atom_allocate_fb_scratch() commit beb71fc61c2cad64e347f164991b8ef476529e64 upstream. Reviwed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 27e595de3067ce6aeb4425aca22c132264c60404 Author: Alex Deucher Date: Wed Apr 17 09:35:39 2013 -0400 drm/radeon: disable the crtcs in mc_stop (r5xx-r7xx) (v2) commit e884fc640ccbdb6f94b9bdb57cfb8464b6688f4c upstream. Just disabling the mem requests should be enough, but that doesn't seem to work correctly on efi systems. v2: blank displays first, then disable. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 5e1a98badcfd0be0d80f3349e0052bf3ccbd8bde Author: Jerome Glisse Date: Tue Apr 16 12:20:15 2013 -0400 drm/radeon: Always flush the VM commit 466476dfdcafbb4286ffa232a3a792731b9dc852 upstream. This is slightly cleaned up version of Jerome's patch. There seems to be an issue tracking the last flush of the VM which results in hangs in certain cases when VM is used. For now just flush the VM for every IB. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62959 https://bugs.freedesktop.org/show_bug.cgi?id=62997 Signed-off-by: Jerome Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit d388e85d52a871bedd7dbda4a54e6d485dd89520 Author: Alex Deucher Date: Thu Apr 18 16:26:36 2013 -0400 drm/radeon: fix typo in si_select_se_sh() commit 79b52d6a7085a3e430c6de450a5847fdbe04159b upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 647d269f7e0996b67bd4226885f6a57d177d0fdb Author: Alex Deucher Date: Thu Apr 18 09:36:42 2013 -0400 drm/radeon: fix hdmi mode enable on RS600/RS690/RS740 commit dcb852905772416e322536ced5cb3c796d176af5 upstream. These chips were previously skipped since they are pre-R600. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit df5dbe6b637a0a4fef5ddaa9699a510a4c235eb9 Author: Alex Deucher Date: Fri Apr 12 19:15:52 2013 -0400 drm/radeon: cleanup properly if mmio mapping fails commit 0cd9cb76ae26a19df21abc6f94f5fff141e689c7 upstream. If we fail to map the mmio BAR, skip driver tear down that requires mmio. Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=56541 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 35fa3f99ee1e54c14b5dd1ce177613cc99196e3a Author: Alex Deucher Date: Thu Apr 11 12:45:34 2013 -0400 drm/radeon/evergreen+: don't enable HPD interrupts on eDP/LVDS commit 2e97be73e5f74a317232740ae82eb8f95326a660 upstream. Avoids potential interrupt storms when the display is disabled. May fix: https://bugzilla.kernel.org/show_bug.cgi?id=56041 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f8080cb410b0abcbebefe881ce4e522a6e1f2adc Author: Alex Deucher Date: Thu Apr 25 13:55:15 2013 -0400 drm/radeon: add some new SI PCI ids commit 18932a28419596bc9403770f5d8a108c5433fe59 upstream. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c0cd6d26b063108b6fda52430dd0367f2049ff36 Author: Alex Deucher Date: Wed Apr 10 19:08:14 2013 -0400 drm/radeon: disable the crtcs in mc_stop (evergreen+) (v2) commit abf1457bbbe4c62066bd03c6d31837dea28644dc upstream. Just disabling the mem requests should be enough, but that doesn't seem to work correctly on efi systems. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=57567 https://bugs.freedesktop.org/show_bug.cgi?id=43655 https://bugzilla.kernel.org/show_bug.cgi?id=56441 v2: blank displays first, then disable. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 038ab29360e6aaed9208c18d8c50d7f236aa2efb Author: Alex Deucher Date: Tue Apr 9 18:32:01 2013 -0400 drm/radeon: update wait_for_vblank for r1xx-r4xx commit 2b48b968c0d00aa5ab520b65a15a4f374cda7dda upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c365bdab5704ec2db1882e34bdf8bf537729b105 Author: Alex Deucher Date: Wed Apr 10 09:47:05 2013 -0400 drm/radeon: properly lock disp in mc_stop/resume for r5xx-r7xx commit 2f86e2ede39a98650c2d465857405ef1c51372b1 upstream. Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 2e85e599a509e4278b3a0b854d595f636970719e Author: Alex Deucher Date: Wed Apr 10 09:58:42 2013 -0400 drm/radeon: properly lock disp in mc_stop/resume for evergreen+ commit 968c01664ccbe0e46c19a1af662c4c266a904203 upstream. Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f046835bd06046b36e114709dae7a28e9bdc770b Author: Alex Deucher Date: Tue Apr 9 18:49:59 2013 -0400 drm/radeon: update wait_for_vblank for evergreen+ commit 10257a6d8359c41407eb26b7ad7bf710a7e00155 upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4bafb0c54acae09a8d3774512c953c4f7a2074b9 Author: Alex Deucher Date: Tue Apr 9 18:41:15 2013 -0400 drm/radeon: update wait_for_vblank for r5xx-r7xx commit bea5497bfc1067620c8c8e9d37a42e0bb6d7d7fa upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 698733fbe19f26b0fd0e0615f9999aacfd935be2 Author: Alex Deucher Date: Fri Apr 5 10:28:08 2013 -0400 drm/radeon/dce6: add missing display reg for tiling setup commit 7c1c7c18fc752b2a1d07597286467ef186312463 upstream. A new tiling config register for the display blocks was added on DCE6. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=62889 https://bugs.freedesktop.org/show_bug.cgi?id=57919 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 59579ecd40d291aa0ebe2c77223bde4cd180e49e Author: Alex Deucher Date: Thu Apr 4 14:59:35 2013 -0400 drm/radeon: fix typo in rv515_mc_resume() commit 367cbe2fec9b57b72605e2ac4cfd4f2fa823a256 upstream. Doesn't affect anything as the same address gets written in both cases. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a7586684298c3a6201393ea7c858416c31c17fce Author: Alex Deucher Date: Mon Apr 1 16:06:25 2013 -0400 drm/radeon: use frac fb div on RS780/RS880 commit 411678288d61ba17afe1f8afed92200be6bbc65d upstream. Monitors seem to prefer it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37696 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 579b7f8405fb58f58461d3ae17b4d04699e6b110 Author: Alex Deucher Date: Mon Mar 18 17:12:50 2013 -0400 drm/radeon: don't use get_engine_clock() on APUs commit bf05d9985111f85ed6922c134567b96eb789283b upstream. It doesn't work reliably. Just report back the currently selected engine clock. Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62493 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e60d43ee98b0fa4e18801cc44c07e2412cb7f530 Author: Zhang, Xiong Y Date: Sat Apr 27 09:53:33 2013 +0000 drm/i915: correct the calculation of first_pd_entry_in_global_pt commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff upstream. When ppgtt is enabled, dev_priv->gtt.total has excluded the gtt space occupied by ppgtt table in i915_gem_init_global_gtt() function. So the calculation of first_pd_entry_in_global_pt doesn't need to subtract I915_PPGTT_PD_ENTRIES again. Or else PPGTT directory table will be destroyed by global gtt allocation. This regression has been introduced in commit a54c0c279f3864171fe53c66e769d5a137c5c651 Author: Ben Widawsky Date: Thu Jan 24 14:45:00 2013 -0800 drm/i915: remove intel_gtt structure The breakage is pretty subtile since the old gtt_total_entries included the pde range, whereas the new on did not. Signed-off-by: Xiong Zhang [danvet: Add regression citation and cc: stable. Thanks to Chris for correcting my wrong guess about which commit broke things.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 282aab32881276b2239003aecc88b4eeb702353e Author: David Müller Date: Fri Apr 19 10:41:50 2013 +0200 drm/i915: Fall back to bit banging mode for DVO transmitter detection commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream. As discussed in this thread http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html GMBUS based DVO transmitter detection seems to be unreliable which could result in an unusable DVO port. The attached patch fixes this by falling back to bit banging mode for the time DVO transmitter detection is in progress. Signed-off-by: David Müller Tested-by: David Müller Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit ff2c7b8f232d4fdeabec85a0139019696db1c10a Author: Daniel Vetter Date: Fri Apr 12 18:48:43 2013 +0200 drm/i915: Fixup Oops in the pipe config computation commit b6c5164d7bf624f3e1b750787ddb983150c5117c upstream. Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb->depth, so this is a regression brought to light with commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 Author: Daniel Vetter Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html Tested-by: Richard Cochran Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 3d853eee7ad906d15f54bd0c4547346b7077bc7b Author: Paulo Zanoni Date: Fri Apr 12 18:16:53 2013 -0300 drm/i915: don't intel_crt_init on any ULT machines commit c40c0f5bd5b0f09e4386d2cf26c96c89c45ee539 upstream. We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Signed-off-by: Paulo Zanoni Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 396396ac6d52b726665e5cfd8141af1604db2b46 Author: Jani Nikula Date: Fri Apr 12 15:18:38 2013 +0300 drm/i915: ensure single initialization and cleanup of backlight device commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream. Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701 Signed-off-by: Jani Nikula Tested-by: Peter Verthez Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 56dc1d0e51ebd1681bd2396f094a9200db8f8fed Author: Daniel Vetter Date: Thu Apr 11 20:22:50 2013 +0200 drm/i915: don't check inconsistent modeset state when force-restoring commit f30da187cdcd0939288038e11fb3bfbd1b655564 upstream. It will be only consistent once we've restored all the crtcs. Since a bunch of other callers also want to just restore a single crtc, add a boolean to disable checking only where it doesn't make sense. Note that intel_modeset_setup_hw_state already has a call to intel_modeset_check_state at the end, so we don't reduce the amount of checking. v2: Try harder not to create a big patch (Chris). v3: Even smaller (still Chris). Also fix a trailing space. Reviewed-by: Chris Wilson References: https://lkml.org/lkml/2013/3/16/60 Cc: Tomas Melin Cc: Richard Cochran Cc: Chris Wilson Tested-by: Tomas Melin Tested-by: Richard Cochran Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit b58391066b2f2bfe8673746c5c675c288c3a3332 Author: Paulo Zanoni Date: Mon Apr 8 15:48:07 2013 -0300 drm/i915: set CPT FDI RX polarity bits based on VBT commit 3f704fa2778d3fe45e6529825a5c7a8bcbc686f4 upstream. Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029 Signed-off-by: Paulo Zanoni Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 71aa73bafa886679af171ba949d37e853668420e Author: Chris Wilson Date: Mon Apr 8 14:28:40 2013 +0100 drm/i915: Use MLC (l3$) for context objects commit 4615d4c9e27eda42c3e965f208a4b4065841498c upstream. Enabling context support increases SwapBuffers latency by about 20% (measured on an i7-3720qm). We can offset that loss slightly by enabling faster caching for the contexts. As they are not backed by any particular cache (such as the sampler or render caches) our only option is to select the generic mid-level cache. This reduces the latency of the swap by about 5%. Oddly this effect can be observed running smokin-guns on IVB at 1280x1024: Using BLT copies for swaps: 151.67 fps Using Render copies for swaps (unpatched): 141.70 fps With contexts disabled: 150.23 fps With contexts in L3$: 150.77 fps Signed-off-by: Chris Wilson Cc: Ben Widawsky Cc: Kenneth Graunke Reviewed-by: Kenneth Graunke Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 1e8562ada4319256816c5360d52073f8c2c928dc Author: Chris Wilson Date: Thu Apr 4 21:31:03 2013 +0100 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream. In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write. Fixes i-g-t/gem_fence_thrash v2: Bring a bigger gun v3: Switch the bigger gun for heavier bullets (Arjan van de Ven) v4: Remove changes for working generations. v5: Reduce to a per-cpu wbinvd() call prior to updating the fences. v6: Rewrite comments to ellide forgotten history. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191 Signed-off-by: Chris Wilson Cc: Jon Bloomfield Tested-by: Jon Bloomfield (v2) Reviewed-by: Jesse Barnes Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 2a614338d1a2af1c75f754115f1a146c7fd9e777 Author: Egbert Eich Date: Thu Apr 4 16:04:02 2013 -0400 drm/i915: Fix SDVO connector and encoder get_hw_state functions commit 7a7d1fb79fb581553f4830498045de774a9659f8 upstream. The connector associated with the encoder is considered active when the output associtated with this connector is active on the encoder. The encoder itself is considered active when either there is an active output on it or the respective SDVO channel is active. Having active outputs when the SDVO channel is inactive seems to be inconsistent: such states can be found when intel_modeset_setup_hw_state() collects the hardware state set by the BIOS. This inconsistency will be fixed in intel_sanitize_crtc() (when intel_crtc_update_dpms() is called), this however only happens when the encoder is associated with a crtc. This patch also reverts: commit bd6946e87a98fea11907b2a47368e13044458a35 Author: Daniel Vetter Date: Tue Apr 2 21:30:34 2013 +0200 drm/i915: Fix sdvo connector get_hw_state function Signed-off-by: Egbert Eich Suggested-by: Daniel Vetter Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit ebbdb06fe932dca8bc69829d2db8e7f1d8cffa10 Author: Christian Lamparter Date: Wed Apr 3 14:34:11 2013 +0200 drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900 commit 9e9dd0e889c76c786e8f2e164c825c3c06dea30c upstream. The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by: Christian Lamparter Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 5f71bf911d465e082c791989612c47fd3bf28969 Author: Daniel Vetter Date: Tue Apr 2 21:30:34 2013 +0200 drm/i915: Fix sdvo connector get_hw_state function commit bd6946e87a98fea11907b2a47368e13044458a35 upstream. The active output is only the currently selected one, which does not imply that it's actually enabled. Since we don't use the sdvo encoder side dpms support, we need to check whether the chip-side sdvo port is enabled instead. v2: Fix up Bugzilla links. v3: Simplify logic a bit (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Cc: Egbert Eich Cc: Chris Wilson Tested-by: Egbert Eich (v2) Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit c5690562cfb88322b6119a50e645d2f2baa95ebf Author: Dave Airlie Date: Thu May 2 02:40:25 2013 -0400 drm/ast: deal with bo reserve fail in dirty update path commit 306373b645d80625335b8e684fa09b14ba460cec upstream. Port over the mgag200 fix to ast as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c492a74718dde721fe992f77cec7d0f467188449 Author: Dave Airlie Date: Mon Apr 22 09:54:36 2013 +1000 drm/prime: keep a reference from the handle to exported dma-buf (v6) commit 219b47339ced80ca580bb6ce7d1636166984afa7 upstream. Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object reference in its file priv, that isn't cleaned up properly until fd close. The reference gets added at step 2, but at step 6 we don't have enough info to clean it up. The solution is to take a reference on the dma-buf when we export it, and drop the reference when the gem handle goes away. So when we export a dma_buf from a gem object, we keep track of it with the handle, we take a reference to the dma_buf. When we close the handle (i.e. userspace is finished with the buffer), we drop the reference to the dma_buf, and it gets collected. This patch isn't meant to fix any other problem or bikesheds, and it doesn't fix any races with other scenarios. v1.1: move export symbol line back up. v2: okay I had to do a bit more, as the first patch showed a leak on one of my tests, that I found using the dma-buf debugfs support, the problem case is exporting a buffer twice with the same handle, we'd add another export handle for it unnecessarily, however we now fail if we try to export the same object with a different gem handle, however I'm not sure if that is a case I want to support, and I've gotten the code to WARN_ON if we hit something like that. v2.1: rebase this patch, write better commit msg. v3: cleanup error handling, track import vs export in linked list, these two patches were separate previously, but seem to work better like this. v4: danvet is correct, this code is no longer useful, since the buffer better exist, so remove it. v5: always take a reference to the dma buf object, import or export. (Imre Deak contributed this originally) v6: square the circle, remove import vs export tracking now that there is no difference Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c8ff23058da988cfc4b1654178ed9c926b62a10e Author: Imre Deak Date: Fri Apr 19 11:11:56 2013 +1000 drm: prime: fix refcounting on the dmabuf import error path commit 011c2282c74db120f01a8414edc66c3f217f5511 upstream. In commit be8a42ae60 we inroduced a refcount problem, where on the drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for self imported dma buffers. Fix this by taking a reference on the dma buffer in the .gem_import hook instead of assuming the caller had taken one. Besides fixing the bug this is also more logical. Signed-off-by: Imre Deak Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6f1e6342efdecfa0fb47dc24ecfb7ecb871ee65e Author: Anisse Astier Date: Wed Apr 24 17:36:01 2013 +0200 drm/gma500: fix backlight hotkeys behaviour on netbooks commit e127dc28cc3057575da0216cde85687153ca180f upstream. Backlight hotkeys weren't working before on certain cedartrail laptops. The source of this problem is that the hotkeys' ASLE opregion interrupts were simply ignored. Driver seemed to expect the interrupt to be associated with a pipe, but it wasn't. Accepting the ASLE interrupt without an associated pipe event flag fixes the issue, the backlight code is called when needed, making the brightness keys work properly. [patrik: This patch affects irq handling on any netbook with opregion support] Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597 Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.html Signed-off-by: Anisse Astier Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman commit 15b28eb6359ac375f956c3c6f3be1ec91a4158e8 Author: Dave Airlie Date: Thu May 2 00:52:01 2013 -0400 drm/mgag200: deal with bo reserve fail in dirty update path commit 641719599528d806e00de8ae8c8453361266a312 upstream. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit f43f4614a460523e4a89d6153d6a7f8197efc700 Author: Dave Airlie Date: Thu May 2 02:45:02 2013 -0400 drm/cirrus: deal with bo reserve fail in dirty update path commit f3b2bbdc8a87a080ccd23d27fca4b87d61340dd4 upstream. Port over the mgag200 fix to cirrus as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 7e7fc743df596240d2b69dbf0ef3cd3fb7da08e1 Author: James Bottomley Date: Wed Apr 24 08:52:50 2013 -0600 block: fix max discard sectors limit commit 871dd9286e25330c8a581e5dacfa8b1dfe1dd641 upstream. linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with commit 0cfbcafcae8b7364b5fa96c2b26ccde7a3a296a9 (block: add plug for blkdev_issue_discard ) For example, 1) DISCARD rq-1 with size size 4GB 2) DISCARD rq-2 with size size 1GB If these 2 discard requests get merged, final request size will be 5GB. In this case, request's __data_len field may overflow as it can store max 4GB(unsigned int). This issue was observed while doing mkfs.f2fs on 5GB SD card: https://lkml.org/lkml/2013/4/1/292 Info: sector size = 512 Info: total sectors = 11370496 (in 512bytes) Info: zone aligned segment0 blkaddr: 512 [ 257.789764] blk_update_request: bio idx 0 >= vcnt 0 mkfs process gets stuck in D state and I see the following in the dmesg: [ 257.789733] __end_that: dev mmcblk0: type=1, flags=122c8081 [ 257.789764] sector 4194304, nr/cnr 2981888/4294959104 [ 257.789764] bio df3840c0, biotail df3848c0, buffer (null), len 1526726656 [ 257.789764] blk_update_request: bio idx 0 >= vcnt 0 [ 257.794921] request botched: dev mmcblk0: type=1, flags=122c8081 [ 257.794921] sector 4194304, nr/cnr 2981888/4294959104 [ 257.794921] bio df3840c0, biotail df3848c0, buffer (null), len 1526726656 This patch fixes this issue. Reported-by: Max Filippov Signed-off-by: James Bottomley Signed-off-by: Namjae Jeon Tested-by: Max Filippov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ae4282fe84e1208495b2f9fe63eef4cb06773692 Author: Jun'ichi Nomura Date: Tue Apr 9 15:01:21 2013 +0200 blkcg: fix "scheduling while atomic" in blk_queue_bypass_start commit e5072664f8237cf53b0bd68a51aa1a7bc69061c5 upstream. Since 749fefe677 in v3.7 ("block: lift the initial queue bypass mode on blk_register_queue() instead of blk_init_allocated_queue()"), the following warning appears when multipath is used with CONFIG_PREEMPT=y. This patch moves blk_queue_bypass_start() before radix_tree_preload() to avoid the sleeping call while preemption is disabled. BUG: scheduling while atomic: multipath/2460/0x00000002 1 lock held by multipath/2460: #0: (&md->type_lock){......}, at: [] dm_lock_md_type+0x17/0x19 [dm_mod] Modules linked in: ... Pid: 2460, comm: multipath Tainted: G W 3.7.0-rc2 #1 Call Trace: [] __schedule_bug+0x6a/0x78 [] __schedule+0xb4/0x5e0 [] schedule+0x64/0x66 [] schedule_timeout+0x39/0xf8 [] ? put_lock_stats+0xe/0x29 [] ? lock_release_holdtime+0xb6/0xbb [] wait_for_common+0x9d/0xee [] ? try_to_wake_up+0x206/0x206 [] ? kfree_call_rcu+0x1c/0x1c [] wait_for_completion+0x1d/0x1f [] wait_rcu_gp+0x5d/0x7a [] ? wait_rcu_gp+0x7a/0x7a [] ? complete+0x21/0x53 [] synchronize_rcu+0x1e/0x20 [] blk_queue_bypass_start+0x5d/0x62 [] blkcg_activate_policy+0x73/0x270 [] ? kmem_cache_alloc_node_trace+0xc7/0x108 [] cfq_init_queue+0x80/0x28e [] ? dm_blk_ioctl+0xa7/0xa7 [dm_mod] [] elevator_init+0xe1/0x115 [] ? blk_queue_make_request+0x54/0x59 [] blk_init_allocated_queue+0x8c/0x9e [] dm_setup_md_queue+0x36/0xaa [dm_mod] [] table_load+0x1bd/0x2c8 [dm_mod] [] ctl_ioctl+0x1d6/0x236 [dm_mod] [] ? table_clear+0xaa/0xaa [dm_mod] [] dm_ctl_ioctl+0x13/0x17 [dm_mod] [] do_vfs_ioctl+0x3fb/0x441 [] ? file_has_perm+0x8a/0x99 [] sys_ioctl+0x5e/0x82 [] ? trace_hardirqs_on_thunk+0x3a/0x3f [] system_call_fastpath+0x16/0x1b Signed-off-by: Jun'ichi Nomura Acked-by: Vivek Goyal Acked-by: Tejun Heo Cc: Alasdair G Kergon Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0661e5659a502db6c989318628365fc34242481d Author: Catalin Marinas Date: Tue May 7 16:57:06 2013 +0100 arm64: Ignore the 'write' ESR flag on cache maintenance faults commit 0e7f7bcc3fc87489cda5aa6aff8ce40eed912279 upstream. ESR.WnR bit is always set on data cache maintenance faults even though the page is not required to have write permission. If a translation fault (page not yet mapped) happens for read-only user address range, Linux incorrectly assumes a permission fault. This patch adds the check of the ESR.CM bit during the page fault handling to ignore the 'write' flag. Signed-off-by: Catalin Marinas Reported-by: Tim Northover Signed-off-by: Greg Kroah-Hartman commit b548047b3ed2ff999744c89277d40ef494e387d9 Author: Thadeu Lima de Souza Cascardo Date: Mon Apr 1 20:13:39 2013 +0000 RDMA/cxgb4: Fix SQ allocation when on-chip SQ is disabled commit 5b0c275926b8149c555da874bb4ec258ea3292aa upstream. Commit c079c28714e4 ("RDMA/cxgb4: Fix error handling in create_qp()") broke SQ allocation. Instead of falling back to host allocation when on-chip allocation fails, it tries to allocate both. And when it does, and we try to free the address from the genpool using the host address, we hit a BUG and the system crashes as below. We create a new function that has the previous behavior and properly propagate the error, as intended. kernel BUG at /usr/src/packages/BUILD/kernel-ppc64-3.0.68/linux-3.0/lib/genalloc.c:340! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: rdma_ucm rdma_cm ib_addr ib_cm iw_cm ib_sa ib_mad ib_uverbs iw_cxgb4 ib_core ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables fuse loop dm_mod ipv6 ipv6_lib sr_mod cdrom ibmveth(X) cxgb4 sg ext3 jbd mbcache sd_mod crc_t10dif scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh ibmvscsic(X) scsi_transport_srp scsi_tgt scsi_mod Supported: Yes NIP: c00000000037d41c LR: d000000003913824 CTR: c00000000037d3b0 REGS: c0000001f350ae50 TRAP: 0700 Tainted: G X (3.0.68-0.9-ppc64) MSR: 8000000000029032 CR: 24042482 XER: 00000001 TASK = c0000001f6f2a840[3616] 'rping' THREAD: c0000001f3508000 CPU: 0 GPR00: c0000001f6e875c8 c0000001f350b0d0 c000000000fc9690 c0000001f6e875c0 GPR04: 00000000000c0000 0000000000010000 0000000000000000 c0000000009d482a GPR08: 000000006a170000 0000000000100000 c0000001f350b140 c0000001f6e875c8 GPR12: d000000003915dd0 c000000003f40000 000000003e3ecfa8 c0000001f350bea0 GPR16: c0000001f350bcd0 00000000003c0000 0000000000040100 c0000001f6e74a80 GPR20: d00000000399a898 c0000001f6e74ac8 c0000001fad91600 c0000001f6e74ab0 GPR24: c0000001f7d23f80 0000000000000000 0000000000000002 000000006a170000 GPR28: 000000000000000c c0000001f584c8d0 d000000003925180 c0000001f6e875c8 NIP [c00000000037d41c] .gen_pool_free+0x6c/0xf8 LR [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4] Call Trace: [c0000001f350b0d0] [c0000001f350b180] 0xc0000001f350b180 (unreliable) [c0000001f350b170] [d000000003913824] .c4iw_ocqp_pool_free+0x8c/0xd8 [iw_cxgb4] [c0000001f350b210] [d00000000390fd70] .dealloc_sq+0x90/0xb0 [iw_cxgb4] [c0000001f350b280] [d00000000390fe08] .destroy_qp+0x78/0xf8 [iw_cxgb4] [c0000001f350b310] [d000000003912738] .c4iw_destroy_qp+0x208/0x2d0 [iw_cxgb4] [c0000001f350b460] [d000000003861874] .ib_destroy_qp+0x5c/0x130 [ib_core] [c0000001f350b510] [d0000000039911bc] .ib_uverbs_cleanup_ucontext+0x174/0x4f8 [ib_uverbs] [c0000001f350b5f0] [d000000003991568] .ib_uverbs_close+0x28/0x70 [ib_uverbs] [c0000001f350b670] [c0000000001e7b2c] .__fput+0xdc/0x278 [c0000001f350b720] [c0000000001a9590] .remove_vma+0x68/0xd8 [c0000001f350b7b0] [c0000000001a9720] .exit_mmap+0x120/0x160 [c0000001f350b8d0] [c0000000000af330] .mmput+0x80/0x160 [c0000001f350b960] [c0000000000b5d0c] .exit_mm+0x1ac/0x1e8 [c0000001f350ba10] [c0000000000b8154] .do_exit+0x1b4/0x4b8 [c0000001f350bad0] [c0000000000b84b0] .do_group_exit+0x58/0xf8 [c0000001f350bb60] [c0000000000ce9f4] .get_signal_to_deliver+0x2f4/0x5d0 [c0000001f350bc60] [c000000000017ee4] .do_signal_pending+0x6c/0x3e0 [c0000001f350bdb0] [c0000000000182cc] .do_signal+0x74/0x78 [c0000001f350be30] [c000000000009e74] do_work+0x24/0x28 Signed-off-by: Thadeu Lima de Souza Cascardo Cc: Emil Goode Acked-by: Steve Wise Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 352315a9cdad5568ce81e7b5687c216e245f0a59 Author: Stefan Bader Date: Fri Apr 26 13:49:32 2013 +0000 r8169: fix 8168evl frame padding. commit e5195c1f31f399289347e043d6abf3ffa80f0005 upstream. Signed-off-by: Stefan Bader Acked-by: Francois Romieu Cc: hayeswang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 785aacfcaba10a438100b9b7ecb77bcfce83770b Author: David Cohen Date: Thu Apr 11 13:22:14 2013 +0930 MODSIGN: do not send garbage to stderr when enabling modules signature commit 07c449bbc6aa514098c4f12c7b04180cec2417c6 upstream. When compiling kernel with -jN (N > 1), all warning/error messages printed while openssl is generating key pair may get mixed dots and other symbols openssl sends to stderr. This patch makes sure openssl logs go to default stdout. Example of the garbage on stderr: crypto/anubis.c:581: warning: ‘inter’ is used uninitialized in this function Generating a 4096 bit RSA private key ......... drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen6_ggtt_insert_entries’: drivers/gpu/drm/i915/i915_gem_gtt.c:440: warning: ‘addr’ may be used uninitialized in this function .net/mac80211/tx.c: In function ‘ieee80211_subif_start_xmit’: net/mac80211/tx.c:1780: warning: ‘chanctx_conf’ may be used uninitialized in this function ..drivers/isdn/hardware/mISDN/hfcpci.c: In function ‘hfcpci_softirq’: .....drivers/isdn/hardware/mISDN/hfcpci.c:2298: warning: ignoring return value of ‘driver_for_each_device’, declared with attribute warn_unused_result Signed-off-by: David Cohen Reviewed-by: mark gross Acked-by: David Howells Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 0ac885773b1cdf18dff26b018bafe53b3b393714 Author: Theodore Ts'o Date: Sun Apr 21 22:56:32 2013 -0400 ext4: add check for inodes_count overflow in new resize ioctl commit 3f8a6411fbada1fa482276591e037f3b1adcf55b upstream. Addresses-Red-Hat-Bugzilla: #913245 Reported-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Reviewed-by: Carlos Maiolino Signed-off-by: Lingzhu Xiang Signed-off-by: Greg Kroah-Hartman commit 42b5b666c4574ecea8c3396befac1d7685a8c02a Author: Hans Schillstrom Date: Sat Apr 27 20:06:14 2013 +0200 ipvs: ip_vs_sip_fill_param() BUG: bad check of return value commit f7a1dd6e3ad59f0cfd51da29dfdbfd54122c5916 upstream. The reason for this patch is crash in kmemdup caused by returning from get_callid with uniialized matchoff and matchlen. Removing Zero check of matchlen since it's done by ct_sip_get_header() BUG: unable to handle kernel paging request at ffff880457b5763f IP: [] kmemdup+0x2e/0x35 PGD 27f6067 PUD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: xt_state xt_helper nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_mangle xt_connmark xt_conntrack ip6_tables nf_conntrack_ftp ip_vs_ftp nf_nat xt_tcpudp iptable_mangle xt_mark ip_tables x_tables ip_vs_rr ip_vs_lblcr ip_vs_pe_sip ip_vs nf_conntrack_sip nf_conntrack bonding igb i2c_algo_bit i2c_core CPU 5 Pid: 0, comm: swapper/5 Not tainted 3.9.0-rc5+ #5 /S1200KP RIP: 0010:[] [] kmemdup+0x2e/0x35 RSP: 0018:ffff8803fea03648 EFLAGS: 00010282 RAX: ffff8803d61063e0 RBX: 0000000000000003 RCX: 0000000000000003 RDX: 0000000000000003 RSI: ffff880457b5763f RDI: ffff8803d61063e0 RBP: ffff8803fea03658 R08: 0000000000000008 R09: 0000000000000011 R10: 0000000000000011 R11: 00ffffffff81a8a3 R12: ffff880457b5763f R13: ffff8803d67f786a R14: ffff8803fea03730 R15: ffffffffa0098e90 FS: 0000000000000000(0000) GS:ffff8803fea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff880457b5763f CR3: 0000000001a0c000 CR4: 00000000001407e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper/5 (pid: 0, threadinfo ffff8803ee18c000, task ffff8803ee18a480) Stack: ffff8803d822a080 000000000000001c ffff8803fea036c8 ffffffffa000937a ffffffff81f0d8a0 000000038135fdd5 ffff880300000014 ffff880300110000 ffffffff150118ac ffff8803d7e8a000 ffff88031e0118ac 0000000000000000 Call Trace: [] ip_vs_sip_fill_param+0x13a/0x187 [ip_vs_pe_sip] [] ip_vs_sched_persist+0x2c6/0x9c3 [ip_vs] [] ? __lock_acquire+0x677/0x1697 [] ? native_sched_clock+0x3c/0x7d [] ? native_sched_clock+0x3c/0x7d [] ? sched_clock_cpu+0x43/0xcf [] ip_vs_schedule+0x181/0x4ba [ip_vs] ... Signed-off-by: Hans Schillstrom Acked-by: Julian Anastasov Signed-off-by: Simon Horman Signed-off-by: David S. Miller Cc: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 5e23729b22a8ec773f4545bf4a0d0abc3c90d4ba Author: Peter Zijlstra Date: Fri May 3 14:11:25 2013 +0200 perf/x86/intel/lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL commit 7cc23cd6c0c7d7f4bee057607e7ce01568925717 upstream. We should always have proper privileges when requesting kernel data. Signed-off-by: Peter Zijlstra Cc: Andi Kleen Cc: eranian@google.com Link: http://lkml.kernel.org/r/20130503121256.230745028@chello.nl [ Fix build error reported by fengguang.wu@intel.com, propagate error code back. ] Signed-off-by: Ingo Molnar Link: http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwrili@git.kernel.org Signed-off-by: Greg Kroah-Hartman commit d851a41c72181e5170a3a81fa124c678bd449a1c Author: Peter Zijlstra Date: Fri May 3 14:11:24 2013 +0200 perf/x86/intel/lbr: Fix LBR filter commit 6e15eb3ba6c0249c9e8c783517d131b47db995ca upstream. The LBR 'from' adddress is under full userspace control; ensure we validate it before reading from it. Note: is_module_text_address() can potentially be quite expensive; for those running into that with high overhead in modules optimize it using an RCU backed rb-tree. Reported-by: Andi Kleen Signed-off-by: Peter Zijlstra Cc: eranian@google.com Link: http://lkml.kernel.org/r/20130503121256.158211806@chello.nl Signed-off-by: Ingo Molnar Link: http://lkml.kernel.org/n/tip-mk8i82ffzax01cnqo829iy1q@git.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1a2d6c494667deb43c5dfca27b719a1446a1d641 Author: Peter Zijlstra Date: Fri May 3 14:11:23 2013 +0200 perf/x86: Blacklist all MEM_*_RETIRED events for Ivy Bridge commit 741a698f420c34c458294a6accecfbad702a7c52 upstream. Errata BV98 states that all MEM_*_RETIRED events corrupt the counter value of the SMT sibling's counters. Blacklist these events Reported-by: Andi Kleen Signed-off-by: Peter Zijlstra Cc: eranian@google.com Link: http://lkml.kernel.org/r/20130503121256.083340271@chello.nl Signed-off-by: Ingo Molnar Link: http://lkml.kernel.org/n/tip-jwra43mujrv1oq9xk6mfe57v@git.kernel.org Signed-off-by: Greg Kroah-Hartman commit 358247fd37fbb17ac043548f0921d45d4f0009e2 Author: Jan-Simon Möller Date: Tue Apr 30 12:02:33 2013 +0200 perf/x86/intel: Fix unintended variable name reuse commit 1b0dac2ac6debdbf1541e15f2cede03613cf4465 upstream. The variable name events_group is already in used and led to a compilation error when using clang to build the Linux Kernel . The fix is just to rename the var. No functional change. Please apply. Fix suggested in discussion by PaX Team Signed-off-by: Jan-Simon Möller Cc: rostedt@goodmis.org Cc: a.p.zijlstra@chello.nl Cc: paulus@samba.org Cc: acme@ghostprotocols.net Link: http://lkml.kernel.org/r/1367316153-14808-1-git-send-email-dl9pf@gmx.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 4d9a5a21e6c7b3dbcb2d20554f815037dbbe17e9 Author: Vince Weaver Date: Mon Apr 29 15:52:27 2013 -0400 perf/x86/intel: Add support for IvyBridge model 58 Uncore commit 9a6bc14350b130427725f33e371e86212fa56c85 upstream. According to Intel Vol3b 18.9, the IvyBridge model 58 uncore is the same as that of SandyBridge. I've done some simple tests and with this patch things seem to work on my mac-mini. Signed-off-by: Vince Weaver Cc: Peter Zijlstra Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Cc: Stephane Eranian Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1304291549320.15827@vincent-weaver-1.um.maine.edu Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e21673211b417ab7177ffbc1dfd3b410db303bfc Author: Benjamin Herrenschmidt Date: Fri May 3 17:19:01 2013 +0000 net/eth/ibmveth: Fixup retrieval of MAC address commit 13f85203e1060da83d9ec1c1c5a63343eaab8de4 upstream. Some ancient pHyp versions used to create a 8 bytes local-mac-address property in the device-tree instead of a 6 bytes one for veth. The Linux driver code to deal with that is an insane hack which also happens to break with some choices of MAC addresses in qemu by testing for a bit in the address rather than just looking at the size of the property. Sanitize this by doing the latter instead. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 29e671b541848c4f0e0a3f55d249e1975e6c512a Author: Benjamin Poirier Date: Mon Apr 15 10:13:50 2013 -0400 menuconfig: Fix memory leak introduced by jump keys feature commit edb749f4390b3c1604233dc7c4fb0361f472e712 upstream. Fixes the memory leak of struct jump_key allocated in get_prompt_str() Signed-off-by: Benjamin Poirier Tested-by: "Yann E. MORIN" Reviewed-by: "Yann E. MORIN" Signed-off-by: "Yann E. MORIN" Signed-off-by: Greg Kroah-Hartman commit 8957e4463fbfb88d2ee0732156c17ffadd582f38 Author: Joerg Roedel Date: Tue Apr 9 21:14:08 2013 +0200 iommu/amd: Properly initialize irq-table lock commit 197887f03daecdb3ae21bafeb4155412abad3497 upstream. Fixes a lockdep warning. Reviewed-by: Shuah Khan Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 7d65bdce33740070101dd6fb366f1bac003a9a49 Author: Naoya Horiguchi Date: Tue May 7 16:18:13 2013 -0700 hugetlbfs: fix mmap failure in unaligned size request commit af73e4d9506d3b797509f3c030e7dcd554f7d9c4 upstream. The current kernel returns -EINVAL unless a given mmap length is "almost" hugepage aligned. This is because in sys_mmap_pgoff() the given length is passed to vm_mmap_pgoff() as it is without being aligned with hugepage boundary. This is a regression introduced in commit 40716e29243d ("hugetlbfs: fix alignment of huge page requests"), where alignment code is pushed into hugetlb_file_setup() and the variable len in caller side is not changed. To fix this, this patch partially reverts that commit, and adds alignment code in caller side. And it also introduces hstate_sizelog() in order to get proper hstate to specified hugepage size. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=56881 [akpm@linux-foundation.org: fix warning when CONFIG_HUGETLB_PAGE=n] Signed-off-by: Naoya Horiguchi Signed-off-by: Johannes Weiner Reported-by: Cc: Steven Truelove Cc: Jianguo Wu Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bf48b33314ca19cfe861bea3cc1c136441eba3cd Author: Suman Anna Date: Sun Apr 21 16:29:38 2013 +0300 remoteproc: fix kconfig dependencies for VIRTIO commit b9777859ec015a78dae1476e317d04f851bfdd0d upstream. Fix this: warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION) Signed-off-by: Suman Anna [edit commit log] Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman commit 26b2089d1e21d5302592948e7d49169f5e221951 Author: Suman Anna Date: Sun Apr 21 16:32:29 2013 +0300 rpmsg: fix kconfig dependencies for VIRTIO commit 397944df3290ddc46dcc6a08cd71fb560700431b upstream. Fix this: warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION) Signed-off-by: Suman Anna [edit commit log] Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman commit 112fc9f4b4575cec60c743e37196c7c28e72049e Author: David Jeffery Date: Mon May 6 13:49:30 2013 +0800 autofs - remove autofs dentry mount check commit ce8a5dbdf9e709bdaf4618d7ef8cceb91e8adc69 upstream. When checking if an autofs mount point is busy it isn't sufficient to only check if it's a mount point. For example, if the mount of an offset mountpoint in a tree is denied for this host by its export and the dentry becomes a process working directory the check incorrectly returns the mount as not in use at expire. This can happen since the default when mounting within a tree is nostrict, which means ingnore mount fails on mounts within the tree and continue. The nostrict option is meant to allow mounting in this case. Signed-off-by: David Jeffery Signed-off-by: Ian Kent Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5412ac35167ce8bb266391f3b620ab7250ff9d3e Author: Axel Lin Date: Sat Mar 30 20:43:22 2013 +0800 pwm: spear: Fix checking return value of clk_enable() and clk_prepare() commit 563861cd633ae52932843477bb6ca3f1c9e2f78b upstream. The logic to check return value of clk_enable() and clk_prepare() is reversed, fix it. Signed-off-by: Axel Lin Acked-by: Viresh Kumar Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit f63a3b86960177bca59f29eb5c71e3c2fb3e91aa Author: Vaidyanathan Srinivasan Date: Fri Mar 22 05:49:35 2013 +0000 powerpc: fix numa distance for form0 device tree commit 7122beeee7bc1757682049780179d7c216dd1c83 upstream. The following commit breaks numa distance setup for old powerpc systems that use form0 encoding in device tree. commit 41eab6f88f24124df89e38067b3766b7bef06ddb powerpc/numa: Use form 1 affinity to setup node distance Device tree node /rtas/ibm,associativity-reference-points would index into /cpus/PowerPCxxxx/ibm,associativity based on form0 or form1 encoding detected by ibm,architecture-vec-5 property. All modern systems use form1 and current kernel code is correct. However, on older systems with form0 encoding, the numa distance will get hard coded as LOCAL_DISTANCE for all nodes. This causes task scheduling anomaly since scheduler will skip building numa level domain (topmost domain with all cpus) if all numa distances are same. (value of 'level' in sched_init_numa() will remain 0) Prior to the above commit: ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE) Restoring compatible behavior with this patch for old powerpc systems with device tree where numa distance are encoded as form0. Signed-off-by: Vaidyanathan Srinivasan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 4a32fbd0b67057a94dbd173ed85114aa46e32dfb Author: Michael Neuling Date: Thu May 2 15:36:14 2013 +0000 powerpc/tm: Fix null pointer deference in flush_hash_page commit c2fd22df89365df9451d5b91da3b7bfd48122ecd upstream. Make sure that current->thread.reg exists before we deference it in flush_hash_page. Signed-off-by: Michael Neuling Reported-by: John J Miller Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 5e701b123c0d3c58c01d3168de9ef11d86eea34d Author: Anton Blanchard Date: Wed May 1 20:06:33 2013 +0000 powerpc: Emulate non privileged DSCR read and write commit 73d2fb758e678c93bc76d40876c2359f0729b0ef upstream. POWER8 allows read and write of the DSCR in userspace. We added kernel emulation so applications could always use the instructions regardless of the CPU type. Unfortunately there are two SPRs for the DSCR and we only added emulation for the privileged one. Add code to match the non privileged one. A simple test was created to verify the fix: http://ozlabs.org/~anton/junkcode/user_dscr_test.c Without the patch we get a SIGILL and it passes with the patch. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b6356ec0a242fd362019bd1f08680fb8f413af4a Author: Stefano Stabellini Date: Thu Apr 25 13:53:09 2013 +0000 xen/arm: actually pass a non-NULL percpu pointer to request_percpu_irq commit 2798ba7d19aed645663398a21ec4006bfdbb1ef3 upstream. Signed-off-by: Stefano Stabellini Reviewed-by: Ian Campbell Signed-off-by: Greg Kroah-Hartman