mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()
Subsystems (34)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerPATCH 1/38 mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takamori Yamaguchi <[email protected]>
commit b0a8cc58e6b9aaae3045752059e5e6260c0b94bc upstream.
In kswapd(), set current->reclaim_state to NULL before returning, as current->reclaim_state holds reference to variable on kswapd()'s stack.
In rare cases, while returning from kswapd() during memory offlining, __free_slab() and freepages() can access the dangling pointer of current->reclaim_state.
--- mm/vmscan.c | 2 ++ 1 file changed, 2 insertions(+)
mm/vmscan.c +2 -0
@@ -2977,6 +2977,8 @@ static int kswapd(void *p) &balanced_classzone_idx); } } + + current->reclaim_state =NULL ;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 2/38 PCI/PM: Fix deadlock when unbinding device if parent in D3cold
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit 90b5c1d7c45eeb622302680ff96ed30c1a2b6f0e upstream.
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
- device_lock(dev) <--- previous lock here
- __device_release_driver
- pm_runtime_get_sync
...
- rpm_resume(dev)
- rpm_resume(dev->parent)
...
- pci_pm_runtime_resume
...
- pci_set_power_state
- __pci_start_power_transition
- pci_wakeup_bus(dev->parent->subordinate)
- pci_walk_bus
- device_lock(dev) <--- deadlock here
If we do not do device_lock in pci_walk_bus, we can avoid deadlock. Device_lock in pci_walk_bus is introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin said device_lock is added to pci_walk_bus because:
Some error handling functions call pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.
So I fixed the deadlock as follows:
- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback
I checked pci_walk_bus users one by one, and found only PCIe aer needs device lock.
--- drivers/pci/bus.c | 3 --- drivers/pci/pcie/aer/aerdrv_core.c | 20 ++++++++++++++++---- 2 files changed, 16 insertions(+), 7 deletions(-)
drivers/pci/bus.c +0 -3
@@ -284,10 +284,7 @@ void pci_walk_bus(struct pci_bus *top, i }else next = dev->bus_list.next; -/* Run device routines with the device locked */ -device_lock (&dev->dev); retval =cb (dev, userdata); -device_unlock (&dev->dev);if (retval)break ; }
drivers/pci/pcie/aer/aerdrv_core.c +16 -4
@@ -243,6 +243,7 @@ static int report_error_detected(structstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev); dev->error_state = result_data->state; if (!dev->driver ||
@@ -261,12 +262,14 @@ static int report_error_detected(struct dev->driver ? "no AER-aware driver" : "no driver"); } -return 0 ; + goto out; } err_handler = dev->driver->err_handler; vote = err_handler->error_detected (dev, result_data->state); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -277,14 +280,17 @@ static int report_mmio_enabled(struct pcstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->mmio_enabled) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->mmio_enabled (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -295,14 +301,17 @@ static int report_slot_reset(struct pci_struct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->slot_reset) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->slot_reset (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -310,15 +319,18 @@ static int report_resume(struct pci_dev {struct pci_error_handlers *err_handler; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal;if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->resume) -return 0 ; + goto out; err_handler = dev->driver->err_handler; err_handler->resume (dev); +out: +device_unlock (&dev->dev);return 0 ; }
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 39 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.
Quoted 7 lines
So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.
[...]
What about eeh_report_error() inarch/powerpc/platforms/pseries/eeh_driver.c?
Also, is the deadlock even possible before this change in Linux 3.6?
commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800
PCI/PM: add PCIe runtime D3cold support
Ben.
Signature · 2 lines
Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 45 lines · Ben Hutchings
Quoted 44 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callback
Quoted 6 lines
Quoted 2 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?
En... Because pci_walk_bus() invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.
Quoted 7 lines
Also, is the deadlock even possible before this change in Linux 3.6?
commit
448bd857d48e69b33ef323739dc6d8ca20d4cda7Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800PCI/PM: add PCIe runtime D3cold support
Before this, there will be no deadlock. So we do not need fixes before Linux 3.6.
Best Regards,
Huang Ying
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 48 lines · Huang Ying
Quoted 47 lines · Ben Hutchings
Quoted 46 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.
Quoted 7 lines
Quoted 4 lines
[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.
Here is the patch for 3.6. I have no powerpc machine, so build test only.
Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
- device_lock(dev) <--- previous lock here
- __device_release_driver
- pm_runtime_get_sync
...
- rpm_resume(dev)
- rpm_resume(dev->parent)
...
- pci_pm_runtime_resume
...
- pci_set_power_state
- __pci_start_power_transition
- pci_wakeup_bus(dev->parent->subordinate)
- pci_walk_bus
- device_lock(dev) <--- dead lock here
If we do not do device_lock in pci_walk_bus, we can avoid dead lock. Device_lock in pci_walk_bus is introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin said device_lock is added to pci_walk_bus because:
Some error handling functions call pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.
So I fixed the dead lock as follow:
- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback
I checked pci_walk_bus users one by one, and found only PCIe aer needs device lock.
--- arch/powerpc/platforms/pseries/eeh_driver.c | 51 ++++++++++++++++++---------- drivers/pci/bus.c | 3 - drivers/pci/pcie/aer/aerdrv_core.c | 20 ++++++++-- 3 files changed, 50 insertions(+), 24 deletions(-)
arch/powerpc/platforms/pseries/eeh_driver.c +34 -17
@@ -126,18 +126,19 @@ static void eeh_enable_irq(struct pci_destatic int eeh_report_error (struct pci_dev *dev,void *userdata) {enum pci_ers_result rc, *res = userdata; -struct pci_driver *driver = dev->driver; +struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_frozen; - + driver = dev->driver;if (!driver) -return 0 ; + goto out;eeh_disable_irq (dev);if (!driver->err_handler || !driver->err_handler->error_detected) -return 0 ; + goto out; rc = driver->err_handler->error_detected (dev, pci_channel_io_frozen);
@@ -145,6 +146,8 @@ static int eeh_report_error(struct pci_dif (rc ==PCI_ERS_RESULT_NEED_RESET ) *res = rc;if (*res ==PCI_ERS_RESULT_NONE ) *res = rc; +out: +device_unlock (&dev->dev);return 0 ; }
@@ -160,12 +163,14 @@ static int eeh_report_error(struct pci_dstatic int eeh_report_mmio_enabled (struct pci_dev *dev,void *userdata) {enum pci_ers_result rc, *res = userdata; -struct pci_driver *driver = dev->driver; +struct pci_driver *driver; +device_lock (&dev->dev); + driver = dev->driver;if (!driver || !driver->err_handler || !driver->err_handler->mmio_enabled) -return 0 ; + goto out; rc = driver->err_handler->mmio_enabled (dev);
@@ -173,6 +178,8 @@ static int eeh_report_mmio_enabled(strucif (rc ==PCI_ERS_RESULT_NEED_RESET ) *res = rc;if (*res ==PCI_ERS_RESULT_NONE ) *res = rc; +out: +device_unlock (&dev->dev);return 0 ; }
@@ -189,10 +196,12 @@ static int eeh_report_mmio_enabled(strucstatic int eeh_report_reset (struct pci_dev *dev,void *userdata) {enum pci_ers_result rc, *res = userdata; -struct pci_driver *driver = dev->driver; +struct pci_driver *driver; +device_lock (&dev->dev); + driver = dev->driver;if (!driver) -return 0 ; + goto out; dev->error_state = pci_channel_io_normal;
@@ -200,7 +209,7 @@ static int eeh_report_reset(struct pci_dif (!driver->err_handler || !driver->err_handler->slot_reset) -return 0 ; + goto out; rc = driver->err_handler->slot_reset (dev); if ((*res == PCI_ERS_RESULT_NONE) ||
@@ -208,6 +217,8 @@ static int eeh_report_reset(struct pci_dif (*res ==PCI_ERS_RESULT_DISCONNECT && rc ==PCI_ERS_RESULT_NEED_RESET ) *res = rc; +out: +device_unlock (&dev->dev);return 0 ; }
@@ -222,21 +233,24 @@ static int eeh_report_reset(struct pci_d*/ static int eeh_report_resume (struct pci_dev *dev,void *userdata) { -struct pci_driver *driver = dev->driver; +struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal; - + driver = dev->driver;if (!driver) -return 0 ; + goto out;eeh_enable_irq (dev);if (!driver->err_handler || !driver->err_handler->resume) -return 0 ; + goto out; driver->err_handler->resume (dev); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -250,21 +264,24 @@ static int eeh_report_resume(struct pci_*/ static int eeh_report_failure (struct pci_dev *dev,void *userdata) { -struct pci_driver *driver = dev->driver; +struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_perm_failure; - + driver = dev->driver;if (!driver) -return 0 ; + goto out;eeh_disable_irq (dev);if (!driver->err_handler || !driver->err_handler->error_detected) -return 0 ; + goto out; driver->err_handler->error_detected (dev, pci_channel_io_perm_failure); +out: +device_unlock (&dev->dev);return 0 ; }
drivers/pci/bus.c +0 -3
@@ -316,10 +316,7 @@ void pci_walk_bus(struct pci_bus *top, i }else next = dev->bus_list.next; -/* Run device routines with the device locked */ -device_lock (&dev->dev); retval =cb (dev, userdata); -device_unlock (&dev->dev);if (retval)break ; }
drivers/pci/pcie/aer/aerdrv_core.c +16 -4
@@ -244,6 +244,7 @@ static int report_error_detected(structstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev); dev->error_state = result_data->state; if (!dev->driver ||
@@ -262,12 +263,14 @@ static int report_error_detected(struct dev->driver ? "no AER-aware driver" : "no driver"); } -return 0 ; + goto out; } err_handler = dev->driver->err_handler; vote = err_handler->error_detected (dev, result_data->state); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -278,14 +281,17 @@ static int report_mmio_enabled(struct pcstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->mmio_enabled) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->mmio_enabled (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -296,14 +302,17 @@ static int report_slot_reset(struct pci_struct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->slot_reset) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->slot_reset (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -311,15 +320,18 @@ static int report_resume(struct pci_dev {struct pci_error_handlers *err_handler; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal;if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->resume) -return 0 ; + goto out; err_handler = dev->driver->err_handler; err_handler->resume (dev); +out: +device_unlock (&dev->dev);return 0 ; }
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 98 lines · Huang Ying
Quoted 48 lines · Huang Ying
Quoted 47 lines · Ben Hutchings
Quoted 46 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Quoted 7 lines
Quoted 4 lines
[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Here is the patch for 3.6. I have no powerpc machine, so build test only.
Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- dead lock hereIf we do not do
device_lockinpci_walk_bus, we can avoid dead lock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the dead lock as follow:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callback
Quoted 7 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Signed-off-by Huang Ying <[email protected]>Cc Zhang Yanmin <[email protected]>--- arch/powerpc/platforms/pseries/eeh_driver.c | 51 ++++++++++++++++++----------
Due to me applying a power pci patch, feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbc in Linus's tree to 3.6-stable, this patch doesn't apply here anymore.
Because that patch is in the tree, is it now just safe to take your original, unmodified, version of this patch for 3.6-stable?
thanks,
greg k-h
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 107 lines · Greg Kroah-Hartman
Quoted 98 lines · Huang Ying
Quoted 48 lines · Huang Ying
Quoted 47 lines · Ben Hutchings
Quoted 46 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Quoted 7 lines
Quoted 4 lines
[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Here is the patch for 3.6. I have no powerpc machine, so build test only.
Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- dead lock hereIf we do not do
device_lockinpci_walk_bus, we can avoid dead lock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the dead lock as follow:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 7 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Signed-off-by Huang Ying <[email protected]>Cc Zhang Yanmin <[email protected]>--- arch/powerpc/platforms/pseries/eeh_driver.c | 51 ++++++++++++++++++----------
Quoted 6 lines
Due to me applying a power pci patch,
feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbcin Linus's tree to 3.6-stable, this patch doesn't apply here anymore.Because that patch is in the tree, is it now just safe to take your original, unmodified, version of this patch for 3.6-stable?
No. My original version does not work. I need to rebase my patch on this patch. Which tree should I base?
Best Regards,
Huang Ying
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 112 lines · Huang Ying
Quoted 111 lines · Greg Kroah-Hartman
Quoted 98 lines · Huang Ying
Quoted 48 lines · Huang Ying
Quoted 47 lines · Ben Hutchings
Quoted 46 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Quoted 7 lines
Quoted 4 lines
[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Here is the patch for 3.6. I have no powerpc machine, so build test only.
Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- dead lock hereIf we do not do
device_lockinpci_walk_bus, we can avoid dead lock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the dead lock as follow:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 7 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Signed-off-by Huang Ying <[email protected]>Cc Zhang Yanmin <[email protected]>--- arch/powerpc/platforms/pseries/eeh_driver.c | 51 ++++++++++++++++++----------Due to me applying a power pci patch,
feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbcin Linus's tree to 3.6-stable, this patch doesn't apply here anymore.
Quoted 5 lines
Quoted 2 lines
Because that patch is in the tree, is it now just safe to take your original, unmodified, version of this patch for 3.6-stable?
No. My original version does not work. I need to rebase my patch on this patch. Which tree should I base?
Which tree should I base the patch on?
Best Regards,
Huang Ying
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 113 lines · Huang Ying
Quoted 112 lines · Huang Ying
Quoted 111 lines · Greg Kroah-Hartman
Quoted 98 lines · Huang Ying
Quoted 48 lines · Huang Ying
Quoted 47 lines · Ben Hutchings
Quoted 46 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackI checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Quoted 7 lines
Quoted 4 lines
[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Here is the patch for 3.6. I have no powerpc machine, so build test only.
Subject: [BUGFIX] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- dead lock hereIf we do not do
device_lockinpci_walk_bus, we can avoid dead lock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the dead lock as follow:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 7 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.Signed-off-by Huang Ying <[email protected]>Cc Zhang Yanmin <[email protected]>--- arch/powerpc/platforms/pseries/eeh_driver.c | 51 ++++++++++++++++++----------Due to me applying a power pci patch,
feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbcin Linus's tree to 3.6-stable, this patch doesn't apply here anymore.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Because that patch is in the tree, is it now just safe to take your original, unmodified, version of this patch for 3.6-stable?
No. My original version does not work. I need to rebase my patch on this patch. Which tree should I base?
Which tree should I base the patch on?
3.6.10 would be great.
thanks,
greg k-h
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 1 line · Greg Kroah-Hartman
On Tue, Dec 11, 2012 at 04:12:52PM +0800, Huang Ying wrote:
[snip]
Quoted 3 lines
Quoted 1 line
Which tree should I base the patch on?
3.6.10 would be great.
Here is the patch for 3.6.10.
------------------------------------------------------------------------->
Subject: [PATCH] PCI/PM: Fix deadlock when unbind device if its parent in D3cold
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
- device_lock(dev) <--- previous lock here
- __device_release_driver
- pm_runtime_get_sync
...
- rpm_resume(dev)
- rpm_resume(dev->parent)
...
- pci_pm_runtime_resume
...
- pci_set_power_state
- __pci_start_power_transition
- pci_wakeup_bus(dev->parent->subordinate)
- pci_walk_bus
- device_lock(dev) <--- dead lock here
If we do not do device_lock in pci_walk_bus, we can avoid dead lock. Device_lock in pci_walk_bus is introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin said device_lock is added to pci_walk_bus because:
Some error handling functions call pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.
So I fixed the dead lock as follow:
- remove device_lock from pci_walk_bus
- add device_lock into callback if callback will call driver's callback
I checked pci_walk_bus users one by one, and found only PCIe aer needs device lock.
--- arch/powerpc/platforms/pseries/eeh_driver.c | 35 ++++++++++++++++++++-------- drivers/pci/bus.c | 3 -- drivers/pci/pcie/aer/aerdrv_core.c | 20 ++++++++++++---- 3 files changed, 41 insertions(+), 17 deletions(-)
drivers/pci/bus.c +0 -3
@@ -316,10 +316,7 @@ void pci_walk_bus(struct pci_bus *top, i }else next = dev->bus_list.next; -/* Run device routines with the device locked */ -device_lock (&dev->dev); retval =cb (dev, userdata); -device_unlock (&dev->dev);if (retval)break ; }
drivers/pci/pcie/aer/aerdrv_core.c +16 -4
@@ -244,6 +244,7 @@ static int report_error_detected(structstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev); dev->error_state = result_data->state; if (!dev->driver ||
@@ -262,12 +263,14 @@ static int report_error_detected(struct dev->driver ? "no AER-aware driver" : "no driver"); } -return 0 ; + goto out; } err_handler = dev->driver->err_handler; vote = err_handler->error_detected (dev, result_data->state); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -278,14 +281,17 @@ static int report_mmio_enabled(struct pcstruct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->mmio_enabled) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->mmio_enabled (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -296,14 +302,17 @@ static int report_slot_reset(struct pci_struct aer_broadcast_data *result_data; result_data = (struct aer_broadcast_data *) data; +device_lock (&dev->dev);if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->slot_reset) -return 0 ; + goto out; err_handler = dev->driver->err_handler; vote = err_handler->slot_reset (dev); result_data->result =merge_result (result_data->result, vote); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -311,15 +320,18 @@ static int report_resume(struct pci_dev {struct pci_error_handlers *err_handler; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal;if (!dev->driver || !dev->driver->err_handler || !dev->driver->err_handler->resume) -return 0 ; + goto out; err_handler = dev->driver->err_handler; err_handler->resume (dev); +out: +device_unlock (&dev->dev);return 0 ; }
arch/powerpc/platforms/pseries/eeh_driver.c +25 -10
@@ -164,17 +164,18 @@ static int eeh_report_error(struct pci_denum pci_ers_result rc, *res = userdata;struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_frozen; driver =eeh_pcid_get (dev); -if (!driver)return 0 ; +if (!driver) goto out;eeh_disable_irq (dev);if (!driver->err_handler || !driver->err_handler->error_detected) {eeh_pcid_put (dev); -return 0 ; + goto out; } rc = driver->err_handler->error_detected (dev, pci_channel_io_frozen);
@@ -184,6 +185,8 @@ static int eeh_report_error(struct pci_dif (*res ==PCI_ERS_RESULT_NONE ) *res = rc;eeh_pcid_put (dev); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -201,13 +204,14 @@ static int eeh_report_mmio_enabled(strucenum pci_ers_result rc, *res = userdata;struct pci_driver *driver; +device_lock (&dev->dev); driver =eeh_pcid_get (dev); -if (!driver)return 0 ; +if (!driver) goto out;if (!driver->err_handler || !driver->err_handler->mmio_enabled) {eeh_pcid_put (dev); -return 0 ; + goto out; } rc = driver->err_handler->mmio_enabled (dev);
@@ -217,6 +221,8 @@ static int eeh_report_mmio_enabled(strucif (*res ==PCI_ERS_RESULT_NONE ) *res = rc;eeh_pcid_put (dev); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -235,17 +241,18 @@ static int eeh_report_reset(struct pci_denum pci_ers_result rc, *res = userdata;struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal; driver =eeh_pcid_get (dev); -if (!driver)return 0 ; +if (!driver) goto out;eeh_enable_irq (dev);if (!driver->err_handler || !driver->err_handler->slot_reset) {eeh_pcid_put (dev); -return 0 ; + goto out; } rc = driver->err_handler->slot_reset (dev);
@@ -255,6 +262,8 @@ static int eeh_report_reset(struct pci_d rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;eeh_pcid_put (dev); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -271,22 +280,25 @@ static int eeh_report_resume(struct pci_ {struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_normal; driver =eeh_pcid_get (dev); -if (!driver)return 0 ; +if (!driver) goto out;eeh_enable_irq (dev);if (!driver->err_handler || !driver->err_handler->resume) {eeh_pcid_put (dev); -return 0 ; + goto out; } driver->err_handler->resume (dev);eeh_pcid_put (dev); +out: +device_unlock (&dev->dev);return 0 ; }
@@ -302,22 +314,25 @@ static int eeh_report_failure(struct pci {struct pci_driver *driver; +device_lock (&dev->dev); dev->error_state = pci_channel_io_perm_failure; driver =eeh_pcid_get (dev); -if (!driver)return 0 ; +if (!driver) goto out;eeh_disable_irq (dev);if (!driver->err_handler || !driver->err_handler->error_detected) {eeh_pcid_put (dev); -return 0 ; + goto out; } driver->err_handler->error_detected (dev, pci_channel_io_perm_failure);eeh_pcid_put (dev); +out: +device_unlock (&dev->dev);return 0 ; }
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 8 lines · Huang Ying
Quoted 1 line · Greg Kroah-Hartman
On Tue, Dec 11, 2012 at 04:12:52PM +0800, Huang Ying wrote:
[snip]
Quoted 3 lines
Quoted 1 line
Which tree should I base the patch on?
3.6.10 would be great.
Here is the patch for 3.6.10.
Thanks, now applied.
greg k-h
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
In reply to Huang YingQuoted 58 lines · Huang Ying
Quoted 45 lines · Ben Hutchings
Quoted 44 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 6 lines
Quoted 2 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Quoted 2 lines
Also, is the deadlock even possible before this change in Linux 3.6?
Quoted 8 lines
Quoted 5 lines
commit
448bd857d48e69b33ef323739dc6d8ca20d4cda7Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800PCI/PM: add PCIe runtime D3cold support
Before this, there will be no deadlock. So we do not need fixes before Linux 3.6.
So the first patch mentioned here should not be included in the 3.0 and 3.4 stable kernel releases?
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 63 lines · Greg Kroah-Hartman
Quoted 62 lines · Huang Ying
Quoted 45 lines · Ben Hutchings
Quoted 44 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 6 lines
Quoted 2 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Quoted 6 lines
Also, is the deadlock even possible before this change in Linux 3.6?
commit
448bd857d48e69b33ef323739dc6d8ca20d4cda7Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
PCI/PM: add PCIe runtime D3cold support
Before this, there will be no deadlock. So we do not need fixes before Linux 3.6.
So the first patch mentioned here should not be included in the 3.0 and 3.4 stable kernel releases?
Ok, I've dropped the patch from 3.0 and 3.4-stable trees now.
For 3.6, what should I do?
thanks,
greg k-h
Greg Kroah-Hartman
maintainerRe: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 69 lines · Greg Kroah-Hartman
Quoted 68 lines · Greg Kroah-Hartman
Quoted 66 lines · Huang Ying
Quoted 45 lines · Ben Hutchings
Quoted 44 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 6 lines
Quoted 2 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Quoted 7 lines
Also, is the deadlock even possible before this change in Linux 3.6?
commit
448bd857d48e69b33ef323739dc6d8ca20d4cda7Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800PCI/PM: add PCIe runtime D3cold support
Before this, there will be no deadlock. So we do not need fixes before Linux 3.6.
Quoted 6 lines
Quoted 2 lines
So the first patch mentioned here should not be included in the 3.0 and 3.4 stable kernel releases?
Ok, I've dropped the patch from 3.0 and 3.4-stable trees now.
For 3.6, what should I do?
Ok, for now, I've dropped this patch from 3.6-stable as well. If you think it still needs to go there, can you provide something that works? I see you posted one patch in this thread, but I don't understand if that is what needs to go upstream in Linus's tree, or if it is for the 3.6-stable tree. Please clarify.
thanks,
greg k-h
Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold
Quoted 75 lines · Greg Kroah-Hartman
Quoted 74 lines · Greg Kroah-Hartman
Quoted 63 lines · Greg Kroah-Hartman
Quoted 62 lines · Huang Ying
Quoted 45 lines · Ben Hutchings
Quoted 44 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huang Ying <[email protected]>
commit
90b5c1d7c45eeb622302680ff96ed30c1a2b6f0eupstream.If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow:
-
driver_unbind
-device_release_driver
-device_lock(dev)<--- previous lock here
-__device_release_driver
-pm_runtime_get_sync
...
-rpm_resume(dev)
-rpm_resume(dev->parent)
...
-pci_pm_runtime_resume
...
-pci_set_power_state
-__pci_start_power_transition
-pci_wakeup_bus(dev->parent->subordinate)
-pci_walk_bus
-device_lock(dev)<--- deadlock hereIf we do not do
device_lockinpci_walk_bus, we can avoid deadlock.Device_lockinpci_walk_busis introduced in commit:d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread
is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin saiddevice_lockis added topci_walk_busbecause:Some error handling functions call
pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function.So I fixed the deadlock as follows:
- remove
device_lockfrompci_walk_bus
- adddevice_lockinto callback if callback will call driver's callbackQuoted 6 lines
Quoted 2 lines
I checked
pci_walk_bususers one by one, and found only PCIe aer needs device lock.[...]
What about
eeh_report_error()inarch/powerpc/platforms/pseries/eeh_driver.c?En... Because
pci_walk_bus()invocation is removed in 3.7, so this patch is only valid for 3.7. We need another version for 3.6.Quoted 6 lines
Also, is the deadlock even possible before this change in Linux 3.6?
commit
448bd857d48e69b33ef323739dc6d8ca20d4cda7Author: Huang Ying <[email protected]> Date: Sat Jun 23 10:23:51 2012 +0800Quoted 7 lines
Quoted 4 lines
Quoted 1 line
PCI/PM: add PCIe runtime D3cold support
Before this, there will be no deadlock. So we do not need fixes before Linux 3.6.
So the first patch mentioned here should not be included in the 3.0 and 3.4 stable kernel releases?
Ok, I've dropped the patch from 3.0 and 3.4-stable trees now.
Quoted 7 lines
Quoted 1 line
For 3.6, what should I do?
Ok, for now, I've dropped this patch from 3.6-stable as well. If you think it still needs to go there, can you provide something that works? I see you posted one patch in this thread, but I don't understand if that is what needs to go upstream in Linus's tree, or if it is for the 3.6-stable tree. Please clarify.
Sorry for late. The patch I posted in this thread is for 3.6-stable tree. But I have no powerpc machine to test it, just build test it.
Best Regards,
Huang Ying
Greg Kroah-Hartman
maintainerPATCH 3/38 fanotify: fix missing break
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Paris <[email protected]>
commit 848561d368751a1c0f679b9f045a02944506a801 upstream.
Anders Blomdell noted in 2010 that Fanotify lost events and provided a test case. Eric Paris confirmed it was a bug and posted a fix to the list
https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/RrJfTfyW2BE
but never applied it. Repeated attempts over time to actually get him to apply it have never had a reply from anyone who has raised it
So apply it anyway
--- fs/notify/fanotify/fanotify.c | 1 + 1 file changed, 1 insertion(+)
fs/notify/fanotify/fanotify.c +1 -0
@@ -21,6 +21,7 @@ static bool should_merge(struct fsnotifyif ((old->path.mnt == new->path.mnt) && (old->path.dentry == new->path.dentry))return true; +break ;case (FSNOTIFY_EVENT_NONE ):return true;default :
Greg Kroah-Hartman
maintainerPATCH 4/38 crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jussi Kivilinna <[email protected]>
commit 9efade1b3e981f5064f9db9ca971b4dc7557ae42 upstream.
cryptd_queue_worker attempts to prevent simultaneous accesses to crypto workqueue by cryptd_enqueue_request using preempt_disable/preempt_enable. However cryptd_enqueue_request might be called from softirq context, so add local_bh_disable/local_bh_enable to prevent data corruption and panics.
Bug report at http://marc.info/?l=linux-crypto-vger&m=134858649616319&w=2
v2:
- Disable software interrupts instead of hardware interrupts
--- crypto/cryptd.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
crypto/cryptd.c +8 -3
@@ -137,13 +137,18 @@ static void cryptd_queue_worker(struct wstruct crypto_async_request *req, *backlog; cpu_queue = container_of(work, struct cryptd_cpu_queue, work); -/* Only handle one request at a time to avoid hogging crypto -* workqueue. preempt_disable/enable is used to prevent -* being preempted by cryptd_enqueue_request() */ +/* +* Only handle one request at a time to avoid hogging crypto workqueue. +* preempt_disable/enable is used to prevent being preempted by +* cryptd_enqueue_request(). local_bh_disable/enable is used to prevent +* cryptd_enqueue_request() being accessed from software interrupts. +*/ +local_bh_disable ();preempt_disable (); backlog =crypto_get_backlog (&cpu_queue->queue); req =crypto_dequeue_request (&cpu_queue->queue);preempt_enable (); +local_bh_enable ();if (!req)return ;
Greg Kroah-Hartman
maintainerPATCH 5/38 ptp: update adjfreq callback description
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
commit 87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99 upstream.
This patch updates the adjfreq callback description to include a note that the delta in ppb is always relative to the base frequency, and not to the current frequency of the hardware clock.
--- include/linux/ptp_clock_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/linux/ptp_clock_kernel.h +2 -1
@@ -50,7 +50,8 @@ struct ptp_clock_request {* clock operations * * @adjfreq: Adjusts the frequency of the hardware clock. -* parameter delta: Desired period change in parts per billion. +* parameter delta: Desired frequency offset from nominal frequency +* in parts per billion * * @adjtime: Shifts the time of the hardware clock. * parameter delta: Desired change in nanoseconds.
Re: [ 05/38] ptp: update adjfreq callback description
Quoted 26 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
commit
87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99upstream.This patch updates the adjfreq callback description to include a note that the delta in ppb is always relative to the base frequency, and not to the current frequency of the hardware clock.
Signed-off-by Jacob Keller <[email protected]>CC Richard Cochran <[email protected]>CC John Stultz <[email protected]>Signed-off-by Jeff Kirsher <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- include/linux/ptp_clock_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/linux/ptp_clock_kernel.h struct ptp_clock_request { · line 57
Quoted 9 lines
include/linux/ptp_clock_kernel.h +2
-1@@ -50,7 +50,8 @@ struct ptp_clock_request {* clock operations * * @adjfreq: Adjusts the frequency of the hardware clock. -* parameter delta: Desired period change in parts per billion. +* parameter delta: Desired frequency offset from nominal frequency +* in parts per billion * * @adjtime: Shifts the time of the hardware clock. * parameter delta: Desired change in nanoseconds.
This was marked for only 3.5 or later on the original changelog:
"CC: [email protected] [v3.5+]"
Signature · 2 lines
[]'s Herton
Greg Kroah-Hartman
maintainerRe: [ 05/38] ptp: update adjfreq callback description
Quoted 24 lines · Herton Ronaldo Krzesinski
Quoted 23 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
commit
87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99upstream.This patch updates the adjfreq callback description to include a note that the delta in ppb is always relative to the base frequency, and not to the current frequency of the hardware clock.
Signed-off-by Jacob Keller <[email protected]>CC Richard Cochran <[email protected]>CC John Stultz <[email protected]>Signed-off-by Jeff Kirsher <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- include/linux/ptp_clock_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Quoted 15 lines
include/linux/ptp_clock_kernel.h struct ptp_clock_request { · line 57
Quoted 12 lines
include/linux/ptp_clock_kernel.h +2
-1@@ -50,7 +50,8 @@ struct ptp_clock_request {* clock operations * * @adjfreq: Adjusts the frequency of the hardware clock. -* parameter delta: Desired period change in parts per billion. +* parameter delta: Desired frequency offset from nominal frequency +* in parts per billion * * @adjtime: Shifts the time of the hardware clock. * parameter delta: Desired change in nanoseconds. This was marked for only 3.5 or later on the original changelog:
"CC: [email protected] [v3.5+]"
Ugh, my fault, now dropped from the 3.0 and 3.4-stable trees, thanks for finding my error.
thanks,
greg k-h
RE: [ 05/38] ptp: update adjfreq callback description
Quoted 55 lines
-----Original Message-----
From: Greg Kroah-Hartman [mailto:[email protected]]
Sent: Monday, November 26, 2012 10:46 AM
To: Herton Ronaldo Krzesinski
Cc: [email protected]; [email protected]; [email protected]; Keller, Jacob E; Richard Cochran; John Stultz; Kirsher, Jeffrey T; David S. Miller
Subject: Re: [ 05/38] ptp: update adjfreq callback descriptionQuoted 2 lines · Herton Ronaldo Krzesinski
Quoted 1 line · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me
know.
Quoted 8 lines
Quoted 8 lines
------------------
From: Jacob Keller <[email protected]>
commit
87f4d7c1d36f44b0822053b7e5dedc31fdd0ab99upstream.This patch updates the adjfreq callback description to include a note
that the
Quoted 1 line
Quoted 1 line
delta in ppb is always relative to the base frequency, and not to the
current
Quoted 13 lines
Quoted 13 lines
frequency of the hardware clock.
Signed-off-by Jacob Keller <[email protected]>CC Richard Cochran <[email protected]>CC John Stultz <[email protected]>Signed-off-by Jeff Kirsher <[email protected]>Signed-off-by David S. Miller <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- include/linux/ptp_clock_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)Quoted 7 lines
include/linux/ptp_clock_kernel.h struct ptp_clock_request { · line 53
Quoted 7 lines
include/linux/ptp_clock_kernel.h +0
-1@@ -50,7 +50,8 @@ struct ptp_clock_request {* clock operations * * @adjfreq: Adjusts the frequency of the hardware clock. -* parameter delta: Desired period change in parts per billion.
Quoted 1 line
include/linux/ptp_clock_kernel.h struct ptp_clock_request { · line 53
Quoted 1 line
include/linux/ptp_clock_kernel.h +1
-0+* parameter delta: Desired frequency offset from nominal frequency
Quoted 7 lines
include/linux/ptp_clock_kernel.h struct ptp_clock_request { · line 57
Quoted 4 lines
include/linux/ptp_clock_kernel.h +1
-0+* in parts per billion * * @adjtime: Shifts the time of the hardware clock. * parameter delta: Desired change in nanoseconds. This was marked for only 3.5 or later on the original changelog:
"CC: [email protected] [v3.5+]"
Quoted 6 lines
Ugh, my fault, now dropped from the 3.0 and 3.4-stable trees, thanks for finding my error.
thanks,
greg k-h
It seems to me that it should be applied back to 3.0 if PTP is there..
- Jake
Greg Kroah-Hartman
maintainerPATCH 6/38 ALSA: hda: Cirrus: Fix coefficient index for beep configuration
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Stein <[email protected]>
commit 5a83b4b5a391f07141b157ac9daa51c409e71ab5 upstream.
--- sound/pci/hda/patch_cirrus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/pci/hda/patch_cirrus.c +1 -1
@@ -991,7 +991,7 @@ static const struct hda_verb cs_coef_ini | 0x0400 /* Disable Coefficient Auto increment */ )},/* Beep */ - {0x11, AC_VERB_SET_COEF_INDEX, IDX_DAC_CFG}, + {0x11, AC_VERB_SET_COEF_INDEX, IDX_BEEP_CFG}, {0x11, AC_VERB_SET_PROC_COEF, 0x0007}, /* Enable Beep thru DAC1/2/3 */ {} /* terminator */
Greg Kroah-Hartman
maintainerPATCH 7/38 ALSA: hda - Force to reset IEC958 status bits for AD codecs
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit ae24c3191ba2ab03ec6b4be323e730e00404b4b6 upstream.
Several bug reports suggest that the forcibly resetting IEC958 status bits is required for AD codecs to get the SPDIF output working properly after changing streams.
Original fix credit to Javeed Shaikh.
--- sound/pci/hda/patch_analog.c | 1 + 1 file changed, 1 insertion(+)
sound/pci/hda/patch_analog.c +1 -0
@@ -465,6 +465,7 @@ static int ad198x_build_pcms(struct hda_if (spec->multiout.dig_out_nid) { info++; codec->num_pcms++; + codec->spdif_status_reset =1 ; info->name ="AD198x Digital" ; info->pcm_type =HDA_PCM_TYPE_SPDIF ; info->stream[SNDRV_PCM_STREAM_PLAYBACK ] = ad198x_pcm_digital_playback;
Greg Kroah-Hartman
maintainerPATCH 8/38 ASoC: wm8978: pll incorrectly configured when codec is master
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Millbrandt <[email protected]>
commit 55c6f4cb6ef49afbb86222c6a3ff85329199c729 upstream.
When MCLK is supplied externally and BCLK and LRC are configured as outputs (codec is master), the PLL values are only calculated correctly on the first transmission. On subsequent transmissions, at differenct sample rates, the wrong PLL values are used. Test for f_opclk instead of f_pllout to determine if the PLL values are needed.
--- sound/soc/codecs/wm8978.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/codecs/wm8978.c +1 -1
@@ -750,7 +750,7 @@ static int wm8978_hw_params(struct snd_p wm8978->mclk_idx =-1 ; f_sel = wm8978->f_mclk; }else { -if (!wm8978->f_pllout) { +if (!wm8978->f_opclk) {/* We only enter here, if OPCLK is not used */ int ret =wm8978_configure_pll (codec);if (ret <0 )
Greg Kroah-Hartman
maintainerPATCH 9/38 ASoC: dapm: Use card_list during DAPM shutdown
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Misael Lopez Cruz <[email protected]>
commit 445632ad6dda42f4d3f9df2569a852ca0d4ea608 upstream.
DAPM shutdown incorrectly uses "list" field of codec struct while iterating over probed components (codec_dev_list). "list" field refers to codecs registered in the system, "card_list" field is used for probed components.
--- sound/soc/soc-dapm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/soc/soc-dapm.c +1 -1
@@ -2634,7 +2634,7 @@ void snd_soc_dapm_shutdown(struct snd_so {struct snd_soc_codec *codec; -list_for_each_entry (codec, &card->codec_dev_list, list) { +list_for_each_entry (codec, &card->codec_dev_list, card_list) {soc_dapm_shutdown_codec (&codec->dapm);if (codec->dapm.bias_level ==SND_SOC_BIAS_STANDBY ) snd_soc_dapm_set_bias_level(&codec->dapm,
Greg Kroah-Hartman
maintainerPATCH 10/38 UBIFS: fix mounting problems after power cuts
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
commit a28ad42a4a0c6f302f488f26488b8b37c9b30024 upstream.
This is a bugfix for a problem with the following symptoms:
1. A power cut happens
2. After reboot, we try to mount UBIFS
3. Mount fails with "No space left on device" error message
UBIFS complains like this:
UBIFS error (pid 28225): grab_empty_leb: could not find an empty LEB
The root cause of this problem is that when we mount, not all LEBs are categorized. Only those which were read are. However, the 'ubifs_find_free_leb_for_idx()' function assumes that all LEBs were categorized and 'c->freeable_cnt' is valid, which is a false assumption.
This patch fixes the problem by teaching 'ubifs_find_free_leb_for_idx()' to always fall back to LPT scanning if no freeable LEBs were found.
This problem was reported by few people in the past, but Brent Taylor was able to reproduce it and send me a flash image which cannot be mounted, which made it easy to hunt the bug. Kudos to Brent.
--- fs/ubifs/find.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
fs/ubifs/find.c +10 -2
@@ -681,8 +681,16 @@ int ubifs_find_free_leb_for_idx(struct uif (!lprops) { lprops =ubifs_fast_find_freeable (c);if (!lprops) { -ubifs_assert (c->freeable_cnt ==0 ); -if (c->lst.empty_lebs - c->lst.taken_empty_lebs >0 ) { +/* +* The first condition means the following: go scan the +* LPT if there are uncategorized lprops, which means +* there may be freeable LEBs there (UBIFS does not +* store the information about freeable LEBs in the +* master node). +*/ +if (c->in_a_category_cnt != c->main_lebs || + c->lst.empty_lebs - c->lst.taken_empty_lebs >0 ) { +ubifs_assert (c->freeable_cnt ==0 ); lprops =scan_for_leb_for_idx (c);if (IS_ERR (lprops)) { err =PTR_ERR (lprops);
Greg Kroah-Hartman
maintainerPATCH 11/38 UBIFS: introduce categorized lprops counter
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Artem Bityutskiy <[email protected]>
commit 98a1eebda3cb2a84ecf1f219bb3a95769033d1bf upstream.
This commit is a preparation for a subsequent bugfix. We introduce a counter for categorized lprops.
--- fs/ubifs/lprops.c | 6 ++++++ fs/ubifs/ubifs.h | 3 +++ 2 files changed, 9 insertions(+)
fs/ubifs/lprops.c +6 -0
@@ -300,8 +300,11 @@ void ubifs_add_to_cat(struct ubifs_infodefault :ubifs_assert (0 ); } + lprops->flags &= ~LPROPS_CAT_MASK ; lprops->flags |= cat; + c->in_a_category_cnt +=1 ; +ubifs_assert (c->in_a_category_cnt <= c->main_lebs); }/**
@@ -334,6 +337,9 @@ static void ubifs_remove_from_cat(structdefault :ubifs_assert (0 ); } + + c->in_a_category_cnt -=1 ; +ubifs_assert (c->in_a_category_cnt >=0 ); }/**
fs/ubifs/ubifs.h +3 -0
@@ -1187,6 +1187,8 @@ struct ubifs_debug_info;* @freeable_list: list of freeable non-index LEBs (free + dirty == @leb_size) * @frdi_idx_list: list of freeable index LEBs (free + dirty == @leb_size) * @freeable_cnt: number of freeable LEBs in @freeable_list +* @in_a_category_cnt: count of lprops which are in a certain category, which +* basically meants that they were loaded from the flash * * @ltab_lnum: LEB number of LPT's own lprops table * @ltab_offs: offset of LPT's own lprops table
@@ -1416,6 +1418,7 @@ struct ubifs_info {struct list_head freeable_list;struct list_head frdi_idx_list;int freeable_cnt; +int in_a_category_cnt;int ltab_lnum;int ltab_offs;
Greg Kroah-Hartman
maintainerPATCH 12/38 s390/gup: add missing TASK_SIZE check to get_user_pages_fast()
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <[email protected]>
commit d55c4c613fc4d4ad2ba0fc6fa2b57176d420f7e4 upstream.
When walking page tables we need to make sure that everything is within bounds of the ASCE limit of the task's address space. Otherwise we might calculate e.g. a pud pointer which is not within a pud and dereference it.
So check against TASK_SIZE (which is the ASCE limit) before walking page tables.
--- arch/s390/mm/gup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/s390/mm/gup.c +1 -1
@@ -183,7 +183,7 @@ int get_user_pages_fast(unsigned long st addr = start; len = (unsigned long ) nr_pages <<PAGE_SHIFT ; end = start + len; -if (end < start) +if ((end < start) || (end >TASK_SIZE )) goto slow_irqon;/*
Greg Kroah-Hartman
maintainerPATCH 13/38 USB: option: add Novatel E362 and Dell Wireless 5800 USB IDs
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit fcb21645f1bd86d2be29baf48aa1b298de52ccc7 upstream.
The Dell 5800 appears to be a simple rebrand of the Novatel E362.
--- drivers/usb/serial/option.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/usb/serial/option.c +7 -0
@@ -157,6 +157,7 @@ static void option_instat_callback(struc#define NOVATELWIRELESS_PRODUCT_EVDO_EMBEDDED_HIGHSPEED 0x8001#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_FULLSPEED 0x9000#define NOVATELWIRELESS_PRODUCT_HSPA_EMBEDDED_HIGHSPEED 0x9001 +#define NOVATELWIRELESS_PRODUCT_E362 0x9010#define NOVATELWIRELESS_PRODUCT_G1 0xA001#define NOVATELWIRELESS_PRODUCT_G1_M 0xA002#define NOVATELWIRELESS_PRODUCT_G2 0xA010
@@ -192,6 +193,9 @@ static void option_instat_callback(struc#define DELL_PRODUCT_5730_MINICARD_TELUS 0x8181#define DELL_PRODUCT_5730_MINICARD_VZW 0x8182 +#define DELL_PRODUCT_5800_MINICARD_VZW 0x8195/* Novatel E362 */ +#define DELL_PRODUCT_5800_V2_MINICARD_VZW 0x8196/* Novatel E362 */ +#define KYOCERA_VENDOR_ID 0x0c88#define KYOCERA_PRODUCT_KPC650 0x17da#define KYOCERA_PRODUCT_KPC680 0x180a
@@ -705,6 +709,7 @@ static const struct usb_device_id option { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_G2) },/* Novatel Ovation MC551 a.k.a. Verizon USB551L */ { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_MC551, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(NOVATELWIRELESS_VENDOR_ID, NOVATELWIRELESS_PRODUCT_E362, 0xff, 0xff, 0xff) }, { USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01) }, { USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_H01A) },
@@ -727,6 +732,8 @@ static const struct usb_device_id option { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5730_MINICARD_SPRINT) }, /* Dell Wireless 5730 Mobile Broadband EVDO/HSPA Mini-Card */ { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5730_MINICARD_TELUS) }, /* Dell Wireless 5730 Mobile Broadband EVDO/HSPA Mini-Card */ { USB_DEVICE(DELL_VENDOR_ID, DELL_PRODUCT_5730_MINICARD_VZW) }, /* Dell Wireless 5730 Mobile Broadband EVDO/HSPA Mini-Card */ + { USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_MINICARD_VZW, 0xff, 0xff, 0xff) }, + { USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, DELL_PRODUCT_5800_V2_MINICARD_VZW, 0xff, 0xff, 0xff) }, { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_E100A) }, /* ADU-E100, ADU-310 */ { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_500A) }, { USB_DEVICE(ANYDATA_VENDOR_ID, ANYDATA_PRODUCT_ADU_620UW) },
Greg Kroah-Hartman
maintainerPATCH 14/38 USB: option: add Alcatel X220/X500D USB IDs
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Williams <[email protected]>
commit c0bc3098871dd9b964f6b45ec1e4d70d87811744 upstream.
--- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/option.c +2 -0
@@ -286,6 +286,7 @@ static void option_instat_callback(struc/* ALCATEL PRODUCTS */ #define ALCATEL_VENDOR_ID 0x1bbb#define ALCATEL_PRODUCT_X060S_X200 0x0000 +#define ALCATEL_PRODUCT_X220_X500D 0x0017#define PIRELLI_VENDOR_ID 0x1266#define PIRELLI_PRODUCT_C100_1 0x1002
@@ -1163,6 +1164,7 @@ static const struct usb_device_id option { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X060S_X200), .driver_info = (kernel_ulong_t)&alcatel_x200_blacklist }, + { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_X220_X500D) }, { USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) }, { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) }, { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
Greg Kroah-Hartman
maintainerPATCH 15/38 wireless: allow 40 MHz on world roaming channels 12/13
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johannes Berg <[email protected]>
commit 43c771a1963ab461a2f194e3c97fded1d5fe262f upstream.
When in world roaming mode, allow 40 MHz to be used on channels 12 and 13 so that an AP that is, e.g., using HT40+ on channel 9 (in the UK) can be used.
--- net/wireless/reg.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
net/wireless/reg.c +2 -3
@@ -125,9 +125,8 @@ static const struct ieee80211_regdomain .reg_rules = {/* IEEE 802.11b/g, channels 1..11 */ REG_RULE (2412 -10 ,2462 +10 ,40 ,6 ,20 ,0 ), -/* IEEE 802.11b/g, channels 12..13. No HT40 -* channel fits here. */ -REG_RULE (2467 -10 ,2472 +10 ,20 ,6 ,20 , +/* IEEE 802.11b/g, channels 12..13. */ +REG_RULE (2467 -10 ,2472 +10 ,40 ,6 ,20 ,NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_IBSS),/* IEEE 802.11 channel 14 - Only JP enables
Greg Kroah-Hartman
maintainerPATCH 16/38 m68k: fix sigset_t accessor functions
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andreas Schwab <[email protected]>
commit 34fa78b59c52d1db3513db4c1a999db26b2e9ac2 upstream.
The sigaddset/sigdelset/sigismember functions that are implemented with bitfield insn cannot allow the sigset argument to be placed in a data register since the sigset is wider than 32 bits. Remove the "d" constraint from the asm statements.
The effect of the bug is that sending RT signals does not work, the signal number is truncated modulo 32.
--- arch/m68k/include/asm/signal.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/m68k/include/asm/signal.h +3 -3
@@ -156,7 +156,7 @@ typedef struct sigaltstack {static inline void sigaddset (sigset_t *set,int _sig) { asm ("bfset %0{%1,#1}" - :"+od" (*set) + :"+o" (*set) :"id" ((_sig -1 ) ^31 ) :"cc" ); }
@@ -164,7 +164,7 @@ static inline void sigaddset(sigset_t *sstatic inline void sigdelset (sigset_t *set,int _sig) { asm ("bfclr %0{%1,#1}" - :"+od" (*set) + :"+o" (*set) :"id" ((_sig -1 ) ^31 ) :"cc" ); }
@@ -180,7 +180,7 @@ static inline int __gen_sigismember(sigsint ret; asm ("bfextu %1{%2,#1},%0" :"=d" (ret) - :"od" (*set),"id" ((_sig-1 ) ^31 ) + :"o" (*set),"id" ((_sig-1 ) ^31 ) :"cc" );return ret; }
Greg Kroah-Hartman
maintainerPATCH 17/38 ipv4: avoid undefined behavior in do_ip_setsockopt()
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xi Wang <[email protected]>
[ Upstream commit 0c9f79be295c99ac7e4b569ca493d75fdcc19e4e ]
(1<<optname) is undefined behavior in C with a negative optname or optname larger than 31. In those cases the result of the shift is not necessarily zero (e.g., on x86).
This patch simplifies the code with a switch statement on optname. It also allows the compiler to generate better code (e.g., using a 64-bit mask).
--- net/ipv4/ip_sockglue.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
net/ipv4/ip_sockglue.c +21 -12
@@ -467,18 +467,27 @@ static int do_ip_setsockopt(struct sockstruct inet_sock *inet =inet_sk (sk);int val =0 , err; -if (((1 <<optname) & ((1 <<IP_PKTINFO ) | (1 <<IP_RECVTTL ) | - (1 <<IP_RECVOPTS ) | (1 <<IP_RECVTOS ) | - (1 <<IP_RETOPTS ) | (1 <<IP_TOS ) | - (1 <<IP_TTL ) | (1 <<IP_HDRINCL ) | - (1 <<IP_MTU_DISCOVER ) | (1 <<IP_RECVERR ) | - (1 <<IP_ROUTER_ALERT ) | (1 <<IP_FREEBIND ) | - (1 <<IP_PASSSEC ) | (1 <<IP_TRANSPARENT ) | - (1 <<IP_MINTTL ) | (1 <<IP_NODEFRAG ))) || - optname ==IP_MULTICAST_TTL || - optname ==IP_MULTICAST_ALL || - optname ==IP_MULTICAST_LOOP || - optname ==IP_RECVORIGDSTADDR ) { +switch (optname) { +case IP_PKTINFO : +case IP_RECVTTL : +case IP_RECVOPTS : +case IP_RECVTOS : +case IP_RETOPTS : +case IP_TOS : +case IP_TTL : +case IP_HDRINCL : +case IP_MTU_DISCOVER : +case IP_RECVERR : +case IP_ROUTER_ALERT : +case IP_FREEBIND : +case IP_PASSSEC : +case IP_TRANSPARENT : +case IP_MINTTL : +case IP_NODEFRAG : +case IP_MULTICAST_TTL : +case IP_MULTICAST_ALL : +case IP_MULTICAST_LOOP : +case IP_RECVORIGDSTADDR :if (optlen >=sizeof (int )) {if (get_user (val, (int __user *) optval))return -EFAULT ;
Greg Kroah-Hartman
maintainerPATCH 18/38 ipv6: setsockopt(IPIPPROTO_IPV6, IPV6_MINHOPCOUNT) forgot to set return value
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hannes Frederic Sowa <[email protected]>
[ Upstream commit d4596bad2a713fcd0def492b1960e6d899d5baa8 ]
--- net/ipv6/ipv6_sockglue.c | 1 + 1 file changed, 1 insertion(+)
net/ipv6/ipv6_sockglue.c +1 -0
@@ -798,6 +798,7 @@ pref_skip_coa:if (val <0 || val >255 ) goto e_inval; np->min_hopcount = val; + retv =0 ;break ;case IPV6_DONTFRAG : np->dontfrag = valbool;
Greg Kroah-Hartman
maintainerPATCH 19/38 net: correct check in dev_addr_del()
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Pirko <[email protected]>
[ Upstream commit a652208e0b52c190e57f2a075ffb5e897fe31c3b ]
Check (ha->addr == dev->dev_addr) is always true because dev_addr_init() sets this. Correct the check to behave properly on addr removal.
--- net/core/dev_addr_lists.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/core/dev_addr_lists.c +2 -1
@@ -307,7 +307,8 @@ int dev_addr_del(struct net_device *dev,*/ ha =list_first_entry (&dev->dev_addrs.list, struct netdev_hw_addr, list); -if (ha->addr == dev->dev_addr && ha->refcount ==1 ) +if (!memcmp (ha->addr, addr, dev->addr_len) && + ha->type == addr_type && ha->refcount ==1 )return -ENOENT ; err = __hw_addr_del(&dev->dev_addrs, addr, dev->addr_len,
Greg Kroah-Hartman
maintainerPATCH 20/38 net-rps: Fix brokeness causing OOO packets
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Herbert <[email protected]>
[ Upstream commit baefa31db2f2b13a05d1b81bdf2d20d487f58b0a ]
In commit c445477d74ab3779 which adds aRFS to the kernel, the CPU selected for RFS is not set correctly when CPU is changing. This is causing OOO packets and probably other issues.
--- net/core/dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
net/core/dev.c +3 -1
@@ -2706,8 +2706,10 @@ static int get_rps_cpu(struct net_deviceif (unlikely (tcpu != next_cpu) && (tcpu ==RPS_NO_CPU || !cpu_online (tcpu) || ((int )(per_cpu (softnet_data, tcpu).input_queue_head - - rflow->last_qtail)) >=0 )) + rflow->last_qtail)) >=0 )) { + tcpu = next_cpu; rflow =set_rps_cpu (dev, skb, rflow, next_cpu); + }if (tcpu !=RPS_NO_CPU &&cpu_online (tcpu)) { *rflowp = rflow;
Greg Kroah-Hartman
maintainerPATCH 21/38 r8169: use unlimited DMA burst for TX
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Schmidt <[email protected]>
commit aee77e4accbeb2c86b1d294cd84fec4a12dde3bd upstream.
The r8169 driver currently limits the DMA burst for TX to 1024 bytes. I have a box where this prevents the interface from using the gigabit line to its full potential. This patch solves the problem by setting TX_DMA_BURST to unlimited.
The box has an ASRock B75M motherboard with on-board RTL8168evl/8111evl (XID 0c900880). TSO is enabled.
I used netperf (TCP_STREAM test) to measure the dependency of TX throughput on MTU. I did it for three different values of TX_DMA_BURST ('5'=512, '6'=1024, '7'=unlimited). This chart shows the results:
http://michich.fedorapeople.org/r8169/r8169-effects-of-TX_DMA_BURST.png
Interesting points:
- With the current DMA burst limit (1024):
- at the default MTU=1500 I get only 842 Mbit/s.
- when going from small MTU, the performance rises monotonically with increasing MTU only up to a peak at MTU=1076 (908 MBit/s). Then there's a sudden drop to 762 MBit/s from which the throughput rises monotonically again with further MTU increases.
- With a smaller DMA burst limit (512):
- there's a similar peak at MTU=1076 and another one at MTU=564.
- With unlimited DMA burst:
- at the default MTU=1500 I get nice 940 Mbit/s.
- the throughput rises monotonically with increasing MTU with no strange peaks.
Notice that the peaks occur at MTU sizes that are multiples of the DMA burst limit plus 52. Why 52? Because:
20 (IP header) + 20 (TCP header) + 12 (TCP options) = 52
The Realtek-provided r8168 driver (v8.032.00) uses unlimited TX DMA burst too, except for CFG_METHOD_1 where the TX DMA burst is set to 512 bytes. CFG_METHOD_1 appears to be the oldest MAC version of "RTL8168B/8111B", i.e. RTL_GIGA_MAC_VER_11 in r8169. Not sure if this MAC version really needs the smaller burst limit, or if any other versions have similar requirements.
--- drivers/net/r8169.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/r8169.c +1 -1
@@ -75,7 +75,7 @@ static const int multicast_filter_limit#define MAX_READ_REQUEST_SHIFT 12#define RX_FIFO_THRESH 7/* 7 means NO threshold, Rx buffer level before first PCI xfer. */ #define RX_DMA_BURST 6/* Maximum PCI burst, '6' is 1024 */ -#define TX_DMA_BURST 6/* Maximum PCI burst, '6' is 1024 */ +#define TX_DMA_BURST 7/* Maximum PCI burst, '7' is unlimited */ #define SafeMtu 0x1c20/* ... actually life sucks beyond ~7k */ #define InterFrameGap 0x03/* 3 means InterFrameGap = the shortest one */
Greg Kroah-Hartman
maintainerPATCH 22/38 kbuild: Fix gcc -x syntax
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jean Delvare <[email protected]>
commit b1e0d8b70fa31821ebca3965f2ef8619d7c5e316 upstream.
The correct syntax for gcc -x is "gcc -x assembler", not "gcc -xassembler". Even though the latter happens to work, the former is what is documented in the manual page and thus what gcc wrappers such as icecream do expect.
This isn't a cosmetic change. The missing space prevents icecream from recognizing compilation tasks it can't handle, leading to silent kernel miscompilations.
Besides me, credits go to Michael Matz and Dirk Mueller for investigating the miscompilation issue and tracking it down to this incorrect -x parameter syntax.
--- arch/mips/Makefile | 2 +- arch/mips/kernel/Makefile | 2 +- scripts/Kbuild.include | 12 ++++++------ scripts/gcc-version.sh | 6 +++--- scripts/gcc-x86_32-has-stack-protector.sh | 2 +- scripts/gcc-x86_64-has-stack-protector.sh | 2 +- scripts/kconfig/check.sh | 2 +- scripts/kconfig/lxdialog/check-lxdialog.sh | 2 +- tools/perf/Makefile | 2 +- 9 files changed, 16 insertions(+), 16 deletions(-)
arch/mips/Makefile +1 -1
@@ -236,7 +236,7 @@ KBUILD_CPPFLAGS += -D"DATAOFFSET=$(if $( LDFLAGS += -m $(ld-emul) ifdef CONFIG_MIPS -CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -xc /dev/null | \ +CHECKFLAGS += $(shell $(CC) $(KBUILD_CFLAGS) -dM -E -x c /dev/null | \ egrep -vw '__GNUC_(|MINOR_|PATCHLEVEL_)_' | \ sed -e 's/^\#define /-D/' -e "s/ /='/" -e "s/$$/'/") ifdef CONFIG_64BIT
arch/mips/kernel/Makefile +1 -1
@@ -100,7 +100,7 @@ obj-$(CONFIG_MIPS_MACHINE) += mips_machi obj-$(CONFIG_OF) += prom.o -CFLAGS_cpu-bugs64.o = $(shell if $(CC) $(KBUILD_CFLAGS) -Wa,-mdaddi -c -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi) +CFLAGS_cpu-bugs64.o = $(shell if $(CC) $(KBUILD_CFLAGS) -Wa,-mdaddi -c -o /dev/null -x c /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi) obj-$(CONFIG_HAVE_STD_PC_SERIAL_PORT) += 8250-platform.o
scripts/Kbuild.include +6 -6
@@ -94,24 +94,24 @@ try-run = $(shell set -e; \ # Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,) as-option = $(call try-run,\ - $(CC) $(KBUILD_CFLAGS) $(1) -c -xassembler /dev/null -o "$$TMP",$(1),$(2)) + $(CC) $(KBUILD_CFLAGS) $(1) -c -x assembler /dev/null -o "$$TMP",$(1),$(2)) # as-instr # Usage: cflags-y += $(call as-instr,instr,option1,option2) as-instr = $(call try-run,\ - /bin/echo -e "$(1)" | $(CC) $(KBUILD_AFLAGS) -c -xassembler -o "$$TMP" -,$(2),$(3)) + /bin/echo -e "$(1)" | $(CC) $(KBUILD_AFLAGS) -c -x assembler -o "$$TMP" -,$(2),$(3)) # cc-option # Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) cc-option = $(call try-run,\ - $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -xc /dev/null -o "$$TMP",$(1),$(2)) + $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",$(1),$(2)) # cc-option-yn # Usage: flag := $(call cc-option-yn,-march=winchip-c6) cc-option-yn = $(call try-run,\ - $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -xc /dev/null -o "$$TMP",y,n) + $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(1) -c -x c /dev/null -o "$$TMP",y,n) # cc-option-align # Prefix align with either -falign or -malign
@@ -121,7 +121,7 @@ cc-option-align = $(subst -functions=0,, # cc-disable-warning # Usage: cflags-y += $(call cc-disable-warning,unused-but-set-variable) cc-disable-warning = $(call try-run,\ - $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -xc /dev/null -o "$$TMP",-Wno-$(strip $(1))) + $(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o "$$TMP",-Wno-$(strip $(1))) # cc-version # Usage gcc-ver := $(call cc-version)
@@ -139,7 +139,7 @@ cc-ifversion = $(shell [ $(call cc-versi # cc-ldoption # Usage: ldflags += $(call cc-ldoption, -Wl$(comma)--hash-style=both) cc-ldoption = $(call try-run,\ - $(CC) $(1) -nostdlib -xc /dev/null -o "$$TMP",$(1),$(2)) + $(CC) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2)) # ld-option # Usage: LDFLAGS += $(call ld-option, -X)
scripts/gcc-version.sh +3 -3
@@ -22,10 +22,10 @@ if [ ${#compiler} -eq 0 ]; then exit 1 fi -MAJOR=$(echo __GNUC__ | $compiler -E -xc - | tail -n 1) -MINOR=$(echo __GNUC_MINOR__ | $compiler -E -xc - | tail -n 1) +MAJOR=$(echo __GNUC__ | $compiler -E -x c - | tail -n 1) +MINOR=$(echo __GNUC_MINOR__ | $compiler -E -x c - | tail -n 1) if [ "x$with_patchlevel" != "x" ] ; then - PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -xc - | tail -n 1) + PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -x c - | tail -n 1) printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL else printf "%02d%02d\\n" $MAJOR $MINOR
scripts/gcc-x86_32-has-stack-protector.sh +1 -1
@@ -1,6 +1,6 @@ #!/bin/sh -echo "int foo(void) { char X[200]; return 3; }" | $* -S -xc -c -O0 -fstack-protector - -o - 2> /dev/null | grep -q "%gs" +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -fstack-protector - -o - 2> /dev/null | grep -q "%gs" if [ "$?" -eq "0" ] ; then echo y else
scripts/gcc-x86_64-has-stack-protector.sh +1 -1
@@ -1,6 +1,6 @@ #!/bin/sh -echo "int foo(void) { char X[200]; return 3; }" | $* -S -xc -c -O0 -mcmodel=kernel -fstack-protector - -o - 2> /dev/null | grep -q "%gs" +echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -O0 -mcmodel=kernel -fstack-protector - -o - 2> /dev/null | grep -q "%gs" if [ "$?" -eq "0" ] ; then echo y else
scripts/kconfig/check.sh +1 -1
@@ -1,6 +1,6 @@ #!/bin/sh # Needed for systems without gettext -$* -xc -o /dev/null - > /dev/null 2>&1 << EOF +$* -x c -o /dev/null - > /dev/null 2>&1 << EOF #include <libintl.h> int main() {
scripts/kconfig/lxdialog/check-lxdialog.sh +1 -1
@@ -38,7 +38,7 @@ trap "rm -f $tmp" 0 1 2 3 15 # Check if we can link to ncurses check() { - $cc -xc - -o $tmp 2>/dev/null <<'EOF' + $cc -x c - -o $tmp 2>/dev/null <<'EOF' #include CURSES_LOC main() {} EOF
tools/perf/Makefile +1 -1
@@ -54,7 +54,7 @@ ifeq ($(ARCH),x86_64) ARCH := x86 IS_X86_64 := 0 ifeq (, $(findstring m32,$(EXTRA_CFLAGS))) - IS_X86_64 := $(shell echo __x86_64__ | ${CC} -E -xc - | tail -n 1) + IS_X86_64 := $(shell echo __x86_64__ | ${CC} -E -x c - | tail -n 1) endif ifeq (${IS_X86_64}, 1) RAW_ARCH := x86_64
Greg Kroah-Hartman
maintainerPATCH 23/38 netfilter: Validate the sequence number of dataless ACK packets as well
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jozsef Kadlecsik <[email protected]>
commit 4a70bbfaef0361d27272629d1a250a937edcafe4 upstream.
We spare nothing by not validating the sequence number of dataless ACK packets and enabling it makes harder off-path attacks.
See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,
http://arxiv.org/abs/1201.2074
--- net/netfilter/nf_conntrack_proto_tcp.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-)
net/netfilter/nf_conntrack_proto_tcp.c +2 -8
@@ -628,15 +628,9 @@ static bool tcp_in_window(const struct n ack = sack = receiver->td_end; } -if (seq == end - && (!tcph->rst - || (seq ==0 && state->state ==TCP_CONNTRACK_SYN_SENT ))) +if (tcph->rst && seq ==0 && state->state ==TCP_CONNTRACK_SYN_SENT )/* -* Packets contains no data: we assume it is valid -* and check the ack value only. -* However RST segments are always validated by their -* SEQ number, except when seq == 0 (reset sent answering -* SYN. +* RST sent answering SYN. */ seq = end = sender->td_end;
Greg Kroah-Hartman
maintainerPATCH 24/38 netfilter: Mark SYN/ACK packets as invalid from original direction
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jozsef Kadlecsik <[email protected]>
commit 64f509ce71b08d037998e93dd51180c19b2f464c upstream.
Clients should not send such packets. By accepting them, we open up a hole by wich ephemeral ports can be discovered in an off-path attack.
See: "Reflection scan: an Off-Path Attack on TCP" by Jan Wrobel,
http://arxiv.org/abs/1201.2074
--- net/netfilter/nf_conntrack_proto_tcp.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
net/netfilter/nf_conntrack_proto_tcp.c +8 -11
@@ -159,21 +159,18 @@ static const u8 tcp_conntracks[2][6][TCP* sCL -> sSS */ /* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sS2 */ -/*synack*/ { sIV, sIV, sIG, sIG, sIG, sIG, sIG, sIG, sIG, sSR }, +/*synack*/ { sIV, sIV, sSR, sIV, sIV, sIV, sIV, sIV, sIV, sSR },/* * sNO -> sIV Too late and no reason to do anything * sSS -> sIV Client can't send SYN and then SYN/ACK * sS2 -> sSR SYN/ACK sent to SYN2 in simultaneous open -* sSR -> sIG -* sES -> sIG Error: SYNs in window outside the SYN_SENT state -* are errors. Receiver will reply with RST -* and close the connection. -* Or we are not in sync and hold a dead connection. -* sFW -> sIG -* sCW -> sIG -* sLA -> sIG -* sTW -> sIG -* sCL -> sIG +* sSR -> sSR Late retransmitted SYN/ACK in simultaneous open +* sES -> sIV Invalid SYN/ACK packets sent by the client +* sFW -> sIV +* sCW -> sIV +* sLA -> sIV +* sTW -> sIV +* sCL -> sIV */ /* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sS2 */ /*fin*/ { sIV, sIV, sFW, sFW, sLA, sLA, sLA, sTW, sCL, sIV },
Greg Kroah-Hartman
maintainerPATCH 25/38 netfilter: nf_nat: dont check for port change on ICMP tuples
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulrich Weber <[email protected]>
commit 38fe36a248ec3228f8e6507955d7ceb0432d2000 upstream.
ICMP tuples have id in src and type/code in dst. So comparing src.u.all with dst.u.all will always fail here and ip_xfrm_me_harder() is called for every ICMP packet, even if there was no NAT.
--- net/ipv4/netfilter/nf_nat_standalone.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/ipv4/netfilter/nf_nat_standalone.c +4 -2
@@ -194,7 +194,8 @@ nf_nat_out(unsigned int hooknum,if ((ct->tuplehash[dir].tuple.src.u3.ip != ct->tuplehash[!dir].tuple.dst.u3.ip) || - (ct->tuplehash[dir].tuple.src.u.all != + (ct->tuplehash[dir].tuple.dst.protonum !=IPPROTO_ICMP && + ct->tuplehash[dir].tuple.src.u.all != ct->tuplehash[!dir].tuple.dst.u.all) )return ip_xfrm_me_harder (skb) ==0 ? ret :NF_DROP ;
@@ -230,7 +231,8 @@ nf_nat_local_fn(unsigned int hooknum, ret =NF_DROP ; }#ifdef CONFIG_XFRM - else if (ct->tuplehash[dir].tuple.dst.u.all != + else if (ct->tuplehash[dir].tuple.dst.protonum != IPPROTO_ICMP && + ct->tuplehash[dir].tuple.dst.u.all != ct->tuplehash[!dir].tuple.src.u.all) if (ip_xfrm_me_harder(skb)) ret =NF_DROP ;
Greg Kroah-Hartman
maintainerPATCH 26/38 usb: use usb_serial_put in usb_serial_probe errors
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Safrata <[email protected]>
commit 0658a3366db7e27fa32c12e886230bb58c414c92 upstream.
The use of kfree(serial) in error cases of usb_serial_probe was invalid - usb_serial structure allocated in create_serial() gets reference of usb_device that needs to be put, so we need to use usb_serial_put() instead of simple kfree().
--- drivers/usb/serial/usb-serial.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/serial/usb-serial.c +3 -3
@@ -764,7 +764,7 @@ int usb_serial_probe(struct usb_interfacif (retval) {dbg ("sub driver rejected device" ); -kfree (serial); +usb_serial_put (serial);module_put (type->driver.owner);return retval; }
@@ -836,7 +836,7 @@ int usb_serial_probe(struct usb_interfac*/ if (num_bulk_in ==0 || num_bulk_out ==0 ) {dev_info (&interface->dev,"PL-2303 hack: descriptors matched but endpoints did not\n" ); -kfree (serial); +usb_serial_put (serial);module_put (type->driver.owner);return -ENODEV ; }
@@ -850,7 +850,7 @@ int usb_serial_probe(struct usb_interfacif (num_ports ==0 ) {dev_err (&interface->dev,"Generic device with no bulk out, not allowed.\n" ); -kfree (serial); +usb_serial_put (serial);module_put (type->driver.owner);return -EIO ; }
Greg Kroah-Hartman
maintainerPATCH 27/38 eCryptfs: Copy up POSIX ACL and read-only flags from lower mount
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tyler Hicks <[email protected]>
commit 069ddcda37b2cf5bb4b6031a944c0e9359213262 upstream.
When the eCryptfs mount options do not include '-o acl', but the lower filesystem's mount options do include 'acl', the MS_POSIXACL flag is not flipped on in the eCryptfs super block flags. This flag is what the VFS checks in do_last() when deciding if the current umask should be applied to a newly created inode's mode or not. When a default POSIX ACL mask is set on a directory, the current umask is incorrectly applied to new inodes created in the directory. This patch ignores the MS_POSIXACL flag passed into ecryptfs_mount() and sets the flag on the eCryptfs super block depending on the flag's presence on the lower super block.
Additionally, it is incorrect to allow a writeable eCryptfs mount on top of a read-only lower mount. This missing check did not allow writes to the read-only lower mount because permissions checks are still performed on the lower filesystem's objects but it is best to simply not allow a rw mount on top of ro mount. However, a ro eCryptfs mount on top of a rw mount is valid and still allowed.
https://launchpad.net/bugs/1009207
--- fs/ecryptfs/main.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/ecryptfs/main.c +9 -1
@@ -505,7 +505,6 @@ static struct dentry *ecryptfs_mount(str goto out; } - s->s_flags = flags; rc =bdi_setup_and_register (&sbi->bdi,"ecryptfs" ,BDI_CAP_MAP_COPY );if (rc) goto out1;
@@ -541,6 +540,15 @@ static struct dentry *ecryptfs_mount(str }ecryptfs_set_superblock_lower (s, path.dentry->d_sb); + +/** +* Set the POSIX ACL flag based on whether they're enabled in the lower +* mount. Force a read-only eCryptfs mount if the lower mount is ro. +* Allow a ro eCryptfs mount even when the lower mount is rw. +*/ + s->s_flags = flags & ~MS_POSIXACL ; + s->s_flags |= path.dentry->d_sb->s_flags & (MS_RDONLY |MS_POSIXACL ); + s->s_maxbytes = path.dentry->d_sb->s_maxbytes; s->s_blocksize = path.dentry->d_sb->s_blocksize; s->s_magic =ECRYPTFS_SUPER_MAGIC ;
Greg Kroah-Hartman
maintainerPATCH 28/38 eCryptfs: check for eCryptfs cipher support at mount
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tim Sally <[email protected]>
commit 5f5b331d5c21228a6519dcb793fc1629646c51a6 upstream.
The issue occurs when eCryptfs is mounted with a cipher supported by the crypto subsystem but not by eCryptfs. The mount succeeds and an error does not occur until a write. This change checks for eCryptfs cipher support at mount time.
Resolves Launchpad issue #338914, reported by Tyler Hicks in 03/2009.
https://bugs.launchpad.net/ecryptfs/+bug/338914
--- fs/ecryptfs/main.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
fs/ecryptfs/main.c +13 -0
@@ -279,6 +279,7 @@ static int ecryptfs_parse_options(structchar *fnek_src;char *cipher_key_bytes_src;char *fn_cipher_key_bytes_src; +u8 cipher_code; *check_ruid =0 ;
@@ -420,6 +421,18 @@ static int ecryptfs_parse_options(struct && !fn_cipher_key_bytes_set) mount_crypt_stat->global_default_fn_cipher_key_bytes = mount_crypt_stat->global_default_cipher_key_size; + + cipher_code =ecryptfs_code_for_cipher_string ( + mount_crypt_stat->global_default_cipher_name, + mount_crypt_stat->global_default_cipher_key_size); +if (!cipher_code) { +ecryptfs_printk (KERN_ERR , +"eCryptfs doesn't support cipher: %s" , + mount_crypt_stat->global_default_cipher_name); + rc = -EINVAL ; + goto out; + } +mutex_lock (&key_tfm_list_mutex);if (!ecryptfs_tfm_exists (mount_crypt_stat->global_default_cipher_name,NULL )) {
Greg Kroah-Hartman
maintainerPATCH 29/38 sky2: Fix for interrupt handler
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mirko Lindner <[email protected]>
commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.
Re-enable interrupts if it is not our interrupt
--- drivers/net/sky2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/sky2.c +3 -1
@@ -2929,8 +2929,10 @@ static irqreturn_t sky2_intr(int irq, vo/* Reading this mask interrupts as side effect */ status =sky2_read32 (hw,B0_Y2_SP_ISRC2 ); -if (status ==0 || status == ~0 ) +if (status ==0 || status == ~0 ) { +sky2_write32 (hw,B0_Y2_SP_ICR ,2 );return IRQ_NONE ; + }prefetch (&hw->st_le[hw->st_idx]);
Greg Kroah-Hartman
maintainerPATCH 30/38 drm/i915: fix overlay on i830M
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Vetter <[email protected]>
commit a9193983f4f292a82a00c72971c17ec0ee8c6c15 upstream.
The overlay on the i830M has a peculiar failure mode: It works the first time around after boot-up, but consistenly hangs the second time it's used.
Chris Wilson has dug out a nice errata:
"1.5.12 Clock Gating Disable for Display Register
Address Offset: 06200h–06203h
"Bit 3
Ovrunit Clock Gating Disable.
0 = Clock gating controlled by unit enabling logic
1 = Disable clock gating function
DevALM Errata ALM049: Overlay Clock Gating Must be Disabled: Overlay & L2 Cache clock gating must be disabled in order to prevent device hangs when turning off overlay.SW must turn off Ovrunit clock gating (6200h) and L2 Cache clock gating (C8h)."
Now I've nowhere found that 0xc8 register and hence couldn't apply the l2 cache workaround. But I've remembered that part of the magic that the OVERLAY_ON/OFF commands are supposed to do is to rearrange cache allocations so that the overlay scaler has some scratch space.
And while pondering how that could explain the hang the 2nd time we enable the overlay, I've remembered that the old ums overlay code did _not_ issue the OVERLAY_OFF cmd.
And indeed, disabling the OFF cmd results in the overlay working flawlessly, so I guess we can workaround the lack of the above workaround by simply never disabling the overlay engine once it's enabled.
Note that we have the first part of the above w/a already implemented in i830_init_clock_gating - leave that as-is to avoid surprises.
v2: Add a comment in the code.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47827
[bwh: Backported to 3.2:
- Adjust context
- s/intel_ring_emit(ring, /OUT_RING(/]
--- drivers/gpu/drm/i915/intel_overlay.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/intel_overlay.c +11 -3
@@ -428,9 +428,17 @@ static int intel_overlay_off(struct inteOUT_RING (flip_addr);OUT_RING (MI_WAIT_FOR_EVENT |MI_WAIT_FOR_OVERLAY_FLIP );/* turn overlay off */ -OUT_RING (MI_OVERLAY_FLIP |MI_OVERLAY_OFF ); -OUT_RING (flip_addr); -OUT_RING (MI_WAIT_FOR_EVENT |MI_WAIT_FOR_OVERLAY_FLIP ); +if (IS_I830 (dev)) { +/* Workaround: Don't disable the overlay fully, since otherwise +* it dies on the next OVERLAY_ON cmd. */ +OUT_RING (MI_NOOP ); +OUT_RING (MI_NOOP ); +OUT_RING (MI_NOOP ); + }else { +OUT_RING (MI_OVERLAY_FLIP |MI_OVERLAY_OFF ); +OUT_RING (flip_addr); +OUT_RING (MI_WAIT_FOR_EVENT |MI_WAIT_FOR_OVERLAY_FLIP ); + }ADVANCE_LP_RING (); return intel_overlay_do_wait_request(overlay, request,
Greg Kroah-Hartman
maintainerPATCH 31/38 NFS: Wait for session recovery to finish before returning
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bryan Schumaker <[email protected]>
commit 399f11c3d872bd748e1575574de265a6304c7c43 upstream.
Currently, we will schedule session recovery and then return to the caller of nfs4_handle_exception. This works for most cases, but causes a hang on the following test case:
Client Server
------ ------
Open file over NFS v4.1
Write to file
Expire client
Try to lock file
The server will return NFS4ERR_BADSESSION, prompting the client to schedule recovery. However, the client will continue placing lock attempts and the open recovery never seems to be scheduled. The simplest solution is to wait for session recovery to run before retrying the lock.
--- fs/nfs/nfs4proc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/nfs/nfs4proc.c +1 -2
@@ -300,8 +300,7 @@ static int nfs4_handle_exception(structdprintk ("%s ERROR: %d Reset session\n" , __func__, errorcode);nfs4_schedule_session_recovery (clp->cl_session); - exception->retry =1 ; -break ; + goto wait_on_recovery;#endif /* defined(CONFIG_NFS_V4_1) */ case -NFS4ERR_FILE_OPEN :if (exception->timeout >HZ ) {
Greg Kroah-Hartman
maintainerPATCH 32/38 reiserfs: Fix lock ordering during remount
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 3bb3e1fc47aca554e7e2cc4deeddc24750987ac2 upstream.
When remounting reiserfs dquot_suspend() or dquot_resume() can be called. These functions take dqonoff_mutex which ranks above write lock so we have to drop it before calling into quota code.
--- fs/reiserfs/super.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-)
fs/reiserfs/super.c +20 -7
@@ -1207,7 +1207,7 @@ static int reiserfs_remount(struct superkfree (qf_names[i]);#endif err = -EINVAL ; - goto out_err; + goto out_unlock; }#ifdef CONFIG_QUOTA handle_quota_files (s, qf_names, &qfmt);
@@ -1250,7 +1250,7 @@ static int reiserfs_remount(struct superif (blocks) { err =reiserfs_resize (s, blocks);if (err !=0 ) - goto out_err; + goto out_unlock; }if (*mount_flags &MS_RDONLY ) {
@@ -1260,9 +1260,15 @@ static int reiserfs_remount(struct super/* it is read-only already */ goto out_ok; +/* +* Drop write lock. Quota will retake it when needed and lock +* ordering requires calling dquot_suspend() without it. +*/ +reiserfs_write_unlock (s); err =dquot_suspend (s,-1 );if (err <0 ) goto out_err; +reiserfs_write_lock (s);/* try to remount file system with read-only permissions */ if (sb_umount_state(rs) == REISERFS_VALID_FS
@@ -1272,7 +1278,7 @@ static int reiserfs_remount(struct super err =journal_begin (&th, s,10 );if (err) - goto out_err; + goto out_unlock;/* Mounting a rw partition read-only. */ reiserfs_prepare_for_journal (s,SB_BUFFER_WITH_SB (s),1 );
@@ -1287,7 +1293,7 @@ static int reiserfs_remount(struct superif (reiserfs_is_journal_aborted (journal)) { err = journal->j_errno; - goto out_err; + goto out_unlock; }handle_data_mode (s, mount_options);
@@ -1296,7 +1302,7 @@ static int reiserfs_remount(struct super s->s_flags &= ~MS_RDONLY ;/* now it is safe to call journal_begin */ err =journal_begin (&th, s,10 );if (err) - goto out_err; + goto out_unlock;/* Mount a partition which is read-only, read-write */ reiserfs_prepare_for_journal (s,SB_BUFFER_WITH_SB (s),1 );
@@ -1313,11 +1319,17 @@ static int reiserfs_remount(struct superSB_JOURNAL (s)->j_must_wait =1 ; err =journal_end (&th, s,10 );if (err) - goto out_err; + goto out_unlock; s->s_dirt =0 ;if (!(*mount_flags &MS_RDONLY )) { +/* +* Drop write lock. Quota will retake it when needed and lock +* ordering requires calling dquot_resume() without it. +*/ +reiserfs_write_unlock (s);dquot_resume (s,-1 ); +reiserfs_write_lock (s);finish_unfinished (s);reiserfs_xattr_init (s, *mount_flags); }
@@ -1327,9 +1339,10 @@ out_ok:reiserfs_write_unlock (s);return 0 ; +out_unlock: +reiserfs_write_unlock (s); out_err:kfree (new_opts); -reiserfs_write_unlock (s);return err; }
Greg Kroah-Hartman
maintainerPATCH 33/38 reiserfs: Protect reiserfs_quota_on() with write lock
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit b9e06ef2e8706fe669b51f4364e3aeed58639eb2 upstream.
In reiserfs_quota_on() we do quite some work - for example unpacking tail of a quota file. Thus we have to hold write lock until a moment we call back into the quota code.
--- fs/reiserfs/super.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
fs/reiserfs/super.c +8 -3
@@ -2072,8 +2072,11 @@ static int reiserfs_quota_on(struct supestruct inode *inode;struct reiserfs_transaction_handle th; -if (!(REISERFS_SB (sb)->s_mount_opt & (1 <<REISERFS_QUOTA ))) -return -EINVAL ; +reiserfs_write_lock (sb); +if (!(REISERFS_SB (sb)->s_mount_opt & (1 <<REISERFS_QUOTA ))) { + err = -EINVAL ; + goto out; + }/* Quotafile not on the same filesystem? */ if (path->mnt->mnt_sb != sb) {
@@ -2115,8 +2118,10 @@ static int reiserfs_quota_on(struct supeif (err) goto out; } - err =dquot_quota_on (sb, type, format_id, path); +reiserfs_write_unlock (sb); +return dquot_quota_on (sb, type, format_id, path); out: +reiserfs_write_unlock (sb);return err; }
Greg Kroah-Hartman
maintainerPATCH 34/38 reiserfs: Move quota calls out of write lock
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 7af11686933726e99af22901d622f9e161404e6b upstream.
Calls into highlevel quota code cannot happen under the write lock. These calls take dqio_mutex which ranks above write lock. So drop write lock before calling back into quota code.
--- fs/reiserfs/inode.c | 10 +++++++--- fs/reiserfs/stree.c | 4 ++++ fs/reiserfs/super.c | 18 ++++++++++++++---- 3 files changed, 25 insertions(+), 7 deletions(-)
fs/reiserfs/inode.c +7 -3
@@ -1783,8 +1783,9 @@ int reiserfs_new_inode(struct reiserfs_tBUG_ON (!th->t_trans_id); -dquot_initialize (inode); +reiserfs_write_unlock (inode->i_sb); err =dquot_alloc_inode (inode); +reiserfs_write_lock (inode->i_sb);if (err) goto out_end_trans;if (!dir->i_nlink) {
@@ -1980,8 +1981,10 @@ int reiserfs_new_inode(struct reiserfs_t out_end_trans:journal_end (th, th->t_super, th->t_blocks_allocated); +reiserfs_write_unlock (inode->i_sb);/* Drop can be outside and it needs more credits so it's better to have it outside */ dquot_drop (inode); +reiserfs_write_lock (inode->i_sb); inode->i_flags |=S_NOQUOTA ;make_bad_inode (inode);
@@ -3105,10 +3108,9 @@ int reiserfs_setattr(struct dentry *dent/* must be turned off for recursive notify_change calls */ ia_valid = attr->ia_valid &= ~(ATTR_KILL_SUID |ATTR_KILL_SGID ); - depth =reiserfs_write_lock_once (inode->i_sb);if (is_quota_modification (inode, attr))dquot_initialize (inode); - + depth =reiserfs_write_lock_once (inode->i_sb);if (attr->ia_valid &ATTR_SIZE ) {/* version 2 items will be caught by the s_maxbytes check ** done for us in vmtruncate
@@ -3169,7 +3171,9 @@ int reiserfs_setattr(struct dentry *dent error =journal_begin (&th, inode->i_sb, jbegin_count);if (error) goto out; +reiserfs_write_unlock_once (inode->i_sb, depth); error =dquot_transfer (inode, attr); + depth =reiserfs_write_lock_once (inode->i_sb);if (error) {journal_end (&th, inode->i_sb, jbegin_count); goto out;
fs/reiserfs/stree.c +4 -0
@@ -1968,7 +1968,9 @@ int reiserfs_paste_into_item(struct reis key2type(&(key->on_disk_key)));#endif +reiserfs_write_unlock (inode->i_sb); retval =dquot_alloc_space_nodirty (inode, pasted_size); +reiserfs_write_lock (inode->i_sb);if (retval) {pathrelse (search_path);return retval;
@@ -2061,9 +2063,11 @@ int reiserfs_insert_item(struct reiserfs"reiserquota insert_item(): allocating %u id=%u type=%c" , quota_bytes, inode->i_uid, head2type(ih));#endif +reiserfs_write_unlock (inode->i_sb);/* We can't dirty inode here. It would be immediately written but * appropriate stat item isn't inserted yet... */ retval =dquot_alloc_space_nodirty (inode, quota_bytes); +reiserfs_write_lock (inode->i_sb);if (retval) {pathrelse (path);return retval;
fs/reiserfs/super.c +14 -4
@@ -254,7 +254,9 @@ static int finish_unfinished(struct supe retval =remove_save_link_only (s, &save_link_key,0 );continue ; } +reiserfs_write_unlock (s);dquot_initialize (inode); +reiserfs_write_lock (s);if (truncate &&S_ISDIR (inode->i_mode)) {/* We got a truncate request for a dir which is impossible.
@@ -1965,13 +1967,15 @@ static int reiserfs_write_dquot(struct d REISERFS_QUOTA_TRANS_BLOCKS(dquot->dq_sb));if (ret) goto out; +reiserfs_write_unlock (dquot->dq_sb); ret =dquot_commit (dquot); +reiserfs_write_lock (dquot->dq_sb); err =journal_end (&th, dquot->dq_sb,REISERFS_QUOTA_TRANS_BLOCKS (dquot->dq_sb));if (!ret && err) ret = err; - out: +out:reiserfs_write_unlock (dquot->dq_sb);return ret; }
@@ -1987,13 +1991,15 @@ static int reiserfs_acquire_dquot(struct REISERFS_QUOTA_INIT_BLOCKS(dquot->dq_sb));if (ret) goto out; +reiserfs_write_unlock (dquot->dq_sb); ret =dquot_acquire (dquot); +reiserfs_write_lock (dquot->dq_sb); err =journal_end (&th, dquot->dq_sb,REISERFS_QUOTA_INIT_BLOCKS (dquot->dq_sb));if (!ret && err) ret = err; - out: +out:reiserfs_write_unlock (dquot->dq_sb);return ret; }
@@ -2007,19 +2013,21 @@ static int reiserfs_release_dquot(struct ret =journal_begin (&th, dquot->dq_sb,REISERFS_QUOTA_DEL_BLOCKS (dquot->dq_sb)); +reiserfs_write_unlock (dquot->dq_sb);if (ret) {/* Release dquot anyway to avoid endless cycle in dqput() */ dquot_release (dquot); goto out; } ret =dquot_release (dquot); +reiserfs_write_lock (dquot->dq_sb); err =journal_end (&th, dquot->dq_sb,REISERFS_QUOTA_DEL_BLOCKS (dquot->dq_sb));if (!ret && err) ret = err; - out:reiserfs_write_unlock (dquot->dq_sb); +out:return ret; }
@@ -2044,11 +2052,13 @@ static int reiserfs_write_info(struct su ret =journal_begin (&th, sb,2 );if (ret) goto out; +reiserfs_write_unlock (sb); ret =dquot_commit_info (sb, type); +reiserfs_write_lock (sb); err =journal_end (&th, sb,2 );if (!ret && err) ret = err; - out: +out:reiserfs_write_unlock (sb);return ret; }
Greg Kroah-Hartman
maintainerPATCH 35/38 reiserfs: Protect reiserfs_quota_write() with write lock
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit 361d94a338a3fd0cee6a4ea32bbc427ba228e628 upstream.
Calls into reiserfs journalling code and reiserfs_get_block() need to be protected with write lock. We remove write lock around calls to high level quota code in the next patch so these paths would suddently become unprotected.
--- fs/reiserfs/super.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/reiserfs/super.c +4 -0
@@ -2205,7 +2205,9 @@ static ssize_t reiserfs_quota_write(stru tocopy = sb->s_blocksize - offset < towrite ? sb->s_blocksize - offset : towrite; tmp_bh.b_state =0 ; +reiserfs_write_lock (sb); err =reiserfs_get_block (inode, blk, &tmp_bh,GET_BLOCK_CREATE ); +reiserfs_write_unlock (sb);if (err) goto out;if (offset || tocopy != sb->s_blocksize)
@@ -2221,10 +2223,12 @@ static ssize_t reiserfs_quota_write(struflush_dcache_page (bh->b_page);set_buffer_uptodate (bh);unlock_buffer (bh); +reiserfs_write_lock (sb);reiserfs_prepare_for_journal (sb, bh,1 );journal_mark_dirty (current->journal_info, sb, bh);if (!journal_quota)reiserfs_add_ordered_list (inode, bh); +reiserfs_write_unlock (sb);brelse (bh); offset =0 ; towrite -= tocopy;
Greg Kroah-Hartman
maintainerPATCH 36/38 selinux: fix sel_netnode_insert() suspicious rcu dereference
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jones <[email protected]>
commit 88a693b5c1287be4da937699cb82068ce9db0135 upstream.
===============================
[ INFO: suspicious RCU usage. ]
3.5.0-rc1+ #63 Not tainted
-------------------------------security/selinux/netnode.c:178 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by trinity-child1/8750:
#0: (sel_netnode_lock){+.....}, at: [<ffffffff812d8f8a>] sel_netnode_sid+0x16a/0x3e0
stack backtrace: Pid: 8750, comm: trinity-child1 Not tainted 3.5.0-rc1+ #63 Call Trace: [<ffffffff810cec2d>] lockdep_rcu_suspicious+0xfd/0x130 [<ffffffff812d91d1>] sel_netnode_sid+0x3b1/0x3e0 [<ffffffff812d8e20>] ? sel_netnode_find+0x1a0/0x1a0 [<ffffffff812d24a6>] selinux_socket_bind+0xf6/0x2c0 [<ffffffff810cd1dd>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff810cdb55>] ? lock_release_holdtime.part.9+0x15/0x1a0 [<ffffffff81093841>] ? lock_hrtimer_base+0x31/0x60 [<ffffffff812c9536>] security_socket_bind+0x16/0x20 [<ffffffff815550ca>] sys_bind+0x7a/0x100 [<ffffffff816c03d5>] ? sysret_check+0x22/0x5d [<ffffffff810d392d>] ? trace_hardirqs_on_caller+0x10d/0x1a0 [<ffffffff8133b09e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff816c03a9>] system_call_fastpath+0x16/0x1b
This patch below does what Paul McKenney suggested in the previous thread.
--- security/selinux/netnode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
security/selinux/netnode.c +2 -1
@@ -190,7 +190,8 @@ static void sel_netnode_insert(struct seif (sel_netnode_hash[idx].size ==SEL_NETNODE_HASH_BKT_LIMIT ) {struct sel_netnode *tail; tail =list_entry ( -rcu_dereference (sel_netnode_hash[idx].list.prev), +rcu_dereference_protected (sel_netnode_hash[idx].list.prev, +lockdep_is_held (&sel_netnode_lock)), struct sel_netnode, list);list_del_rcu (&tail->list);call_rcu (&tail->rcu, sel_netnode_free);
Greg Kroah-Hartman
maintainerPATCH 37/38 PCI : ability to relocate assigned pci-resources
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ram Pai <[email protected]>
commit 2bbc6942273b5b3097bd265d82227bdd84b351b2 upstream.
Currently pci-bridges are allocated enough resources to satisfy their immediate requirements. Any additional resource-requests fail if additional free space, contiguous to the one already allocated, is not available. This behavior is not reasonable since sufficient contiguous resources, that can satisfy the request, are available at a different location.
This patch provides the ability to expand and relocate a allocated resource.
v2: Changelog: Fixed size calculation in pci_reassign_resource()
v3: Changelog : Split this patch. The resource.c changes are already
upstream. All the pci driver changes are in here.
--- drivers/pci/setup-bus.c | 27 +++++--- drivers/pci/setup-res.c | 150 ++++++++++++++++++++++++++++++------------------ include/linux/pci.h | 1 3 files changed, 112 insertions(+), 66 deletions(-)
drivers/pci/setup-bus.c +17 -10
@@ -34,6 +34,7 @@ struct resource_list_x {resource_size_t start;resource_size_t end;resource_size_t add_size; +resource_size_t min_align;unsigned long flags; };
@@ -65,7 +66,7 @@ void pci_realloc(void)*/ static void add_to_list (struct resource_list_x *head,struct pci_dev *dev,struct resource *res, -resource_size_t add_size) +resource_size_t add_size,resource_size_t min_align) {struct resource_list_x *list = head;struct resource_list_x *ln = list->next;
@@ -84,13 +85,16 @@ static void add_to_list(struct resource_ tmp->end = res->end; tmp->flags = res->flags; tmp->add_size = add_size; + tmp->min_align = min_align; list->next = tmp; }static void add_to_failed_list (struct resource_list_x *head,struct pci_dev *dev,struct resource *res) { -add_to_list (head, dev, res,0 ); +add_to_list (head, dev, res, +0 /* dont care */ , +0 /* dont care */ ); } static void __dev_sort_resources(struct pci_dev *dev,
@@ -159,13 +163,16 @@ static void adjust_resources_sorted(stru idx = res - &list->dev->resource[0 ]; add_size=list->add_size; -if (!resource_size (res) && add_size) { - res->end = res->start + add_size -1 ; -if (pci_assign_resource (list->dev, idx)) +if (!resource_size (res)) { + res->end = res->start + add_size -1 ; +if (pci_assign_resource (list->dev, idx))reset_resource (res); - }else if (add_size) { -adjust_resource (res, res->start, -resource_size (res) + add_size); + }else { +resource_size_t align = list->min_align; + res->flags |= list->flags & (IORESOURCE_STARTALIGN |IORESOURCE_SIZEALIGN ); +if (pci_reassign_resource (list->dev, idx, add_size, align)) +dev_printk (KERN_DEBUG , &list->dev->dev,"failed to add optional resources res=%pR\n" , + res); } out: tmp = list;
@@ -622,7 +629,7 @@ static void pbus_size_io(struct pci_bus b_res->end = b_res->start + size0 -1 ; b_res->flags |=IORESOURCE_STARTALIGN ;if (size1 > size0 && add_head) -add_to_list (add_head, bus->self, b_res, size1-size0); +add_to_list (add_head, bus->self, b_res, size1-size0,4096 ); }/**
@@ -725,7 +732,7 @@ static int pbus_size_mem(struct pci_bus b_res->end = size0 + min_align -1 ; b_res->flags |=IORESOURCE_STARTALIGN | mem64_mask;if (size1 > size0 && add_head) -add_to_list (add_head, bus->self, b_res, size1-size0); +add_to_list (add_head, bus->self, b_res, size1-size0, min_align);return 1 ; }
drivers/pci/setup-res.c +94 -56
200 lines not on this page · raw message
include/linux/pci.h +1 -0
@@ -800,6 +800,7 @@ int __pci_reset_function(struct pci_devint pci_reset_function (struct pci_dev *dev);void pci_update_resource (struct pci_dev *dev,int resno);int __must_check pci_assign_resource (struct pci_dev *dev,int i); +int __must_check pci_reassign_resource (struct pci_dev *dev,int i,resource_size_t add_size,resource_size_t align);int pci_select_bars (struct pci_dev *dev,unsigned long flags);/* ROM control related routines */
Re: [ 37/38] PCI : ability to relocate assigned pci-resources
Quoted 16 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ram Pai <[email protected]>
commit
2bbc6942273b5b3097bd265d82227bdd84b351b2upstream.Currently pci-bridges are allocated enough resources to satisfy their immediate requirements. Any additional resource-requests fail if additional free space, contiguous to the one already allocated, is not available. This behavior is not reasonable since sufficient contiguous resources, that can satisfy the request, are available at a different location.
This patch provides the ability to expand and relocate a allocated resource.
Quoted 8 lines
v2: Changelog: Fixed size calculation in
pci_reassign_resource()
v3: Changelog : Split this patch. Theresource.cchanges are already
upstream. All the pci driver changes are in here.Signed-off-by Ram Pai <[email protected]>Signed-off-by Jesse Barnes <[email protected]>Cc Andrew Worsley <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
This change is said to bring a regression:
http://comments.gmane.org/gmane.linux.kernel.pci/11666
fixed by:
commit 47ea91b4052d9e94b9dca5d7a3d947fbebd07ba9
Resource: fix wrong resource window calculation
Which wasn't applied with this series for 3.0.
Signature · 2 lines
[]'s Herton
A message that is not in the archive (sent off-list or not yet received): [email protected]
Greg Kroah-Hartman
maintainerRe: [ 37/38] PCI : ability to relocate assigned pci-resources
Quoted 30 lines · Ram Pai
Quoted 29 lines · Herton Ronaldo Krzesinski
Quoted 16 lines · Greg Kroah-Hartman
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ram Pai <[email protected]>
commit
2bbc6942273b5b3097bd265d82227bdd84b351b2upstream.Currently pci-bridges are allocated enough resources to satisfy their immediate requirements. Any additional resource-requests fail if additional free space, contiguous to the one already allocated, is not available. This behavior is not reasonable since sufficient contiguous resources, that can satisfy the request, are available at a different location.
This patch provides the ability to expand and relocate a allocated resource.
Quoted 8 lines
v2: Changelog: Fixed size calculation in
pci_reassign_resource()
v3: Changelog : Split this patch. Theresource.cchanges are already
upstream. All the pci driver changes are in here.Signed-off-by Ram Pai <[email protected]>Signed-off-by Jesse Barnes <[email protected]>Cc Andrew Worsley <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>This change is said to bring a regression:
http://comments.gmane.org/gmane.linux.kernel.pci/11666
Quoted 7 lines
Quoted 5 lines
fixed by:
commit47ea91b4052d9e94b9dca5d7a3d947fbebd07ba9
Resource: fix wrong resource window calculationWhich wasn't applied with this series for 3.0.
You are right. We need to apply that fix along with this patch.
Thanks, now added to the tree.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 38/38 PCI : Calculate right add_size
In reply to a message not in the archive3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yinghai Lu <[email protected]>
commit a4ac9fea016fc5c09227eb479bd35e34978323a4 upstream.
During debug of one SRIOV enabled hotplug device, we found found that add_size is not passed properly.
The device has devices under two level bridges:
+-[0000:80]-+-00.0-[81-8f]-- | +-01.0-[90-9f]-- | +-02.0-[a0-af]----00.0-[a1-a3]--+-02.0-[a2]--+-00.0 Oracle Corporation Device | | \-03.0-[a3]--+-00.0 Oracle Corporation Device
Which means later the parent bridge will not try to add a big enough range:
[ 557.455077] pci 0000:a0:00.0: BAR 14: assigned [mem 0xf9000000-0xf93fffff] [ 557.461974] pci 0000:a0:00.0: BAR 15: assigned [mem 0xf6000000-0xf61fffff pref] [ 557.469340] pci 0000:a1:02.0: BAR 14: assigned [mem 0xf9000000-0xf91fffff] [ 557.476231] pci 0000:a1:02.0: BAR 15: assigned [mem 0xf6000000-0xf60fffff pref] [ 557.483582] pci 0000:a1:03.0: BAR 14: assigned [mem 0xf9200000-0xf93fffff] [ 557.490468] pci 0000:a1:03.0: BAR 15: assigned [mem 0xf6100000-0xf61fffff pref] [ 557.497833] pci 0000:a1:03.0: BAR 14: can't assign mem (size 0x200000) [ 557.504378] pci 0000:a1:03.0: failed to add optional resources res=[mem 0xf9200000-0xf93fffff] [ 557.513026] pci 0000:a1:02.0: BAR 14: can't assign mem (size 0x200000) [ 557.519578] pci 0000:a1:02.0: failed to add optional resources res=[mem 0xf9000000-0xf91fffff]
It turns out we did not calculate size1 properly.
static resource_size_t calculate_memsize(resource_size_t size,
resource_size_t min_size, resource_size_t size1, resource_size_t old_size, resource_size_t align)
{
if (size < min_size)
size = min_size;
if (old_size == 1 )
old_size = 0;
if (size < old_size)
size = old_size;
size = ALIGN(size + size1, align);
return size;
}We should not pass add_size with min_size in calculate_memsize since that will make add_size not contribute final add_size.
So just pass add_size with size1 to calculate_memsize().
With this change, we should have chance to remove extra addon in pci_reassign_resource.
--- drivers/pci/setup-bus.c | 4 ++-- drivers/pci/setup-res.c | 5 +++-- 2 files changed, 5 insertions(+), 4 deletions(-)
drivers/pci/setup-bus.c +2 -2
@@ -614,7 +614,7 @@ static void pbus_size_io(struct pci_busif (children_add_size > add_size) add_size = children_add_size; size1 = (!add_head || (add_head && !add_size)) ? size0 : -calculate_iosize (size, min_size+add_size, size1, +calculate_iosize (size, min_size, add_size + size1,resource_size (b_res),4096 );if (!size0 && !size1) {if (b_res->start || b_res->end)
@@ -718,7 +718,7 @@ static int pbus_size_mem(struct pci_busif (children_add_size > add_size) add_size = children_add_size; size1 = (!add_head || (add_head && !add_size)) ? size0 : -calculate_memsize (size, min_size+add_size,0 , +calculate_memsize (size, min_size, add_size,resource_size (b_res), min_align);if (!size0 && !size1) {if (b_res->start || b_res->end)
drivers/pci/setup-res.c +3 -2
@@ -233,11 +233,12 @@ int pci_reassign_resource(struct pci_devreturn -EINVAL ; } - new_size =resource_size (res) + addsize + min_align; +/* already aligned with min_align */ + new_size =resource_size (res) + addsize; ret =_pci_assign_resource (dev, resno, new_size, min_align);if (!ret) { res->flags &= ~IORESOURCE_STARTALIGN ; -dev_info (&dev->dev,"BAR %d: assigned %pR\n" , resno, res); +dev_info (&dev->dev,"BAR %d: reassigned %pR\n" , resno, res);if (resno <PCI_BRIDGE_RESOURCES )pci_update_resource (dev, resno); }