- Apr 06, 2013
-
-
Daniel Vetter authored
The behaviour around handling the eDP bpp value from vbt has been slightly changed in commit 36008365 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure The old behaviour was that we used the plane's bpp (usually 24bpp) for computing the dp link bw, but set up the pipe with the bpp value from vbt if available. This takes the vbt bpp override into account even for the dp link bw configuration. On Paulo's hsw machine this resulted in a slower link clock and a black screen - but the mode actually /should/ fit even with the lower clock. Until we've cleared up simply stay bug-for-bug compatible with the old code. While at it, also restore a debug message lost in: commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This reverts commit deb18211 . It completely breaks the logic, since when we fall through to the end of the function we actually _have_ figured out the correct pipe. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
VLV has the color range selection bit in the PIPECONF register. Configure it appropriately. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> [danvet: fixup rebase issues due to slightly different baseline.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Prep-patch to improve the bpc handling in a next patch. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Christian Lamparter authored
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 <chunkeey@googlemail.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Apr 03, 2013
-
-
Daniel Vetter authored
Clock computations and handling are highly encoder specific, both in the optimal clock selection and also in which clocks to use and when sharing of clocks is possible. So the best place to do this is somewhere in the encoders, with a generic fallback for those encoders without special needs. To facility this, add a pipe_config->clocks_set boolean. This patch here is only prep work, it simply sets the computed clock values in pipe_config->dpll, and uses that data in the hw clock setting functions. Haswell code isn't touched, simply because Haswell clocks work much different and need their own infrastructure (with probably a Haswell-specific config->ddi_clock substruct). Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now we can ditch the checks in the Haswell disable code. v2: add support for Haswell Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We need to be able to read out the hw state code for a bunch of reasons: - Correctly disabling boot-up/resume state. - Pure paranoia. Since not all of the pipe configuration is e.g. relevant for fastboot (or at least we can allow some wiggle room in some parameters, like the clocks), we need to add a strict_checking parameter to intel_pipe_config_compare for fastboot. For now intel_pipe_config_compare should be fully paranoid and check everything that the hw state readout code supports. Which for this infrastructure code is nothing. I've gone a bit overboard with adding 3 get_pipe_config functions: The ilk version will differ with the next patch, so it's not too onerous. v2: Don't check the hw config if the pipe is off, since an enabled, but dpms off crtc will obviously have tons of difference with the hw state. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
The only exception left is is_cpu_edp in the haswell modeset code. We need that to assign the cpu transcoder, but we might want to move that eventually into the encoder, too. \o/-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Jesse Barnes noticed in his review of my DP cleanup series that intel_edp_target_clock is now unused. Checking related code I've noticed that also intel_edp_link_config is long unused. Kill them both. Wrt leaky eDP functions used in the common crtc code, the only thing still left is intel_encoder_is_pch_edp. That one is just due to the massive confusion between eDP vs. DP and port A vs. port D. Crtc code should at most concern itself with the later, never with the former. But that's material for another patch series. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We need it in the fdi m_n computation, which nicely kills almost all ugly special cases in there. It looks like we also need this to handle 12bpc hdmi correctly. Eventually it might be better to switch things around and put the target clock into adjusted_mode->clock and create a new pipe_config parameter for the port link clock. v2: Add a massive comment in the code to explain this mess. v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi use-case. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We need a flag to designate dp encoders and the dp link m_n parameters in the pipe config for that. And now that the pipe bpp computations have been moved up and stored in the pipe config, too, we can do this without losing our sanity. v2: Rebased on top of Takashi Iwai's fix to (again) fix the target clock handling for eDP. Luckily the new code is sane enough and just does the right thing! v3: Move ->has_dp_encoder to this patch (Jesse). Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
There's a rather decent confusion going on around transcoder m_n values. So let's clarify: - All dp encoders need this, either on the pch transcoder if it's a pch port, or on the cpu transcoder/pipe if it's a cpu port. - fdi links need to have the right m_n values for the fdi link set in the cpu transcoder. To handle the pch vs transcoder stuff a bit better, extract transcoder set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n registers are all at the same offset) can use it. Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs. edp works exactly the same as dp (since there's no pch dp any more), so use that as a check. And only set up the fdi m_n values if we really have a pch encoder present (which means we have a VGA encoder). On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch encoders. Now that dp_set_m_n handles all dp links (thanks to the pch encoder check), we can ditch the cpu_edp stuff from the fdi_set_m_n function. Since the dp_m_n values are not readily available, we need to carefully coax the edp values out of the encoder. Hence we can't (yet) kill this superflous complexity. v2: Rebase on top of the ivb fdi B/C check patch - we need to properly clear intel_crtc->fdi_lane, otherwise those checks will misfire. v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni. v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse). Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups for -next, but they will conflict all over the place with commit 9d1a455b Author: Takashi Iwai <tiwai@suse.de> Date: Mon Mar 18 11:25:36 2013 +0100 drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() from -fixes. Conflicts: drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed. drivers/gpu/drm/i915/intel_panel.c: A field rename in -next conflicts with a bugfix in -fixes. Take the version from -fixes and apply the rename. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
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 <eich@pdx.freedesktop.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Egbert Eich <eich@pdx.freedesktop.org> (v2) Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
We don't need this until we start using the wait event commands. v2: move to i915_irq.c (Jesse) drop unneeded sprite flip done enables (Ville) v3: drop the DPFLIPSTAT enables altogether (Ville) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Slightly different than other platforms. v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine. v3: drop turbo defines from this patch (Ville) use PCI_DEVFN(2,0) instead of open coding (Ville) Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> [danvet: Add checkpatch bikeshed about missing space.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
PPS register offsets have changed in Valleyview. v2: don't clobber port select bits on VLV when fixing up PPS timings don't bother with G4x PPS regs (Jani) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Needed to handle pre/post enable/disable paths on VLV and avoid a few fields that are marked reserved on VLV. v2: don't set color range or DP PLL fields (Jani) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Need to make sure sprites are disabled before shutting off a pipe. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
No constant alpha yet though, that needs a new ioctl and/or property to get/set. v2: use drm_plane_format_cpp (Ville) fix up vlv_disable_plane, remove IVB bits (Ville) remove error path rework (Ville) fix component order confusion (Ville) clean up platform init (Ville) use compute_offset_xtiled (Ville) v3: fix up more format confusion (Ville) update to new page offset function (Ville) v4: remove incorrect formats from framebuffer_init (Ville) Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Modifying the clock sources (via the DREF control on the PCH) is a slow multi-stage process as we need to let the clocks stabilise between each stage. If we are not actually changing the clock sources, then we can return early. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> [danvet: Appease checkpatch by deleting a space after a ~] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Apr 02, 2013
-
-
Jani Nikula authored
No functional changes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Earlier code would leave both bits set, so any reset after the first would only reset media. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- Apr 01, 2013
-
-
Linus Torvalds authored
-
git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds authored
Pull slave-dmaengine fixes from Vinod Koul: "Two fixes for slave-dmaengine. The first one is for making slave_id value correct for dw_dmac and the other one fixes the endieness in DT parsing" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dw_dmac: adjust slave_id accordingly to request line base dmaengine: dw_dma: fix endianess for DT xlate function
-
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-mediaLinus Torvalds authored
Pull media fixes from Mauro Carvalho Chehab: "For a some fixes for Kernel 3.9: - subsystem build fix when VIDEO_DEV=y, VIDEO_V4L2=m and I2C=m - compilation fix for arm multiarch preventing IR_RX51 to be selected - regression fix at bttv crop logic - s5p-mfc/m5mols/exynos: a few fixes for cameras on exynos hardware" * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] [REGRESSION] bt8xx: Fix too large height in cropcap [media] fix compilation with both V4L2 and I2C as 'm' [media] m5mols: Fix bug in stream on handler [media] s5p-fimc: Do not attempt to disable not enabled media pipeline [media] s5p-mfc: Fix encoder control 15 issue [media] s5p-mfc: Fix frame skip bug [media] s5p-fimc: send valid m2m ctx to fimc_m2m_job_finish [media] exynos-gsc: send valid m2m ctx to gsc_m2m_job_finish [media] fimc-lite: Fix the variable type to avoid possible crash [media] fimc-lite: Initialize 'step' field in fimc_lite_ctrl structure [media] ir: IR_RX51 only works on OMAP2
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block fixes from Jens Axboe: "Alright, this time from 10K up in the air. Collection of fixes that have been queued up since the merge window opened, hence postponed until later in the cycle. The pull request contains: - A bunch of fixes for the xen blk front/back driver. - A round of fixes for the new IBM RamSan driver, fixing various nasty issues. - Fixes for multiple drives from Wei Yongjun, bad handling of return values and wrong pointer math. - A fix for loop properly killing partitions when being detached." * tag 'for-linus-20130331' of git://git.kernel.dk/linux-block: (25 commits) mg_disk: fix error return code in mg_probe() rsxx: remove unused variable rsxx: enable error return of rsxx_eeh_save_issued_dmas() block: removes dynamic allocation on stack Block: blk-flush: Fixed indent code style cciss: fix invalid use of sizeof in cciss_find_cfgtables() loop: cleanup partitions when detaching loop device loop: fix error return code in loop_add() mtip32xx: fix error return code in mtip_pci_probe() xen-blkfront: remove frame list from blk_shadow xen-blkfront: pre-allocate pages for requests xen-blkback: don't store dev_bus_addr xen-blkfront: switch from llist to list xen-blkback: fix foreach_grant_safe to handle empty lists xen-blkfront: replace kmalloc and then memcpy with kmemdup xen-blkback: fix dispatch_rw_block_io() error path rsxx: fix missing unlock on error return in rsxx_eeh_remap_dmas() Adding in EEH support to the IBM FlashSystem 70/80 device driver block: IBM RamSan 70/80 error message bug fix. block: IBM RamSan 70/80 branding changes. ...
-
Paul Walmsley authored
This reverts commit 6aa97070. Commit 6aa97070 ("lockdep: check that no locks held at freeze time") causes problems with NFS root filesystems. The failures were noticed on OMAP2 and 3 boards during kernel init: [ BUG: swapper/0/1 still has locks held! ] 3.9.0-rc3-00344-ga937536 #1 Not tainted ------------------------------------- 1 lock held by swapper/0/1: #0: (&type->s_umount_key#13/1){+.+.+.}, at: [<c011e84c>] sget+0x248/0x574 stack backtrace: rpc_wait_bit_killable __wait_on_bit out_of_line_wait_on_bit __rpc_execute rpc_run_task rpc_call_sync nfs_proc_get_root nfs_get_root nfs_fs_mount_common nfs_try_mount nfs_fs_mount mount_fs vfs_kern_mount do_mount sys_mount do_mount_root mount_root prepare_namespace kernel_init_freeable kernel_init Although the rootfs mounts, the system is unstable. Here's a transcript from a PM test: http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130317194234/pm/37xxevm/37xxevm_log.txt Here's what the test log should look like: http://www.pwsan.com/omap/testlogs/test_v3.8/20130218214403/pm/37xxevm/37xxevm_log.txt Mailing list discussion is here: http://lkml.org/lkml/2013/3/4/221 Deal with this for v3.9 by reverting the problem commit, until folks can figure out the right long-term course of action. Signed-off-by:
Paul Walmsley <paul@pwsan.com> Cc: Mandeep Singh Baines <msb@chromium.org> Cc: Jeff Layton <jlayton@redhat.com> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: <maciej.rutecki@gmail.com> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Ben Chan <benchan@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Mar 31, 2013
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pendingLinus Torvalds authored
Pull SCSI target fixes from Nicholas Bellinger: "This includes the bug-fix for a >= v3.8-rc1 regression specific to iscsi-target persistent reservation conflict handling (CC'ed to stable), and a tcm_vhost patch to drop VIRTIO_RING_F_EVENT_IDX usage so that in-flight qemu vhost-scsi-pci device code can detect the proper vhost feature bits. Also, there are two more tcm_vhost patches still being discussed by MST and Asias for v3.9 that will be required for the in-flight qemu vhost-scsi-pci device patch to function properly, and that should (hopefully) be the last target fixes for this round." * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: target: Fix RESERVATION_CONFLICT status regression for iscsi-target special case tcm_vhost: Avoid VIRTIO_RING_F_EVENT_IDX feature bit
-
- Mar 30, 2013
-
-
Andy Shevchenko authored
On some hardware configurations we have got the request line with the offset. The patch introduces convert_slave_id() helper for that cases. The request line base is came from the driver data provided by the platform_device_id table. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Vinod Koul <vinod.koul@intel.com>
-
Arnd Bergmann authored
As reported by Wu Fengguang's build robot tracking sparse warnings, the dma_spec arguments in the dw_dma_xlate are already byte swapped on little-endian platforms and must not get swapped again. This code is currently not used anywhere, but will be used in Linux 3.10 when the ARM SPEAr platform starts using the generic DMA DT binding. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Vinod Koul <vinod.koul@intel.com>
-
Rafael J. Wysocki authored
The Adam Belay's e-mail address in MAINTAINERS under PNP SUPPORT is not valid any more and I started to maintain that code in the meantime as a matter of fact, so list myself as a maintainer of it along with Bjorn and remove the Adam's entry from it. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-clientLinus Torvalds authored
Pull ceph fix from Sage Weil: "This fixes a regression introduced during the last merge window when mapping non-existent images." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client: rbd: don't zero-fill non-image object requests
-
Alex Elder authored
A result of ENOENT from a read request for an object that's part of an rbd image indicates that there is a hole in that portion of the image. Similarly, a short read for such an object indicates that the remainder of the read should be interpreted a full read with zeros filling out the end of the request. This behavior is not correct for objects that are not backing rbd image data. Currently rbd_img_obj_request_callback() assumes it should be done for all objects. Change rbd_img_obj_request_callback() so it only does this zeroing for image objects. Encapsulate that special handling in its own function. Add an assertion that the image object request is a bio request, since we assume that (and we currently don't support any other types). This resolves a problem identified here: http://tracker.ceph.com/issues/4559 The regression was introduced by bf0d5f50 . Reported-by:
Dan van der Ster <dan@vanderster.com> Signed-off-by:
Alex Elder <elder@inktank.com> Reviewed-off-by:
Sage Weil <sage@inktank.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfsLinus Torvalds authored
Pull btrfs fixes from Chris Mason: "We've had a busy two weeks of bug fixing. The biggest patches in here are some long standing early-enospc problems (Josef) and a very old race where compression and mmap combine forces to lose writes (me). I'm fairly sure the mmap bug goes all the way back to the introduction of the compression code, which is proof that fsx doesn't trigger every possible mmap corner after all. I'm sure you'll notice one of these is from this morning, it's a small and isolated use-after-free fix in our scrub error reporting. I double checked it here." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs: Btrfs: don't drop path when printing out tree errors in scrub Btrfs: fix wrong return value of btrfs_lookup_csum() Btrfs: fix wrong reservation of csums Btrfs: fix double free in the btrfs_qgroup_account_ref() Btrfs: limit the global reserve to 512mb Btrfs: hold the ordered operations mutex when waiting on ordered extents Btrfs: fix space accounting for unlink and rename Btrfs: fix space leak when we fail to reserve metadata space Btrfs: fix EIO from btrfs send in is_extent_unchanged for punched holes Btrfs: fix race between mmap writes and compression Btrfs: fix memory leak in btrfs_create_tree() Btrfs: fix locking on ROOT_REPLACE operations in tree mod log Btrfs: fix missing qgroup reservation before fallocating Btrfs: handle a bogus chunk tree nicely Btrfs: update to use fs_state bit
-
Len Brown authored
Commit 3e7fc708 ("ia64 idle: delete pm_idle") in 3.9-rc1 didn't finish the job, leaving an un-initialized reference to (*idle)(). [ Haven't seen a crash from this - but seems like we are just being lucky that "idle" is zero so it does get initialized before we jump to randomland - Len ] Reported-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-