--- /dev/null
+From ba84cd1f2b5dd49bda9300c5a11373f7e14c3c66 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Wed, 24 Nov 2010 17:37:17 +0000
+Subject: drm/i915/sdvo: Always add a 30ms delay to make SDVO TV detection reliable
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit ba84cd1f2b5dd49bda9300c5a11373f7e14c3c66 upstream.
+
+Commit d09c23de intended to add a 30ms delay to give the ADD time to
+detect any TVs connected. However, it used the sdvo->is_tv flag to do so
+which is dependent upon the previous detection result and not whether the
+output supports TVs.
+
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/intel_sdvo.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_sdvo.c
++++ b/drivers/gpu/drm/i915/intel_sdvo.c
+@@ -1498,10 +1498,12 @@ intel_sdvo_detect(struct drm_connector *
+ if (!intel_sdvo_write_cmd(intel_sdvo,
+ SDVO_CMD_GET_ATTACHED_DISPLAYS, NULL, 0))
+ return connector_status_unknown;
+- if (intel_sdvo->is_tv) {
+- /* add 30ms delay when the output type is SDVO-TV */
++
++ /* add 30ms delay when the output type might be TV */
++ if (intel_sdvo->caps.output_flags &
++ (SDVO_OUTPUT_SVID0 | SDVO_OUTPUT_CVBS0))
+ mdelay(30);
+- }
++
+ if (!intel_sdvo_read_response(intel_sdvo, &response, 2))
+ return connector_status_unknown;
+
--- /dev/null
+From 48fcfc888b48ad49dd83faa107264bbfb0089cad Mon Sep 17 00:00:00 2001
+From: Kyle McMartin <kyle@redhat.com>
+Date: Wed, 3 Nov 2010 16:27:57 -0400
+Subject: i915: reprogram power monitoring registers on resume
+
+From: Kyle McMartin <kyle@redhat.com>
+
+commit 48fcfc888b48ad49dd83faa107264bbfb0089cad upstream.
+
+Fixes issue where i915_gfx_val was reporting values several
+orders of magnitude higher than physically possible (without
+leaving scorch marks on my thighs at least.)
+
+Signed-off-by: Kyle McMartin <kyle@redhat.com>
+Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/gpu/drm/i915/i915_suspend.c | 4 +++-
+ drivers/gpu/drm/i915/intel_drv.h | 1 +
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/i915_suspend.c
++++ b/drivers/gpu/drm/i915/i915_suspend.c
+@@ -862,8 +862,10 @@ int i915_restore_state(struct drm_device
+ /* Clock gating state */
+ intel_init_clock_gating(dev);
+
+- if (HAS_PCH_SPLIT(dev))
++ if (HAS_PCH_SPLIT(dev)) {
+ ironlake_enable_drps(dev);
++ intel_init_emon(dev);
++ }
+
+ /* Cache mode state */
+ I915_WRITE (CACHE_MODE_0, dev_priv->saveCACHE_MODE_0 | 0xffff0000);
+--- a/drivers/gpu/drm/i915/intel_drv.h
++++ b/drivers/gpu/drm/i915/intel_drv.h
+@@ -250,6 +250,7 @@ extern void intel_crtc_fb_gamma_get(stru
+ extern void intel_init_clock_gating(struct drm_device *dev);
+ extern void ironlake_enable_drps(struct drm_device *dev);
+ extern void ironlake_disable_drps(struct drm_device *dev);
++extern void intel_init_emon(struct drm_device *dev);
+
+ extern int intel_pin_and_fence_fb_obj(struct drm_device *dev,
+ struct drm_gem_object *obj);
--- /dev/null
+From e5e408fc94595aab897f613b6f4e2f5b36870a6f Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Sat, 28 Aug 2010 11:04:32 +0200
+Subject: intel-gtt: fix gtt_total_entries detection
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit e5e408fc94595aab897f613b6f4e2f5b36870a6f upstream.
+
+In commit f1befe71 Chris Wilson added some code to clear the full gtt
+on g33/pineview instead of just the mappable part. The code looks like
+it was copy-pasted from agp/intel-gtt.c, at least an identical piece
+of code is still there (in intel_i830_init_gtt_entries). This lead to
+a regression in 2.6.35 which was supposedly fixed in commit e7b96f28
+
+Now this commit makes absolutely no sense to me. It seems to be
+slightly confused about chipset generations - it references docs for
+4th gen but the regression concerns 3rd gen g33. Luckily the the g33
+gmch docs are available with the GMCH Graphics Control pci config
+register definitions. The other (bigger problem) is that the new
+check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen
+mem). They are different since the i855GM.
+
+The most likely case is that it hits the 512M fallback, which was
+probably the right thing for the boxes this was tested on.
+
+So the original approach by Chris Wilson seems to be wrong and the
+current code is definitely wrong. There is a third approach by Jesse
+Barnes from his RFC patch "Who wants a bigger GTT mapping range?"
+where he simply shoves g33 in the same clause like later chipset
+generations.
+
+I've asked him and Jesse confirmed that this should work. So implement
+it.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$
+Tested-by: Anisse Astier <anisse@astier.eu>
+Signed-off-by: Anisse Astier <anisse@astier.eu>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/char/agp/intel-gtt.c | 63 ++++++++++++++++++-------------------------
+ 1 file changed, 27 insertions(+), 36 deletions(-)
+
+--- a/drivers/char/agp/intel-gtt.c
++++ b/drivers/char/agp/intel-gtt.c
+@@ -534,7 +534,7 @@ static void intel_i830_init_gtt_entries(
+
+ pci_read_config_word(agp_bridge->dev, I830_GMCH_CTRL, &gmch_ctrl);
+
+- if (IS_I965) {
++ if (IS_G33 || IS_I965) {
+ u32 pgetbl_ctl;
+ pgetbl_ctl = readl(intel_private.registers+I810_PGETBL_CTL);
+
+@@ -567,22 +567,6 @@ static void intel_i830_init_gtt_entries(
+ size = 512;
+ }
+ size += 4; /* add in BIOS popup space */
+- } else if (IS_G33 && !IS_PINEVIEW) {
+- /* G33's GTT size defined in gmch_ctrl */
+- switch (gmch_ctrl & G33_PGETBL_SIZE_MASK) {
+- case G33_PGETBL_SIZE_1M:
+- size = 1024;
+- break;
+- case G33_PGETBL_SIZE_2M:
+- size = 2048;
+- break;
+- default:
+- dev_info(&agp_bridge->dev->dev,
+- "unknown page table size 0x%x, assuming 512KB\n",
+- (gmch_ctrl & G33_PGETBL_SIZE_MASK));
+- size = 512;
+- }
+- size += 4;
+ } else if (IS_G4X || IS_PINEVIEW) {
+ /* On 4 series hardware, GTT stolen is separate from graphics
+ * stolen, ignore it in stolen gtt entries counting. However,
+@@ -1257,24 +1241,31 @@ static int intel_i915_get_gtt_size(void)
+ int size;
+
+ if (IS_G33) {
+- u16 gmch_ctrl;
++ u32 pgetbl_ctl;
++ pgetbl_ctl = readl(intel_private.registers+I810_PGETBL_CTL);
+
+- /* G33's GTT size defined in gmch_ctrl */
+- pci_read_config_word(agp_bridge->dev, I830_GMCH_CTRL, &gmch_ctrl);
+- switch (gmch_ctrl & I830_GMCH_GMS_MASK) {
+- case I830_GMCH_GMS_STOLEN_512:
++ switch (pgetbl_ctl & I965_PGETBL_SIZE_MASK) {
++ case I965_PGETBL_SIZE_128KB:
++ size = 128;
++ break;
++ case I965_PGETBL_SIZE_256KB:
++ size = 256;
++ break;
++ case I965_PGETBL_SIZE_512KB:
+ size = 512;
+ break;
+- case I830_GMCH_GMS_STOLEN_1024:
++ case I965_PGETBL_SIZE_1MB:
+ size = 1024;
+ break;
+- case I830_GMCH_GMS_STOLEN_8192:
+- size = 8*1024;
++ case I965_PGETBL_SIZE_2MB:
++ size = 2048;
++ break;
++ case I965_PGETBL_SIZE_1_5MB:
++ size = 1024 + 512;
+ break;
+ default:
+- dev_info(&agp_bridge->dev->dev,
+- "unknown page table size 0x%x, assuming 512KB\n",
+- (gmch_ctrl & I830_GMCH_GMS_MASK));
++ dev_info(&intel_private.pcidev->dev,
++ "unknown page table size, assuming 512KB\n");
+ size = 512;
+ }
+ } else {
+@@ -1306,14 +1297,6 @@ static int intel_i915_create_gatt_table(
+ pci_read_config_dword(intel_private.pcidev, I915_MMADDR, &temp);
+ pci_read_config_dword(intel_private.pcidev, I915_PTEADDR, &temp2);
+
+- gtt_map_size = intel_i915_get_gtt_size();
+-
+- intel_private.gtt = ioremap(temp2, gtt_map_size);
+- if (!intel_private.gtt)
+- return -ENOMEM;
+-
+- intel_private.gtt_total_size = gtt_map_size / 4;
+-
+ temp &= 0xfff80000;
+
+ intel_private.registers = ioremap(temp, 128 * 4096);
+@@ -1322,6 +1305,14 @@ static int intel_i915_create_gatt_table(
+ return -ENOMEM;
+ }
+
++ gtt_map_size = intel_i915_get_gtt_size();
++
++ intel_private.gtt = ioremap(temp2, gtt_map_size);
++ if (!intel_private.gtt)
++ return -ENOMEM;
++
++ intel_private.gtt_total_size = gtt_map_size / 4;
++
+ temp = readl(intel_private.registers+I810_PGETBL_CTL) & 0xfffff000;
+ global_cache_flush(); /* FIXME: ? */
+
--- /dev/null
+From 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Mon, 1 Nov 2010 11:39:19 +0100
+Subject: libata: fix NULL sdev dereference race in atapi_qc_complete()
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 upstream.
+
+SCSI commands may be issued between __scsi_add_device() and dev->sdev
+assignment, so it's unsafe for ata_qc_complete() to dereference
+dev->sdev->locked without checking whether it's NULL or not. Fix it.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/libata-scsi.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/libata-scsi.c
++++ b/drivers/ata/libata-scsi.c
+@@ -2577,8 +2577,11 @@ static void atapi_qc_complete(struct ata
+ *
+ * If door lock fails, always clear sdev->locked to
+ * avoid this infinite loop.
++ *
++ * This may happen before SCSI scan is complete. Make
++ * sure qc->dev->sdev isn't NULL before dereferencing.
+ */
+- if (qc->cdb[0] == ALLOW_MEDIUM_REMOVAL)
++ if (qc->cdb[0] == ALLOW_MEDIUM_REMOVAL && qc->dev->sdev)
+ qc->dev->sdev->locked = 0;
+
+ qc->scsicmd->result = SAM_STAT_CHECK_CONDITION;
--- /dev/null
+From 8c05cd08a7504b855c265263e84af61aabafa329 Mon Sep 17 00:00:00 2001
+From: Darrick J. Wong <djwong@us.ibm.com>
+Date: Tue, 16 Nov 2010 09:13:41 -0800
+Subject: PCI: fix offset check for sysfs mmapped files
+
+From: Darrick J. Wong <djwong@us.ibm.com>
+
+commit 8c05cd08a7504b855c265263e84af61aabafa329 upstream.
+
+I just loaded 2.6.37-rc2 on my machines, and I noticed that X no longer starts.
+Running an strace of the X server shows that it's doing this:
+
+open("/sys/bus/pci/devices/0000:07:00.0/resource0", O_RDWR) = 10
+mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EINVAL (Invalid argument)
+
+This code seems to be asking for a shared read/write mapping of 16MB worth of
+BAR0 starting at file offset 0, and letting the kernel assign a starting
+address. Unfortunately, this -EINVAL causes X not to start. Looking into
+dmesg, there's a complaint like so:
+
+process "Xorg" tried to map 0x01000000 bytes at page 0x00000000 on 0000:07:00.0 BAR 0 (start 0x 96000000, size 0x 1000000)
+
+...with the following code in pci_mmap_fits:
+
+ pci_start = (mmap_api == PCI_MMAP_SYSFS) ?
+ pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
+ if (start >= pci_start && start < pci_start + size &&
+ start + nr <= pci_start + size)
+
+It looks like the logic here is set up such that when the mmap call comes via
+sysfs, the check in pci_mmap_fits wants vma->vm_pgoff to be between the
+resource's start and end address, and the end of the vma to be no farther than
+the end. However, the sysfs PCI resource files always start at offset zero,
+which means that this test always fails for programs that mmap the sysfs files.
+Given the comment in the original commit
+3b519e4ea618b6943a82931630872907f9ac2c2b, I _think_ the old procfs files
+require that the file offset be equal to the resource's base address when
+mmapping.
+
+I think what we want here is for pci_start to be 0 when mmap_api ==
+PCI_MMAP_PROCFS. The following patch makes that change, after which the Matrox
+and Mach64 X drivers work again.
+
+Acked-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
+Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/pci-sysfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/pci-sysfs.c
++++ b/drivers/pci/pci-sysfs.c
+@@ -715,7 +715,7 @@ int pci_mmap_fits(struct pci_dev *pdev,
+ nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ start = vma->vm_pgoff;
+ size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
+- pci_start = (mmap_api == PCI_MMAP_SYSFS) ?
++ pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
+ pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
+ if (start >= pci_start && start < pci_start + size &&
+ start + nr <= pci_start + size)
--- /dev/null
+From 3b519e4ea618b6943a82931630872907f9ac2c2b Mon Sep 17 00:00:00 2001
+From: Martin Wilck <martin.wilck@ts.fujitsu.com>
+Date: Wed, 10 Nov 2010 11:03:21 +0100
+Subject: PCI: fix size checks for mmap() on /proc/bus/pci files
+
+From: Martin Wilck <martin.wilck@ts.fujitsu.com>
+
+commit 3b519e4ea618b6943a82931630872907f9ac2c2b upstream.
+
+The checks for valid mmaps of PCI resources made through /proc/bus/pci files
+that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several
+problems:
+
+1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0,
+whereas under /sys/bus/pci/devices, the start of the resource corresponds
+to offset 0. This may lead to false negatives in pci_mmap_fits(), which
+implicitly assumes the /sys/bus/pci/devices layout.
+
+2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads
+to false positives, because pci_mmap_fits() doesn't treat empty resources
+correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT)
+in this case!).
+
+3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus
+WARNINGS for the first resources that don't fit until the correct one is found.
+
+On many controllers the first 2-4 BARs are used, and the others are empty.
+In this case, an mmap attempt will first fail on the non-empty BARs
+(including the "right" BAR because of 1.) and emit bogus WARNINGS because
+of 3., and finally succeed on the first empty BAR because of 2.
+This is certainly not the intended behaviour.
+
+This patch addresses all 3 issues.
+Updated with an enum type for the additional parameter for pci_mmap_fits().
+
+Signed-off-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/pci-sysfs.c | 22 ++++++++++++++++------
+ drivers/pci/pci.h | 7 ++++++-
+ drivers/pci/proc.c | 2 +-
+ 3 files changed, 23 insertions(+), 8 deletions(-)
+
+--- a/drivers/pci/pci-sysfs.c
++++ b/drivers/pci/pci-sysfs.c
+@@ -705,17 +705,21 @@ void pci_remove_legacy_files(struct pci_
+
+ #ifdef HAVE_PCI_MMAP
+
+-int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma)
++int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma,
++ enum pci_mmap_api mmap_api)
+ {
+- unsigned long nr, start, size;
++ unsigned long nr, start, size, pci_start;
+
++ if (pci_resource_len(pdev, resno) == 0)
++ return 0;
+ nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+ start = vma->vm_pgoff;
+ size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
+- if (start < size && size - start >= nr)
++ pci_start = (mmap_api == PCI_MMAP_SYSFS) ?
++ pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
++ if (start >= pci_start && start < pci_start + size &&
++ start + nr <= pci_start + size)
+ return 1;
+- WARN(1, "process \"%s\" tried to map 0x%08lx-0x%08lx on %s BAR %d (size 0x%08lx)\n",
+- current->comm, start, start+nr, pci_name(pdev), resno, size);
+ return 0;
+ }
+
+@@ -745,8 +749,14 @@ pci_mmap_resource(struct kobject *kobj,
+ if (i >= PCI_ROM_RESOURCE)
+ return -ENODEV;
+
+- if (!pci_mmap_fits(pdev, i, vma))
++ if (!pci_mmap_fits(pdev, i, vma, PCI_MMAP_SYSFS)) {
++ WARN(1, "process \"%s\" tried to map 0x%08lx bytes "
++ "at page 0x%08lx on %s BAR %d (start 0x%16Lx, size 0x%16Lx)\n",
++ current->comm, vma->vm_end-vma->vm_start, vma->vm_pgoff,
++ pci_name(pdev), i,
++ pci_resource_start(pdev, i), pci_resource_len(pdev, i));
+ return -EINVAL;
++ }
+
+ /* pci_mmap_page_range() expects the same kind of entry as coming
+ * from /proc/bus/pci/ which is a "user visible" value. If this is
+--- a/drivers/pci/pci.h
++++ b/drivers/pci/pci.h
+@@ -22,8 +22,13 @@ extern void pci_remove_firmware_label_fi
+ #endif
+ extern void pci_cleanup_rom(struct pci_dev *dev);
+ #ifdef HAVE_PCI_MMAP
++enum pci_mmap_api {
++ PCI_MMAP_SYSFS, /* mmap on /sys/bus/pci/devices/<BDF>/resource<N> */
++ PCI_MMAP_PROCFS /* mmap on /proc/bus/pci/<BDF> */
++};
+ extern int pci_mmap_fits(struct pci_dev *pdev, int resno,
+- struct vm_area_struct *vma);
++ struct vm_area_struct *vmai,
++ enum pci_mmap_api mmap_api);
+ #endif
+ int pci_probe_reset_function(struct pci_dev *dev);
+
+--- a/drivers/pci/proc.c
++++ b/drivers/pci/proc.c
+@@ -260,7 +260,7 @@ static int proc_bus_pci_mmap(struct file
+
+ /* Make sure the caller is mapping a real resource for this device */
+ for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+- if (pci_mmap_fits(dev, i, vma))
++ if (pci_mmap_fits(dev, i, vma, PCI_MMAP_PROCFS))
+ break;
+ }
+
--- /dev/null
+From 6506cf6ce68d78a5470a8360c965dafe8e4b78e3 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Thu, 16 Sep 2010 17:50:31 +0200
+Subject: sched: fix RCU lockdep splat from task_group()
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 6506cf6ce68d78a5470a8360c965dafe8e4b78e3 upstream.
+
+This addresses the following RCU lockdep splat:
+
+[0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
+[0.052999] lockdep: fixing up alternatives.
+[0.054105]
+[0.054106] ===================================================
+[0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
+[0.054999] ---------------------------------------------------
+[0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
+[0.054999]
+[0.054999] other info that might help us debug this:
+[0.054999]
+[0.054999]
+[0.054999] rcu_scheduler_active = 1, debug_locks = 1
+[0.054999] 3 locks held by swapper/1:
+[0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be933>] cpu_up+0x42/0x6a
+[0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8>] cpu_hotplug_begin+0x2a/0x51
+[0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init_idle+0x2f/0x113
+[0.054999]
+[0.054999] stack backtrace:
+[0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
+[0.054999] Call Trace:
+[0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
+[0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
+[0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
+[0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
+[0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
+[0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
+[0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
+[0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
+[0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
+[0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
+[0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
+[0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
+[0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
+[0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
+[0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
+[0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
+[0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
+[0.130045] #2lockdep: fixing up alternatives.
+[0.203089] #3 Ok.
+[0.275286] Brought up 4 CPUs
+[0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
+
+The cgroup_subsys_state structures referenced by idle tasks are never
+freed, because the idle tasks should be part of the root cgroup,
+which is not removable.
+
+The problem is that while we do in-fact hold rq->lock, the newly spawned
+idle thread's cpu is not yet set to the correct cpu so the lockdep check
+in task_group():
+
+ lockdep_is_held(&task_rq(p)->lock)
+
+will fail.
+
+But this is a chicken and egg problem. Setting the CPU's runqueue requires
+that the CPU's runqueue already be set. ;-)
+
+So insert an RCU read-side critical section to avoid the complaint.
+
+Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/sched.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/kernel/sched.c
++++ b/kernel/sched.c
+@@ -5330,7 +5330,19 @@ void __cpuinit init_idle(struct task_str
+ idle->se.exec_start = sched_clock();
+
+ cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
++ /*
++ * We're having a chicken and egg problem, even though we are
++ * holding rq->lock, the cpu isn't yet set to this cpu so the
++ * lockdep check in task_group() will fail.
++ *
++ * Similar case to sched_fork(). / Alternatively we could
++ * use task_rq_lock() here and obtain the other rq->lock.
++ *
++ * Silence PROVE_RCU
++ */
++ rcu_read_lock();
+ __set_task_cpu(idle, cpu);
++ rcu_read_unlock();
+
+ rq->curr = rq->idle = idle;
+ #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
drm-radeon-kms-fix-interlaced-and-doublescan-handling.patch
exec-make-argv-envp-memory-visible-to-oom-killer.patch
exec-copy-and-paste-the-fixes-into-compat_do_execve-paths.patch
+drm-i915-sdvo-always-add-a-30ms-delay-to-make-sdvo-tv-detection-reliable.patch
+i915-reprogram-power-monitoring-registers-on-resume.patch
+intel-gtt-fix-gtt_total_entries-detection.patch
+sched-fix-rcu-lockdep-splat-from-task_group.patch
+libata-fix-null-sdev-dereference-race-in-atapi_qc_complete.patch
+pci-fix-size-checks-for-mmap-on-proc-bus-pci-files.patch
+pci-fix-offset-check-for-sysfs-mmapped-files.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
