Re: [ 00/13] 3.0.99-stable review

[Guenter Roeck]

On 10/02/2013 09:04 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.0.99 release.
There are 13 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Oct  5 04:03:47 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.99-rc1.gz
and the diffstat can be found below.



Heads up: I am getting lots of build failures in 3.0 and 3.4 builds.

mm/built-in.o: In function `__put_compound_page':
slab.c:(.text+0xaa3c): undefined reference to `PageHuge'
mm/built-in.o: In function `put_compound_page':
slab.c:(.text+0xaab0): undefined reference to `PageHuge'
mm/built-in.o: In function `__get_page_tail':
slab.c:(.text+0xb178): undefined reference to `PageHuge'
make: *** [.tmp_vmlinux1] Error 1

More tomorrow.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems

[Gleb Natapov]

On Thu, Oct 03, 2013 at 08:45:42AM +1000, Paul Mackerras wrote:
> On Wed, Oct 02, 2013 at 04:36:05PM +0200, Alexander Graf wrote:
> > 
> > On 02.10.2013, at 16:33, Paolo Bonzini wrote:
> > 
> > > Il 02/10/2013 16:08, Alexander Graf ha scritto:
> > >>> The hwrng is accessible by host userspace via /dev/mem.
> > >> 
> > >> A guest should live on the same permission level as a user space
> > >> application. If you run QEMU as UID 1000 without access to /dev/mem, why
> > >> should the guest suddenly be able to directly access a memory location
> > >> (MMIO) it couldn't access directly through a normal user space interface.
> > >> 
> > >> It's basically a layering violation.
> > > 
> > > With Michael's earlier patch in this series, the hwrng is accessible by
> > > host userspace via /dev/hwrng, no?
> > 
> > Yes, but there's not token from user space that gets passed into the kernel 
> > to check whether access is ok or not. So while QEMU may not have permission 
> > to open /dev/hwrng it could spawn a guest that opens it, drains all entropy 
> > out of it and thus stall other processes which try to fetch entropy, no?
> 
> Even if you drain all entropy out of it, wait 64 microseconds and it
> will be full again. :)  Basically it produces 64 bits every
> microsecond and puts that in a 64 entry x 64-bit FIFO buffer, which is
> what is read by the MMIO.  So there is no danger of stalling other
> processes for any significant amount of time.
> 
Even if user crates 100s guests each one of which reads hwrng in a loop?

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/7] KGDB/KDB: add support for external NMI handler to call KGDB/KDB.

[Ingo Molnar]

* Jason Wessel  wrote:

> On 09/23/2013 04:25 PM, Mike Travis wrote:
> > This patch adds a kgdb_nmicallin() interface that can be used by
> > external NMI handlers to call the KGDB/KDB handler.  The primary need
> > for this is for those types of NMI interrupts where all the CPUs
> > have already received the NMI signal.  Therefore no send_IPI(NMI)
> > is required, and in fact it will cause a 2nd unhandled NMI to occur.
> > This generates the "Dazed and Confuzed" messages.
> > 
> > Since all the CPUs are getting the NMI at roughly the same time, it's not
> > guaranteed that the first CPU that hits the NMI handler will manage to
> > enter KGDB and set the dbg_master_lock before the slaves start entering.
> > The new argument "send_ready" was added for KGDB to signal the NMI handler
> > to release the slave CPUs for entry into KGDB.
> > 
> > Signed-off-by: Mike Travis 
> > Reviewed-by: Dimitri Sivanich 
> > Reviewed-by: Hedi Berriche 
> 
> One problem that I pointed out before and then you can add 
> 
> Acked-by: Jason Wessel 
>
> > ---
> >  include/linux/kdb.h |1 +
> >  include/linux/kgdb.h|1 +
> >  kernel/debug/debug_core.c   |   30 +-
> >  kernel/debug/debug_core.h   |1 +
> >  kernel/debug/kdb/kdb_debugger.c |5 -
> >  kernel/debug/kdb/kdb_main.c |3 +++
> >  6 files changed, 39 insertions(+), 2 deletions(-)

Jason, would you be fine with me merging this via tip:x86/uv with your 
Acked-by? That is the tree where the actual usecase of this callback would 
be merged upstream (v3.13-ish), and most of the other commits are x86/uv 
specific.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems

[Gleb Natapov]

On Thu, Oct 03, 2013 at 08:02:20AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-02 at 13:02 +0300, Gleb Natapov wrote:
> 
> > Yes, I alluded to it in my email to Paul and Paolo asked also. How this
> > interface is disabled? Also hwrnd is MMIO in a host why guest needs to
> > use hypercall instead of emulating the device (in kernel or somewhere
> > else?).
> 
> Migration will have to be dealt with one way or another, I suppose we
> will indeed need a qemu fallback.
> 
So at least from amount of code perspective userspace and kernel space
solutions are on par since later will require former anyway.

What about other direction? Migration from KVM that does not have the
hypercall to one that has? We try to not change HW under a guest.

> As for why hypercall instead of MMIO, well, you'd have to ask the folks
> who wrote the PAPR spec :-) It's specified as a hypercall and
> implemented as such in pHyp (PowerVM). The existing guests expect it
> that way.
OK.

> 
> It might have to do with the required whitening done by the hypervisor
> (H_RANDOM output is supposed to be clean). It also abstracts us from the
> underlying HW implementation which could in theory change.
>  
But I guess bare metal OS has to know how to do whitening and deal with
HW change already. Anyway this is not the place to discuss PAPR
decisions. Thanks for insights.

> >  Another things is that on a host hwrnd is protected from
> > direct userspace access by virtue of been a device, but guest code (event
> > kernel mode) is userspace as far as hosts security model goes, so by
> > implementing this hypercall in a way that directly access hwrnd you
> > expose hwrnd to a userspace unconditionally. Why is this a good idea? 
> 
> Why would this be a bad idea ?
> 
When you elevate privilege you need to explain why it is not harmful
and why the privilege was restricted in the first place. /dev/hwrng
that first patch created gives access only to root, this patch changes
it to whoever can create a guest. 

Why it can be a bad idea? User can drain hwrng continuously making other
users of it much slower, or even worse, making them fall back to another
much less reliable, source of entropy.

--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] pinctrl: single: Add support for wake-up interrupts

[Tony Lindgren]

The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij .

This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.

Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.

Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.

In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.

Cc: Peter Ujfalusi 
Cc: Grygorii Strashko 
Cc: Prakash Manjunathappa 
Cc: Roger Quadros 
Cc: Haojian Zhuang 
Cc: Linus Walleij 
Cc: linux-kernel@vger.kernel.org
Cc: Benoît Cousson 
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren 
---
 .../devicetree/bindings/pinctrl/pinctrl-single.txt |   11 +
 drivers/pinctrl/pinctrl-single.c   |  325 
 2 files changed, 336 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins & gpio function */
pinctrl-single,gpio-range = < 0 3 0  3 9 1>;
 
