From c511851de162e8ec03d62e7d7feecbdf590d881d Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 29 Oct 2013 13:12:56 +0100 Subject: [PATCH 1/3] Revert "epoll: use freezable blocking call" This reverts commit 1c441e921201 (epoll: use freezable blocking call) which is reported to cause user space memory corruption to happen after suspend to RAM. Since it appears to be extremely difficult to root cause this problem, it is best to revert the offending commit and try to address the original issue in a better way later. References: https://bugzilla.kernel.org/show_bug.cgi?id=61781 Reported-by: Natrio Reported-by: Jeff Pohlmeyer Bisected-by: Leo Wolf Fixes: 1c441e921201 (epoll: use freezable blocking call) Signed-off-by: Rafael J. Wysocki Cc: 3.11+ # 3.11+ --- fs/eventpoll.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/fs/eventpoll.c b/fs/eventpoll.c index 473e09da7d02..810c28fb8c3c 100644 --- a/fs/eventpoll.c +++ b/fs/eventpoll.c @@ -34,7 +34,6 @@ #include #include #include -#include #include #include #include @@ -1605,8 +1604,7 @@ fetch_events: } spin_unlock_irqrestore(&ep->lock, flags); - if (!freezable_schedule_hrtimeout_range(to, slack, - HRTIMER_MODE_ABS)) + if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS)) timed_out = 1; spin_lock_irqsave(&ep->lock, flags); From 59612d187912750f416fbffe0c00bc0811c54ab5 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 29 Oct 2013 23:43:08 +0100 Subject: [PATCH 2/3] Revert "select: use freezable blocking call" This reverts commit 9745cdb36da8 (select: use freezable blocking call) that triggers problems during resume from suspend to RAM on Paul Bolle's 32-bit x86 machines. Paul says: Ever since I tried running (release candidates of) v3.11 on the two working i686s I still have lying around I ran into issues on resuming from suspend. Reverting 9745cdb36da8 (select: use freezable blocking call) resolves those issues. Resuming from suspend on i686 on (release candidates of) v3.11 and later triggers issues like: traps: systemd[1] general protection ip:b738e490 sp:bf882fc0 error:0 in libc-2.16.so[b731c000+1b0000] and traps: rtkit-daemon[552] general protection ip:804d6e5 sp:b6cb32f0 error:0 in rtkit-daemon[8048000+d000] Once I hit the systemd error I can only get out of the mess that the system is at that point by power cycling it. Since we are reverting another freezer-related change causing similar problems to happen, this one should be reverted as well. References: https://lkml.org/lkml/2013/10/29/583 Reported-by: Paul Bolle Fixes: 9745cdb36da8 (select: use freezable blocking call) Signed-off-by: Rafael J. Wysocki Cc: 3.11+ # 3.11+ --- fs/select.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/select.c b/fs/select.c index 35d4adc749d9..dfd5cb18c012 100644 --- a/fs/select.c +++ b/fs/select.c @@ -238,8 +238,7 @@ int poll_schedule_timeout(struct poll_wqueues *pwq, int state, set_current_state(state); if (!pwq->triggered) - rc = freezable_schedule_hrtimeout_range(expires, slack, - HRTIMER_MODE_ABS); + rc = schedule_hrtimeout_range(expires, slack, HRTIMER_MODE_ABS); __set_current_state(TASK_RUNNING); /* From ab1225901da2d4cd2dcbae6840e93abbef417064 Mon Sep 17 00:00:00 2001 From: Mika Westerberg Date: Wed, 30 Oct 2013 14:40:36 +0200 Subject: [PATCH 3/3] Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious notifies" Commit 2dc4128 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) changed the enable_slot() to check return value of pci_scan_slot() and if it is zero return early from the function. It means that there were no new devices in this particular slot. However, if a device appeared deeper in the hierarchy the code now ignores it causing things like Thunderbolt chaining fail to recognize new devices. The problem with Alex Williamson's machine was solved with commit a47d8c8 (ACPI / hotplug / PCI: Avoid parent bus rescans on spurious device checks) and hence we should be able to restore the original functionality that we always rescan on bus check notification. On a device check notification we still check what acpiphp_rescan_slot() returns and on zero bail out early. Fixes: 2dc41281b1d1 (ACPI / hotplug / PCI: Avoid doing too much for spurious notifies) Signed-off-by: Mika Westerberg Tested-by: Alex Williamson Signed-off-by: Rafael J. Wysocki --- drivers/pci/hotplug/acpiphp_glue.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c index be12fbfcae10..1ea75236a15f 100644 --- a/drivers/pci/hotplug/acpiphp_glue.c +++ b/drivers/pci/hotplug/acpiphp_glue.c @@ -552,9 +552,8 @@ static void __ref enable_slot(struct acpiphp_slot *slot) struct acpiphp_func *func; int max, pass; LIST_HEAD(add_list); - int nr_found; - nr_found = acpiphp_rescan_slot(slot); + acpiphp_rescan_slot(slot); max = acpiphp_max_busnr(bus); for (pass = 0; pass < 2; pass++) { list_for_each_entry(dev, &bus->devices, bus_list) { @@ -574,9 +573,6 @@ static void __ref enable_slot(struct acpiphp_slot *slot) } } __pci_bus_assign_resources(bus, &add_list, NULL); - /* Nothing more to do here if there are no new devices on this bus. */ - if (!nr_found && (slot->flags & SLOT_ENABLED)) - return; acpiphp_sanitize_bus(bus); acpiphp_set_hpp_values(bus);