[ 01/38] mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()

[ 01/38] mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Takamori Yamaguchi <takamori.yamaguchi@jp.sony.com>

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.

Signed-off-by: Takamori Yamaguchi <takamori.yamaguchi@jp.sony.com>
Signed-off-by: Aaditya Kumar <aaditya.kumar@ap.sony.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/vmscan.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2977,6 +2977,8 @@ static int kswapd(void *p)
 						&balanced_classzone_idx);
 		}
 	}
+
+	current->reclaim_state = NULL;
 	return 0;
 }
 

[ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Huang Ying <ying.huang@intel.com>

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.

Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: Zhang Yanmin <yanmin.zhang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pci/bus.c                  |    3 ---
 drivers/pci/pcie/aer/aerdrv_core.c |   20 ++++++++++++++++----
 2 files changed, 16 insertions(+), 7 deletions(-)

--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -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;
 	}
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -243,6 +243,7 @@ static int report_error_detected(struct
 	struct 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 pc
 	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->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

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Huang Ying <ying.huang@intel.com>
> 
> 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.
[...]

What about eeh_report_error() in
arch/powerpc/platforms/pseries/eeh_driver.c?

Also, is the deadlock even possible before this change in Linux 3.6?

commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
Author: Huang Ying <ying.huang@intel.com>
Date:   Sat Jun 23 10:23:51 2012 +0800

    PCI/PM: add PCIe runtime D3cold support

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Huang Ying]

On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Huang Ying <ying.huang@intel.com>
> > 
> > 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.
> [...]
> 
> What about eeh_report_error() in
> arch/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.

> Also, is the deadlock even possible before this change in Linux 3.6?
> 
> commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
> Author: Huang Ying <ying.huang@intel.com>
> Date:   Sat Jun 23 10:23:51 2012 +0800
> 
>     PCI/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

[Huang Ying]

On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote:
> On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Huang Ying <ying.huang@intel.com>
> > > 
> > > 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.
> > [...]
> > 
> > What about eeh_report_error() in
> > arch/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.

Signed-off-by: Huang Ying <ying.huang@intel.com>
Cc: Zhang Yanmin <yanmin.zhang@intel.com>
---
 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(-)