+- interrupt-controller : standard interrupt controller binding if using
+  interrupts for wake-up events for example. In this case pinctrl-single
+  is set up as a chained interrupt controller and the wake-up interrupts
+  can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
 This driver assumes that there is only one register for each pin (unless the
 pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux@4a100040 {
reg = <0x4a100040 0x0196>;
#address-cells = <1>;
#size-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0x>;
 };
@@ -131,6 +140,8 @@ pmx_wkup: pinmux@4a31e040 {
reg = <0x4a31e040 0x0038>;
#address-cells = <1>;
#size-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
pinctrl-single,register-width = <16>;
pinctrl-single,function-mask = <0x>;
 };
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f88d3d1..b4ff055 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -15,10 +15,14 @@
 #include 
 #include 
 #include 
+#include 
+
+#include 
 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -152,9 +156,15 @@ struct pcs_name {
 /**
  * struct pcs_soc_data - SoC specific settings
  * @flags: initial SoC specific PCS_FEAT_xxx values
+ * @irq:   optional interrupt for the controller
+ * @irq_enable_mask:   optional SoC specific interrupt enable mask
+ * @irq_status_mask:   optional SoC specific interrupt status mask
  */
 struct pcs_soc_data {
unsigned flags;
+   int irq;
+   unsigned irq_enable_mask;
+   unsigned irq_status_mask;
 };
 
 /**
@@ -165,6 +175,7 @@ struct pcs_soc_data {
  * @dev:   device entry
  * @pctl:  pin controller device
  * @flags: mask of PCS_FEAT_xxx values
+ * @lock:  spinlock for register access
  * @mutex: mutex protecting the lists
  * @width: bits per mux register
  * @fmask: function register mask
@@ -179,6 +190,9 @@ struct pcs_soc_data {
  * @pingroups: list of pingroups
  * @functions: list of functions
  * @gpiofuncs: list of gpio functions
+ * @irqs:  list of interrupt registers
+ * @chip:  chip container for this instance
+ * @domain:IRQ domain for this instance
  * @ngroups:   number of pingroups
  * 

[PATCH 5/6] pinctrl: single: Add support for auxdata

[Tony Lindgren]

For omaps, we still have dependencies to the legacy code
for handling the PRM (Power Reset Management) interrupts,
and also for reconfiguring the io wake-up chain after
changes.

Let's pass the PRM interrupt and the rearm functions via
auxdata. Then when at some point we have a proper PRM
driver, we can get the interrupt via device tree and
set up the rearm function as exported function in the
PRM driver.

By using auxdata we can remove a dependency to the
wake-up events for converting omap3 to be device
tree only.

Cc: Peter Ujfalusi 
Cc: Grygorii Strashko 
Cc: Prakash Manjunathappa 
Cc: Roger Quadros 
Cc: Haojian Zhuang 
Cc: Linus Walleij 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tony Lindgren 
---
 drivers/pinctrl/pinctrl-single.c |   23 +++
 include/linux/platform_data/pinctrl-single.h |   12 
 2 files changed, 35 insertions(+)
 create mode 100644 include/linux/platform_data/pinctrl-single.h

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b4ff055..e7092e8 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include 
+
 #include "core.h"
 #include "pinconf.h"
 
@@ -159,12 +161,14 @@ struct pcs_name {
  * @irq:   optional interrupt for the controller
  * @irq_enable_mask:   optional SoC specific interrupt enable mask
  * @irq_status_mask:   optional SoC specific interrupt status mask
+ * @rearm: optional SoC specific wake-up rearm function
  */
 struct pcs_soc_data {
unsigned flags;
int irq;
unsigned irq_enable_mask;
unsigned irq_status_mask;
+   void (*rearm)(void);
 };
 
 /**
@@ -1622,6 +1626,8 @@ static void pcs_irq_unmask(struct irq_data *d)
struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
 
pcs_irq_set(pcs_soc, d->irq, true);
+   if (pcs_soc->rearm)
+   pcs_soc->rearm();
 }
 
 /**
@@ -1672,6 +1678,11 @@ static int pcs_irq_handle(struct pcs_soc_data *pcs_soc)
}
}
 
+   /*
+* For debugging on omaps, you may want to call pcs_soc->rearm()
+* here to see wake-up interrupts during runtime also.
+*/
+
return count;
 }
 
@@ -1838,6 +1849,7 @@ static int pcs_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *match;
+   struct pcs_pdata *pdata;
struct resource *res;
struct pcs_device *pcs;
const struct pcs_soc_data *soc;
@@ -1952,6 +1964,17 @@ static int pcs_probe(struct platform_device *pdev)
if (pcs->socdata.irq)
pcs->flags |= PCS_FEAT_IRQ;
 
+   /* We still need auxdata for some omaps for PRM interrupts */
+   pdata = dev_get_platdata(>dev);
+   if (pdata) {
+   if (pdata->rearm)
+   pcs->socdata.rearm = pdata->rearm;
+   if (pdata->irq) {
+   pcs->socdata.irq = pdata->irq;
+   pcs->flags |= PCS_FEAT_IRQ;
+   }
+   }
+
if (PCS_HAS_IRQ) {
ret = pcs_irq_init_chained_handler(pcs, np);
if (ret < 0)
diff --git a/include/linux/platform_data/pinctrl-single.h 
b/include/linux/platform_data/pinctrl-single.h
new file mode 100644
index 000..72eacda
--- /dev/null
+++ b/include/linux/platform_data/pinctrl-single.h
@@ -0,0 +1,12 @@
+/**
+ * irq:optional wake-up interrupt
+ * rearm:  optional soc specific rearm function
+ *
+ * Note that the irq and rearm setup should come from device
+ * tree except for omap where there are still some dependencies
+ * to the legacy PRM code.
+ */
+struct pcs_pdata {
+   int irq;
+   void (*rearm)(void);
+};

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features

[Tony Lindgren]

Let's replace is_pinconf with flags and add struct pcs_soc_data
so we can support SoC specific features like pin wake-up events.

Done in collaboration with Roger Quadros .

Cc: Peter Ujfalusi 
Cc: Grygorii Strashko 
Cc: Prakash Manjunathappa 
Cc: Haojian Zhuang 
Cc: Linus Walleij 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
 drivers/pinctrl/pinctrl-single.c |   38 +-
 1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a82ace4..f88d3d1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -150,19 +150,27 @@ struct pcs_name {
 };
 
 /**
+ * struct pcs_soc_data - SoC specific settings
+ * @flags: initial SoC specific PCS_FEAT_xxx values
+ */
+struct pcs_soc_data {
+   unsigned flags;
+};
+
+/**
  * struct pcs_device - pinctrl device instance
  * @res:   resources
  * @base:  virtual address of the controller
  * @size:  size of the ioremapped area
  * @dev:   device entry
  * @pctl:  pin controller device
+ * @flags: mask of PCS_FEAT_xxx values
  * @mutex: mutex protecting the lists
  * @width: bits per mux register
  * @fmask: function register mask
  * @fshift:function register shift
  * @foff:  value to turn mux off
  * @fmax:  max number of functions in fmask
- * @is_pinconf:whether supports pinconf
  * @bits_per_pin:number of bits per pin
  * @names: array of register names for pins
  * @pins:  physical pins on the SoC
@@ -183,6 +191,8 @@ struct pcs_device {
unsigned size;
struct device *dev;
struct pinctrl_dev *pctl;
+   unsigned flags;
+#define PCS_FEAT_PINCONF   (1 << 0)
struct mutex mutex;
unsigned width;
unsigned fmask;
@@ -190,7 +200,6 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
-   bool is_pinconf;
unsigned bits_per_pin;
struct pcs_name *names;
struct pcs_data pins;
@@ -206,6 +215,8 @@ struct pcs_device {
void (*write)(unsigned val, void __iomem *reg);
 };
 
+#define PCS_HAS_PINCONF(pcs->flags & PCS_FEAT_PINCONF)
+
 static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
   unsigned long *config);
 static int pcs_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1060,7 +1071,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs, 
struct device_node *np,
};
 
/* If pinconf isn't supported, don't parse properties in below. */
-   if (!pcs->is_pinconf)
+   if (!PCS_HAS_PINCONF)
return 0;
 
/* cacluate how much properties are supported in current node */
@@ -1184,7 +1195,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device 
*pcs,
(*map)->data.mux.group = np->name;
(*map)->data.mux.function = np->name;
 
-   if (pcs->is_pinconf) {
+   if (PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1305,7 +1316,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct 
pcs_device *pcs,
(*map)->data.mux.group = np->name;
(*map)->data.mux.function = np->name;
 
-   if (pcs->is_pinconf) {
+   if (PCS_HAS_PINCONF) {
dev_err(pcs->dev, "pinconf not supported\n");
goto free_pingroups;
}
@@ -1525,6 +1536,7 @@ static int pcs_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
+   const struct pcs_soc_data *soc;
int ret;
 
match = of_match_device(pcs_of_match, >dev);
@@ -1541,7 +1553,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(>pingroups);
INIT_LIST_HEAD(>functions);
INIT_LIST_HEAD(>gpiofuncs);
-   pcs->is_pinconf = match->data;
+   soc = match->data;
+   pcs->flags = soc->flags;
 
PCS_GET_PROP_U32("pinctrl-single,register-width", >width,
 "register width not specified\n");
@@ -1610,7 +1623,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs->desc.name = DRIVER_NAME;
pcs->desc.pctlops = _pinctrl_ops;
pcs->desc.pmxops = _pinmux_ops;
-   if (pcs->is_pinconf)
+   if (PCS_HAS_PINCONF)
pcs->desc.confops = _pinconf_ops;
pcs->desc.owner = THIS_MODULE;
 
@@ -1652,9 +1665,16 @@ static int pcs_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct pcs_soc_data pinctrl_single = {
+};
+
+static const struct pcs_soc_data pinconf_single = {
+   .flags = PCS_FEAT_PINCONF,
+};
+
 static struct of_device_id pcs_of_match[] = {
-   { .compatible = "pinctrl-single", .data = (void *)false },
-   { .compatible = 

Re: [PATCH 6/9][v5] powerpc/perf: Define big-endian version of perf_mem_data_src

[Michael Ellerman]

On Tue, Oct 01, 2013 at 05:15:07PM -0700, Sukadev Bhattiprolu wrote:
> perf_mem_data_src is an union that is initialized via the ->val field
> and accessed via the bitmap fields. For this to work on big endian
> platforms, we also need a big-endian represenation of perf_mem_data_src.
> 
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index ca1d90b..846f399 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -19,6 +19,50 @@
>  #include 
>  
>  /*
> + * Kernel and userspace check for endianness in incompatible ways.
> + * In user space,  defines both __BIG_ENDIAN and __LITTLE_ENDIAN
> + * but sets __BYTE_ORDER to one or the other. So user space uses checks are:


Why can't you use __BIG_ENDIAN_BITFIELD ?

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/7] cross rename

[H. Peter Anvin]

Yes... Al  and I had a brief conversation about the complexities over IRC this 
evening.

Linus Torvalds  wrote:
>On Wed, Oct 2, 2013 at 6:58 PM, H. Peter Anvin  wrote:
>>
>> I would suggest it shouldn't be renameat2() but rather renameat3(),
>i.e.
>> rename file A -> B, if B exists rename B to C.  It may not be
>desirable
>> to expose the stale B in the same namespace as A, but still want it
>to
>> be possible to scavenge it.  Obviously, A=C is a valid subcase.
>
>I really *really* prefer to stay with two names. Miklos had an earlier
>three-name version, and it was hugely more complex, and it does not
>fit nearly as well in the model.
>
>Two directory entries is also what the current rename() effectively
>always does (clearing one, changing another). So doing the
>cross-rename model is actually fairly close to a normal rename. A
>three-way one is not actually at all similar.
>
>So I was actually very relieved to see this much simpler and cleaner
>model, because the alternative really was nasty. This one looks fairly
>simple and clean and straightforward. The previous was none of that.
>
>  Linus

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] cpufreq: make sure frequency transitions are serialized

[Viresh Kumar]

On 26 September 2013 00:07, Rafael J. Wysocki  wrote:
> So the problem is real, but the fix seems to be of a "quick and dirty" kind.

Hmm..

> First of all, it looks like we need a clear "begin transition" call that
> I suppose drivers should execute from their .target() methods once they have
> decided to do a transition.  That would increment the "ongoing" counter etc.
>
> Second, we need a corresponding "end transition" call that would be executed
> whenever appropriate from the driver's perspective.

Hmm..

> Clearly, these two things should be independent of the notifiers and the
> notifications should only be done between "begin transition" and "end
> transition" and only by whoever called the "begin transition" to start with.

So, we need to have begin/end calls in cpufreq_out_of_sync() as well?
As that is sending notifications..

> Now, question is what should happen if "begin transition" is called when
> the previous transition hasn't been completed yet, should it block or should
> it fail?  There seem to be arguments for both, but I suppose blocking would be
> easier to implement.

Hmm.. I will repost this once my other patches are in now.. as that will
change ->target() routine for multiple drivers and things would be simple
to fix then..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9][v5] powerpc: implement is_instr_load_store().

[Michael Ellerman]

On Tue, Oct 01, 2013 at 05:15:06PM -0700, Sukadev Bhattiprolu wrote:
> Implement is_instr_load_store() to detect whether a given instruction
> is one of the fixed-point or floating-point load/store instructions.
> This function will be used in a follow-on patch to save memory hierarchy
> information of the load/store.

The search over the array is a bit of a pity, especially as the worst
case penalises you when you haven't hit a load/store.

I think we can do better. If you look at the opcode maps, and in
particular the extended table for opcode 31, you'll see there's a
reasonable amount of structure.

The following is only valid for arch 2.06, ie. it will classify reserved
opcodes as being load/store, but I think that's fine for the moment. If
we need to use it somewhere in future we can update it. But we should
add a big comment saying it's only valid in that case.

Anyway, I think the following logic is all we need for opcode 31:

bool is_load_store(int ext_opcode)
{
upper = ext_opcode >> 5;
lower = ext_opcode & 0x1f;

/* Short circuit as many misses as we can */
if (lower < 3 || lower > 23)
return false;

if (lower == 3)
if (upper >= 16)
return true;

return false;

if (lower == 6)
if (upper <= 1)
return true;
return false;

if (lower == 7 || lower == 12)
return true;

if (lower >= 20) /* && lower <= 23 (implicit) */
return true;

return false;
}


Which is not pretty, but I think it's preferable to the full search over the
array.

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 0/7] cross rename

[Linus Torvalds]

On Wed, Oct 2, 2013 at 6:58 PM, H. Peter Anvin  wrote:
>
> I would suggest it shouldn't be renameat2() but rather renameat3(), i.e.
> rename file A -> B, if B exists rename B to C.  It may not be desirable
> to expose the stale B in the same namespace as A, but still want it to
> be possible to scavenge it.  Obviously, A=C is a valid subcase.

I really *really* prefer to stay with two names. Miklos had an earlier
three-name version, and it was hugely more complex, and it does not
fit nearly as well in the model.

Two directory entries is also what the current rename() effectively
always does (clearing one, changing another). So doing the
cross-rename model is actually fairly close to a normal rename. A
three-way one is not actually at all similar.

So I was actually very relieved to see this much simpler and cleaner
model, because the alternative really was nasty. This one looks fairly
simple and clean and straightforward. The previous was none of that.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers

[Suman Anna]

Hi Mark,

On 10/01/2013 03:36 AM, Mark Rutland wrote:
> Hi Suman,
> 
> Apologies for replying to a subthread, due to an earlier mistake on my
> part I don't have the original to hand.

No issues, thanks for your review.

> 
> On Fri, Sep 27, 2013 at 05:04:22PM +0100, Kumar Gala wrote:
>>
>> On Sep 17, 2013, at 2:30 PM, Suman Anna wrote:
>>
>>> All the platform-specific hwlock driver implementations need the
>>> number of locks and the associated base id for registering the
>>> locks present within a hwspinlock device with the driver core.
>>> These two variables are represented by 'hwlock-num-locks' and
>>> 'hwlock-base-id' properties. The documentation and OF helpers to
>>> retrieve these common properties have been added to the driver core.
>>>
>>> Signed-off-by: Suman Anna 
>>> ---
>>> .../devicetree/bindings/hwlock/hwlock.txt  | 26 +
>>> drivers/hwspinlock/hwspinlock_core.c   | 61 
>>> +-
>>> include/linux/hwspinlock.h | 11 ++--
>>> 3 files changed, 93 insertions(+), 5 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt 
>>> b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> new file mode 100644
>>> index 000..789930e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> @@ -0,0 +1,26 @@
>>> +Generic hwlock bindings
>>> +===
>>> +
>>> +Generic bindings that are common to all the hwlock platform specific driver
>>> +implementations, the retrieved values are used for registering the device
>>> +specific parameters with the hwspinlock core.
>>> +
>>> +The validity and need of these common properties may vary from one driver
>>> +implementation to another. Look through the individual hwlock driver
>>> +binding documentations for identifying which are mandatory and which are
>>> +optional for that specific driver.
>>> +
>>> +Common properties:
>>> +- hwlock-base-id:  Base Id for the locks for a particular hwlock device.
>>> +   This property is used for representing a set of locks
>>> +   present in a hwlock device with a unique base id in
>>> +   the driver core. This property is mandatory ONLY if a
>>> +   SoC has several hwlock devices.
>>> +
>>> +   See documentation on struct hwspinlock_pdata in
>>> +   linux/hwspinlock.h for more details.
> 
> I don't like this, as it seems to be encoding a Linux implementation
> detail (the ID of the lock, which means that we have to have a numeric
> representation of each hwlock) in the device tree.
> 
> I don't see why the ID within Linux should be a concern of the device
> tree binding. I think that whatever internal identifier we have in Linux
> (be it an integer or struct) should be allocated by Linux. If a driver
> needs to request specific hwlocks, then we should have a phandle + args
> representation for referring to a specific hwlock that bidnings can use,
> and some code for parsing that and returning a Linux-internal
> identifier/struct as we do with interrupts and clocks.

This is based on gathering the information required by the platform
implementation drivers for registering with the driver core. The driver
core currently maintains all the locks from different instances as a
radix tree, as it is simpler to manage when granting locks to users.
The current version is based on allowing the platform implementation
drivers to retrieve the required data for registering with the
hwspinlock driver core.

The users would either get a lock dynamically by requesting any free one
(and extract the id thereafter to share with others), or a specific one
which is currently by id. I agree that the phandle + args approach is
best suited for requesting a specific one through DT, but I would think
that the args would still have to be a relative lock number from 0 w.r.t
a phandle. I will look into the feasibility of such an approach
retaining the radix tree implementation, as this requires new OF
friendly registration and request functions.

> 
>>> +
>>> +- hwlock-num-locks:Number of locks present in a hwlock device. This
>>> +   property is needed on hwlock devices, where the number
>>> +   of supported locks within a hwlock device cannot be
>>> +   read from a register.
> 
> Hmm... this seems generic, but it doesn't allow for sparse ID spaces on
> the hwlock module. It should probably be common for the moment, but if
> we encounter a hwlock module with a sparse ID space, we'll need to come
> up with a way of handling sparse IDs (that might be device-specific).

Agreed.

> 
>>> diff --git a/drivers/hwspinlock/hwspinlock_core.c 
>>> b/drivers/hwspinlock/hwspinlock_core.c
>>> index 461a0d7..aec32e7 100644
>>> --- a/drivers/hwspinlock/hwspinlock_core.c
>>> +++ 

[ 14/16] mm, memcg: give exiting processes access to memory reserves

[Greg Kroah-Hartman]

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

--


From: David Rientjes 

commit 465adcf1ea7b2e49b2e0899366624f5532b64012

A memcg may livelock when oom if the process that grabs the hierarchy's
oom lock is never the first process with PF_EXITING set in the memcg's
task iteration.

The oom killer, both global and memcg, will defer if it finds an
eligible process that is in the process of exiting and it is not being
ptraced.  The idea is to allow it to exit without using memory reserves
before needlessly killing another process.

This normally works fine except in the memcg case with a large number of
threads attached to the oom memcg.  In this case, the memcg oom killer
only gets called for the process that grabs the hierarchy's oom lock;
all others end up blocked on the memcg's oom waitqueue.  Thus, if the
process that grabs the hierarchy's oom lock is never the first
PF_EXITING process in the memcg's task iteration, the oom killer is
constantly deferred without anything making progress.

The fix is to give PF_EXITING processes access to memory reserves so
that we've marked them as oom killed without any iteration.  This allows
__mem_cgroup_try_charge() to succeed so that the process may exit.  This
makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
immediately granted for processes with pending SIGKILLs and those in the
exit path, to be equivalent to what is done for the global oom killer.

Signed-off-by: David Rientjes 
Acked-by: Michal Hocko 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Qiang: backported to 3.4:
 - move the changes from memcontrol.c to oom_kill.c]
Signed-off-by: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman 
---
 mm/oom_kill.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -562,11 +562,11 @@ void mem_cgroup_out_of_memory(struct mem
struct task_struct *p;
 
/*
-* If current has a pending SIGKILL, then automatically select it.  The
-* goal is to allow it to allocate so that it may quickly exit and free
-* its memory.
+* If current has a pending SIGKILL or is exiting, then automatically
+* select it.  The goal is to allow it to allocate so that it may
+* quickly exit and free its memory.
 */
-   if (fatal_signal_pending(current)) {
+   if (fatal_signal_pending(current) || current->flags & PF_EXITING) {
set_thread_flag(TIF_MEMDIE);
return;
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 15/16] mm: fix aio performance regression for database caused by THP

[Greg Kroah-Hartman]

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

--

From: Khalid Aziz 

commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream.

This patch needed to be backported due to changes to mm/swap.c some time
after 3.6 kernel.

I am working with a tool that simulates oracle database I/O workload.
This tool (orion to be specific -
)
allocates hugetlbfs pages using shmget() with SHM_HUGETLB flag.  It then
does aio into these pages from flash disks using various common block
sizes used by database.  I am looking at performance with two of the most
common block sizes - 1M and 64K.  aio performance with these two block
sizes plunged after Transparent HugePages was introduced in the kernel.
Here are performance numbers:

pre-THP 2.6.39  3.11-rc5
1M read 8384 MB/s   5629 MB/s   6501 MB/s
64K read7867 MB/s   4576 MB/s   4251 MB/s

I have narrowed the performance impact down to the overheads introduced by
THP in __get_page_tail() and put_compound_page() routines.  perf top shows
>40% of cycles being spent in these two routines.  Every time direct I/O
to hugetlbfs pages starts, kernel calls get_page() to grab a reference to
the pages and calls put_page() when I/O completes to put the reference
away.  THP introduced significant amount of locking overhead to get_page()
and put_page() when dealing with compound pages because hugepages can be
split underneath get_page() and put_page().  It added this overhead
irrespective of whether it is dealing with hugetlbfs pages or transparent
hugepages.  This resulted in 20%-45% drop in aio performance when using
hugetlbfs pages.

Since hugetlbfs pages can not be split, there is no reason to go through
all the locking overhead for these pages from what I can see.  I added
code to __get_page_tail() and put_compound_page() to bypass all the
locking code when working with hugetlbfs pages.  This improved performance
significantly.  Performance numbers with this patch:

pre-THP 3.11-rc53.11-rc5 + Patch
1M read 8384 MB/s   6501 MB/s   8371 MB/s
64K read7867 MB/s   4251 MB/s   6510 MB/s

Performance with 64K read is still lower than what it was before THP, but
still a 53% improvement.  It does mean there is more work to be done but I
will take a 53% improvement for now.

Please take a look at the following patch and let me know if it looks
reasonable.

[a...@linux-foundation.org: tweak comments]
Signed-off-by: Khalid Aziz 
Cc: Pravin B Shelar 
Cc: Christoph Lameter 
Cc: Andrea Arcangeli 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Minchan Kim 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
---
 mm/swap.c |   65 --
 1 file changed, 47 insertions(+), 18 deletions(-)

--- a/mm/swap.c
+++ b/mm/swap.c
@@ -40,6 +40,8 @@ static DEFINE_PER_CPU(struct pagevec[NR_
 static DEFINE_PER_CPU(struct pagevec, lru_rotate_pvecs);
 static DEFINE_PER_CPU(struct pagevec, lru_deactivate_pvecs);
 
+int PageHuge(struct page *page);
+
 /*
  * This path almost never happens for VM activity - pages are normally
  * freed via pagevecs.  But it gets used by networking.
@@ -68,13 +70,26 @@ static void __put_compound_page(struct p
 {
compound_page_dtor *dtor;
 
-   __page_cache_release(page);
+   if (!PageHuge(page))
+   __page_cache_release(page);
dtor = get_compound_page_dtor(page);
(*dtor)(page);
 }
 
 static void put_compound_page(struct page *page)
 {
+   /*
+* hugetlbfs pages can not be split from under us. So if this
+* is a hugetlbfs page, check refcount on head page and release
+* the page if refcount is zero.
+*/
+   if (PageHuge(page)) {
+   page = compound_head(page);
+   if (put_page_testzero(page))
+   __put_compound_page(page);
+   return;
+   }
+
if (unlikely(PageTail(page))) {
/* __split_huge_page_refcount can run under us */
struct page *page_head = compound_trans_head(page);
@@ -157,26 +172,40 @@ bool __get_page_tail(struct page *page)
 * proper PT lock that already serializes against
 * split_huge_page().
 */
-   unsigned long flags;
bool got = false;
-   struct page *page_head = compound_trans_head(page);
 
-   if (likely(page != page_head && get_page_unless_zero(page_head))) {
-   /*
-* page_head wasn't a dangling pointer but it
-* may not be a head page anymore by the time
-* we obtain the lock. That is ok as long as it
-* can't be freed from under us.
-*/
-   flags = 

[ 16/16] HID: LG: validate HID output report details

[Greg Kroah-Hartman]

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

--

From: Kees Cook 

commit 0fb6bd06e06792469acc15bbe427361b56ada528 upstream.

A HID device could send a malicious output report that would cause the
lg, lg3, and lg4 HID drivers to write beyond the output report allocation
during an event, causing a heap overflow:

[  325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
...
[  414.518960] BUG kmalloc-4096 (Not tainted): Redzone overwritten

Additionally, while lg2 did correctly validate the report details, it was
cleaned up and shortened.

CVE-2013-2893

Signed-off-by: Kees Cook 
Reviewed-by: Benjamin Tissoires 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hid/hid-lg2ff.c |   19 +++
 drivers/hid/hid-lg3ff.c |   29 ++---
 drivers/hid/hid-lg4ff.c |   20 +---
 drivers/hid/hid-lgff.c  |   17 ++---
 4 files changed, 12 insertions(+), 73 deletions(-)

--- a/drivers/hid/hid-lg2ff.c
+++ b/drivers/hid/hid-lg2ff.c
@@ -66,26 +66,13 @@ int lg2ff_init(struct hid_device *hid)
struct hid_report *report;
struct hid_input *hidinput = list_entry(hid->inputs.next,
struct hid_input, list);
-   struct list_head *report_list =
-   >report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
int error;
 
-   if (list_empty(report_list)) {
-   hid_err(hid, "no output report found\n");
+   /* Check that the report looks ok */
+   report = hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 7);
+   if (!report)
return -ENODEV;
-   }
-
-   report = list_entry(report_list->next, struct hid_report, list);
-
-   if (report->maxfield < 1) {
-   hid_err(hid, "output report is empty\n");
-   return -ENODEV;
-   }
-   if (report->field[0]->report_count < 7) {
-   hid_err(hid, "not enough values in the field\n");
-   return -ENODEV;
-   }
 
lg2ff = kmalloc(sizeof(struct lg2ff_device), GFP_KERNEL);
if (!lg2ff)
--- a/drivers/hid/hid-lg3ff.c
+++ b/drivers/hid/hid-lg3ff.c
@@ -68,10 +68,11 @@ static int hid_lg3ff_play(struct input_d
int x, y;
 
 /*
- * Maxusage should always be 63 (maximum fields)
- * likely a better way to ensure this data is clean
+ * Available values in the field should always be 63, but we only use up to
+ * 35. Instead, clear the entire area, however big it is.
  */
-   memset(report->field[0]->value, 0, 
sizeof(__s32)*report->field[0]->maxusage);
+   memset(report->field[0]->value, 0,
+  sizeof(__s32) * report->field[0]->report_count);
 
switch (effect->type) {
case FF_CONSTANT:
@@ -131,32 +132,14 @@ static const signed short ff3_joystick_a
 int lg3ff_init(struct hid_device *hid)
 {
struct hid_input *hidinput = list_entry(hid->inputs.next, struct 
hid_input, list);
-   struct list_head *report_list = 
>report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
-   struct hid_report *report;
-   struct hid_field *field;
const signed short *ff_bits = ff3_joystick_ac;
int error;
int i;
 
-   /* Find the report to use */
-   if (list_empty(report_list)) {
-   hid_err(hid, "No output report found\n");
-   return -1;
-   }
-
/* Check that the report looks ok */
-   report = list_entry(report_list->next, struct hid_report, list);
-   if (!report) {
-   hid_err(hid, "NULL output report\n");
-   return -1;
-   }
-
-   field = report->field[0];
-   if (!field) {
-   hid_err(hid, "NULL field\n");
-   return -1;
-   }
+   if (!hid_validate_values(hid, HID_OUTPUT_REPORT, 0, 0, 35))
+   return -ENODEV;
 
/* Assume single fixed device G940 */
for (i = 0; ff_bits[i] >= 0; i++)
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -339,33 +339,15 @@ static ssize_t lg4ff_range_store(struct
 int lg4ff_init(struct hid_device *hid)
 {
struct hid_input *hidinput = list_entry(hid->inputs.next, struct 
hid_input, list);
-   struct list_head *report_list = 
>report_enum[HID_OUTPUT_REPORT].report_list;
struct input_dev *dev = hidinput->input;
-   struct hid_report *report;
-   struct hid_field *field;
struct lg4ff_device_entry *entry;
struct usb_device_descriptor *udesc;
int error, i, j;
__u16 bcdDevice, rev_maj, rev_min;
 
-   /* Find the report to use */
-   if (list_empty(report_list)) {
-   hid_err(hid, "No output report found\n");
-   return -1;
-   }
-
/* Check that the report looks ok */
-   report = list_entry(report_list->next, struct 

[ 12/52] x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically

[Greg Kroah-Hartman]

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

--

From: Masoud Sharbiani 

commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream.

Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time.

Signed-off-by: Masoud Sharbiani 
Signed-off-by: Vinson Lee 
Cc: Robin Holt 
Cc: Russell King 
Cc: Guan Xuetao 
Link: 
http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-v...@freedesktop.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/reboot.c |   16 
 1 file changed, 16 insertions(+)

--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -447,6 +447,22 @@ static struct dmi_system_id __initdata r
DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
},
},
+   {   /* Handle problems with rebooting on the Dell PowerEdge C6100. 
*/
+   .callback = set_pci_reboot,
+   .ident = "Dell PowerEdge C6100",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+   },
+   },
+   {   /* Some C6100 machines were shipped with vendor being 'Dell'. */
+   .callback = set_pci_reboot,
+   .ident = "Dell PowerEdge C6100",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
+   },
+   },
{ }
 };
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 19/52] serial: tegra: fix tty-kref leak

[Greg Kroah-Hartman]

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

--

From: Johan Hovold 

commit cfd29aa0e81b791985e8428e6507e80e074e6730 upstream.

Fix potential tty-kref leak in stop_rx path.

Signed-off-by: Johan Hovold 
Tested-by: Stephen Warren 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/serial-tegra.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -726,7 +726,7 @@ static irqreturn_t tegra_uart_isr(int ir
 static void tegra_uart_stop_rx(struct uart_port *u)
 {
struct tegra_uart_port *tup = to_tegra_uport(u);
-   struct tty_struct *tty = tty_port_tty_get(>uport.state->port);
+   struct tty_struct *tty;
struct tty_port *port = >state->port;
struct dma_tx_state state;
unsigned long ier;
@@ -738,6 +738,8 @@ static void tegra_uart_stop_rx(struct ua
if (!tup->rx_in_progress)
return;
 
+   tty = tty_port_tty_get(>uport.state->port);
+
tegra_uart_wait_sym_time(tup, 1); /* wait a character interval */
 
ier = tup->ier_shadow;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 15/52] mei: make me client counters less error prone

[Greg Kroah-Hartman]

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

--

From: Tomas Winkler 

commit 1aee351a739153529fbb98ee461777b2abd5e1c9 upstream.

1. u8 counters are prone to hard to detect overflow:
 make them unsigned long to match bit_ functions argument type

2. don't check me_clients_num for negativity, it is unsigned.

3. init all the me client counters from one place

Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/hbm.c |   10 ++
 drivers/misc/mei/mei_dev.h |6 +++---
 2 files changed, 9 insertions(+), 7 deletions(-)

--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -35,11 +35,15 @@ static void mei_hbm_me_cl_allocate(struc
struct mei_me_client *clients;
int b;
 
+   dev->me_clients_num = 0;
+   dev->me_client_presentation_num = 0;
+   dev->me_client_index = 0;
+
/* count how many ME clients we have */
for_each_set_bit(b, dev->me_clients_map, MEI_CLIENTS_MAX)
dev->me_clients_num++;
 
-   if (dev->me_clients_num <= 0)
+   if (dev->me_clients_num == 0)
return;
 
kfree(dev->me_clients);
@@ -221,7 +225,7 @@ static int mei_hbm_prop_req(struct mei_d
struct hbm_props_request *prop_req;
const size_t len = sizeof(struct hbm_props_request);
unsigned long next_client_index;
-   u8 client_num;
+   unsigned long client_num;
 
 
client_num = dev->me_client_presentation_num;
@@ -650,8 +654,6 @@ void mei_hbm_dispatch(struct mei_device
if (dev->dev_state == MEI_DEV_INIT_CLIENTS &&
dev->hbm_state == MEI_HBM_ENUM_CLIENTS) {
dev->init_clients_timer = 0;
-   dev->me_client_presentation_num = 0;
-   dev->me_client_index = 0;
mei_hbm_me_cl_allocate(dev);
dev->hbm_state = MEI_HBM_CLIENT_PROPERTIES;
 
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -402,9 +402,9 @@ struct mei_device {
struct mei_me_client *me_clients; /* Note: memory has to be allocated */
DECLARE_BITMAP(me_clients_map, MEI_CLIENTS_MAX);
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
-   u8 me_clients_num;
-   u8 me_client_presentation_num;
-   u8 me_client_index;
+   unsigned long me_clients_num;
+   unsigned long me_client_presentation_num;
+   unsigned long me_client_index;
 
struct mei_cl wd_cl;
enum mei_wd_states wd_state;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 17/52] mei: cancel stall timers in mei_reset

[Greg Kroah-Hartman]

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

--

From: Alexander Usyskin 

commit 4a704575cc1afb3b848f096778fa9b8d7b3d5813 upstream.

Unset init_clients_timer and amthif_stall_timers
in mei_reset in order to cancel timer ticking and hence
avoid recursive reset calls.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/amthif.c |1 +
 drivers/misc/mei/init.c   |3 +++
 2 files changed, 4 insertions(+)

--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -57,6 +57,7 @@ void mei_amthif_reset_params(struct mei_
dev->iamthif_ioctl = false;
dev->iamthif_state = MEI_IAMTHIF_IDLE;
dev->iamthif_timer = 0;
+   dev->iamthif_stall_timer = 0;
 }
 
 /**
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -164,6 +164,9 @@ void mei_reset(struct mei_device *dev, i
memset(>wr_ext_msg, 0, sizeof(dev->wr_ext_msg));
}
 
+   /* we're already in reset, cancel the init timer */
+   dev->init_clients_timer = 0;
+
dev->me_clients_num = 0;
dev->rd_msg_hdr = 0;
dev->wd_pending = false;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 25/52] drm/i915/tv: clear adjusted_mode.flags

[Greg Kroah-Hartman]

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

--

From: Daniel Vetter 

commit 1062b81598bc00e2f6620e6f3788f8f8df2f01e7 upstream.

The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.

This changed with the additional sanitation done with

commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0
Author: Imre Deak 
Date:   Tue Jul 30 13:36:32 2013 +0300

drm/i915: make user mode sync polarity setting explicit

sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.

Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us.  But that's
definitely work for a different patch series. So just add a FIXME
comment for now.

Reported-by: Knut Petersen 
Cc: Knut Petersen 
Cc: Imre Deak 
Cc: Chris Wilson 
Tested-by: Knut Petersen 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/intel_tv.c |8 
 1 file changed, 8 insertions(+)

--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -921,6 +921,14 @@ intel_tv_compute_config(struct intel_enc
DRM_DEBUG_KMS("forcing bpc to 8 for TV\n");
pipe_config->pipe_bpp = 8*3;
 
+   /* TV has it's own notion of sync and other mode flags, so clear them. 
*/
+   pipe_config->adjusted_mode.flags = 0;
+
+   /*
+* FIXME: We don't check whether the input mode is actually what we want
+* or whether userspace is doing something stupid.
+*/
+
return true;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 29/52] xhci: Fix race between ep halt and URB cancellation

[Greg Kroah-Hartman]

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

--

From: Florian Wolter 

commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.

The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699

Signed-off-by: Florian Wolter 
Signed-off-by: Sarah Sharp 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-ring.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -857,8 +857,12 @@ remove_finished_td:
/* Otherwise ring the doorbell(s) to restart queued transfers */
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
-   ep->stopped_td = NULL;
-   ep->stopped_trb = NULL;
+
+   /* Clear stopped_td and stopped_trb if endpoint is not halted */
+   if (!(ep->ep_state & EP_HALTED)) {
+   ep->stopped_td = NULL;
+   ep->stopped_trb = NULL;
+   }
 
/*
 * Drop the lock and complete the URBs in the cancelled TD list.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 06/52] bcache: Fix a writeback performance regression

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit c2a4f3183a1248f615a695fbd8905da55ad11bba upstream.

Background writeback works by scanning the btree for dirty data and
adding those keys into a fixed size buffer, then for each dirty key in
the keybuf writing it to the backing device.

When read_dirty() finishes and it's time to scan for more dirty data, we
need to wait for the outstanding writeback IO to finish - they still
take up slots in the keybuf (so that foreground writes can check for
them to avoid races) - without that wait, we'll continually rescan when
we'll be able to add at most a key or two to the keybuf, and that takes
locks that starves foreground IO.  Doh.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/bcache.h|7 ++
 drivers/md/bcache/util.c  |   11 +-
 drivers/md/bcache/util.h  |   12 ---
 drivers/md/bcache/writeback.c |   43 --
 4 files changed, 43 insertions(+), 30 deletions(-)

--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -499,7 +499,7 @@ struct cached_dev {
 */
atomic_thas_dirty;
 
-   struct ratelimitwriteback_rate;
+   struct bch_ratelimitwriteback_rate;
struct delayed_work writeback_rate_update;
 
/*
@@ -508,10 +508,9 @@ struct cached_dev {
 */
sector_tlast_read;
 
-   /* Number of writeback bios in flight */
-   atomic_tin_flight;
+   /* Limit number of writeback bios in flight */
+   struct semaphorein_flight;
struct closure_with_timer writeback;
-   struct closure_waitlist writeback_wait;
 
struct keybuf   writeback_keys;
 
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -190,7 +190,16 @@ void bch_time_stats_update(struct time_s
stats->last = now ?: 1;
 }
 
-unsigned bch_next_delay(struct ratelimit *d, uint64_t done)
+/**
+ * bch_next_delay() - increment @d by the amount of work done, and return how
+ * long to delay until the next time to do some work.
+ *
+ * @d - the struct bch_ratelimit to update
+ * @done - the amount of work done, in arbitrary units
+ *
+ * Returns the amount of time to delay by, in jiffies
+ */
+uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done)
 {
uint64_t now = local_clock();
 
--- a/drivers/md/bcache/util.h
+++ b/drivers/md/bcache/util.h
@@ -452,17 +452,23 @@ read_attribute(name ## _last_ ## frequen
(ewma) >> factor;   \
 })
 
-struct ratelimit {
+struct bch_ratelimit {
+   /* Next time we want to do some work, in nanoseconds */
uint64_tnext;
+
+   /*
+* Rate at which we want to do work, in units per nanosecond
+* The units here correspond to the units passed to bch_next_delay()
+*/
unsignedrate;
 };
 
-static inline void ratelimit_reset(struct ratelimit *d)
+static inline void bch_ratelimit_reset(struct bch_ratelimit *d)
 {
d->next = local_clock();
 }
 
-unsigned bch_next_delay(struct ratelimit *d, uint64_t done);
+uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done);
 
 #define __DIV_SAFE(n, d, zero) \
 ({ \
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -91,11 +91,15 @@ static void update_writeback_rate(struct
 
 static unsigned writeback_delay(struct cached_dev *dc, unsigned sectors)
 {
+   uint64_t ret;
+
if (atomic_read(>disk.detaching) ||
!dc->writeback_percent)
return 0;
 
-   return bch_next_delay(>writeback_rate, sectors * 1000ULL);
+   ret = bch_next_delay(>writeback_rate, sectors * 1000ULL);
+
+   return min_t(uint64_t, ret, HZ);
 }
 
 /* Background writeback */
@@ -165,7 +169,7 @@ static void refill_dirty(struct closure
 
up_write(>writeback_lock);
 
-   ratelimit_reset(>writeback_rate);
+   bch_ratelimit_reset(>writeback_rate);
 
/* Punt to workqueue only so we don't recurse and blow the stack */
continue_at(cl, read_dirty, dirty_wq);
@@ -246,9 +250,7 @@ static void write_dirty_finish(struct cl
}
 
bch_keybuf_del(>writeback_keys, w);
-   atomic_dec_bug(>in_flight);
-
-   closure_wake_up(>writeback_wait);
+   up(>in_flight);
 
closure_return_with_destructor(cl, dirty_io_destructor);
 }
@@ -278,7 +280,7 @@ static void write_dirty(struct closure *
trace_bcache_write_dirty(>bio);
closure_bio_submit(>bio, cl, >dc->disk);
 
-   continue_at(cl, write_dirty_finish, dirty_wq);
+   continue_at(cl, write_dirty_finish, system_wq);
 }
 
 static void 

[ 09/52] bcache: Fix a shrinker deadlock

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit a698e08c82dfb9771e0bac12c7337c706d729b6d upstream.

GFP_NOIO means we could be getting called recursively - mca_alloc() ->
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/btree.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -633,7 +633,7 @@ static int bch_mca_shrink(struct shrinke
return mca_can_free(c) * c->btree_pages;
 
/* Return -1 if we can't do anything right now */
-   if (sc->gfp_mask & __GFP_WAIT)
+   if (sc->gfp_mask & __GFP_IO)
mutex_lock(>bucket_lock);
else if (!mutex_trylock(>bucket_lock))
return -1;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 43/52] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

[Greg Kroah-Hartman]

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

--

From: Jani Nikula 

commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.

There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.

Signed-off-by: Jani Nikula 
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor 
Reviewed-by: Todd Previte 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/intel_dp.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -604,7 +604,18 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *
DRM_DEBUG_KMS("aux_ch native nack\n");
return -EREMOTEIO;
case AUX_NATIVE_REPLY_DEFER:
-   udelay(100);
+   /*
+* For now, just give more slack to branch devices. We
+* could check the DPCD for I2C bit rate capabilities,
+* and if available, adjust the interval. We could also
+* be more careful with DP-to-Legacy adapters where a
+* long legacy cable may force very low I2C bit rates.
+*/
+   if (intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DWN_STRM_PORT_PRESENT)
+   usleep_range(500, 600);
+   else
+   usleep_range(300, 400);
continue;
default:
DRM_ERROR("aux_ch invalid native reply 0x%02x\n",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 49/52] ARM: mxs: stub out mxs_pm_init for !CONFIG_PM

[Greg Kroah-Hartman]

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

--

From: Arnd Bergmann 

commit 7a9caf59f60e55a8caf96f856713bd0ef0cc25a7 upstream.

When building a kernel without CONFIG_PM, we get a link
error from referencing mxs_pm_init in the machine
descriptor. This defines a macro to NULL for that case.

Signed-off-by: Arnd Bergmann 
Acked-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/mach-mxs/pm.h |4 
 1 file changed, 4 insertions(+)

--- a/arch/arm/mach-mxs/pm.h
+++ b/arch/arm/mach-mxs/pm.h
@@ -9,6 +9,10 @@
 #ifndef __ARCH_MXS_PM_H
 #define __ARCH_MXS_PM_H
 
+#ifdef CONFIG_PM
 void mxs_pm_init(void);
+#else
+#define mxs_pm_init NULL
+#endif
 
 #endif


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 50/52] hwmon: (applesmc) Check key count before proceeding

[Greg Kroah-Hartman]

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

--

From: Henrik Rydberg 

commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.

After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.

Reported-by: 
Suggested-by: Guenter Roeck 
Signed-off-by: Henrik Rydberg 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hwmon/applesmc.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -525,16 +525,25 @@ static int applesmc_init_smcreg_try(void
 {
struct applesmc_registers *s = 
bool left_light_sensor, right_light_sensor;
+   unsigned int count;
u8 tmp[1];
int ret;
 
if (s->init_complete)
return 0;
 
-   ret = read_register_count(>key_count);
+   ret = read_register_count();
if (ret)
return ret;
 
+   if (s->cache && s->key_count != count) {
+   pr_warn("key count changed from %d to %d\n",
+   s->key_count, count);
+   kfree(s->cache);
+   s->cache = NULL;
+   }
+   s->key_count = count;
+
if (!s->cache)
s->cache = kcalloc(s->key_count, sizeof(*s->cache), GFP_KERNEL);
if (!s->cache)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 34/52] usb: dwc3: pci: add support for BayTrail

[Greg Kroah-Hartman]

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

--

From: Heikki Krogerus 

commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

Add PCI id for Intel BayTrail.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -48,6 +48,7 @@
 /* FIXME define these in  */
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
 
 struct dwc3_pci {
struct device   *dev;
@@ -208,6 +209,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{  }/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 51/52] ALSA: compress: Fix compress device unregister.

[Greg Kroah-Hartman]

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

--

From: Liam Girdwood 

commit 4028b6c4c03f213260e9290ff3a6b5439aad07ce upstream.

snd_unregister_device() should return the device type and not stream
direction.

Signed-off-by: Liam Girdwood 
Acked-by: Vinod Koul 
Tested-by: Vinod Koul 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/core/compress_offload.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -837,7 +837,8 @@ static int snd_compress_dev_disconnect(s
struct snd_compr *compr;
 
compr = device->device_data;
-   snd_unregister_device(compr->direction, compr->card, compr->device);
+   snd_unregister_device(SNDRV_DEVICE_TYPE_COMPRESS, compr->card,
+   compr->device);
return 0;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] usb: chipidea: add Intel Clovertrail pci id

[Greg KH]

On Tue, Oct 01, 2013 at 02:32:58PM -0700, David Cohen wrote:
> Signed-off-by: David Cohen 
> ---
>  drivers/usb/chipidea/ci_hdrc_pci.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c 
> b/drivers/usb/chipidea/ci_hdrc_pci.c
> index 08a724b..d514332 100644
> --- a/drivers/usb/chipidea/ci_hdrc_pci.c
> +++ b/drivers/usb/chipidea/ci_hdrc_pci.c
> @@ -129,6 +129,11 @@ static DEFINE_PCI_DEVICE_TABLE(ci_hdrc_pci_id_table) = {
>   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829),
>   .driver_data = (kernel_ulong_t)_pci_platdata,
>   },
> + {
> + /* Intel Clovertrail */
> + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006),
> + .driver_data = (kernel_ulong_t)_pci_platdata,
> + },

Can this go into 3.12-final, and any other stable kernel releases as
well?  Or does this platform also need other fixes that aren't in 3.10
and 3.11?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 36/52] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit

[Greg Kroah-Hartman]

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

--

From: Kurt Garloff 

commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.

Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).

The reason is a USB control message
 usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 
wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.

The kernel thus rejects the IO and thus we see the failure.

Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.

It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to.  The device seems to happily deal with that though (and
seems to not really care about this value much).

So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.

The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)

With attached patch, the app in Windows in KVM works.
 usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but 
needs 81

I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].

[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/

Signed-off-by: Kurt Garloff 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/core/devio.c |   16 
 1 file changed, 16 insertions(+)

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -742,6 +742,22 @@ static int check_ctrlrecip(struct dev_st
if ((index & ~USB_DIR_IN) == 0)
return 0;
ret = findintfep(ps->dev, index);
+   if (ret < 0) {
+   /*
+* Some not fully compliant Win apps seem to get
+* index wrong and have the endpoint number here
+* rather than the endpoint address (with the
+* correct direction). Win does let this through,
+* so we'll not reject it here but leave it to
+* the device to not break KVM. But we warn.
+*/
+   ret = findintfep(ps->dev, index ^ 0x80);
+   if (ret >= 0)
+   dev_info(>dev->dev,
+   "%s: process %i (%s) requesting ep %02x 
but needs %02x\n",
+   __func__, task_pid_nr(current),
+   current->comm, index, index ^ 0x80);
+   }
if (ret >= 0)
ret = checkintf(ps, ret);
break;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check

[Guenter Roeck]

irq_of_parse_and_map() returns 0 on error, not NO_IRQ.

Fix the following xtensa:allmodconfig build error.

sound/soc/fsl/fsl_ssi.c:705:26: error: 'NO_IRQ' undeclared (first use in this 
function)
make[4]: *** [sound/soc/fsl/fsl_ssi.o] Error 1

Cc: Geert Uytterhoeven 
Cc: Grant Likely 
Signed-off-by: Guenter Roeck 
---
Previously submitted by Grant Likely as part of a different patch set.
See https://lkml.org/lkml/2012/1/11/342.
Also see https://lkml.org/lkml/2013/7/25/642.

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

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index c6b7439..6b81d0c 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -936,7 +936,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->ssi_phys = res.start;
 
ssi_private->irq = irq_of_parse_and_map(np, 0);
-   if (ssi_private->irq == NO_IRQ) {
+   if (ssi_private->irq == 0) {
dev_err(>dev, "no irq for node %s\n", np->full_name);
return -ENXIO;
}
-- 
1.7.9.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 41/52] dm-raid: silence compiler warning on rebuilds_per_group.

[Greg Kroah-Hartman]

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

--

From: NeilBrown 

commit 3f6bbd3ffd7b733dd705e494663e5761aa2cb9c1 upstream.

This doesn't really need to be initialised, but it doesn't hurt,
silences the compiler, and as it is a counter it makes sense for it to
start at zero.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-raid.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -380,7 +380,7 @@ static int validate_region_size(struct r
 static int validate_raid_redundancy(struct raid_set *rs)
 {
unsigned i, rebuild_cnt = 0;
-   unsigned rebuilds_per_group, copies, d;
+   unsigned rebuilds_per_group = 0, copies, d;
unsigned group_size, last_group_start;
 
for (i = 0; i < rs->md.raid_disks; i++)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 12/57] kernel/reboot.c: re-enable the function of variable reboot_default

[Greg Kroah-Hartman]

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

--

From: Chuansheng Liu 

commit e2f0b88e84eed9cf9797f0a88c8012ee0b885a6d upstream.

Commit 1b3a5d02ee07 ("reboot: move arch/x86 reboot= handling to generic
kernel") did some cleanup for reboot= command line, but it made the
reboot_default inoperative.

The default value of variable reboot_default should be 1, and if command
line reboot= is not set, system will use the default reboot mode.

[a...@linux-foundation.org: fix comment layout]
Signed-off-by: Li Fei 
Signed-off-by: liu chuansheng 
Acked-by: Robin Holt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/reboot.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -32,7 +32,14 @@ EXPORT_SYMBOL(cad_pid);
 #endif
 enum reboot_mode reboot_mode DEFAULT_REBOOT_MODE;
 
-int reboot_default;
+/*
+ * This variable is used privately to keep track of whether or not
+ * reboot_type is still set to its default value (i.e., reboot= hasn't
+ * been set on the command line).  This is needed so that we can
+ * suppress DMI scanning for reboot quirks.  Without it, it's
+ * impossible to override a faulty reboot quirk without recompiling.
+ */
+int reboot_default = 1;
 int reboot_cpu;
 enum reboot_type reboot_type = BOOT_ACPI;
 int reboot_force;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 27/57] Revert "cw1200: Dont perform SPI transfers in interrupt context"

[Greg Kroah-Hartman]

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

--

From: Solomon Peachy 

commit c4fb19d21b003ec99ec490ba2cb60baffabc73f3 upstream.

This reverts commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35.

This solution turned out to cause interrupt delivery problems, and
rather than trying to fix this approach, it has been scrapped in favor
of an alternative (and far simpler) implementation.

Signed-off-by: Solomon Peachy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/cw1200/cw1200_spi.c |   19 +++
 drivers/net/wireless/cw1200/fwio.c   |2 +-
 drivers/net/wireless/cw1200/hwbus.h  |1 -
 drivers/net/wireless/cw1200/hwio.c   |   15 ---
 4 files changed, 4 insertions(+), 33 deletions(-)

--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -42,7 +42,6 @@ struct hwbus_priv {
spinlock_t  lock; /* Serialize all bus operations */
wait_queue_head_t   wq;
int claimed;
-   int irq_disabled;
 };
 
 #define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -238,8 +237,6 @@ static irqreturn_t cw1200_spi_irq_handle
struct hwbus_priv *self = dev_id;
 
if (self->core) {
-   disable_irq_nosync(self->func->irq);
-   self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -273,22 +270,13 @@ exit:
 
 static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
 {
+   int ret = 0;
+
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
 
-   return 0;
-}
-
-static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
-{
-   /* Disables are handled by the interrupt handler */
-   if (enable && self->irq_disabled) {
-   enable_irq(self->func->irq);
-   self->irq_disabled = 0;
-   }
-
-   return 0;
+   return ret;
 }
 
 static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -368,7 +356,6 @@ static struct hwbus_ops cw1200_spi_hwbus
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
-   .irq_enable = cw1200_spi_irq_enable,
 };
 
 /* Probe Function to be called by SPI stack when device is discovered */
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_c
 
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
-   ret = __cw1200_irq_enable(priv, 2);
+   ret = __cw1200_irq_enable(priv, 1);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,7 +28,6 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
-   int (*irq_enable)(struct hwbus_priv *self, int enable);
 };
 
 #endif /* CW1200_HWBUS_H */
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,21 +273,6 @@ int __cw1200_irq_enable(struct cw1200_co
u16 val16;
int ret;
 
-   /* We need to do this hack because the SPI layer can sleep on I/O
-  and the general path involves I/O to the device in interrupt
-  context.
-
-  However, the initial enable call needs to go to the hardware.
-
-  We don't worry about shutdown because we do a full reset which
-  clears the interrupt enabled bits.
-   */
-   if (priv->hwbus_ops->irq_enable) {
-   ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
-   if (ret || enable < 2)
-   return ret;
-   }
-
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, );
if (ret < 0) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 22/57] serial: pch_uart: fix tty-kref leak in dma-rx path

[Greg Kroah-Hartman]

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

--

From: Johan Hovold 

commit 19b85cfb190eb9980eaf416bff96aef4159a430e upstream.

Fix tty_kref leak when tty_buffer_request room fails in dma-rx path.

Note that the tty ref isn't really needed anymore, but as the leak has
always been there, fixing it before removing should makes it easier to
backport the fix.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/pch_uart.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -658,11 +658,12 @@ static int dma_push_rx(struct eg20t_port
dev_warn(port->dev, "Rx overrun: dropping %u bytes\n",
 size - room);
if (!room)
-   return room;
+   goto out;
 
tty_insert_flip_string(tport, sg_virt(>sg_rx), size);
 
port->icount.rx += room;
+out:
tty_kref_put(tty);
 
return room;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 19/57] tty: Fix SIGTTOU not sent with tcflush()

[Greg Kroah-Hartman]

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

--

From: Peter Hurley 

commit 5cec7bf699c61d14f0538345076480bb8c8ebfbb upstream.

Commit 'e7f3880cd9b98c5bf9391ae7acdec82b75403776'
  tty: Fix recursive deadlock in tty_perform_flush()
introduced a regression where tcflush() does not generate
SIGTTOU for background process groups.

Make sure ioctl(TCFLSH) calls tty_check_change() when
invoked from the line discipline.

Reported-by: Oleg Nesterov 
Signed-off-by: Peter Hurley 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/tty_ioctl.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1201,6 +1201,9 @@ int n_tty_ioctl_helper(struct tty_struct
}
return 0;
case TCFLSH:
+   retval = tty_check_change(tty);
+   if (retval)
+   return retval;
return __tty_perform_flush(tty, arg);
default:
/* Try the mode commands */


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 41/57] dm snapshot: workaround for a false positive lockdep warning

[Greg Kroah-Hartman]

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

--

From: Mikulas Patocka 

commit 5ea330a75bd86b2b2a01d7b85c516983238306fb upstream.

The kernel reports a lockdep warning if a snapshot is invalidated because
it runs out of space.

The lockdep warning was triggered by commit 0976dfc1d0cd80a4e9dfaf87bd87
("workqueue: Catch more locking problems with flush_work()") in v3.5.

The warning is false positive.  The real cause for the warning is that
the lockdep engine treats different instances of md->lock as a single
lock.

This patch is a workaround - we use flush_workqueue instead of flush_work.
This code path is not performance sensitive (it is called only on
initialization or invalidation), thus it doesn't matter that we flush the
whole workqueue.

The real fix for the problem would be to teach the lockdep engine to treat
different instances of md->lock as separate locks.

Signed-off-by: Mikulas Patocka 
Acked-by: Alasdair G Kergon 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-snap-persistent.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/dm-snap-persistent.c
+++ b/drivers/md/dm-snap-persistent.c
@@ -256,7 +256,7 @@ static int chunk_io(struct pstore *ps, v
 */
INIT_WORK_ONSTACK(, do_metadata);
queue_work(ps->metadata_wq, );
-   flush_work();
+   flush_workqueue(ps->metadata_wq);
 
return req.result;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 35/57] USB: Fix breakage in ffs_fs_mount()

[Greg Kroah-Hartman]

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

--

From: Al Viro 

commit 2606b28aabd7dea1766c23a105e1124c95409c96 upstream.

There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics.  Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been.  ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().

Current behaviour of ffs_fs_mount():

We have struct ffs_sb_fill_data data on stack there.  We do
ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data.  Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback.  That will either fail
outright, or manage to call ffs_sb_fill().  There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data).  Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there).  Any of those might fail.  Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns.  If mount_nodev() fails for any reason whatsoever,
we proceed to
functionfs_release_dev_callback(data.ffs_data);

That's broken in a lot of ways.  Suppose the thing has failed in
allocation of e.g. root inode or dentry.  We have
functionfs_release_dev_callback(ffs);
ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data).  Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.

Suppose we fail *before* root inode allocation.  What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info).  And
functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into.  In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.

FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.

The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data.  And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().

Signed-off-by: Al Viro 
Acked-by: Michal Nazarewicz 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/f_fs.c |   60 +++---
 1 file changed, 26 insertions(+), 34 deletions(-)

--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -1034,37 +1034,19 @@ struct ffs_sb_fill_data {
struct ffs_file_perms perms;
umode_t root_mode;
const char *dev_name;
-   union {
-   /* set by ffs_fs_mount(), read by ffs_sb_fill() */
-   void *private_data;
-   /* set by ffs_sb_fill(), read by ffs_fs_mount */
-   struct ffs_data *ffs_data;
-   };
+   struct ffs_data *ffs_data;
 };
 
 static int ffs_sb_fill(struct super_block *sb, void *_data, int silent)
 {
struct ffs_sb_fill_data *data = _data;
struct inode*inode;
-   struct ffs_data *ffs;
+   struct ffs_data *ffs = data->ffs_data;
 
ENTER();
 
-   /* Initialise data */
-   ffs = ffs_data_new();
-   if (unlikely(!ffs))
-   goto Enomem;
-
ffs->sb  = sb;
-   ffs->dev_name= kstrdup(data->dev_name, GFP_KERNEL);
-   if (unlikely(!ffs->dev_name))
-   goto Enomem;
-   ffs->file_perms  = data->perms;
-   ffs->private_data= data->private_data;
-
-   /* used by the caller of this function */
-   data->ffs_data   = ffs;
-
+   data->ffs_data   = NULL;
sb->s_fs_info= ffs;
sb->s_blocksize  = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
@@ -1080,17 +1062,14 @@ 

[ 29/57] xhci: Ensure a command structure points to the correct trb on the command ring

[Greg Kroah-Hartman]

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

--

From: Mathias Nyman 

commit ec7e43e2d98173483866fe2e4e690143626b659c upstream.

If a command on the command ring needs to be cancelled before it is handled
it can be turned to a no-op operation when the ring is stopped.
We want to store the command ring enqueue pointer in the command structure
when the command in enqueued for the cancellation case.

Some commands used to store the command ring dequeue pointers instead of enqueue
(these often worked because enqueue happends to equal dequeue quite often)

Other commands correctly used the enqueue pointer but did not check if it 
pointed
to a valid trb or a link trb, this caused for example stop endpoint command to 
timeout in
xhci_stop_device() in about 2% of suspend/resume cases.

This should also solve some weird behavior happening in command cancellation 
cases.

This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
then forgotten:
http://marc.info/?l=linux-usb=136269803207465=2

This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"

Signed-off-by: Mathias Nyman 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-hub.c  |2 +-
 drivers/usb/host/xhci-ring.c |   10 ++
 drivers/usb/host/xhci.c  |   25 +
 drivers/usb/host/xhci.h  |1 +
 4 files changed, 17 insertions(+), 21 deletions(-)

--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -286,7 +286,7 @@ static int xhci_stop_device(struct xhci_
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
xhci_queue_stop_endpoint(xhci, slot_id, i, suspend);
}
-   cmd->command_trb = xhci->cmd_ring->enqueue;
+   cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(>cmd_list, _dev->cmd_list);
xhci_queue_stop_endpoint(xhci, slot_id, 0, suspend);
xhci_ring_cmd_db(xhci);
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -122,6 +122,16 @@ static int enqueue_is_link_trb(struct xh
return TRB_TYPE_LINK_LE32(link->control);
 }
 
+union xhci_trb *xhci_find_next_enqueue(struct xhci_ring *ring)
+{
+   /* Enqueue pointer can be left pointing to the link TRB,
+* we must handle that
+*/
+   if (TRB_TYPE_LINK_LE32(ring->enqueue->link.control))
+   return ring->enq_seg->next->trbs;
+   return ring->enqueue;
+}
+
 /* Updates trb to point to the next TRB in the ring, and updates seg if the 
next
  * TRB is in a new segment.  This does not skip over link TRBs, and it does not
  * effect the ring dequeue or enqueue pointers.
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2635,15 +2635,7 @@ static int xhci_configure_endpoint(struc
if (command) {
cmd_completion = command->completion;
cmd_status = >status;
-   command->command_trb = xhci->cmd_ring->enqueue;
-
-   /* Enqueue pointer can be left pointing to the link TRB,
-* we must handle that
-*/
-   if (TRB_TYPE_LINK_LE32(command->command_trb->link.control))
-   command->command_trb =
-   xhci->cmd_ring->enq_seg->next->trbs;
-
+   command->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
list_add_tail(>cmd_list, _dev->cmd_list);
} else {
cmd_completion = _dev->cmd_completion;
@@ -2651,7 +2643,7 @@ static int xhci_configure_endpoint(struc
}
init_completion(cmd_completion);
 
-   cmd_trb = xhci->cmd_ring->dequeue;
+   cmd_trb = xhci_find_next_enqueue(xhci->cmd_ring);
if (!ctx_change)
ret = xhci_queue_configure_endpoint(xhci, in_ctx->dma,
udev->slot_id, must_succeed);
@@ -3468,14 +3460,7 @@ int xhci_discover_or_reset_device(struct
 
/* Attempt to submit the Reset Device command to the command ring */
spin_lock_irqsave(>lock, flags);
-   reset_device_cmd->command_trb = xhci->cmd_ring->enqueue;
-
-   /* Enqueue pointer can be left pointing to the link TRB,
-* we must handle that
-*/
-   if (TRB_TYPE_LINK_LE32(reset_device_cmd->command_trb->link.control))
-   reset_device_cmd->command_trb =
-   xhci->cmd_ring->enq_seg->next->trbs;
+   reset_device_cmd->command_trb = xhci_find_next_enqueue(xhci->cmd_ring);
 
list_add_tail(_device_cmd->cmd_list, _dev->cmd_list);
ret = xhci_queue_reset_device(xhci, slot_id);
@@ -3679,7 +3664,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd,
union xhci_trb *cmd_trb;
 
spin_lock_irqsave(>lock, flags);
-   cmd_trb = xhci->cmd_ring->dequeue;
+   

[ 30/57] xhci: Fix oops happening after address device timeout

[Greg Kroah-Hartman]

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

--

From: Mathias Nyman 

commit 284d20552461466b04d6bfeafeb1c47a8891b591 upstream.

When a command times out, the command ring is first aborted,
and then stopped. If the command ring is empty when it is stopped
the stop event will point to next command which is not yet set.
xHCI tries to handle this next event often causing an oops.

Don't handle command completion events on stopped cmd ring if ring is
empty.

This patch should be backported to kernels as old as 3.7, that contain
the commit b92cc66c047ff7cf587b318fe377061a353c120f "xHCI: add aborting
command ring function"

Signed-off-by: Mathias Nyman 
Reported-by: Giovanni 
Signed-off-by: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-ring.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1400,6 +1400,12 @@ static void handle_cmd_completion(struct
inc_deq(xhci, xhci->cmd_ring);
return;
}
+   /* There is no command to handle if we get a stop event when the
+* command ring is empty, event->cmd_trb points to the next
+* unset command
+*/
+   if (xhci->cmd_ring->dequeue == xhci->cmd_ring->enqueue)
+   return;
}
 
switch (le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3])


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 34/57] USB: UHCI: accept very late isochronous URBs

[Greg Kroah-Hartman]

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

--

From: Alan Stern 

commit bef073b067a7b1874a6b381e0035bb0516d71a77 upstream.

Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd.  URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright.  Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet.  This is what client drivers expect.

This patch implements the same policy in uhci-hcd.  It should be
applied to all kernels containing commit c44b225077bb (UHCI: implement
new semantics for URB_ISO_ASAP).

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/uhci-q.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

--- a/drivers/usb/host/uhci-q.c
+++ b/drivers/usb/host/uhci-q.c
@@ -1303,7 +1303,7 @@ static int uhci_submit_isochronous(struc
}
 
/* Fell behind? */
-   if (uhci_frame_before_eq(frame, next)) {
+   if (!uhci_frame_before_eq(next, frame)) {
 
/* USB_ISO_ASAP: Round up to the first available slot */
if (urb->transfer_flags & URB_ISO_ASAP)
@@ -1311,13 +1311,17 @@ static int uhci_submit_isochronous(struc
-qh->period;
 
/*
-* Not ASAP: Use the next slot in the stream.  If
-* the entire URB falls before the threshold, fail.
+* Not ASAP: Use the next slot in the stream,
+* no matter what.
 */
else if (!uhci_frame_before_eq(next,
frame + (urb->number_of_packets - 1) *
qh->period))
-   return -EXDEV;
+   dev_dbg(uhci_dev(uhci), "iso underrun %p (%u+%u 
< %u)\n",
+   urb, frame,
+   (urb->number_of_packets - 1) *
+   qh->period,
+   next);
}
}
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 31/57] USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

[Greg Kroah-Hartman]

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

--

From: Alan Stern 

commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream.

Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm
field in their pci_driver structures should be protected by CONFIG_PM
rather than CONFIG_PM_SLEEP.  The corresponding change has already
been made for ohci-hcd.

Without this change, controllers won't do runtime suspend if system
suspend or hibernation isn't enabled.

Signed-off-by: Alan Stern 
CC: Sarah Sharp 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/ehci-pci.c |2 +-
 drivers/usb/host/uhci-pci.c |2 +-
 drivers/usb/host/xhci-pci.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -403,7 +403,7 @@ static struct pci_driver ehci_pci_driver
.remove =   usb_hcd_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver =   {
.pm =   _hcd_pci_pm_ops
},
--- a/drivers/usb/host/uhci-pci.c
+++ b/drivers/usb/host/uhci-pci.c
@@ -293,7 +293,7 @@ static struct pci_driver uhci_pci_driver
.remove =   usb_hcd_pci_remove,
.shutdown = uhci_shutdown,
 
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver =   {
.pm =   _hcd_pci_pm_ops
},
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -345,7 +345,7 @@ static struct pci_driver xhci_pci_driver
/* suspend and resume implemented later */
 
.shutdown = usb_hcd_pci_shutdown,
-#ifdef CONFIG_PM_SLEEP
+#ifdef CONFIG_PM
.driver = {
.pm = _hcd_pci_pm_ops
},


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 02/57] sysv: Add forgotten superblock lock init for v7 fs

[Greg Kroah-Hartman]

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

--

From: Lubomir Rintel 

commit 4947848d396a0c78fb2f8ecceb3f3f263ef1 upstream.

Superblock lock was replaced with (un)lock_super() removal, but left
uninitialized for Seventh Edition UNIX filesystem in the following commit (3.7):
c07cb01 sysv: drop lock/unlock super

Signed-off-by: Lubomir Rintel 
Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/sysv/super.c |1 +
 1 file changed, 1 insertion(+)

--- a/fs/sysv/super.c
+++ b/fs/sysv/super.c
@@ -487,6 +487,7 @@ static int v7_fill_super(struct super_bl
sbi->s_sb = sb;
sbi->s_block_base = 0;
sbi->s_type = FSTYPE_V7;
+   mutex_init(>s_lock);
sb->s_fs_info = sbi;

sb_set_blocksize(sb, 512);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 33/57] USB: OHCI: accept very late isochronous URBs

[Greg Kroah-Hartman]

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

--

From: Alan Stern 

commit a8693424c751b8247ee19bd8b857f1d4f432b972 upstream.

Commit 24f531371de1 (USB: EHCI: accept very late isochronous URBs)
changed the isochronous API provided by ehci-hcd.  URBs submitted too
late, so that the time slots for all their packets have already
expired, are no longer rejected outright.  Instead the submission is
accepted, and the URB completes normally with a -EXDEV error for each
packet.  This is what client drivers expect.

This patch implements the same policy in ohci-hcd.  The change is more
complicated than it was in ehci-hcd, because ohci-hcd doesn't scan for
isochronous completions in the same way as ehci-hcd does.  Rather, it
depends on the hardware adding completed TDs to a "done queue".  Some
OHCI controller don't handle this properly when a TD's time slot has
already expired, so we have to avoid adding such TDs to the schedule
in the first place.  As a result, if the URB was submitted too late
then none of its TDs will get put on the schedule, so none of them
will end up on the done queue, so the driver will never realize that
the URB should be completed.

To solve this problem, the patch adds one to urb_priv->td_cnt for such
URBs, making it larger than urb_priv->length (td_cnt already gets set
to the number of TD's that had to be skipped because their slots have
expired).  Each time an URB is given back, the finish_urb() routine
looks to see if urb_priv->td_cnt for the next URB on the same endpoint
is marked in this way.  If so, it gives back the next URB right away.

This should be applied to all kernels containing commit 815fa7b91761
(USB: OHCI: fix logic for scheduling isochronous URBs).

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/ohci-hcd.c |   22 --
 drivers/usb/host/ohci-q.c   |   26 ++
 2 files changed, 34 insertions(+), 14 deletions(-)

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -216,31 +216,26 @@ static int ohci_urb_enqueue (
frame &= ~(ed->interval - 1);
frame |= ed->branch;
urb->start_frame = frame;
+   ed->last_iso = frame + ed->interval * (size - 1);
}
} else if (ed->type == PIPE_ISOCHRONOUS) {
u16 next = ohci_frame_no(ohci) + 1;
u16 frame = ed->last_iso + ed->interval;
+   u16 length = ed->interval * (size - 1);
 
/* Behind the scheduling threshold? */
if (unlikely(tick_before(frame, next))) {
 
-   /* USB_ISO_ASAP: Round up to the first available slot */
+   /* URB_ISO_ASAP: Round up to the first available slot */
if (urb->transfer_flags & URB_ISO_ASAP) {
frame += (next - frame + ed->interval - 1) &
-ed->interval;
 
/*
-* Not ASAP: Use the next slot in the stream.  If
-* the entire URB falls before the threshold, fail.
+* Not ASAP: Use the next slot in the stream,
+* no matter what.
 */
} else {
-   if (tick_before(frame + ed->interval *
-   (urb->number_of_packets - 1), next)) {
-   retval = -EXDEV;
-   usb_hcd_unlink_urb_from_ep(hcd, urb);
-   goto fail;
-   }
-
/*
 * Some OHCI hardware doesn't handle late TDs
 * correctly.  After retiring them it proceeds
@@ -251,9 +246,16 @@ static int ohci_urb_enqueue (
urb_priv->td_cnt = DIV_ROUND_UP(
(u16) (next - frame),
ed->interval);
+   if (urb_priv->td_cnt >= urb_priv->length) {
+   ++urb_priv->td_cnt; /* Mark it */
+   ohci_dbg(ohci, "iso underrun %p (%u+%u 
< %u)\n",
+   urb, frame, length,
+   next);
+   }
}
}
urb->start_frame = frame;
+   ed->last_iso = frame + length;
}
 
/* fill the TDs and link them to the ed; and
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -41,9 +41,13 @@ finish_urb(struct ohci_hcd *ohci, struct
 

[ 06/57] bcache: Fix a writeback performance regression

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit c2a4f3183a1248f615a695fbd8905da55ad11bba upstream.

Background writeback works by scanning the btree for dirty data and
adding those keys into a fixed size buffer, then for each dirty key in
the keybuf writing it to the backing device.

When read_dirty() finishes and it's time to scan for more dirty data, we
need to wait for the outstanding writeback IO to finish - they still
take up slots in the keybuf (so that foreground writes can check for
them to avoid races) - without that wait, we'll continually rescan when
we'll be able to add at most a key or two to the keybuf, and that takes
locks that starves foreground IO.  Doh.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/bcache.h|7 ++
 drivers/md/bcache/util.c  |   11 +-
 drivers/md/bcache/util.h  |   12 ---
 drivers/md/bcache/writeback.c |   43 --
 4 files changed, 43 insertions(+), 30 deletions(-)

--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -498,7 +498,7 @@ struct cached_dev {
 */
atomic_thas_dirty;
 
-   struct ratelimitwriteback_rate;
+   struct bch_ratelimitwriteback_rate;
struct delayed_work writeback_rate_update;
 
/*
@@ -507,10 +507,9 @@ struct cached_dev {
 */
sector_tlast_read;
 
-   /* Number of writeback bios in flight */
-   atomic_tin_flight;
+   /* Limit number of writeback bios in flight */
+   struct semaphorein_flight;
struct closure_with_timer writeback;
-   struct closure_waitlist writeback_wait;
 
struct keybuf   writeback_keys;
 
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -190,7 +190,16 @@ void bch_time_stats_update(struct time_s
stats->last = now ?: 1;
 }
 
-unsigned bch_next_delay(struct ratelimit *d, uint64_t done)
+/**
+ * bch_next_delay() - increment @d by the amount of work done, and return how
+ * long to delay until the next time to do some work.
+ *
+ * @d - the struct bch_ratelimit to update
+ * @done - the amount of work done, in arbitrary units
+ *
+ * Returns the amount of time to delay by, in jiffies
+ */
+uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done)
 {
uint64_t now = local_clock();
 
--- a/drivers/md/bcache/util.h
+++ b/drivers/md/bcache/util.h
@@ -450,17 +450,23 @@ read_attribute(name ## _last_ ## frequen
(ewma) >> factor;   \
 })
 
-struct ratelimit {
+struct bch_ratelimit {
+   /* Next time we want to do some work, in nanoseconds */
uint64_tnext;
+
+   /*
+* Rate at which we want to do work, in units per nanosecond
+* The units here correspond to the units passed to bch_next_delay()
+*/
unsignedrate;
 };
 
-static inline void ratelimit_reset(struct ratelimit *d)
+static inline void bch_ratelimit_reset(struct bch_ratelimit *d)
 {
d->next = local_clock();
 }
 
-unsigned bch_next_delay(struct ratelimit *d, uint64_t done);
+uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done);
 
 #define __DIV_SAFE(n, d, zero) \
 ({ \
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -94,11 +94,15 @@ static void update_writeback_rate(struct
 
 static unsigned writeback_delay(struct cached_dev *dc, unsigned sectors)
 {
+   uint64_t ret;
+
if (atomic_read(>disk.detaching) ||
!dc->writeback_percent)
return 0;
 
-   return bch_next_delay(>writeback_rate, sectors * 1000ULL);
+   ret = bch_next_delay(>writeback_rate, sectors * 1000ULL);
+
+   return min_t(uint64_t, ret, HZ);
 }
 
 /* Background writeback */
@@ -208,7 +212,7 @@ normal_refill:
 
up_write(>writeback_lock);
 
-   ratelimit_reset(>writeback_rate);
+   bch_ratelimit_reset(>writeback_rate);
 
/* Punt to workqueue only so we don't recurse and blow the stack */
continue_at(cl, read_dirty, dirty_wq);
@@ -318,9 +322,7 @@ static void write_dirty_finish(struct cl
}
 
bch_keybuf_del(>writeback_keys, w);
-   atomic_dec_bug(>in_flight);
-
-   closure_wake_up(>writeback_wait);
+   up(>in_flight);
 
closure_return_with_destructor(cl, dirty_io_destructor);
 }
@@ -349,7 +351,7 @@ static void write_dirty(struct closure *
 
closure_bio_submit(>bio, cl, >dc->disk);
 
-   continue_at(cl, write_dirty_finish, dirty_wq);
+   continue_at(cl, write_dirty_finish, system_wq);
 }
 
 static void read_dirty_endio(struct bio *bio, int error)
@@ -369,7 +371,7 @@ 

[ 04/57] bcache: Strip endline when writing the label through sysfs

[Greg Kroah-Hartman]

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

--

From: Gabriel de Perthuis 

commit aee6f1cfff3ce240eb4b43b41ca466b907acbd2e upstream.

sysfs attributes with unusual characters have crappy failure modes
in Squeeze (udev 164); later versions of udev are unaffected.

This should make these characters more unusual.

Signed-off-by: Gabriel de Perthuis 
Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/sysfs.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -223,8 +223,13 @@ STORE(__cached_dev)
}
 
if (attr == _label) {
-   /* note: endlines are preserved */
-   memcpy(dc->sb.label, buf, SB_LABEL_SIZE);
+   if (size > SB_LABEL_SIZE)
+   return -EINVAL;
+   memcpy(dc->sb.label, buf, size);
+   if (size < SB_LABEL_SIZE)
+   dc->sb.label[size] = '\0';
+   if (size && dc->sb.label[size - 1] == '\n')
+   dc->sb.label[size - 1] = '\0';
bch_write_bdev_super(dc, NULL);
if (dc->disk.c) {
memcpy(dc->disk.c->uuids[dc->disk.id].label,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 42/57] dm-snapshot: fix performance degradation due to small hash size

[Greg Kroah-Hartman]

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

--

From: Mikulas Patocka 

commit 60e356f381954d79088d0455e357db48cfdd6857 upstream.

LVM2, since version 2.02.96, creates origin with zero size, then loads
the snapshot driver and then loads the origin.  Consequently, the
snapshot driver sees the origin size zero and sets the hash size to the
lower bound 64.  Such small hash table causes performance degradation.

This patch changes it so that the hash size is determined by the size of
snapshot volume, not minimum of origin and snapshot size.  It doesn't
make sense to set the snapshot size significantly larger than the origin
size, so we do not need to take origin size into account when
calculating the hash size.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-snap.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -725,17 +725,16 @@ static int calc_max_buckets(void)
  */
 static int init_hash_tables(struct dm_snapshot *s)
 {
-   sector_t hash_size, cow_dev_size, origin_dev_size, max_buckets;
+   sector_t hash_size, cow_dev_size, max_buckets;
 
/*
 * Calculate based on the size of the original volume or
 * the COW volume...
 */
cow_dev_size = get_dev_size(s->cow->bdev);
-   origin_dev_size = get_dev_size(s->origin->bdev);
max_buckets = calc_max_buckets();
 
-   hash_size = min(origin_dev_size, cow_dev_size) >> s->store->chunk_shift;
+   hash_size = cow_dev_size >> s->store->chunk_shift;
hash_size = min(hash_size, max_buckets);
 
if (hash_size < 64)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 07/57] bcache: Fix a flush/fua performance bug

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit 1394d6761b6e9e15ee7c632a6d48791188727b40 upstream.

bch_journal_meta() was missing the flush to make the journal write
actually go down (instead of waiting up to journal_delay_ms)...

Whoops

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/journal.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -695,6 +695,7 @@ void bch_journal_meta(struct cache_set *
if (cl)
BUG_ON(!closure_wait(>wait, cl));
 
+   closure_flush(>journal.io);
__journal_try_write(c, true);
}
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpufreq: highbank-cpufreq: Enable Midway/ECX-2000

[Viresh Kumar]

On Tue, Oct 1, 2013 at 9:00 PM, Mark Langsdorf
 wrote:
> Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank,
> so add it to the driver's compatibility list.
>
> This is a minor change that can safely be applied to the 3.10 and 3.11
> stable trees.
>
> Signed-off-by: Mark Langsdorf 
> ---
>  drivers/cpufreq/highbank-cpufreq.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/highbank-cpufreq.c 
> b/drivers/cpufreq/highbank-cpufreq.c
> index 794123f..bf8902a 100644
> --- a/drivers/cpufreq/highbank-cpufreq.c
> +++ b/drivers/cpufreq/highbank-cpufreq.c
> @@ -66,7 +66,8 @@ static int hb_cpufreq_driver_init(void)
> struct device_node *np;
> int ret;
>
> -   if (!of_machine_is_compatible("calxeda,highbank"))
> +   if ((!of_machine_is_compatible("calxeda,highbank")) &&
> +   (!of_machine_is_compatible("calxeda,ecx-2000")))
> return -ENODEV;
>
> cpu_dev = get_cpu_device(0);

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [QUERY] Why does perf-trace need me to be root?

[Ramkumar Ramachandra]

David Ahern wrote:
> If you trust your users make the debugfs mount point rx by group,world.

Thanks David. I can preserve this configuration across reboots by
putting an entry in fstab, right? How do I preserve the value of
/proc/sys/kernel/perf_event_paranoid across reboots?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/13] tpm: Pull everything related to /dev/tpmX into tpm-dev.c

[Jason Gunthorpe]

On Wed, Oct 02, 2013 at 01:14:18AM +0200, Peter H?we wrote:

> > I botched the makefile changes for the new .c files.
> > 
> > I believe it should be like this:
> > 
> > obj-$(CONFIG_TCG_TPM) += tpm-core.o
> > tpm-core-y := tpm.o tpm-dev.o tpm-sysfs.o
> > 
> > > I added a suitable patch with the appropriate EXPORT_SYMBOL_GPL
> > > declarations to my testing branch. (also see next message)
> > 
> > EXPORT_SYMBOL_GPL is not correct, these are in-module references, not
> > cross module references, and I've deliberately not exported them to
> > prevent drivers from trying to use them inappropriately.

> Of course you're right - I just wanted to get it compile as fast as
> possible ;)

It looks like my solution changes the tpm module name to tpm-core.o.
This should be noted in the commit log:

 In doing so we also change the core tpm module name from 'tpm' to 'tpm-core',
 this is because kbuild does not like it if a multi-file module has a .c
 file of the same name.

Is that OK? It follows the pattern other systems have in the kernel.

If this is not OK, then I think we have to rename tpm.c to tpm-XX.c to
make the build system work.

I've consolidated all the remarks and changes thus far on my github:
 https://github.com/jgunthorpe/linux/commits/tpm-devel
 ec94ce9d29298ba75cec83a136fd841f8da9d528

(plus 1 more untested patch to remove the tpm-bios module)

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm: Select NOP_USB_XCEIV if MACH_OMAP3EVM is enabled

[Guenter Roeck]

arm builds have been failing on and off with

arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to
`usb_nop_xceiv_register'

for several years. Current arm:allmodconfig build fails for this reason.

Problem is that board-omap3evm.c is always build into the kernel.
It calls usb_nop_xceiv_register(), which is built with NOP_USB_XCEIV,
which in turn can be configured as module. This results in the observed
build failure.

Fix the problem once and for all by selecting NOP_USB_XCEIV if MACH_OMAP3EVM
is enabled.

Signed-off-by: Guenter Roeck 
---
 arch/arm/mach-omap2/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b5fb5f7..0bc2cf4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -265,6 +265,7 @@ config MACH_OMAP3EVM
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
+   select NOP_USB_XCEIV
 
 config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
-- 
1.7.9.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] ARM: SoC fixes for 3.12-rc

[Brian Norris]

(Trimming CC list)

Hi David,

On Thu, Sep 19, 2013 at 4:19 PM, Woodhouse, David
 wrote:
> On Thu, 2013-09-19 at 15:57 -0700, Brian Norris wrote:
>> Speaking of such process issues: there's an outstanding patch for a
>> (small) memory leak that was introduced in the nand_base.c ONFI code
>> in 3.12-rc1. Can I expect you to attend to these sort of -rcX (where X
>> > 1) issues? Or should I send Linus the patch myself? I don't really
>> want it to wait around until 3.13-rc1 to go to -stable.
>
> I'm aware of it, and will get to it shortly. Was going to round it up
> along with the one that Olof just sent, either some time this week at
> Plumbers or when I get home.

I see that you have queued up some 3.12-rc patches in linux-mtd.git.
This is a reminder to send a pull request...

> If you want to stick it in the linux-mtd.git tree before that and send
> Linus a pull request, I have no objection.

...or else I will just send them myself within a week.

Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 09/57] bcache: Fix a shrinker deadlock

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit a698e08c82dfb9771e0bac12c7337c706d729b6d upstream.

GFP_NOIO means we could be getting called recursively - mca_alloc() ->
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/btree.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -617,7 +617,7 @@ static int bch_mca_shrink(struct shrinke
return mca_can_free(c) * c->btree_pages;
 
/* Return -1 if we can't do anything right now */
-   if (sc->gfp_mask & __GFP_WAIT)
+   if (sc->gfp_mask & __GFP_IO)
mutex_lock(>bucket_lock);
else if (!mutex_trylock(>bucket_lock))
return -1;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] fix unsafe set_memory_rw from softirq

[Eric Dumazet]

On Wed, 2013-10-02 at 21:53 -0700, Eric Dumazet wrote:
> On Wed, 2013-10-02 at 21:44 -0700, Alexei Starovoitov wrote:
> 
> > I think ifdef config_x86 is a bit ugly inside struct sk_filter, but
> > don't mind whichever way.
> 
> Its not fair to make sk_filter bigger, because it means that simple (non
> JIT) filter might need an extra cache line.
> 
> You could presumably use the following layout instead :
> 
> struct sk_filter
> {
> atomic_trefcnt;
> struct rcu_head rcu;
>   struct work_struct  work;
> 
> unsigned intlen cacheline_aligned;/* Number of 
> filter blocks */
> unsigned int(*bpf_func)(const struct sk_buff *skb,
> const struct sock_filter *filter);
> struct sock_filter  insns[0];
> };

And since @len is not used by sk_run_filter() use :

struct sk_filter {
atomic_trefcnt;
int len; /* number of filter blocks */
struct rcu_head rcu;
struct work_struct  work;

unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct sock_filter *filter) 
cacheline_aligned;
struct sock_filter  insns[0];
};



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 55/57] hwmon: (applesmc) Check key count before proceeding

[Greg Kroah-Hartman]

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

--

From: Henrik Rydberg 

commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream.

After reports from Chris and Josh Boyer of a rare crash in applesmc,
Guenter pointed at the initialization problem fixed below. The patch
has not been verified to fix the crash, but should be applied
regardless.

Reported-by: 
Suggested-by: Guenter Roeck 
Signed-off-by: Henrik Rydberg 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hwmon/applesmc.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -525,16 +525,25 @@ static int applesmc_init_smcreg_try(void
 {
struct applesmc_registers *s = 
bool left_light_sensor, right_light_sensor;
+   unsigned int count;
u8 tmp[1];
int ret;
 
if (s->init_complete)
return 0;
 
-   ret = read_register_count(>key_count);
+   ret = read_register_count();
if (ret)
return ret;
 
+   if (s->cache && s->key_count != count) {
+   pr_warn("key count changed from %d to %d\n",
+   s->key_count, count);
+   kfree(s->cache);
+   s->cache = NULL;
+   }
+   s->key_count = count;
+
if (!s->cache)
s->cache = kcalloc(s->key_count, sizeof(*s->cache), GFP_KERNEL);
if (!s->cache)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] fix unsafe set_memory_rw from softirq

[Eric Dumazet]

On Wed, 2013-10-02 at 21:44 -0700, Alexei Starovoitov wrote:

> I think ifdef config_x86 is a bit ugly inside struct sk_filter, but
> don't mind whichever way.

Its not fair to make sk_filter bigger, because it means that simple (non
JIT) filter might need an extra cache line.

You could presumably use the following layout instead :

struct sk_filter
{
atomic_trefcnt;
struct rcu_head rcu;
struct work_struct  work;

unsigned intlen cacheline_aligned;/* Number of 
filter blocks */
unsigned int(*bpf_func)(const struct sk_buff *skb,
const struct sock_filter *filter);
struct sock_filter  insns[0];
};



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 57/57] irq: Always define devm_{request_threaded,free}_irq()

[Greg Kroah-Hartman]

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

--

From: Ben Hutchings 

This is only needed for 3.11, as s390 has now been changed to use the
generic IRQ code upstream.

These functions are currently defined only if CONFIG_GENERIC_HARDIRQS
is enabled.  But they are still needed on s390 which has its own IRQ
management.

References: 
https://buildd.debian.org/status/fetch.php?pkg=linux=s390=3.11%7Erc4-1%7Eexp1=1376009959
Signed-off-by: Ben Hutchings 
---
 kernel/Makefile |2 +-
 kernel/irq/Makefile |6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -79,7 +79,7 @@ obj-$(CONFIG_KPROBES) += kprobes.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
 obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
-obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
+obj-y += irq/
 obj-$(CONFIG_SECCOMP) += seccomp.o
 obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
 obj-$(CONFIG_TREE_RCU) += rcutree.o
--- a/kernel/irq/Makefile
+++ b/kernel/irq/Makefile
@@ -1,8 +1,10 @@
-
-obj-y := irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o 
devres.o
+obj-y += devres.o
+ifdef CONFIG_GENERIC_HARDIRQS
+obj-y += irqdesc.o handle.o manage.o spurious.o resend.o chip.o dummychip.o
 obj-$(CONFIG_GENERIC_IRQ_CHIP) += generic-chip.o
 obj-$(CONFIG_GENERIC_IRQ_PROBE) += autoprobe.o
 obj-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
 obj-$(CONFIG_PROC_FS) += proc.o
 obj-$(CONFIG_GENERIC_PENDING_IRQ) += migration.o
 obj-$(CONFIG_PM_SLEEP) += pm.o
+endif


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] fix unsafe set_memory_rw from softirq

[Alexei Starovoitov]

On Wed, Oct 2, 2013 at 9:23 PM, Eric Dumazet  wrote:
> On Wed, 2013-10-02 at 20:50 -0700, Alexei Starovoitov wrote:
>> on x86 system with net.core.bpf_jit_enable = 1
>
>> diff --git a/include/linux/filter.h b/include/linux/filter.h
>> index a6ac848..378fa03 100644
>> --- a/include/linux/filter.h
>> +++ b/include/linux/filter.h
>> @@ -27,6 +27,7 @@ struct sk_filter
>>   unsigned intlen;/* Number of filter blocks */
>>   unsigned int(*bpf_func)(const struct sk_buff *skb,
>>   const struct sock_filter *filter);
>> + struct work_struct  work;
>>   struct rcu_head rcu;
>>   struct sock_filter  insns[0];
>>  };
>
> Nice catch !
>
> It seems only x86 and s390 needs this work_struct.

I think ifdef config_x86 is a bit ugly inside struct sk_filter, but
don't mind whichever way.

> (and you might CC Heiko Carstens  to ask him
> to make the s390 part, of Ack it if you plan to do it)

set_memory_rw() on s390 is a simple page table walker that doesn't do
any IPI unlike x86
Heiko, please confirm that it's not an issue there.

Thanks
Alexei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 45/57] drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

[Greg Kroah-Hartman]

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

--

From: Jani Nikula 

commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.

There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.

Signed-off-by: Jani Nikula 
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor 
Reviewed-by: Todd Previte 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/intel_dp.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -567,7 +567,18 @@ intel_dp_i2c_aux_ch(struct i2c_adapter *
DRM_DEBUG_KMS("aux_ch native nack\n");
return -EREMOTEIO;
case AUX_NATIVE_REPLY_DEFER:
-   udelay(100);
+   /*
+* For now, just give more slack to branch devices. We
+* could check the DPCD for I2C bit rate capabilities,
+* and if available, adjust the interval. We could also
+* be more careful with DP-to-Legacy adapters where a
+* long legacy cable may force very low I2C bit rates.
+*/
+   if (intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DWN_STRM_PORT_PRESENT)
+   usleep_range(500, 600);
+   else
+   usleep_range(300, 400);
continue;
default:
DRM_ERROR("aux_ch invalid native reply 0x%02x\n",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 53/57] drm/radeon: add missing hdmi callbacks for rv6xx

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 upstream.

When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729

Signed-off-by: Alex Deucher 
Reviewed-by: Christian König 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_asic.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -926,6 +926,8 @@ static struct radeon_asic r520_asic = {
.wait_for_vblank = _wait_for_vblank,
.set_backlight_level = _set_backlight_level,
.get_backlight_level = _get_backlight_level,
+   .hdmi_enable = _hdmi_enable,
+   .hdmi_setmode = _hdmi_setmode,
},
.copy = {
.blit = _copy_blit,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 54/57] drm/radeon: fix hdmi audio on DCE3.0/3.1 asics

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a upstream.

These asics seem to use a mix of the DCE2.x and
DCE3.2 audio interfaces despite what the register spec
says.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
https://bugs.freedesktop.org/show_bug.cgi?id=69671

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/r600_hdmi.c |   20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -257,10 +257,7 @@ void r600_audio_set_dto(struct drm_encod
 * number (coefficient of two integer numbers.  DCCG_AUDIO_DTOx_PHASE
 * is the numerator, DCCG_AUDIO_DTOx_MODULE is the denominator
 */
-   if (ASIC_IS_DCE3(rdev)) {
-   /* according to the reg specs, this should DCE3.2 only, but in
-* practice it seems to cover DCE3.0 as well.
-*/
+   if (ASIC_IS_DCE32(rdev)) {
if (dig->dig_encoder == 0) {
dto_cntl = RREG32(DCCG_AUDIO_DTO0_CNTL) & 
~DCCG_AUDIO_DTO_WALLCLOCK_RATIO_MASK;
dto_cntl |= 
DCCG_AUDIO_DTO_WALLCLOCK_RATIO(wallclock_ratio);
@@ -276,8 +273,21 @@ void r600_audio_set_dto(struct drm_encod
WREG32(DCCG_AUDIO_DTO1_MODULE, dto_modulo);
WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
}
+   } else if (ASIC_IS_DCE3(rdev)) {
+   /* according to the reg specs, this should DCE3.2 only, but in
+* practice it seems to cover DCE3.0/3.1 as well.
+*/
+   if (dig->dig_encoder == 0) {
+   WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100);
+   WREG32(DCCG_AUDIO_DTO0_MODULE, clock * 100);
+   WREG32(DCCG_AUDIO_DTO_SELECT, 0); /* select DTO0 */
+   } else {
+   WREG32(DCCG_AUDIO_DTO1_PHASE, base_rate * 100);
+   WREG32(DCCG_AUDIO_DTO1_MODULE, clock * 100);
+   WREG32(DCCG_AUDIO_DTO_SELECT, 1); /* select DTO1 */
+   }
} else {
-   /* according to the reg specs, this should be DCE2.0 and DCE3.0 
*/
+   /* according to the reg specs, this should be DCE2.0 and 
DCE3.0/3.1 */
WREG32(AUDIO_DTO, AUDIO_DTO_PHASE(base_rate / 10) |
   AUDIO_DTO_MODULE(clock / 10));
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 19/21] cpuidle: create list of registered drivers

[Viresh Kumar]

On 1 October 2013 00:07, Daniel Lezcano  wrote:
> Interesting, thanks for the pointer.

So, should I keep this patch with SRCU?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 48/57] drm/radeon/cik: fix overflow in vram fetch

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 13c5bfdad758bddc199850c22246ddf26adcec1f upstream.

Missing ULL when calculating the amount of vram
leads to an overflow when the amount of vram is >= 4G.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/cik.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4225,8 +4225,8 @@ static int cik_mc_init(struct radeon_dev
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
-   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
-   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, >mc);
radeon_update_bandwidth_info(rdev);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/11] pinctrl: plgpio: Remove redundant of_match_ptr

[Viresh Kumar]

On 28 September 2013 17:38, Sachin Kamat  wrote:
> The data structure of_match_ptr() protects is always compiled in.

of_match_ptr() isn't a data structure.. And also what does "protects" mean here?

> Hence of_match_ptr() is not needed.
>
> Signed-off-by: Sachin Kamat 
> Cc: Viresh Kumar 
> ---
>  drivers/pinctrl/spear/pinctrl-plgpio.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/spear/pinctrl-plgpio.c 
> b/drivers/pinctrl/spear/pinctrl-plgpio.c
> index 0a7f0bdb..ff2940e 100644
> --- a/drivers/pinctrl/spear/pinctrl-plgpio.c
> +++ b/drivers/pinctrl/spear/pinctrl-plgpio.c
> @@ -735,7 +735,7 @@ static struct platform_driver plgpio_driver = {
> .owner = THIS_MODULE,
> .name = "spear-plgpio",
> .pm = _dev_pm_ops,
> -   .of_match_table = of_match_ptr(plgpio_of_match),
> +   .of_match_table = plgpio_of_match,
> },
>  };

Patch is okay otherwise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [tpmdd-devel] [PATCH 02/13] tpm atmel: Call request_region with the correct base

[Jason Gunthorpe]

On Wed, Oct 02, 2013 at 07:11:14PM -0500, Ashley D Lai wrote:

> > I somewhat have the feeling that we should maybe begin to deprecate
> > the vendor specific 1.1 tpms...

> I agree. If we have a machine to test and it fails then we know we don't
> have a user for this.

Is this driver is only used on IBM systems? If so, will IBM provide
support for those systems on RHEL7? If not the driver can probably
safely be dropped.

The trouble with these old drivers is that they don't follow modern
conventions (there are several little bugs at least) and nobody can
test them to safely fix them.

If you do find hardware, we can at least take a solid run at sprucing
up the testable drivers which should give them more life..

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 56/57] ALSA: compress: Fix compress device unregister.

[Greg Kroah-Hartman]

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

--

From: Liam Girdwood 

commit 4028b6c4c03f213260e9290ff3a6b5439aad07ce upstream.

snd_unregister_device() should return the device type and not stream
direction.

Signed-off-by: Liam Girdwood 
Acked-by: Vinod Koul 
Tested-by: Vinod Koul 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/core/compress_offload.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -837,7 +837,8 @@ static int snd_compress_dev_disconnect(s
struct snd_compr *compr;
 
compr = device->device_data;
-   snd_unregister_device(compr->direction, compr->card, compr->device);
+   snd_unregister_device(SNDRV_DEVICE_TYPE_COMPRESS, compr->card,
+   compr->device);
return 0;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 49/57] drm/radeon: avoid UVD corruption on AGP cards using GPU gart

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb upstream.

If the user has forced the driver to use the internal GPU gart
rather than AGP on an AGP card, force the buffers to vram
as well.

Signed-off-by: Alex Deucher 
Reviewed-by: Christian König 
Tested-by: Dieter Nützel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_cs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -84,7 +84,7 @@ static int radeon_cs_parser_relocs(struc
   VRAM, also but everything into VRAM on AGP cards to avoid
   image corruptions */
if (p->ring == R600_RING_TYPE_UVD_INDEX &&
-   (i == 0 || p->rdev->flags & RADEON_IS_AGP)) {
+   (i == 0 || drm_pci_device_is_agp(p->rdev->ddev))) {
/* TODO: is this still needed for NI+ ? */
p->relocs[i].lobj.domain =
RADEON_GEM_DOMAIN_VRAM;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 44/57] drm/i915: preserve pipe A quirk in i9xx_set_pipeconf

[Greg Kroah-Hartman]

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

--

From: Daniel Vetter 

commit 67c72a12254101d4e8d9b9f3a02646ba0be84a2d upstream.

This regression has been introduced in

commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
Author: Daniel Vetter 
Date:   Thu Jun 13 00:54:58 2013 +0200

drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms

Ville brough up the idea that this is just the pipe A quirk gone
wrong.

Note that after resume the bios might or might not have enabled pipe A
already.  We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.

v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos 
Cc: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Chris Wilson 
[danvet: Use |= instead of = as suggested by Chris.]
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/intel_display.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4735,6 +4735,10 @@ static void i9xx_set_pipeconf(struct int
 
pipeconf = 0;
 
+   if (dev_priv->quirks & QUIRK_PIPEA_FORCE &&
+   I915_READ(PIPECONF(intel_crtc->pipe)) & PIPECONF_ENABLE)
+   pipeconf |= PIPECONF_ENABLE;
+
if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) {
/* Enable pixel doubling when the dot clock is > 90% of the 
(display)
 * core speed.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 50/57] drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2)

[Greg Kroah-Hartman]

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

--

From: Alex Ivanov 

commit 0eb3448aa6b31fbf24c31756aba7940cac5ad6b8 upstream.

Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.

Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a 
KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed 
(scratch(0x8504)=0xCAFEDEAD)" issue.

v2: agd5f: add some parens around ring->ready check

Signed-off-by: Alex Ivanov 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/r100.c|8 +---
 drivers/gpu/drm/radeon/radeon_ring.c |8 +---
 2 files changed, 10 insertions(+), 6 deletions(-)

--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2926,9 +2926,11 @@ static int r100_debugfs_cp_ring_info(str
seq_printf(m, "CP_RB_RPTR 0x%08x\n", rdp);
seq_printf(m, "%u free dwords in ring\n", ring->ring_free_dw);
seq_printf(m, "%u dwords in ring\n", count);
-   for (j = 0; j <= count; j++) {
-   i = (rdp + j) & ring->ptr_mask;
-   seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
+   if (ring->ready) {
+   for (j = 0; j <= count; j++) {
+   i = (rdp + j) & ring->ptr_mask;
+   seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
+   }
}
return 0;
 }
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -846,9 +846,11 @@ static int radeon_debugfs_ring_info(stru
 * packet that is the root issue
 */
i = (ring->rptr + ring->ptr_mask + 1 - 32) & ring->ptr_mask;
-   for (j = 0; j <= (count + 32); j++) {
-   seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
-   i = (i + 1) & ring->ptr_mask;
+   if (ring->ready) {
+   for (j = 0; j <= (count + 32); j++) {
+   seq_printf(m, "r[%5d]=0x%08x\n", i, ring->ring[i]);
+   i = (i + 1) & ring->ptr_mask;
+   }
}
return 0;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 47/57] drm/radeon/cik: Fix encoding of number of banks in tiling configuration info

[Greg Kroah-Hartman]

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

--

From: Michel Dänzer 

commit a537314e0b539e22934d3cffeb0b1f476e56491c upstream.

There are multiple valid values, not just 0 or 1.  Required
to properly support 2D tiling in the userspace drivers.

Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/cik.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -2008,10 +2008,8 @@ static void cik_gpu_init(struct radeon_d
rdev->config.cik.tile_config |= (3 << 0);
break;
}
-   if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
-   rdev->config.cik.tile_config |= 1 << 4;
-   else
-   rdev->config.cik.tile_config |= 0 << 4;
+   rdev->config.cik.tile_config |=
+   ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) << 4;
rdev->config.cik.tile_config |=
((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >> 
PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
rdev->config.cik.tile_config |=


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 46/57] drm/radeon/cik: Fix printing of client name on VM protection fault

[Greg Kroah-Hartman]

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

--

From: Michel Dänzer 

commit 328a50c7b09d313ab9278f972950da414d348eb1 upstream.

The string is encoded from the MSB to the LSB of the register.

Signed-off-by: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/cik.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4506,12 +4506,13 @@ static void cik_vm_decode_fault(struct r
u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
-   char *block = (char *)_client;
+   char block[5] = { mc_client >> 24, (mc_client >> 16) & 0xff,
+   (mc_client >> 8) & 0xff, mc_client & 0xff, 0 };
 
-   printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n",
+   printk("VM fault (0x%02x, vmid %d) at page %u, %s from '%s' (0x%08x) 
(%d)\n",
   protections, vmid, addr,
   (status & MEMORY_CLIENT_RW_MASK) ? "write" : "read",
-  block, mc_id);
+  block, mc_client, mc_id);
 }
 
 /**


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 51/57] drm/radeon: dont set default clocks for SI when DPM is disabled

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 360991867d83e10827d907ef67206986a98953b3 upstream.

This is a partial revert of c6cfa32da874fabec4fd1c2a579f0ba4e4dd.

We need to take into account the clk voltage dependencies of the
board.  Not doing so can lead to stability issues on certain
boards if the clks exceed the levels in the dep tables.

DPM already takes that into account, so for optimal performance,
use DPM.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_pm.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -919,7 +919,7 @@ static void radeon_pm_resume_old(struct
 {
/* set up the default clocks if the MC ucode is loaded */
if ((rdev->family >= CHIP_BARTS) &&
-   (rdev->family <= CHIP_HAINAN) &&
+   (rdev->family <= CHIP_CAYMAN) &&
rdev->mc_fw) {
if (rdev->pm.default_vddc)
radeon_atom_set_voltage(rdev, rdev->pm.default_vddc,
@@ -963,7 +963,7 @@ static void radeon_pm_resume_dpm(struct
if (ret) {
DRM_ERROR("radeon: dpm resume failed\n");
if ((rdev->family >= CHIP_BARTS) &&
-   (rdev->family <= CHIP_HAINAN) &&
+   (rdev->family <= CHIP_CAYMAN) &&
rdev->mc_fw) {
if (rdev->pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev->pm.default_vddc,
@@ -1014,7 +1014,7 @@ static int radeon_pm_init_old(struct rad
radeon_pm_init_profile(rdev);
/* set up the default clocks if the MC ucode is loaded */
if ((rdev->family >= CHIP_BARTS) &&
-   (rdev->family <= CHIP_HAINAN) &&
+   (rdev->family <= CHIP_CAYMAN) &&
rdev->mc_fw) {
if (rdev->pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev->pm.default_vddc,
@@ -1099,7 +1099,7 @@ static int radeon_pm_init_dpm(struct rad
if (ret) {
rdev->pm.dpm_enabled = false;
if ((rdev->family >= CHIP_BARTS) &&
-   (rdev->family <= CHIP_HAINAN) &&
+   (rdev->family <= CHIP_CAYMAN) &&
rdev->mc_fw) {
if (rdev->pm.default_vddc)
radeon_atom_set_voltage(rdev, 
rdev->pm.default_vddc,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] fix unsafe set_memory_rw from softirq

[Eric Dumazet]

On Wed, 2013-10-02 at 20:50 -0700, Alexei Starovoitov wrote:
> on x86 system with net.core.bpf_jit_enable = 1

> diff --git a/include/linux/filter.h b/include/linux/filter.h
> index a6ac848..378fa03 100644
> --- a/include/linux/filter.h
> +++ b/include/linux/filter.h
> @@ -27,6 +27,7 @@ struct sk_filter
>   unsigned intlen;/* Number of filter blocks */
>   unsigned int(*bpf_func)(const struct sk_buff *skb,
>   const struct sock_filter *filter);
> + struct work_struct  work;
>   struct rcu_head rcu;
>   struct sock_filter  insns[0];
>  };

Nice catch !

It seems only x86 and s390 needs this work_struct.

(and you might CC Heiko Carstens  to ask him
to make the s390 part, of Ack it if you plan to do it)

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 52/57] drm/radeon: disable tests/benchmarks if accel is disabled

[Greg Kroah-Hartman]

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

--

From: Alex Deucher 

commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.

The tests are only usable if the acceleration engines have
been successfully initialized.

Based on an initial patch from: Alex Ivanov 

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/radeon/radeon_device.c |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1297,13 +1297,22 @@ int radeon_device_init(struct radeon_dev
return r;
}
if ((radeon_testing & 1)) {
-   radeon_test_moves(rdev);
+   if (rdev->accel_working)
+   radeon_test_moves(rdev);
+   else
+   DRM_INFO("radeon: acceleration disabled, skipping move 
tests\n");
}
if ((radeon_testing & 2)) {
-   radeon_test_syncing(rdev);
+   if (rdev->accel_working)
+   radeon_test_syncing(rdev);
+   else
+   DRM_INFO("radeon: acceleration disabled, skipping sync 
tests\n");
}
if (radeon_benchmarking) {
-   radeon_benchmark(rdev, radeon_benchmarking);
+   if (rdev->accel_working)
+   radeon_benchmark(rdev, radeon_benchmarking);
+   else
+   DRM_INFO("radeon: acceleration disabled, skipping 
benchmarks\n");
}
return 0;
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 43/57] dm mpath: disable WRITE SAME if it fails

[Greg Kroah-Hartman]

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

--

From: Mike Snitzer 

commit f84cb8a46a771f36a04a02c61ea635c968ed5f6a upstream.

Workaround the SCSI layer's problematic WRITE SAME heuristics by
disabling WRITE SAME in the DM multipath device's queue_limits if an
underlying device disabled it.

The WRITE SAME heuristics, with both the original commit 5db44863b6eb
("[SCSI] sd: Implement support for WRITE SAME") and the updated commit
66c28f971 ("[SCSI] sd: Update WRITE SAME heuristics"), default to enabling
WRITE SAME(10) even without successfully determining it is supported.
After the first failed WRITE SAME the SCSI layer will disable WRITE SAME
for the device (by setting sdkp->device->no_write_same which results in
'max_write_same_sectors' in device's queue_limits to be set to 0).

When a device is stacked ontop of such a SCSI device any changes to that
SCSI device's queue_limits do not automatically propagate up the stack.
As such, a DM multipath device will not have its WRITE SAME support
disabled.  This causes the block layer to continue to issue WRITE SAME
requests to the mpath device which causes paths to fail and (if mpath IO
isn't configured to queue when no paths are available) it will result in
actual IO errors to the upper layers.

This fix doesn't help configurations that have additional devices
stacked ontop of the mpath device (e.g. LVM created linear DM devices
ontop).  A proper fix that restacks all the queue_limits from the bottom
of the device stack up will need to be explored if SCSI will continue to
use this model of optimistically allowing op codes and then disabling
them after they fail for the first time.

Before this patch:

EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: failing WRITE SAME IO with 
error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.
device-mapper: multipath: Failing path 8:112.
end_request: I/O error, dev dm-6, sector 4616
dm-6: WRITE SAME failed. Manually zeroing.
end_request: I/O error, dev dm-6, sector 4616
end_request: I/O error, dev dm-6, sector 5640
end_request: I/O error, dev dm-6, sector 6664
end_request: I/O error, dev dm-6, sector 7688
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.
end_request: I/O error, dev dm-6, sector 524296
Aborting journal on device dm-6-8.
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.

# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
33553920

After this patch:

EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: WRITE SAME I/O failed with 
error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.

# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
0

It should be noted that WRITE SAME support wasn't enabled in DM
multipath until v3.10.

Signed-off-by: Mike Snitzer 
Cc: Martin K. Petersen 
Cc: Hannes Reinecke 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-mpath.c |   11 ++-
 drivers/md/dm.c   |   11 +++
 include/linux/device-mapper.h |3 ++-
 3 files changed, 23 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1284,8 +1284,17 @@ static int do_end_io(struct multipath *m
if (!error && !clone->errors)
return 0;   /* I/O complete */
 
-   if (error == -EOPNOTSUPP || error == -EREMOTEIO || error == -EILSEQ)
+   if (error == -EOPNOTSUPP || error == -EREMOTEIO || error == -EILSEQ) {
+   if ((clone->cmd_flags & REQ_WRITE_SAME) &&
+   !clone->q->limits.max_write_same_sectors) {
+   struct queue_limits *limits;
+
+   /* device doesn't really support WRITE SAME, disable it 
*/
+   limits = 
dm_get_queue_limits(dm_table_get_md(m->ti->table));
+   limits->max_write_same_sectors = 0;
+   }
return error;
+   }
 
if (mpio->pgpath)
fail_path(mpio->pgpath);
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2250,6 +2250,17 @@ struct target_type *dm_get_immutable_tar
 }
 
 /*
+ * The queue_limits are only valid as long as you have a reference
+ * count on 'md'.
+ */
+struct queue_limits *dm_get_queue_limits(struct 

[ 37/57] usb: dwc3: pci: add support for BayTrail

[Greg Kroah-Hartman]

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

--

From: Heikki Krogerus 

commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

Add PCI id for Intel BayTrail.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -48,6 +48,7 @@
 /* FIXME define these in  */
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
 
 struct dwc3_pci {
struct device   *dev;
@@ -207,6 +208,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{  }/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 03/57] bcache: Fix a dumb journal discard bug

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit 6d9d21e35fbfa2934339e96934f862d118abac23 upstream.

That switch statement was obviously wrong, leading to some sort of weird
spinning on rare occasion with discards enabled...

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/journal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -428,7 +428,7 @@ static void do_journal_discard(struct ca
return;
}
 
-   switch (atomic_read(>discard_in_flight) == DISCARD_IN_FLIGHT) {
+   switch (atomic_read(>discard_in_flight)) {
case DISCARD_IN_FLIGHT:
return;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 26/57] drm/i915/tv: clear adjusted_mode.flags

[Greg Kroah-Hartman]

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

--

From: Daniel Vetter 

commit 1062b81598bc00e2f6620e6f3788f8f8df2f01e7 upstream.

The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.

This changed with the additional sanitation done with

commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0
Author: Imre Deak 
Date:   Tue Jul 30 13:36:32 2013 +0300

drm/i915: make user mode sync polarity setting explicit

sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.

Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us.  But that's
definitely work for a different patch series. So just add a FIXME
comment for now.

Reported-by: Knut Petersen 
Cc: Knut Petersen 
Cc: Imre Deak 
Cc: Chris Wilson 
Tested-by: Knut Petersen 
Signed-off-by: Daniel Vetter 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/i915/intel_tv.c |8 
 1 file changed, 8 insertions(+)

--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -918,6 +918,14 @@ intel_tv_compute_config(struct intel_enc
DRM_DEBUG_KMS("forcing bpc to 8 for TV\n");
pipe_config->pipe_bpp = 8*3;
 
+   /* TV has it's own notion of sync and other mode flags, so clear them. 
*/
+   pipe_config->adjusted_mode.flags = 0;
+
+   /*
+* FIXME: We don't check whether the input mode is actually what we want
+* or whether userspace is doing something stupid.
+*/
+
return true;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 40/57] driver core : Fix use after free of dev->parent in device_shutdown

[Greg Kroah-Hartman]

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

--

From: Benson Leung 

commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream.

The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.

However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.

Copy the parent pointer instead to avoid this condition.

This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"

In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).

This change should be applied on any kernel with this change :
d1c6c030fcec6f860d9bb6c632a3ebe62e28440b

Signed-off-by: Benson Leung 
Reviewed-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/base/core.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2033,7 +2033,7 @@ EXPORT_SYMBOL_GPL(device_move);
  */
 void device_shutdown(void)
 {
-   struct device *dev;
+   struct device *dev, *parent;
 
spin_lock(_kset->list_lock);
/*
@@ -2050,7 +2050,7 @@ void device_shutdown(void)
 * prevent it from being freed because parent's
 * lock is to be held
 */
-   get_device(dev->parent);
+   parent = get_device(dev->parent);
get_device(dev);
/*
 * Make sure the device is off the kset list, in the
@@ -2060,8 +2060,8 @@ void device_shutdown(void)
spin_unlock(_kset->list_lock);
 
/* hold lock to avoid race with probe/release */
-   if (dev->parent)
-   device_lock(dev->parent);
+   if (parent)
+   device_lock(parent);
device_lock(dev);
 
/* Don't allow any more runtime suspends */
@@ -2079,11 +2079,11 @@ void device_shutdown(void)
}
 
device_unlock(dev);
-   if (dev->parent)
-   device_unlock(dev->parent);
+   if (parent)
+   device_unlock(parent);
 
put_device(dev);
-   put_device(dev->parent);
+   put_device(parent);
 
spin_lock(_kset->list_lock);
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 00/57] 3.11.4-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.11.4 release.
There are 57 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Oct  5 04:06:23 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.11.4-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.11.4-rc1

Ben Hutchings 
irq: Always define devm_{request_threaded,free}_irq()

Liam Girdwood 
ALSA: compress: Fix compress device unregister.

Henrik Rydberg 
hwmon: (applesmc) Check key count before proceeding

Alex Deucher 
drm/radeon: fix hdmi audio on DCE3.0/3.1 asics

Alex Deucher 
drm/radeon: add missing hdmi callbacks for rv6xx

Alex Deucher 
drm/radeon: disable tests/benchmarks if accel is disabled

Alex Deucher 
drm/radeon: don't set default clocks for SI when DPM is disabled

Alex Ivanov 
drm/radeon: Make r100_cp_ring_info() and radeon_ring_gfx() safe (v2)

Alex Deucher 
drm/radeon: avoid UVD corruption on AGP cards using GPU gart

Alex Deucher 
drm/radeon/cik: fix overflow in vram fetch

Michel Dänzer 
drm/radeon/cik: Fix encoding of number of banks in tiling configuration info

Michel Dänzer 
drm/radeon/cik: Fix printing of client name on VM protection fault

Jani Nikula 
drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER

Daniel Vetter 
drm/i915: preserve pipe A quirk in i9xx_set_pipeconf

Mike Snitzer 
dm mpath: disable WRITE SAME if it fails

Mikulas Patocka 
dm-snapshot: fix performance degradation due to small hash size

Mikulas Patocka 
dm snapshot: workaround for a false positive lockdep warning

Benson Leung 
driver core : Fix use after free of dev->parent in device_shutdown

Kurt Garloff 
usb/core/devio.c: Don't reject control message to endpoint with wrong 
direction bit

David Cohen 
usb: dwc3: add support for Merrifield

Heikki Krogerus 
usb: dwc3: pci: add support for BayTrail

Ramneek Mehresh 
fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy

Al Viro 
USB: Fix breakage in ffs_fs_mount()

Alan Stern 
USB: UHCI: accept very late isochronous URBs

Alan Stern 
USB: OHCI: accept very late isochronous URBs

Florian Wolter 
xhci: Fix race between ep halt and URB cancellation

Alan Stern 
USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd

Mathias Nyman 
xhci: Fix oops happening after address device timeout

Mathias Nyman 
xhci: Ensure a command structure points to the correct trb on the command 
ring

Solomon Peachy 
cw1200: Use a threaded oneshot irq handler for cw1200_spi

Solomon Peachy 
Revert "cw1200: Don't perform SPI transfers in interrupt context"

Daniel Vetter 
drm/i915/tv: clear adjusted_mode.flags

Malcolm Priestley 
staging: vt6656: [BUG] iwctl_siwencodeext return if device not open

Malcolm Priestley 
staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier.

Ard Biesheuvel 
ARM: 7837/3: fix Thumb-2 bug in AES assembler code

Johan Hovold 
serial: pch_uart: fix tty-kref leak in dma-rx path

Johan Hovold 
serial: pch_uart: fix tty-kref leak in rx-error path

Johan Hovold 
serial: tegra: fix tty-kref leak

Peter Hurley 
tty: Fix SIGTTOU not sent with tcflush()

Alexander Usyskin 
mei: cancel stall timers in mei_reset

Tomas Winkler 
mei: bus: stop wait for read during cl state transition

Tomas Winkler 
mei: make me client counters less error prone

Josh Boyer 
x86, efi: Don't map Boot Services on i386

Vinson Lee 
tools lib lk: Uninclude linux/magic.h in debugfs.c

Masoud Sharbiani 
x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically

Chuansheng Liu 
kernel/reboot.c: re-enable the function of variable reboot_default

Kent Overstreet 
bcache: Fix flushes in writeback mode

Kent Overstreet 
bcache: Fix for handling overlapping extents when reading in a btree node

Kent Overstreet 
bcache: Fix a shrinker deadlock

Kent Overstreet 
bcache: Fix a dumb CPU spinning bug in writeback

Kent Overstreet 
bcache: Fix a flush/fua performance bug

Kent Overstreet 
bcache: Fix a writeback performance regression

Kent Overstreet 
bcache: Fix for when no journal entries are found

Gabriel de Perthuis 
bcache: Strip endline when writing the label through sysfs

Kent Overstreet 
bcache: Fix a dumb journal discard bug

Lubomir Rintel 
sysv: Add forgotten superblock lock init for v7 fs

Kent Overstreet 
block: Fix bio_copy_data()


-

Diffstat:

 Makefile |  4 +--
 arch/arm/crypto/aes-armv4.S  |  6 ++--
 arch/x86/kernel/reboot.c | 16 +
 

[ 39/57] usb/core/devio.c: Dont reject control message to endpoint with wrong direction bit

[Greg Kroah-Hartman]

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

--

From: Kurt Garloff 

commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream.

Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101)
[1] with the Windows App (EasyNote) works natively but fails when
Windows is running under KVM (and the USB device handed to KVM).

The reason is a USB control message
 usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 
wLength=0008
This goes to endpoint address 0x01 (wIndex); however, endpoint address
0x01 does not exist. There is an endpoint 0x81 though (same number,
but other direction); the app may have meant that endpoint instead.

The kernel thus rejects the IO and thus we see the failure.

Apparently, Linux is more strict here than Windows ... we can't change
the Win app easily, so that's a problem.

It seems that the Win app/driver is buggy here and the driver does not
behave fully according to the USB HID class spec that it claims to
belong to.  The device seems to happily deal with that though (and
seems to not really care about this value much).

So the question is whether the Linux kernel should filter here.
Rejecting has the risk that somewhat non-compliant userspace apps/
drivers (most likely in a virtual machine) are prevented from working.
Not rejecting has the risk of confusing an overly sensitive device with
such a transfer. Given the fact that Windows does not filter it makes
this risk rather small though.

The patch makes the kernel more tolerant: If the endpoint address in
wIndex does not exist, but an endpoint with toggled direction bit does,
it will let the transfer through. (It does NOT change the message.)

With attached patch, the app in Windows in KVM works.
 usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but 
needs 81

I suspect this will mostly affect apps in virtual environments; as on
Linux the apps would have been adapted to the stricter handling of the
kernel. I have done that for mine[2].

[1] http://www.pegatech.com/
[2] https://sourceforge.net/projects/notetakerpen/

Signed-off-by: Kurt Garloff 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/core/devio.c |   16 
 1 file changed, 16 insertions(+)

--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -742,6 +742,22 @@ static int check_ctrlrecip(struct dev_st
if ((index & ~USB_DIR_IN) == 0)
return 0;
ret = findintfep(ps->dev, index);
+   if (ret < 0) {
+   /*
+* Some not fully compliant Win apps seem to get
+* index wrong and have the endpoint number here
+* rather than the endpoint address (with the
+* correct direction). Win does let this through,
+* so we'll not reject it here but leave it to
+* the device to not break KVM. But we warn.
+*/
+   ret = findintfep(ps->dev, index ^ 0x80);
+   if (ret >= 0)
+   dev_info(>dev->dev,
+   "%s: process %i (%s) requesting ep %02x 
but needs %02x\n",
+   __func__, task_pid_nr(current),
+   current->comm, index, index ^ 0x80);
+   }
if (ret >= 0)
ret = checkintf(ps, ret);
break;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 28/57] cw1200: Use a threaded oneshot irq handler for cw1200_spi

[Greg Kroah-Hartman]

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

--

From: Solomon Peachy 

commit 87421cb6010a2f6494938fbe0a95e1b096b3b7af upstream.

This supercedes the older patch ("cw1200: Don't perform SPI transfers in
interrupt context") that badly attempted to fix this problem.

This is a far simpler solution, which has the added benefit of
actually working.

Signed-off-by: Solomon Peachy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/cw1200/cw1200_spi.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -250,9 +250,10 @@ static int cw1200_spi_irq_subscribe(stru
 
pr_debug("SW IRQ subscribe\n");
 
-   ret = request_any_context_irq(self->func->irq, cw1200_spi_irq_handler,
- IRQF_TRIGGER_HIGH,
- "cw1200_wlan_irq", self);
+   ret = request_threaded_irq(self->func->irq, NULL,
+  cw1200_spi_irq_handler,
+  IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
+  "cw1200_wlan_irq", self);
if (WARN_ON(ret < 0))
goto exit;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 08/57] bcache: Fix a dumb CPU spinning bug in writeback

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit 79e3dab90d9f826ceca67c7890e048ac9169de49 upstream.

schedule_timeout() != schedule_timeout_uninterruptible()

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/writeback.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -397,8 +397,7 @@ static void read_dirty(struct closure *c
if (delay > 0 &&
(KEY_START(>key) != dc->last_read ||
 jiffies_to_msecs(delay) > 50))
-   while (delay)
-   delay = schedule_timeout(delay);
+   delay = schedule_timeout_uninterruptible(delay);
 
dc->last_read   = KEY_OFFSET(>key);
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 32/57] xhci: Fix race between ep halt and URB cancellation

[Greg Kroah-Hartman]

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

--

From: Florian Wolter 

commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream.

The halted state of a endpoint cannot be cleared over CLEAR_HALT from a
user process, because the stopped_td variable was overwritten in the
handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will
refuse the reset and communication with device can not run over this endpoint.
https://bugzilla.kernel.org/show_bug.cgi?id=60699

Signed-off-by: Florian Wolter 
Signed-off-by: Sarah Sharp 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-ring.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -857,8 +857,12 @@ remove_finished_td:
/* Otherwise ring the doorbell(s) to restart queued transfers */
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
-   ep->stopped_td = NULL;
-   ep->stopped_trb = NULL;
+
+   /* Clear stopped_td and stopped_trb if endpoint is not halted */
+   if (!(ep->ep_state & EP_HALTED)) {
+   ep->stopped_td = NULL;
+   ep->stopped_trb = NULL;
+   }
 
/*
 * Drop the lock and complete the URBs in the cancelled TD list.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 36/57] fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy

[Greg Kroah-Hartman]

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

--

From: Ramneek Mehresh 

commit ad1260e9fbf768d6bed227d9604ebee76a84aae3 upstream.

For controller versions greater than 1.6, setting ULPI_PHY_CLK_SEL
bit when USB_EN bit is already set causes instability issues with
PHY_CLK_VLD bit. So USB_EN is set only for IP controller version
below 1.6 before setting ULPI_PHY_CLK_SEL bit

Signed-off-by: Ramneek Mehresh 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/ehci-fsl.c |   12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -130,7 +130,7 @@ static int usb_hcd_fsl_probe(const struc
}
 
/* Enable USB controller, 83xx or 8536 */
-   if (pdata->have_sysif_regs)
+   if (pdata->have_sysif_regs && pdata->controller_ver < FSL_USB_VER_1_6)
setbits32(hcd->regs + FSL_SOC_USB_CTRL, 0x4);
 
/* Don't need to set host mode here. It will be done by tdi_reset() */
@@ -232,15 +232,9 @@ static int ehci_fsl_setup_phy(struct usb
case FSL_USB2_PHY_ULPI:
if (pdata->have_sysif_regs && pdata->controller_ver) {
/* controller version 1.6 or above */
+   clrbits32(non_ehci + FSL_SOC_USB_CTRL, UTMI_PHY_EN);
setbits32(non_ehci + FSL_SOC_USB_CTRL,
-   ULPI_PHY_CLK_SEL);
-   /*
-* Due to controller issue of PHY_CLK_VALID in ULPI
-* mode, we set USB_CTRL_USB_EN before checking
-* PHY_CLK_VALID, otherwise PHY_CLK_VALID doesn't work.
-*/
-   clrsetbits_be32(non_ehci + FSL_SOC_USB_CTRL,
-   UTMI_PHY_EN, USB_CTRL_USB_EN);
+   ULPI_PHY_CLK_SEL | USB_CTRL_USB_EN);
}
portsc |= PORT_PTS_ULPI;
break;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 05/57] bcache: Fix for when no journal entries are found

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit c426c4fd46f709ade2bddd51c5738729c7ae1db5 upstream.

The journal replay code didn't handle this case, causing it to go into
an infinite loop...

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/journal.c |   30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

--- a/drivers/md/bcache/journal.c
+++ b/drivers/md/bcache/journal.c
@@ -153,7 +153,8 @@ int bch_journal_read(struct cache_set *c
bitmap_zero(bitmap, SB_JOURNAL_BUCKETS);
pr_debug("%u journal buckets", ca->sb.njournal_buckets);
 
-   /* Read journal buckets ordered by golden ratio hash to quickly
+   /*
+* Read journal buckets ordered by golden ratio hash to quickly
 * find a sequence of buckets with valid journal entries
 */
for (i = 0; i < ca->sb.njournal_buckets; i++) {
@@ -166,18 +167,20 @@ int bch_journal_read(struct cache_set *c
goto bsearch;
}
 
-   /* If that fails, check all the buckets we haven't checked
+   /*
+* If that fails, check all the buckets we haven't checked
 * already
 */
pr_debug("falling back to linear search");
 
-   for (l = 0; l < ca->sb.njournal_buckets; l++) {
-   if (test_bit(l, bitmap))
-   continue;
-
+   for (l = find_first_zero_bit(bitmap, ca->sb.njournal_buckets);
+l < ca->sb.njournal_buckets;
+l = find_next_zero_bit(bitmap, ca->sb.njournal_buckets, l 
+ 1))
if (read_bucket(l))
goto bsearch;
-   }
+
+   if (list_empty(list))
+   continue;
 bsearch:
/* Binary search */
m = r = find_next_bit(bitmap, ca->sb.njournal_buckets, l + 1);
@@ -197,10 +200,12 @@ bsearch:
r = m;
}
 
-   /* Read buckets in reverse order until we stop finding more
+   /*
+* Read buckets in reverse order until we stop finding more
 * journal entries
 */
-   pr_debug("finishing up");
+   pr_debug("finishing up: m %u njournal_buckets %u",
+m, ca->sb.njournal_buckets);
l = m;
 
while (1) {
@@ -228,9 +233,10 @@ bsearch:
}
}
 
-   c->journal.seq = list_entry(list->prev,
-   struct journal_replay,
-   list)->j.seq;
+   if (!list_empty(list))
+   c->journal.seq = list_entry(list->prev,
+   struct journal_replay,
+   list)->j.seq;
 
return 0;
 #undef read_bucket


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 38/57] usb: dwc3: add support for Merrifield

[Greg Kroah-Hartman]

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

--

From: David Cohen 

commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

Add PCI id for Intel Merrifield

Signed-off-by: David Cohen 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -49,6 +49,7 @@
 #define PCI_VENDOR_ID_SYNOPSYS 0x16c3
 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
 #define PCI_DEVICE_ID_INTEL_BYT0x0f37
+#define PCI_DEVICE_ID_INTEL_MRFLD  0x119e
 
 struct dwc3_pci {
struct device   *dev;
@@ -209,6 +210,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
{  }/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 32/52] USB: Fix breakage in ffs_fs_mount()

[Greg Kroah-Hartman]

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

--

From: Al Viro 

commit 2606b28aabd7dea1766c23a105e1124c95409c96 upstream.

There's a bunch of failure exits in ffs_fs_mount() with
seriously broken recovery logics.  Most of that appears to stem
from misunderstanding of the ->kill_sb() semantics; unlike
->put_super() it is called for *all* superblocks of given type,
no matter how (in)complete the setup had been.  ->put_super()
is called only if ->s_root is not NULL; any failure prior to
setting ->s_root will have the call of ->put_super() skipped.
->kill_sb(), OTOH, awaits every superblock that has come from
sget().

Current behaviour of ffs_fs_mount():

We have struct ffs_sb_fill_data data on stack there.  We do
ffs_dev = functionfs_acquire_dev_callback(dev_name);
and store that in data.private_data.  Then we call mount_nodev(),
passing it ffs_sb_fill() as a callback.  That will either fail
outright, or manage to call ffs_sb_fill().  There we allocate an
instance of struct ffs_data, slap the value of ffs_dev (picked
from data.private_data) into ffs->private_data and overwrite
data.private_data by storing ffs into an overlapping member
(data.ffs_data).  Then we store ffs into sb->s_fs_info and attempt
to set the rest of the things up (root inode, root dentry, then
create /ep0 there).  Any of those might fail.  Should that
happen, we get ffs_fs_kill_sb() called before mount_nodev()
returns.  If mount_nodev() fails for any reason whatsoever,
we proceed to
functionfs_release_dev_callback(data.ffs_data);

That's broken in a lot of ways.  Suppose the thing has failed in
allocation of e.g. root inode or dentry.  We have
functionfs_release_dev_callback(ffs);
ffs_data_put(ffs);
done by ffs_fs_kill_sb() (ffs accessed via sb->s_fs_info), followed by
functionfs_release_dev_callback(ffs);
from ffs_fs_mount() (via data.ffs_data).  Note that the second
functionfs_release_dev_callback() has every chance to be done to freed memory.

Suppose we fail *before* root inode allocation.  What happens then?
ffs_fs_kill_sb() doesn't do anything to ffs (it's either not called at all,
or it doesn't have a pointer to ffs stored in sb->s_fs_info).  And
functionfs_release_dev_callback(data.ffs_data);
is called by ffs_fs_mount(), but here we are in nasal daemon country - we
are reading from a member of union we'd never stored into.  In practice,
we'll get what we used to store into the overlapping field, i.e. ffs_dev.
And then we get screwed, since we treat it (struct gfs_ffs_obj * in
disguise, returned by functionfs_acquire_dev_callback()) as struct
ffs_data *, pick what would've been ffs_data ->private_data from it
(*well* past the actual end of the struct gfs_ffs_obj - struct ffs_data
is much bigger) and poke in whatever it points to.

FWIW, there's a minor leak on top of all that in case if ffs_sb_fill()
fails on kstrdup() - ffs is obviously forgotten.

The thing is, there is no point in playing all those games with union.
Just allocate and initialize ffs_data *before* calling mount_nodev() and
pass a pointer to it via data.ffs_data.  And once it's stored in
sb->s_fs_info, clear data.ffs_data, so that ffs_fs_mount() knows that
it doesn't need to kill the sucker manually - from that point on
we'll have it done by ->kill_sb().

Signed-off-by: Al Viro 
Acked-by: Michal Nazarewicz 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/f_fs.c |   60 +++---
 1 file changed, 26 insertions(+), 34 deletions(-)

--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -1034,37 +1034,19 @@ struct ffs_sb_fill_data {
struct ffs_file_perms perms;
umode_t root_mode;
const char *dev_name;
-   union {
-   /* set by ffs_fs_mount(), read by ffs_sb_fill() */
-   void *private_data;
-   /* set by ffs_sb_fill(), read by ffs_fs_mount */
-   struct ffs_data *ffs_data;
-   };
+   struct ffs_data *ffs_data;
 };
 
 static int ffs_sb_fill(struct super_block *sb, void *_data, int silent)
 {
struct ffs_sb_fill_data *data = _data;
struct inode*inode;
-   struct ffs_data *ffs;
+   struct ffs_data *ffs = data->ffs_data;
 
ENTER();
 
-   /* Initialise data */
-   ffs = ffs_data_new();
-   if (unlikely(!ffs))
-   goto Enomem;
-
ffs->sb  = sb;
-   ffs->dev_name= kstrdup(data->dev_name, GFP_KERNEL);
-   if (unlikely(!ffs->dev_name))
-   goto Enomem;
-   ffs->file_perms  = data->perms;
-   ffs->private_data= data->private_data;
-
-   /* used by the caller of this function */
-   data->ffs_data   = ffs;
-
+   data->ffs_data   = NULL;
sb->s_fs_info= ffs;
sb->s_blocksize  = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
@@ -1080,17 +1062,14 @@ 

[ 11/57] bcache: Fix flushes in writeback mode

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit c0f04d88e46d14de51f4baebb6efafb7d59e9f96 upstream.

In writeback mode, when we get a cache flush we need to make sure we
issue a flush to the backing device.

The code for sending down an extra flush was wrong - by cloning the bio
we were probably getting flags that didn't make sense for a bare flush,
and also the old code was firing for FUA bios, for which we don't need
to send a flush to the backing device.

This was causing data corruption somehow - the mechanism was never
determined, but this patch fixes it for the users that were seeing it.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/request.c |   15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -997,14 +997,17 @@ static void request_write(struct cached_
} else {
bch_writeback_add(dc);
 
-   if (s->op.flush_journal) {
+   if (bio->bi_rw & REQ_FLUSH) {
/* Also need to send a flush to the backing device */
-   s->op.cache_bio = bio_clone_bioset(bio, GFP_NOIO,
-  dc->disk.bio_split);
+   struct bio *flush = bio_alloc_bioset(0, GFP_NOIO,
+
dc->disk.bio_split);
 
-   bio->bi_size = 0;
-   bio->bi_vcnt = 0;
-   closure_bio_submit(bio, cl, s->d);
+   flush->bi_rw= WRITE_FLUSH;
+   flush->bi_bdev  = bio->bi_bdev;
+   flush->bi_end_io = request_endio;
+   flush->bi_private = cl;
+
+   closure_bio_submit(flush, cl, s->d);
} else {
s->op.cache_bio = bio;
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 16/57] mei: make me client counters less error prone

[Greg Kroah-Hartman]

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

--

From: Tomas Winkler 

commit 1aee351a739153529fbb98ee461777b2abd5e1c9 upstream.

1. u8 counters are prone to hard to detect overflow:
 make them unsigned long to match bit_ functions argument type

2. don't check me_clients_num for negativity, it is unsigned.

3. init all the me client counters from one place

Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/hbm.c |   10 ++
 drivers/misc/mei/mei_dev.h |6 +++---
 2 files changed, 9 insertions(+), 7 deletions(-)

--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -35,11 +35,15 @@ static void mei_hbm_me_cl_allocate(struc
struct mei_me_client *clients;
int b;
 
+   dev->me_clients_num = 0;
+   dev->me_client_presentation_num = 0;
+   dev->me_client_index = 0;
+
/* count how many ME clients we have */
for_each_set_bit(b, dev->me_clients_map, MEI_CLIENTS_MAX)
dev->me_clients_num++;
 
-   if (dev->me_clients_num <= 0)
+   if (dev->me_clients_num == 0)
return;
 
kfree(dev->me_clients);
@@ -221,7 +225,7 @@ static int mei_hbm_prop_req(struct mei_d
struct hbm_props_request *prop_req;
const size_t len = sizeof(struct hbm_props_request);
unsigned long next_client_index;
-   u8 client_num;
+   unsigned long client_num;
 
 
client_num = dev->me_client_presentation_num;
@@ -677,8 +681,6 @@ void mei_hbm_dispatch(struct mei_device
if (dev->dev_state == MEI_DEV_INIT_CLIENTS &&
dev->hbm_state == MEI_HBM_ENUM_CLIENTS) {
dev->init_clients_timer = 0;
-   dev->me_client_presentation_num = 0;
-   dev->me_client_index = 0;
mei_hbm_me_cl_allocate(dev);
dev->hbm_state = MEI_HBM_CLIENT_PROPERTIES;
 
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -396,9 +396,9 @@ struct mei_device {
struct mei_me_client *me_clients; /* Note: memory has to be allocated */
DECLARE_BITMAP(me_clients_map, MEI_CLIENTS_MAX);
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
-   u8 me_clients_num;
-   u8 me_client_presentation_num;
-   u8 me_client_index;
+   unsigned long me_clients_num;
+   unsigned long me_client_presentation_num;
+   unsigned long me_client_index;
 
struct mei_cl wd_cl;
enum mei_wd_states wd_state;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 37/52] driver core : Fix use after free of dev->parent in device_shutdown

[Greg Kroah-Hartman]

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

--

From: Benson Leung 

commit f123db8e9d6c84c863cb3c44d17e61995dc984fb upstream.

The put_device(dev) at the bottom of the loop of device_shutdown
may result in the dev being cleaned up. In device_create_release,
the dev is kfreed.

However, device_shutdown attempts to use the dev pointer again after
put_device by referring to dev->parent.

Copy the parent pointer instead to avoid this condition.

This bug was found on Chromium OS's chromeos-3.8, which is based on v3.8.11.
See bug report : https://code.google.com/p/chromium/issues/detail?id=297842
This can easily be reproduced when shutting down with
hidraw devices that report battery condition.
Two examples are the HP Bluetooth Mouse X4000b and the Apple Magic Mouse.
For example, with the magic mouse :
The dev in question is "hidraw0"
dev->parent is "magicmouse"

In the course of the shutdown for this device, the input event cleanup calls
a put on hidraw0, decrementing its reference count.
When we finally get to put_device(dev) in device_shutdown, kobject_cleanup
is called and device_create_release does kfree(dev).
dev->parent is no longer valid, and we may crash in
put_device(dev->parent).

This change should be applied on any kernel with this change :
d1c6c030fcec6f860d9bb6c632a3ebe62e28440b

Signed-off-by: Benson Leung 
Reviewed-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/base/core.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1839,7 +1839,7 @@ EXPORT_SYMBOL_GPL(device_move);
  */
 void device_shutdown(void)
 {
-   struct device *dev;
+   struct device *dev, *parent;
 
spin_lock(_kset->list_lock);
/*
@@ -1856,7 +1856,7 @@ void device_shutdown(void)
 * prevent it from being freed because parent's
 * lock is to be held
 */
-   get_device(dev->parent);
+   parent = get_device(dev->parent);
get_device(dev);
/*
 * Make sure the device is off the kset list, in the
@@ -1866,8 +1866,8 @@ void device_shutdown(void)
spin_unlock(_kset->list_lock);
 
/* hold lock to avoid race with probe/release */
-   if (dev->parent)
-   device_lock(dev->parent);
+   if (parent)
+   device_lock(parent);
device_lock(dev);
 
/* Don't allow any more runtime suspends */
@@ -1885,11 +1885,11 @@ void device_shutdown(void)
}
 
device_unlock(dev);
-   if (dev->parent)
-   device_unlock(dev->parent);
+   if (parent)
+   device_unlock(parent);
 
put_device(dev);
-   put_device(dev->parent);
+   put_device(parent);
 
spin_lock(_kset->list_lock);
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 40/52] dm mpath: disable WRITE SAME if it fails

[Greg Kroah-Hartman]

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

--

From: Mike Snitzer 

commit f84cb8a46a771f36a04a02c61ea635c968ed5f6a upstream.

Workaround the SCSI layer's problematic WRITE SAME heuristics by
disabling WRITE SAME in the DM multipath device's queue_limits if an
underlying device disabled it.

The WRITE SAME heuristics, with both the original commit 5db44863b6eb
("[SCSI] sd: Implement support for WRITE SAME") and the updated commit
66c28f971 ("[SCSI] sd: Update WRITE SAME heuristics"), default to enabling
WRITE SAME(10) even without successfully determining it is supported.
After the first failed WRITE SAME the SCSI layer will disable WRITE SAME
for the device (by setting sdkp->device->no_write_same which results in
'max_write_same_sectors' in device's queue_limits to be set to 0).

When a device is stacked ontop of such a SCSI device any changes to that
SCSI device's queue_limits do not automatically propagate up the stack.
As such, a DM multipath device will not have its WRITE SAME support
disabled.  This causes the block layer to continue to issue WRITE SAME
requests to the mpath device which causes paths to fail and (if mpath IO
isn't configured to queue when no paths are available) it will result in
actual IO errors to the upper layers.

This fix doesn't help configurations that have additional devices
stacked ontop of the mpath device (e.g. LVM created linear DM devices
ontop).  A proper fix that restacks all the queue_limits from the bottom
of the device stack up will need to be explored if SCSI will continue to
use this model of optimistically allowing op codes and then disabling
them after they fail for the first time.

Before this patch:

EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: failing WRITE SAME IO with 
error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.
device-mapper: multipath: Failing path 8:112.
end_request: I/O error, dev dm-6, sector 4616
dm-6: WRITE SAME failed. Manually zeroing.
end_request: I/O error, dev dm-6, sector 4616
end_request: I/O error, dev dm-6, sector 5640
end_request: I/O error, dev dm-6, sector 6664
end_request: I/O error, dev dm-6, sector 7688
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.
end_request: I/O error, dev dm-6, sector 524296
Aborting journal on device dm-6-8.
end_request: I/O error, dev dm-6, sector 524288
Buffer I/O error on device dm-6, logical block 65536
lost page write due to I/O error on dm-6
JBD2: Error -5 detected when updating journal superblock for dm-6-8.

# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
33553920

After this patch:

EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null)
device-mapper: multipath: XXX snitm debugging: got -EREMOTEIO (-121)
device-mapper: multipath: XXX snitm debugging: WRITE SAME I/O failed with 
error=-121
end_request: critical target error, dev dm-6, sector 528
dm-6: WRITE SAME failed. Manually zeroing.

# cat /sys/block/sdh/queue/write_same_max_bytes
0
# cat /sys/block/dm-6/queue/write_same_max_bytes
0

It should be noted that WRITE SAME support wasn't enabled in DM
multipath until v3.10.

Signed-off-by: Mike Snitzer 
Cc: Martin K. Petersen 
Cc: Hannes Reinecke 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-mpath.c |   11 ++-
 drivers/md/dm.c   |   11 +++
 include/linux/device-mapper.h |3 ++-
 3 files changed, 23 insertions(+), 2 deletions(-)

--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1284,8 +1284,17 @@ static int do_end_io(struct multipath *m
if (!error && !clone->errors)
return 0;   /* I/O complete */
 
-   if (error == -EOPNOTSUPP || error == -EREMOTEIO || error == -EILSEQ)
+   if (error == -EOPNOTSUPP || error == -EREMOTEIO || error == -EILSEQ) {
+   if ((clone->cmd_flags & REQ_WRITE_SAME) &&
+   !clone->q->limits.max_write_same_sectors) {
+   struct queue_limits *limits;
+
+   /* device doesn't really support WRITE SAME, disable it 
*/
+   limits = 
dm_get_queue_limits(dm_table_get_md(m->ti->table));
+   limits->max_write_same_sectors = 0;
+   }
return error;
+   }
 
if (mpio->pgpath)
fail_path(mpio->pgpath);
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -2219,6 +2219,17 @@ struct target_type *dm_get_immutable_tar
 }
 
 /*
+ * The queue_limits are only valid as long as you have a reference
+ * count on 'md'.
+ */
+struct queue_limits *dm_get_queue_limits(struct 

[ 25/57] staging: vt6656: [BUG] iwctl_siwencodeext return if device not open

[Greg Kroah-Hartman]

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

--

From: Malcolm Priestley 

commit 5e8c3d3e41b0bf241e830a1ee0752405adecc050 upstream.

Don't allow entry to iwctl_siwencodeext if device not open.

This fixes a race condition where wpa supplicant/network manager
enters the function when the device is already closed.

Signed-off-by: Malcolm Priestley 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/vt6656/iwctl.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/staging/vt6656/iwctl.c
+++ b/drivers/staging/vt6656/iwctl.c
@@ -1634,6 +1634,9 @@ int iwctl_siwencodeext(struct net_device
if (pMgmt == NULL)
return -EFAULT;
 
+   if (!(pDevice->flags & DEVICE_FLAGS_OPENED))
+   return -ENODEV;
+
buf = kzalloc(sizeof(struct viawget_wpa_param), GFP_KERNEL);
if (buf == NULL)
return -ENOMEM;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 18/57] mei: cancel stall timers in mei_reset

[Greg Kroah-Hartman]

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

--

From: Alexander Usyskin 

commit 4a704575cc1afb3b848f096778fa9b8d7b3d5813 upstream.

Unset init_clients_timer and amthif_stall_timers
in mei_reset in order to cancel timer ticking and hence
avoid recursive reset calls.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/amthif.c |1 +
 drivers/misc/mei/init.c   |3 +++
 2 files changed, 4 insertions(+)

--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -57,6 +57,7 @@ void mei_amthif_reset_params(struct mei_
dev->iamthif_ioctl = false;
dev->iamthif_state = MEI_IAMTHIF_IDLE;
dev->iamthif_timer = 0;
+   dev->iamthif_stall_timer = 0;
 }
 
 /**
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -169,6 +169,9 @@ void mei_reset(struct mei_device *dev, i
memset(>wr_ext_msg, 0, sizeof(dev->wr_ext_msg));
}
 
+   /* we're already in reset, cancel the init timer */
+   dev->init_clients_timer = 0;
+
dev->me_clients_num = 0;
dev->rd_msg_hdr = 0;
dev->wd_pending = false;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 10/57] bcache: Fix for handling overlapping extents when reading in a btree node

[Greg Kroah-Hartman]

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

--

From: Kent Overstreet 

commit 84786438ed17978d72eeced580ab757e4da8830b upstream.

btree_sort_fixup() was overly clever, because it was trying to avoid
pulling a key off the btree iterator in more than one place.

This led to a really obscure bug where we'd break early from the loop in
btree_sort_fixup() if the current key overlapped with keys in more than
one older set, and the next key it overlapped with was zero size.

Signed-off-by: Kent Overstreet 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/bcache/bset.c |   39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

--- a/drivers/md/bcache/bset.c
+++ b/drivers/md/bcache/bset.c
@@ -926,28 +926,45 @@ struct bkey *bch_next_recurse_key(struct
 
 /* Mergesort */
 
+static void sort_key_next(struct btree_iter *iter,
+ struct btree_iter_set *i)
+{
+   i->k = bkey_next(i->k);
+
+   if (i->k == i->end)
+   *i = iter->data[--iter->used];
+}
+
 static void btree_sort_fixup(struct btree_iter *iter)
 {
while (iter->used > 1) {
struct btree_iter_set *top = iter->data, *i = top + 1;
-   struct bkey *k;
 
if (iter->used > 2 &&
btree_iter_cmp(i[0], i[1]))
i++;
 
-   for (k = i->k;
-k != i->end && bkey_cmp(top->k, _KEY(k)) > 0;
-k = bkey_next(k))
-   if (top->k > i->k)
-   __bch_cut_front(top->k, k);
-   else if (KEY_SIZE(k))
-   bch_cut_back(_KEY(k), top->k);
-
-   if (top->k < i->k || k == i->k)
+   if (bkey_cmp(top->k, _KEY(i->k)) <= 0)
break;
 
-   heap_sift(iter, i - top, btree_iter_cmp);
+   if (!KEY_SIZE(i->k)) {
+   sort_key_next(iter, i);
+   heap_sift(iter, i - top, btree_iter_cmp);
+   continue;
+   }
+
+   if (top->k > i->k) {
+   if (bkey_cmp(top->k, i->k) >= 0)
+   sort_key_next(iter, i);
+   else
+   bch_cut_front(top->k, i->k);
+
+   heap_sift(iter, i - top, btree_iter_cmp);
+   } else {
+   /* can't happen because of comparison func */
+   BUG_ON(!bkey_cmp(_KEY(top->k), _KEY(i->k)));
+   bch_cut_back(_KEY(i->k), top->k);
+   }
}
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 14/57] tools lib lk: Uninclude linux/magic.h in debugfs.c

[Greg Kroah-Hartman]

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

--

From: Vinson Lee 

commit ce7eebe5c3deef8e19c177c24ee75843256e69ca upstream.

The compilation only looks for linux/magic.h from the default include
paths, which does not include the source tree. This results in a build
error if linux/magic.h is not available or not installed.

For example, this build error occurs on CentOS 5.

$ make -C tools/lib/lk V=1
[...]
gcc -o debugfs.o -c -ggdb3 -Wall -Wextra -std=gnu99 -Werror -O6
-D_FORTIFY_SOURCE=2 -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wshadow
-Wstrict-aliasing=3 -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat  -fPIC  -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 debugfs.c
debugfs.c:8:25: error: linux/magic.h: No such file or directory

The only symbol from linux/magic.h needed by debugfs.c is DEBUGFS_MAGIC,
and that is already defined in debugfs.h. linux/magic.h isn't providing
any extra symbols and can unincluded. This is similar to the approach by
perf, which has its own magic.h wrapper at
tools/perf/util/include/linux/magic.h

Signed-off-by: Vinson Lee 
Acked-by: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Vinson Lee 
Link: 
http://lkml.kernel.org/r/1379546200-17028-1-git-send-email-v...@freedesktop.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/lib/lk/debugfs.c |1 -
 1 file changed, 1 deletion(-)

--- a/tools/lib/lk/debugfs.c
+++ b/tools/lib/lk/debugfs.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "debugfs.h"


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 15/57] x86, efi: Dont map Boot Services on i386

[Greg Kroah-Hartman]

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

--

From: Josh Boyer 

commit 700870119f49084da004ab588ea2b799689efaf7 upstream.

Add patch to fix 32bit EFI service mapping (rhbz 726701)

Multiple people are reporting hitting the following WARNING on i386,

  WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
  Modules linked in:
  Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
  Call Trace:
   [] warn_slowpath_common+0x5f/0x80
   [] ? __ioremap_caller+0x3d3/0x440
   [] ? __ioremap_caller+0x3d3/0x440
   [] warn_slowpath_null+0x1d/0x20
   [] __ioremap_caller+0x3d3/0x440
   [] ? get_usage_chars+0xfb/0x110
   [] ? vprintk_emit+0x147/0x480
   [] ? efi_enter_virtual_mode+0x1e4/0x3de
   [] ioremap_cache+0x1a/0x20
   [] ? efi_enter_virtual_mode+0x1e4/0x3de
   [] efi_enter_virtual_mode+0x1e4/0x3de
   [] start_kernel+0x286/0x2f4
   [] ? repair_env_string+0x51/0x51
   [] i386_start_kernel+0x12c/0x12f

Due to the workaround described in commit 916f676f8 ("x86, efi: Retain
boot service code until after switching to virtual mode") EFI Boot
Service regions are mapped for a period during boot. Unfortunately, with
the limited size of the i386 direct kernel map it's possible that some
of the Boot Service regions will not be directly accessible, which
causes them to be ioremap()'d, triggering the above warning as the
regions are marked as E820_RAM in the e820 memmap.

There are currently only two situations where we need to map EFI Boot
Service regions,

  1. To workaround the firmware bug described in 916f676f8
  2. To access the ACPI BGRT image

but since we haven't seen an i386 implementation that requires either,
this simple fix should suffice for now.

[ Added to changelog - Matt ]

Reported-by: Bryan O'Donoghue 
Acked-by: Tom Zanussi 
Acked-by: Darren Hart 
Cc: Josh Triplett 
Cc: Matthew Garrett 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Greg Kroah-Hartman 
Signed-off-by: Josh Boyer 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/platform/efi/efi.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -912,10 +912,13 @@ void __init efi_enter_virtual_mode(void)
 
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
-   if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
-   md->type != EFI_BOOT_SERVICES_CODE &&
-   md->type != EFI_BOOT_SERVICES_DATA)
-   continue;
+   if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
+#ifdef CONFIG_X86_64
+   if (md->type != EFI_BOOT_SERVICES_CODE &&
+   md->type != EFI_BOOT_SERVICES_DATA)
+#endif
+   continue;
+   }
 
size = md->num_pages << EFI_PAGE_SHIFT;
end = md->phys_addr + size;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[ 21/57] serial: pch_uart: fix tty-kref leak in rx-error path

[Greg Kroah-Hartman]

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

--

From: Johan Hovold 

commit fc0919c68cb2f75bb1af759315f9d7e2a9443c28 upstream.

Fix tty-kref leak introduced by commit 384e301e ("pch_uart: fix a
deadlock when pch_uart as console") which never put its tty reference.

Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1071,6 +1071,8 @@ static void pch_uart_err_ir(struct eg20t
if (tty == NULL) {
for (i = 0; error_msg[i] != NULL; i++)
dev_err(>pdev->dev, error_msg[i]);
+   } else {
+   tty_kref_put(tty);
}
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/