--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -126,18 +126,19 @@ static void eeh_enable_irq(struct pci_de
 static 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_d
 	if (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_d
 static 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(struc
 	if (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(struc
 static 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_d
 
 	if (!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_d
 	if (*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;
 }
 
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -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;
 	}
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -244,6 +244,7 @@ static int report_error_detected(struct
 	struct 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 pc
 	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->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;
 }
 

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Fri, Nov 23, 2012 at 03:47:42PM +0800, Huang Ying wrote:
> On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote:
> > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Huang Ying <ying.huang@intel.com>
> > > > 
> > > > 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.
> > > [...]
> > > 
> > > What about eeh_report_error() in
> > > arch/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.
> 
> Signed-off-by: Huang Ying <ying.huang@intel.com>
> Cc: Zhang Yanmin <yanmin.zhang@intel.com>
> ---
>  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

[Huang Ying]

On Thu, 2012-11-29 at 18:01 -0800, Greg Kroah-Hartman wrote:
> On Fri, Nov 23, 2012 at 03:47:42PM +0800, Huang Ying wrote:
> > On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote:
> > > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > > 
> > > > > ------------------
> > > > > 
> > > > > From: Huang Ying <ying.huang@intel.com>
> > > > > 
> > > > > 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.
> > > > [...]
> > > > 
> > > > What about eeh_report_error() in
> > > > arch/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.
> > 
> > Signed-off-by: Huang Ying <ying.huang@intel.com>
> > Cc: Zhang Yanmin <yanmin.zhang@intel.com>
> > ---
> >  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?

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

[Huang Ying]

On Fri, 2012-11-30 at 10:54 +0800, Huang Ying wrote:
> On Thu, 2012-11-29 at 18:01 -0800, Greg Kroah-Hartman wrote:
> > On Fri, Nov 23, 2012 at 03:47:42PM +0800, Huang Ying wrote:
> > > On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote:
> > > > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > > > 
> > > > > > ------------------
> > > > > > 
> > > > > > From: Huang Ying <ying.huang@intel.com>
> > > > > > 
> > > > > > 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.
> > > > > [...]
> > > > > 
> > > > > What about eeh_report_error() in
> > > > > arch/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.
> > > 
> > > Signed-off-by: Huang Ying <ying.huang@intel.com>
> > > Cc: Zhang Yanmin <yanmin.zhang@intel.com>
> > > ---
> > >  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?
> 
> 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

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Tue, Dec 11, 2012 at 04:12:52PM +0800, Huang Ying wrote:
> On Fri, 2012-11-30 at 10:54 +0800, Huang Ying wrote:
> > On Thu, 2012-11-29 at 18:01 -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 23, 2012 at 03:47:42PM +0800, Huang Ying wrote:
> > > > On Fri, 2012-11-23 at 11:09 +0800, Huang Ying wrote:
> > > > > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > > > > 
> > > > > > > ------------------
> > > > > > > 
> > > > > > > From: Huang Ying <ying.huang@intel.com>
> > > > > > > 
> > > > > > > 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.
> > > > > > [...]
> > > > > > 
> > > > > > What about eeh_report_error() in
> > > > > > arch/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.
> > > > 
> > > > Signed-off-by: Huang Ying <ying.huang@intel.com>
> > > > Cc: Zhang Yanmin <yanmin.zhang@intel.com>
> > > > ---
> > > >  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?
> > 
> > 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

[Huang Ying]

On Tue, 2012-12-11 at 10:08 -0800, Greg Kroah-Hartman wrote:
> On Tue, Dec 11, 2012 at 04:12:52PM +0800, Huang Ying wrote:
[snip]
> > 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.

Signed-off-by: Huang Ying <ying.huang@intel.com>
Cc: Zhang Yanmin <yanmin.zhang@intel.com>
---
 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(-)

--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -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;
 	}
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -244,6 +244,7 @@ static int report_error_detected(struct
 	struct 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 pc
 	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->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;
 }
 
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -164,17 +164,18 @@ static int eeh_report_error(struct pci_d
 	enum 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_d
 	if (*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(struc
 	enum 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(struc
 	if (*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_d
 	enum 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;
 }
 

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Fri, Dec 14, 2012 at 03:08:52PM +0800, Huang Ying wrote:
> On Tue, 2012-12-11 at 10:08 -0800, Greg Kroah-Hartman wrote:
> > On Tue, Dec 11, 2012 at 04:12:52PM +0800, Huang Ying wrote:
> [snip]
> > > 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

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote:
> On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Huang Ying <ying.huang@intel.com>
> > > 
> > > 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.
> > [...]
> > 
> > What about eeh_report_error() in
> > arch/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.
> 
> > Also, is the deadlock even possible before this change in Linux 3.6?
> > 
> > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
> > Author: Huang Ying <ying.huang@intel.com>
> > Date:   Sat Jun 23 10:23:51 2012 +0800
> > 
> >     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?

thanks,

greg k-h

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Mon, Nov 26, 2012 at 10:55:05AM -0800, Greg Kroah-Hartman wrote:
> On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote:
> > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Huang Ying <ying.huang@intel.com>
> > > > 
> > > > 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.
> > > [...]
> > > 
> > > What about eeh_report_error() in
> > > arch/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.
> > 
> > > Also, is the deadlock even possible before this change in Linux 3.6?
> > > 
> > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
> > > Author: Huang Ying <ying.huang@intel.com>
> > > Date:   Sat Jun 23 10:23:51 2012 +0800
> > > 
> > >     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

Re: [ 02/38] PCI/PM: Fix deadlock when unbinding device if parent in D3cold

[Greg Kroah-Hartman]

On Mon, Nov 26, 2012 at 11:08:18AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Nov 26, 2012 at 10:55:05AM -0800, Greg Kroah-Hartman wrote:
> > On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote:
> > > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > > 
> > > > > ------------------
> > > > > 
> > > > > From: Huang Ying <ying.huang@intel.com>
> > > > > 
> > > > > 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.
> > > > [...]
> > > > 
> > > > What about eeh_report_error() in
> > > > arch/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.
> > > 
> > > > Also, is the deadlock even possible before this change in Linux 3.6?
> > > > 
> > > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
> > > > Author: Huang Ying <ying.huang@intel.com>
> > > > Date:   Sat Jun 23 10:23:51 2012 +0800
> > > > 
> > > >     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?

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

[Huang Ying]

On Mon, 2012-11-26 at 11:30 -0800, Greg Kroah-Hartman wrote:
> On Mon, Nov 26, 2012 at 11:08:18AM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Nov 26, 2012 at 10:55:05AM -0800, Greg Kroah-Hartman wrote:
> > > On Fri, Nov 23, 2012 at 11:09:37AM +0800, Huang Ying wrote:
> > > > On Fri, 2012-11-23 at 02:35 +0000, Ben Hutchings wrote:
> > > > > On Wed, 2012-11-21 at 16:39 -0800, Greg Kroah-Hartman wrote:
> > > > > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > > > > 
> > > > > > ------------------
> > > > > > 
> > > > > > From: Huang Ying <ying.huang@intel.com>
> > > > > > 
> > > > > > 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.
> > > > > [...]
> > > > > 
> > > > > What about eeh_report_error() in
> > > > > arch/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.
> > > > 
> > > > > Also, is the deadlock even possible before this change in Linux 3.6?
> > > > > 
> > > > > commit 448bd857d48e69b33ef323739dc6d8ca20d4cda7
> > > > > Author: Huang Ying <ying.huang@intel.com>
> > > > > Date:   Sat Jun 23 10:23:51 2012 +0800
> > > > > 
> > > > >     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?
> 
> 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

[ 03/38] fanotify: fix missing break

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Paris <eparis@redhat.com>

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

Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Anders Blomdell <anders.blomdell@control.lth.se>
Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/notify/fanotify/fanotify.c |    1 +
 1 file changed, 1 insertion(+)

--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -21,6 +21,7 @@ static bool should_merge(struct fsnotify
 			if ((old->path.mnt == new->path.mnt) &&
 			    (old->path.dentry == new->path.dentry))
 				return true;
+			break;
 		case (FSNOTIFY_EVENT_NONE):
 			return true;
 		default:

[ 04/38] crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>

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

Reported-by: Gurucharan Shetty <gurucharan.shetty@gmail.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 crypto/cryptd.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -137,13 +137,18 @@ static void cryptd_queue_worker(struct w
 	struct 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;

[ 05/38] ptp: update adjfreq callback description

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jacob Keller <jacob.e.keller@intel.com>

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.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
CC: Richard Cochran <richard.cochran@gmail.com>
CC: John Stultz <john.stultz@linaro.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 include/linux/ptp_clock_kernel.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/include/linux/ptp_clock_kernel.h
+++ b/include/linux/ptp_clock_kernel.h
@@ -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

[Herton Ronaldo Krzesinski]

On Wed, Nov 21, 2012 at 04:39:48PM -0800, Greg Kroah-Hartman wrote:
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Jacob Keller <jacob.e.keller@intel.com>
> 
> 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.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> CC: Richard Cochran <richard.cochran@gmail.com>
> CC: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> ---
>  include/linux/ptp_clock_kernel.h |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> --- a/include/linux/ptp_clock_kernel.h
> +++ b/include/linux/ptp_clock_kernel.h
> @@ -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: stable@vger.kernel.org [v3.5+]"

-- 
[]'s
Herton

Re: [ 05/38] ptp: update adjfreq callback description

[Greg Kroah-Hartman]

On Fri, Nov 23, 2012 at 10:26:01PM -0200, Herton Ronaldo Krzesinski wrote:
> On Wed, Nov 21, 2012 at 04:39:48PM -0800, Greg Kroah-Hartman wrote:
> > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Jacob Keller <jacob.e.keller@intel.com>
> > 
> > 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.
> > 
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > CC: Richard Cochran <richard.cochran@gmail.com>
> > CC: John Stultz <john.stultz@linaro.org>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > ---
> >  include/linux/ptp_clock_kernel.h |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --- a/include/linux/ptp_clock_kernel.h
> > +++ b/include/linux/ptp_clock_kernel.h
> > @@ -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: stable@vger.kernel.org [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

[Keller, Jacob E]

> -----Original Message-----
> From: Greg Kroah-Hartman [mailto:gregkh@linuxfoundation.org]
> Sent: Monday, November 26, 2012 10:46 AM
> To: Herton Ronaldo Krzesinski
> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org;
> alan@lxorguk.ukuu.org.uk; Keller, Jacob E; Richard Cochran; John Stultz;
> Kirsher, Jeffrey T; David S. Miller
> Subject: Re: [ 05/38] ptp: update adjfreq callback description
> 
> On Fri, Nov 23, 2012 at 10:26:01PM -0200, Herton Ronaldo Krzesinski wrote:
> > On Wed, Nov 21, 2012 at 04:39:48PM -0800, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch.  If anyone has any objections, please let me
> know.
> > >
> > > ------------------
> > >
> > > From: Jacob Keller <jacob.e.keller@intel.com>
> > >
> > > 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.
> > >
> > > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > > CC: Richard Cochran <richard.cochran@gmail.com>
> > > CC: John Stultz <john.stultz@linaro.org>
> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > ---
> > >  include/linux/ptp_clock_kernel.h |    3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > --- a/include/linux/ptp_clock_kernel.h
> > > +++ b/include/linux/ptp_clock_kernel.h
> > > @@ -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: stable@vger.kernel.org [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

It seems to me that it should be applied back to 3.0 if PTP is there..

- Jake

[ 06/38] ALSA: hda: Cirrus: Fix coefficient index for beep configuration

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Alexander Stein <alexander.stein@systec-electronic.com>

commit 5a83b4b5a391f07141b157ac9daa51c409e71ab5 upstream.

Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_cirrus.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -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 */

[ 07/38] ALSA: hda - Force to reset IEC958 status bits for AD codecs

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <tiwai@suse.de>

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.

BugLink: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/359361

Reported-by: Robin Kreis <r.kreis@uni-bremen.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/pci/hda/patch_analog.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/pci/hda/patch_analog.c
+++ b/sound/pci/hda/patch_analog.c
@@ -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;

[ 08/38] ASoC: wm8978: pll incorrectly configured when codec is master

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Eric Millbrandt <emillbrandt@dekaresearch.com>

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.

Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/codecs/wm8978.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/codecs/wm8978.c
+++ b/sound/soc/codecs/wm8978.c
@@ -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)

[ 09/38] ASoC: dapm: Use card_list during DAPM shutdown

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Misael Lopez Cruz <misael.lopez@ti.com>

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.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/soc/soc-dapm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -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,

[ 10/38] UBIFS: fix mounting problems after power cuts

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

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.

Reported-by: Brent Taylor <motobud@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ubifs/find.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- a/fs/ubifs/find.c
+++ b/fs/ubifs/find.c
@@ -681,8 +681,16 @@ int ubifs_find_free_leb_for_idx(struct u
 	if (!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);

[ 11/38] UBIFS: introduce categorized lprops counter

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>

commit 98a1eebda3cb2a84ecf1f219bb3a95769033d1bf upstream.

This commit is a preparation for a subsequent bugfix. We introduce a
counter for categorized lprops.

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ubifs/lprops.c |    6 ++++++
 fs/ubifs/ubifs.h  |    3 +++
 2 files changed, 9 insertions(+)

--- a/fs/ubifs/lprops.c
+++ b/fs/ubifs/lprops.c
@@ -300,8 +300,11 @@ void ubifs_add_to_cat(struct ubifs_info
 	default:
 		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(struct
 	default:
 		ubifs_assert(0);
 	}
+
+	c->in_a_category_cnt -= 1;
+	ubifs_assert(c->in_a_category_cnt >= 0);
 }
 
 /**
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -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;

[ 12/38] s390/gup: add missing TASK_SIZE check to get_user_pages_fast()

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Heiko Carstens <heiko.carstens@de.ibm.com>

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.

Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/s390/mm/gup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/s390/mm/gup.c
+++ b/arch/s390/mm/gup.c
@@ -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;
 
 	/*

[ 13/38] USB: option: add Novatel E362 and Dell Wireless 5800 USB IDs

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dan Williams <dcbw@redhat.com>

commit fcb21645f1bd86d2be29baf48aa1b298de52ccc7 upstream.

The Dell 5800 appears to be a simple rebrand of the Novatel E362.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/option.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -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) },

[ 14/38] USB: option: add Alcatel X220/X500D USB IDs

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dan Williams <dcbw@redhat.com>

commit c0bc3098871dd9b964f6b45ec1e4d70d87811744 upstream.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/option.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -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),

[ 15/38] wireless: allow 40 MHz on world roaming channels 12/13

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Johannes Berg <johannes.berg@intel.com>

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.

Reported-by: Eddie Chapman <eddie@ehuk.net>
Tested-by: Eddie Chapman <eddie@ehuk.net>
Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/wireless/reg.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -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

[ 16/38] m68k: fix sigset_t accessor functions

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Andreas Schwab <schwab@linux-m68k.org>

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.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/m68k/include/asm/signal.h |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/m68k/include/asm/signal.h
+++ b/arch/m68k/include/asm/signal.h
@@ -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 *s
 static 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(sigs
 	int ret;
 	asm ("bfextu %1{%2,#1},%0"
 		: "=d" (ret)
-		: "od" (*set), "id" ((_sig-1) ^ 31)
+		: "o" (*set), "id" ((_sig-1) ^ 31)
 		: "cc");
 	return ret;
 }

[ 17/38] ipv4: avoid undefined behavior in do_ip_setsockopt()

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------


From: Xi Wang <xi.wang@gmail.com>

[ 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).

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/ip_sockglue.c |   33 +++++++++++++++++++++------------
 1 file changed, 21 insertions(+), 12 deletions(-)

--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -467,18 +467,27 @@ static int do_ip_setsockopt(struct sock
 	struct 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;

[ 18/38] ipv6: setsockopt(IPIPPROTO_IPV6, IPV6_MINHOPCOUNT) forgot to set return value

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------


From: Hannes Frederic Sowa <hannes@stressinduktion.org>

[ Upstream commit d4596bad2a713fcd0def492b1960e6d899d5baa8 ]

Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv6/ipv6_sockglue.c |    1 +
 1 file changed, 1 insertion(+)

--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -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;

[ 19/38] net: correct check in dev_addr_del()

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------


From: Jiri Pirko <jiri@resnulli.us>

[ 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.

Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/core/dev_addr_lists.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/net/core/dev_addr_lists.c
+++ b/net/core/dev_addr_lists.c
@@ -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,

[ 20/38] net-rps: Fix brokeness causing OOO packets

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------


From: Tom Herbert <therbert@google.com>

[ 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.

Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/core/dev.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2706,8 +2706,10 @@ static int get_rps_cpu(struct net_device
 		if (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;

[ 21/38] r8169: use unlimited DMA burst for TX

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Michal Schmidt <mschmidt@redhat.com>

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.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/r8169.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -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 */
 

[ 22/38] kbuild: Fix gcc -x syntax

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jean Delvare <jdelvare@suse.de>

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.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Bernhard Walle <bernhard@bwalle.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 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(-)

--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -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
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -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
 
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -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)
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -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
--- a/scripts/gcc-x86_32-has-stack-protector.sh
+++ b/scripts/gcc-x86_32-has-stack-protector.sh
@@ -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
--- a/scripts/gcc-x86_64-has-stack-protector.sh
+++ b/scripts/gcc-x86_64-has-stack-protector.sh
@@ -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
--- a/scripts/kconfig/check.sh
+++ b/scripts/kconfig/check.sh
@@ -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()
 {
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ b/scripts/kconfig/lxdialog/check-lxdialog.sh
@@ -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
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -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

[ 23/38] netfilter: Validate the sequence number of dataless ACK packets as well

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

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

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/netfilter/nf_conntrack_proto_tcp.c |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -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;
 

[ 24/38] netfilter: Mark SYN/ACK packets as invalid from original direction

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

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

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/netfilter/nf_conntrack_proto_tcp.c |   19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -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 },

[ 25/38] netfilter: nf_nat: dont check for port change on ICMP tuples

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ulrich Weber <ulrich.weber@sophos.com>

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.

Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 net/ipv4/netfilter/nf_nat_standalone.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/net/ipv4/netfilter/nf_nat_standalone.c
+++ b/net/ipv4/netfilter/nf_nat_standalone.c
@@ -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;

[ 26/38] usb: use usb_serial_put in usb_serial_probe errors

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Safrata <jan.nikitenko@gmail.com>

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().

Signed-off-by: Jan Safrata <jan.nikitenko@gmail.com>
Acked-by: Johan Hovold <jhovold@gmail.com>
Cc: Richard Retanubun <richardretanubun@ruggedcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/usb/serial/usb-serial.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -764,7 +764,7 @@ int usb_serial_probe(struct usb_interfac
 
 		if (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_interfac
 		if (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;
 		}

[ 27/38] eCryptfs: Copy up POSIX ACL and read-only flags from lower mount

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Tyler Hicks <tyhicks@canonical.com>

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

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Stefan Beller <stefanbeller@googlemail.com>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ecryptfs/main.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -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;

[ 28/38] eCryptfs: check for eCryptfs cipher support at mount

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Tim Sally <tsally@atomicpeace.com>

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

Signed-off-by: Tim Sally <tsally@atomicpeace.com>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/ecryptfs/main.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/fs/ecryptfs/main.c
+++ b/fs/ecryptfs/main.c
@@ -279,6 +279,7 @@ static int ecryptfs_parse_options(struct
 	char *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)) {

[ 29/38] sky2: Fix for interrupt handler

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Mirko Lindner <mlindner@marvell.com>

commit d663d181b9e92d80c2455e460e932d34e7a2a7ae upstream.

Re-enable interrupts if it is not our interrupt

Signed-off-by: Mirko Lindner <mlindner@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/sky2.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -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]);
 

[ 30/38] drm/i915: fix overlay on i830M

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Daniel Vetter <daniel.vetter@ffwll.ch>

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
Tested-by: Rhys <rhyspuk@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2:
 - Adjust context
 - s/intel_ring_emit(ring, /OUT_RING(/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/i915/intel_overlay.c |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -428,9 +428,17 @@ static int intel_overlay_off(struct inte
 	OUT_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,

[ 31/38] NFS: Wait for session recovery to finish before returning

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Bryan Schumaker <bjschuma@netapp.com>

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.

Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/nfs4proc.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -300,8 +300,7 @@ static int nfs4_handle_exception(struct
 			dprintk("%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) {

[ 32/38] reiserfs: Fix lock ordering during remount

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

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.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/reiserfs/super.c |   27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -1207,7 +1207,7 @@ static int reiserfs_remount(struct super
 				kfree(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 super
 	if (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 super
 
 		if (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 super
 	SB_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;
 }
 

[ 33/38] reiserfs: Protect reiserfs_quota_on() with write lock

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

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.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/reiserfs/super.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -2072,8 +2072,11 @@ static int reiserfs_quota_on(struct supe
 	struct 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 supe
 		if (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;
 }
 

[ 34/38] reiserfs: Move quota calls out of write lock

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

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.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/reiserfs/inode.c |   10 +++++++---
 fs/reiserfs/stree.c |    4 ++++
 fs/reiserfs/super.c |   18 ++++++++++++++----
 3 files changed, 25 insertions(+), 7 deletions(-)

--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -1783,8 +1783,9 @@ int reiserfs_new_inode(struct reiserfs_t
 
 	BUG_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;
--- a/fs/reiserfs/stree.c
+++ b/fs/reiserfs/stree.c
@@ -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;
--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -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;
 }

[ 35/38] reiserfs: Protect reiserfs_quota_write() with write lock

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

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.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/reiserfs/super.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/fs/reiserfs/super.c
+++ b/fs/reiserfs/super.c
@@ -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(stru
 		flush_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;

[ 36/38] selinux: fix sel_netnode_insert() suspicious rcu dereference

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dave Jones <davej@redhat.com>

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.

Signed-off-by: Dave Jones <davej@redhat.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/selinux/netnode.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/security/selinux/netnode.c
+++ b/security/selinux/netnode.c
@@ -190,7 +190,8 @@ static void sel_netnode_insert(struct se
 	if (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);

[ 37/38] PCI : ability to relocate assigned pci-resources

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Ram Pai <linuxram@us.ibm.com>

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.

Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Andrew Worsley <amworsley@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pci/setup-bus.c |   27 +++++---
 drivers/pci/setup-res.c |  150 ++++++++++++++++++++++++++++++------------------
 include/linux/pci.h     |    1 
 3 files changed, 112 insertions(+), 66 deletions(-)

--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -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;
 }
 
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -129,16 +129,16 @@ void pci_disable_bridge_window(struct pc
 }
 #endif	/* CONFIG_PCI_QUIRKS */
 
+
+
 static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
-				 int resno)
+		int resno, resource_size_t size, resource_size_t align)
 {
 	struct resource *res = dev->resource + resno;
-	resource_size_t size, min, align;
+	resource_size_t min;
 	int ret;
 
-	size = resource_size(res);
 	min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
-	align = pci_resource_alignment(dev, res);
 
 	/* First, try exact prefetching match.. */
 	ret = pci_bus_alloc_resource(bus, res, size, align, min,
@@ -155,56 +155,101 @@ static int __pci_assign_resource(struct
 		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
 					     pcibios_align_resource, dev);
 	}
+	return ret;
+}
 
-	if (ret < 0 && dev->fw_addr[resno]) {
-		struct resource *root, *conflict;
-		resource_size_t start, end;
+static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
+		int resno, resource_size_t size)
+{
+	struct resource *root, *conflict;
+	resource_size_t start, end;
+	int ret = 0;
+
+	if (res->flags & IORESOURCE_IO)
+		root = &ioport_resource;
+	else
+		root = &iomem_resource;
+
+	start = res->start;
+	end = res->end;
+	res->start = dev->fw_addr[resno];
+	res->end = res->start + size - 1;
+	dev_info(&dev->dev, "BAR %d: trying firmware assignment %pR\n",
+		 resno, res);
+	conflict = request_resource_conflict(root, res);
+	if (conflict) {
+		dev_info(&dev->dev,
+			 "BAR %d: %pR conflicts with %s %pR\n", resno,
+			 res, conflict->name, conflict);
+		res->start = start;
+		res->end = end;
+		ret = 1;
+	}
+	return ret;
+}
 
-		/*
-		 * If we failed to assign anything, let's try the address
-		 * where firmware left it.  That at least has a chance of
-		 * working, which is better than just leaving it disabled.
-		 */
+static int _pci_assign_resource(struct pci_dev *dev, int resno, int size, resource_size_t min_align)
+{
+	struct resource *res = dev->resource + resno;
+	struct pci_bus *bus;
+	int ret;
+	char *type;
 
-		if (res->flags & IORESOURCE_IO)
-			root = &ioport_resource;
+	bus = dev->bus;
+	while ((ret = __pci_assign_resource(bus, dev, resno, size, min_align))) {
+		if (!bus->parent || !bus->self->transparent)
+			break;
+		bus = bus->parent;
+	}
+
+	if (ret) {
+		if (res->flags & IORESOURCE_MEM)
+			if (res->flags & IORESOURCE_PREFETCH)
+				type = "mem pref";
+			else
+				type = "mem";
+		else if (res->flags & IORESOURCE_IO)
+			type = "io";
 		else
-			root = &iomem_resource;
+			type = "unknown";
+		dev_info(&dev->dev,
+			 "BAR %d: can't assign %s (size %#llx)\n",
+			 resno, type, (unsigned long long) resource_size(res));
+	}
 
-		start = res->start;
-		end = res->end;
-		res->start = dev->fw_addr[resno];
-		res->end = res->start + size - 1;
-		dev_info(&dev->dev, "BAR %d: trying firmware assignment %pR\n",
-			 resno, res);
-		conflict = request_resource_conflict(root, res);
-		if (conflict) {
-			dev_info(&dev->dev,
-				 "BAR %d: %pR conflicts with %s %pR\n", resno,
-				 res, conflict->name, conflict);
-			res->start = start;
-			res->end = end;
-		} else
-			ret = 0;
+	return ret;
+}
+
+int pci_reassign_resource(struct pci_dev *dev, int resno, resource_size_t addsize,
+			resource_size_t min_align)
+{
+	struct resource *res = dev->resource + resno;
+	resource_size_t new_size;
+	int ret;
+
+	if (!res->parent) {
+		dev_info(&dev->dev, "BAR %d: can't reassign an unassigned resouce %pR "
+			 "\n", resno, res);
+		return -EINVAL;
 	}
 
+	new_size = resource_size(res) + addsize + min_align;
+	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);
 		if (resno < PCI_BRIDGE_RESOURCES)
 			pci_update_resource(dev, resno);
 	}
-
 	return ret;
 }
 
 int pci_assign_resource(struct pci_dev *dev, int resno)
 {
 	struct resource *res = dev->resource + resno;
-	resource_size_t align;
+	resource_size_t align, size;
 	struct pci_bus *bus;
 	int ret;
-	char *type;
 
 	align = pci_resource_alignment(dev, res);
 	if (!align) {
@@ -214,34 +259,27 @@ int pci_assign_resource(struct pci_dev *
 	}
 
 	bus = dev->bus;
-	while ((ret = __pci_assign_resource(bus, dev, resno))) {
-		if (bus->parent && bus->self->transparent)
-			bus = bus->parent;
-		else
-			bus = NULL;
-		if (bus)
-			continue;
-		break;
-	}
+	size = resource_size(res);
+	ret = _pci_assign_resource(dev, resno, size, align);
 
-	if (ret) {
-		if (res->flags & IORESOURCE_MEM)
-			if (res->flags & IORESOURCE_PREFETCH)
-				type = "mem pref";
-			else
-				type = "mem";
-		else if (res->flags & IORESOURCE_IO)
-			type = "io";
-		else
-			type = "unknown";
-		dev_info(&dev->dev,
-			 "BAR %d: can't assign %s (size %#llx)\n",
-			 resno, type, (unsigned long long) resource_size(res));
-	}
+	/*
+	 * If we failed to assign anything, let's try the address
+	 * where firmware left it.  That at least has a chance of
+	 * working, which is better than just leaving it disabled.
+	 */
+	if (ret < 0 && dev->fw_addr[resno])
+		ret = pci_revert_fw_address(res, dev, resno, size);
 
+	if (!ret) {
+		res->flags &= ~IORESOURCE_STARTALIGN;
+		dev_info(&dev->dev, "BAR %d: assigned %pR\n", resno, res);
+		if (resno < PCI_BRIDGE_RESOURCES)
+			pci_update_resource(dev, resno);
+	}
 	return ret;
 }
 
+
 /* Sort resources by alignment */
 void pdev_sort_resources(struct pci_dev *dev, struct resource_list *head)
 {
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -800,6 +800,7 @@ int __pci_reset_function(struct pci_dev
 int 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

[Herton Ronaldo Krzesinski]

On Wed, Nov 21, 2012 at 04:40:20PM -0800, Greg Kroah-Hartman wrote:
> 3.0-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Ram Pai <linuxram@us.ibm.com>
> 
> 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.
> 
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> Cc: Andrew Worsley <amworsley@gmail.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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.

-- 
[]'s
Herton

Re: [ 37/38] PCI : ability to relocate assigned pci-resources

[Greg Kroah-Hartman]

On Sat, Nov 24, 2012 at 09:41:41AM +0800, Ram Pai wrote:
> On Fri, Nov 23, 2012 at 11:29:20AM -0200, Herton Ronaldo Krzesinski wrote:
> > On Wed, Nov 21, 2012 at 04:40:20PM -0800, Greg Kroah-Hartman wrote:
> > > 3.0-stable review patch.  If anyone has any objections, please let me know.
> > > 
> > > ------------------
> > > 
> > > From: Ram Pai <linuxram@us.ibm.com>
> > > 
> > > 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.
> > > 
> > > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > > Cc: Andrew Worsley <amworsley@gmail.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > 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.
> 
> You are right.  We need to apply that fix along with this patch.

Thanks, now added to the tree.

greg k-h

[ 38/38] PCI : Calculate right add_size

[Greg Kroah-Hartman]

3.0-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Yinghai Lu <yinghai@kernel.org>

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.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Andrew Worsley <amworsley@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pci/setup-bus.c |    4 ++--
 drivers/pci/setup-res.c |    5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -614,7 +614,7 @@ static void pbus_size_io(struct pci_bus
 	if (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_bus
 	if (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)
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -233,11 +233,12 @@ int pci_reassign_resource(struct pci_dev
 		return -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);
 	}