Re: [PATCH RFC 0/4] 5-level EPT

2017-03-10 Thread Yu Zhang



On 3/9/2017 10:16 PM, Paolo Bonzini wrote:


On 17/01/2017 03:18, Li, Liang Z wrote:

On 29/12/2016 10:25, Liang Li wrote:

x86-64 is currently limited physical address width to 46 bits, which
can support 64 TiB of memory. Some vendors require to support more for
some use case. Intel plans to extend the physical address width to
52 bits in some of the future products.

The current EPT implementation only supports 4 level page table, which
can support maximum 48 bits physical address width, so it's needed to
extend the EPT to 5 level to support 52 bits physical address width.

This patchset has been tested in the SIMICS environment for 5 level
paging guest, which was patched with Kirill's patchset for enabling
5 level page table, with both the EPT and shadow page support. I just
covered the booting process, the guest can boot successfully.

Some parts of this patchset can be improved. Any comments on the
design or the patches would be appreciated.

I will review the patches.  They seem fairly straightforward.

However, I am worried about the design of the 5-level page table feature
with respect to migration.

Processors that support the new LA57 mode can write 57-canonical/48-
noncanonical linear addresses to some registers even when LA57 mode is
inactive.  This is true even of unprivileged instructions, in particular
WRFSBASE/WRGSBASE.

This is fairly bad because, if a guest performs such a write (because of a bug
or because of malice), it will not be possible to migrate the virtual machine to
a machine that lacks LA57 mode.

Ordinarily, hypervisors trap CPUID to hide features that are only present in
some processors of a heterogeneous cluster, and the hypervisor also traps
for example CR4 writes to prevent enabling features that were masked away.
In this case, however, the only way for the hypervisor to prevent the write
would be to run the guest with
CR4.FSGSBASE=0 and trap all executions of WRFSBASE/WRGSBASE.  This
might have negative effects on performance for workloads that use the
instructions.

Of course, this is a problem even without your patches.  However, I think it
should be addressed first.  I am seriously thinking of blacklisting FSGSBASE
completely on LA57 machines until the above is fixed in hardware.

Paolo

The issue has already been forwarded to the hardware guys, still waiting for 
the feedback.

Going to review this now.  Any news?


Thanks for your reivew, Paolo.
This is Yu Zhang from Intel. I'll pick up this 5 level ept feature, and 
will try to address your comments next. :-)
Now I am learning Liang's code and trying to bring VM up with Kirill's 
native 5 level paging code integrated.


Yu

Paolo





Re: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)

2017-03-10 Thread Yu Zhang

On 3/1/2017 5:04 PM, Yu Zhang wrote:



On 12/13/2016 7:03 PM, Paolo Bonzini wrote:


On 13/12/2016 05:03, Li, Liang Z wrote:

Hi Paolo,

We intended to enable UMIP for KVM and found you had already worked 
on it.
Do you have any plan for the following patch set? It's there 
anything else you expect

us help to do?

Yes, I plan to resend these patches for 4.11.


Hi Paolo,

  Previously we saw your RFC patches of UMIP sent out, and we would 
like to try some unit test in Intel. I found a patch written by you in 
https://patchwork.kernel.org/patch/9225929/, guess this is for the kvm 
unit test(though I failed to git apply it directly).

  And I wonder, when will it be integrated to kvm unit test repo?
  Besides, is this all the test for UMIP unit test? I.e. do we need to 
construct a scenario in the test to trigger vm exit and let hypervisor 
inject a GP fault? - I did not see this scenario in this patch. Or any 
other suggestions? :-)




Hi Paolo, any suggestions?
Sorry for the disturb. :)

Yu

Thanks
Yu





Re: [PATCH] powerpc: asm: convert directive .llong to .8byte

2017-03-10 Thread Tobin C. Harding
On Fri, Mar 10, 2017 at 11:09:08AM +1100, Daniel Axtens wrote:
> Hi Tobin,
> 
> > .llong is an undocumented PPC specific directive. The generic
> > equivalent is .quad, but even better (because it's self describing) is
> > .8byte.
> >
> > Convert directives .llong -> .8byte
> >
> > Signed-off-by: Tobin C. Harding 
> > ---
> >
> > Fixes: issue #33 (github)
> 
> Thanks for tackling these!
> 
> I have applied your patch to my local tree. I ran `git grep '\.llong'`,
> and found:
> 
> tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S: .llong 
> 0x
> 
> That file is also handled by mpe and the powerpc tree even though it
> doesn't live in arch/powerpc - could you please change that one as well?

Awesome, thanks Daniel. I did not know to look there. Will re submit.

thanks,
Tobin.


Re: [PATCH] powerpc: asm: convert directive .llong to .8byte

2017-03-10 Thread Tobin C. Harding
On Fri, Mar 10, 2017 at 06:40:58PM +1100, Michael Ellerman wrote:
> Daniel Axtens  writes:
> 
> > Hi Tobin,
> >
> >> .llong is an undocumented PPC specific directive. The generic
> >> equivalent is .quad, but even better (because it's self describing) is
> >> .8byte.
> >>
> >> Convert directives .llong -> .8byte
> >>
> >> Signed-off-by: Tobin C. Harding 
> >> ---
> >>
> >> Fixes: issue #33 (github)
> >
> > Thanks for tackling these!
> >
> > I have applied your patch to my local tree. I ran `git grep '\.llong'`,
> > and found:
> >
> > tools/testing/selftests/powerpc/switch_endian/switch_endian_test.S: .llong 
> > 0x
> >
> > That file is also handled by mpe and the powerpc tree even though it
> > doesn't live in arch/powerpc - could you please change that one as well?
> 
> I can do that one when I apply it.

Excellent.

thanks,
Tobin.


[ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

2017-03-10 Thread Stephan Müller
Hi,

The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect 
entropy within the Linux kernel. The main improvements compared to the legacy 
/dev/random is to provide sufficient entropy during boot time as well as in 
virtual environments and when using SSDs or Device Mapper targets. A secondary 
design goal is to limit the impact of the entropy collection on massive 
parallel systems and also allow the use accelerated cryptographic primitives. 
Also, all steps of the entropic data processing are testable. Finally 
performance improvements are visible at /dev/urandom and get_random_bytes.

The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

The LRNG has a flexible design by allowing an easy replacement of the
deterministic random number generator component. Currently implemented DRNGs
are an SP800-90A DRBG and a ChaCha20 DRNG.

[1] http://www.chronox.de/lrng.html

[2] http://www.chronox.de/lrng/doc/lrng.pdf

Ciao
Stephan


[patch 2/3] kcmp: Add KCMP_EPOLL_TFD mode to compare epoll target files

2017-03-10 Thread Cyrill Gorcunov
With current epoll architecture target files are addressed
with file_struct and file descriptor number, where the last
is not unique. Moreover files can be transferred from another
process via unix socket, added into queue and closed then
so we won't find this descriptor in the task fdinfo list.

Thus to checkpoint and restore such processes CRIU needs to
find out where exactly the target file is present to add it into
epoll queue. For this sake one can use kcmp call where
some particular target file from the queue is compared with
arbitrary file passed as an argument.

Because epoll target files can have same file descriptor
number but different file_struct a caller should explicitly
specify the offset within.

To test if some particular file is matching entry inside
epoll one have to

 - fill kcmp_epoll_slot structure with epoll file descriptor,
   target file number and target file offset (in case if only
   one target is present then it should be 0)

 - call kcmp as kcmp(pid1, pid2, KCMP_EPOLL_TFD, fd, &kcmp_epoll_slot)
- the kernel fetch file pointer matching file descriptor @fd of pid1
- lookups for file struct in epoll queue of pid2 and returns traditional
  0,1,2 result for sorting purpose

v2:
 - Use KCMP_FILES salt for files comparision (for convenience sake,
   since the pointers are file structs so user can lookup over previously
   collected files tree)
 - Make kcmp_epoll_target as a separate helper instead of opencoding
   it with #ifdef

v3:
 - Use less if()s in kcmp_epoll_target for readability sake (by avagin@)
 - Use u32 for kcmp_epoll_slot::toff instead of u64, which makes the less
   memory pressue

Signed-off-by: Cyrill Gorcunov 
CC: Al Viro 
CC: Andrew Morton 
CC: Andrey Vagin 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Kir Kolyshkin 
CC: Jason Baron 
CC: Andy Lutomirski 
---
 fs/eventpoll.c|   42 +++
 include/linux/eventpoll.h |3 ++
 include/uapi/linux/kcmp.h |   10 
 kernel/kcmp.c |   55 ++
 4 files changed, 110 insertions(+)

Index: linux-ml.git/fs/eventpoll.c
===
--- linux-ml.git.orig/fs/eventpoll.c
+++ linux-ml.git/fs/eventpoll.c
@@ -1000,6 +1000,48 @@ static struct epitem *ep_find(struct eve
return epir;
 }
 
+static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned long 
toff)
+{
+   struct rb_node *rbp;
+   struct epitem *epi;
+
+   for (rbp = rb_first(&ep->rbr); rbp; rbp = rb_next(rbp)) {
+   epi = rb_entry(rbp, struct epitem, rbn);
+   if (epi->ffd.fd == tfd) {
+   if (toff == 0)
+   return epi;
+   else
+   toff--;
+   }
+   cond_resched();
+   }
+
+   return NULL;
+}
+
+struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd,
+unsigned long toff)
+{
+   struct file *file_raw;
+   struct eventpoll *ep;
+   struct epitem *epi;
+
+   if (!is_file_epoll(file))
+   return ERR_PTR(-EINVAL);
+
+   ep = file->private_data;
+
+   mutex_lock(&ep->mtx);
+   epi = ep_find_tfd(ep, tfd, toff);
+   if (epi)
+   file_raw = epi->ffd.file;
+   else
+   file_raw = ERR_PTR(-ENOENT);
+   mutex_unlock(&ep->mtx);
+
+   return file_raw;
+}
+
 /*
  * This is the callback that is passed to the wait queue wakeup
  * mechanism. It is called by the stored file descriptors when they
Index: linux-ml.git/include/linux/eventpoll.h
===
--- linux-ml.git.orig/include/linux/eventpoll.h
+++ linux-ml.git/include/linux/eventpoll.h
@@ -14,6 +14,7 @@
 #define _LINUX_EVENTPOLL_H
 
 #include 
+#include 
 
 
 /* Forward declarations to avoid compiler errors */
@@ -22,6 +23,8 @@ struct file;
 
 #ifdef CONFIG_EPOLL
 
+struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned long 
toff);
+
 /* Used to initialize the epoll bits inside the "struct file" */
 static inline void eventpoll_init_file(struct file *file)
 {
Index: linux-ml.git/include/uapi/linux/kcmp.h
===
--- linux-ml.git.orig/include/uapi/linux/kcmp.h
+++ linux-ml.git/include/uapi/linux/kcmp.h
@@ -1,6 +1,8 @@
 #ifndef _UAPI_LINUX_KCMP_H
 #define _UAPI_LINUX_KCMP_H
 
+#include 
+
 /* Comparison type */
 enum kcmp_type {
KCMP_FILE,
@@ -10,8 +12,16 @@ enum kcmp_type {
KCMP_SIGHAND,
KCMP_IO,
KCMP_SYSVSEM,
+   KCMP_EPOLL_TFD,
 
KCMP_TYPES,
 };
 
+/* Slot for KCMP_EPOLL_TFD */
+struct kcmp_epoll_slot {
+   __u32 efd;  /* epoll file descriptor */
+   __u32 tfd;  /* target file number */
+   __u32 toff; /* target offset within same numbered 

[patch 0/3] fs,epoll: Add ability to call kcmp to find target files

2017-03-10 Thread Cyrill Gorcunov
Hi! This is slightly updated series for epoll extension
in procfs and kcmp syscall. The procfs patch and manpage
is unchanged while kcmp syscall is slightly updated to
drop hard to read if()'s and shrink memory pressue with
kcmp_epoll_slot argument.

Please take a look, once time permit. Being playing with
this patches via criu directly, works as expected.

https://lists.openvz.org/pipermail/criu/2017-February/036031.html


[patch 1/3] procfs: fdinfo -- Extend information about epoll target files

2017-03-10 Thread Cyrill Gorcunov
Since it is possbile to have same number in tfd field (say
file added, closed, then nother file dup'ed to same number
and added back) it is imposible to distinguish such target
files solely by their numbers.

Strictly speaking regular applications don't need to recognize
these targets at all but for checkpoint/restore sake we need
to collect targets to be able to push them back on restore
stage in a proper order.

Thus lets add file position, inode and device number where
this target lays. This three fields can be used as a primary
key for sorting, and together with kcmp help CRIU can find
out an exact file target (from the whole set of processes
being checkpointed).

Signed-off-by: Cyrill Gorcunov 
CC: Al Viro 
CC: Andrew Morton 
CC: Andrey Vagin 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Kir Kolyshkin 
CC: Jason Baron 
CC: Andy Lutomirski 
---
 Documentation/filesystems/proc.txt |6 +-
 fs/eventpoll.c |8 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

Index: linux-ml.git/Documentation/filesystems/proc.txt
===
--- linux-ml.git.orig/Documentation/filesystems/proc.txt
+++ linux-ml.git/Documentation/filesystems/proc.txt
@@ -1779,12 +1779,16 @@ pair provide additional information part
pos:0
flags:  02
mnt_id: 9
-   tfd:5 events:   1d data: 
+   tfd:5 events:   1d data:  pos:0 ino:61af 
sdev:7
 
where 'tfd' is a target file descriptor number in decimal form,
'events' is events mask being watched and the 'data' is data
associated with a target [see epoll(7) for more details].
 
+   The 'pos' is current offset of the target file in decimal form
+   [see lseek(2)], 'ino' and 'sdev' are inode and device numbers
+   where target file resides, all in hex format.
+
Fsnotify files
~~
For inotify files the format is the following
Index: linux-ml.git/fs/eventpoll.c
===
--- linux-ml.git.orig/fs/eventpoll.c
+++ linux-ml.git/fs/eventpoll.c
@@ -883,10 +883,14 @@ static void ep_show_fdinfo(struct seq_fi
mutex_lock(&ep->mtx);
for (rbp = rb_first(&ep->rbr); rbp; rbp = rb_next(rbp)) {
struct epitem *epi = rb_entry(rbp, struct epitem, rbn);
+   struct inode *inode = file_inode(epi->ffd.file);
 
-   seq_printf(m, "tfd: %8d events: %8x data: %16llx\n",
+   seq_printf(m, "tfd: %8d events: %8x data: %16llx "
+  " pos:%lli ino:%lx sdev:%x\n",
   epi->ffd.fd, epi->event.events,
-  (long long)epi->event.data);
+  (long long)epi->event.data,
+  (long long)epi->ffd.file->f_pos,
+  inode->i_ino, inode->i_sb->s_dev);
if (seq_has_overflowed(m))
break;
}



RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

2017-03-10 Thread Jun Li
Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 14:30, Jun Li  wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port.  Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree 
> >> >> >> > info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by software) ?
> >> >
> >> > In my case, charger detection is done by controller driver and I
> >> > need do charger type detection internally, and only pass the
> >> > current draw info via phy which will send out, this seems ok for
> >> > me, but I think it will be good if you or someone can show us an
> >> > example user based on the
> >> design Neil suggested.
> >> > Will you work out that common code if this USB charger framework is
> >> > not
> >> needed?
> >>
> >> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct
> >> phy“. Others are already ready if everyone has no complain about
> >> current design, except
> >
> > Only adding extcon_dev into usb_phy/phy  and all others are ready?
> > My understanding you will also do:
> > - We need find a central place to send the notification(phy common part).
> 
> That will include these implementation when adding extcon_dev.
> 

OK, thanks.

> > - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some
> API to findup it.
> 
> PMIC can find extcon device by phandle.

extcon_dev(not a reference pointer) is directly added in usb_phy/phy, not via 
devicetree,
how PMIC find it by phandle?
 
> 
> >
> >> my one concern. (I am afraid if it is enough to send out vbus draw
> >> information from USB phy dri

Re: [lkp-robot] [x86] ed3ce2a917: BUG:unable_to_handle_kernel

2017-03-10 Thread Borislav Petkov
On Fri, Mar 10, 2017 at 10:33:08AM +0800, Ye Xiaolong wrote:
> Previous kernel bug is gone for 10 times test of HEAD of tip/x86/asm. 
> (f25d3847
> "x86/asm: Optimize clear_page()")
> 
> Tested-by: Xiaolong Ye 

Thanks for verifying!

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.


Re: [RFC PATCH 0/4] KVM: Emulate UMIP (or almost do so)

2017-03-10 Thread Paolo Bonzini


On 10/03/2017 09:02, Yu Zhang wrote:
>>   Besides, is this all the test for UMIP unit test? I.e. do we need to
>> construct a scenario in the test to trigger vm exit and let hypervisor
>> inject a GP fault? - I did not see this scenario in this patch. Or any
>> other suggestions? :-)
> 
> Hi Paolo, any suggestions?
> Sorry for the disturb. :)

Hi, you get the scenario where a vmexit is triggered by the hypervisor
if you run the unit test on a machine that lacks UMIP support.

We can also add a module parameter to force emulation, so that it will
be possible to test UMIP emulation on newer processors too.

Paolo


Re: [PATCH] powerpc: sysdev: cpm1: Optimise gpio bit calculation

2017-03-10 Thread Michael Ellerman
Christophe Leroy  writes:

> Help a bit the compiler to provide better code:
>
> unsigned int f(int i)
> {
>   return 1 << (31 - i);
> }
>
> unsigned int g(int i)
> {
>   return 0x8000 >> i;
> }
>
> Disassembly of section .text:
>
>  :
>0: 20 63 00 1f subfic  r3,r3,31
>4: 39 20 00 01 li  r9,1
>8: 7d 23 18 30 slw r3,r9,r3
>c: 4e 80 00 20 blr
>
> 0010 :
>   10: 3d 20 80 00 lis r9,-32768
>   14: 7d 23 1c 30 srw r3,r9,r3
>   18: 4e 80 00 20 blr

Well yeah, it saves one instruction, but is it worth it? Are these gpio
routines in some hot path I don't know about?

cheers


Re: [PATCH 3/3] mmc: sdhci-st: remove unnecessary platform_set_drvdata() call

2017-03-10 Thread Patrice CHOTARD
Hi Jisheng

On 03/10/2017 04:17 AM, Jisheng Zhang wrote:
> sdhci_pltfm_init() has already set the platform drvdata for us, remove
> the unnecessary platform_set_drvdata() call.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/mmc/host/sdhci-st.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
> index ed92ce729dde..7fff6490855c 100644
> --- a/drivers/mmc/host/sdhci-st.c
> +++ b/drivers/mmc/host/sdhci-st.c
> @@ -418,8 +418,6 @@ static int sdhci_st_probe(struct platform_device *pdev)
>   goto err_out;
>   }
>
> - platform_set_drvdata(pdev, host);
> -
>   host_version = readw_relaxed((host->ioaddr + SDHCI_HOST_VERSION));
>
>   dev_info(&pdev->dev, "SDHCI ST Initialised: Host Version: 0x%x Vendor 
> Version 0x%x\n",
>

Acked-by: Patrice Chotard 

Thanks


Re: [PATCH v5 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

2017-03-10 Thread Vivek Gautam

Hi,


On 03/09/2017 04:31 PM, Bjorn Andersson wrote:

On Thu 09 Mar 10:07 CET 2017, Vivek Gautam wrote:

[..]

+static inline void qusb2_setbits(void __iomem *base, u32 offset, u32 val)
+{
+   u32 reg;
+
+   reg = readl_relaxed(base + offset);
+   reg |= val;
+   writel_relaxed(reg, base + offset);
+
+   /* Ensure above write is completed */
+   mb();

mb() does not ensure that the operation is completed, it only ensures
ordering between this write and subsequent memory accesses.

Unless you have specific reasons to you should not use the _relaxed()
versions of read and write operations. Using the non-relaxed versions
will ensure that your memory operations are not reordered.


Right, I think this is something i took from downstream and didn't
change. I should rather be using readl()/writel() and then readl()
again to ensure writes are through.
Thanks for pointing out.




+}
+
+static inline void qusb2_clrbits(void __iomem *base, u32 offset, u32 val)
+{
+   u32 reg;
+
+   reg = readl_relaxed(base + offset);
+   reg &= ~val;
+   writel_relaxed(reg, base + offset);
+
+   /* Ensure above write is completed */
+   mb();

Dito.


Sure, will change it.




+}
+
+static inline void qcom_qusb2_phy_configure(void __iomem *base,
+   const struct qusb2_phy_init_tbl tbl[],
+   int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++)
+   writel_relaxed(tbl[i].val, base + tbl[i].offset);
+
+   /* flush buffered writes */
+   mb();

Dito.


will correct it.




+}
+
+static int qusb2_phy_toggle_power(struct qusb2_phy *qphy, bool on)
+{
+   struct device *dev = &qphy->phy->dev;
+   int ret;
+
+   if (!on) {
+   ret = 0;
+   goto disable_vdda_phy_dpdm;
+   }

This is an ugly hack.


Right, it sort of minimized the code. :)
It just jumps to disable code for an 'off' call.

But, will amend it to use regulator_bulk_*() apis.




+
+   ret = regulator_enable(qphy->vdd_phy);
+   if (ret) {
+   dev_err(dev, "failed to enable vdd-phy, %d\n", ret);
+   goto err_vdd_phy;
+   }
+
+   ret = regulator_enable(qphy->vdda_pll);
+   if (ret) {
+   dev_err(dev, "failed to enable vdda-pll, %d\n", ret);
+   goto disable_vdd_phy;
+   }
+
+   ret = regulator_enable(qphy->vdda_phy_dpdm);
+   if (ret) {
+   dev_err(dev, "failed to enable vdda-phy-dpdm, %d\n", ret);
+   goto disable_vdda_pll;
+   }
+
+   dev_vdbg(dev, "%s(): regulators are turned on\n", __func__);
+
+   return ret;
+
+disable_vdda_phy_dpdm:
+   regulator_disable(qphy->vdda_phy_dpdm);
+disable_vdda_pll:
+   regulator_disable(qphy->vdda_pll);
+disable_vdd_phy:
+   regulator_disable(qphy->vdd_phy);
+err_vdd_phy:
+   dev_vdbg(dev, "%s(): regulators are turned off\n", __func__);
+   return ret;
+}

If you use the regulator_bulk interface for your regulators you can
replace this entire function with a call to regulator_bulk_enable() and
regulator_bulk_disable().


Sure, will change this as suggested.




+
+/*
+ * Fetches HS Tx tuning value from nvmem and sets the
+ * QUSB2PHY_PORT_TUNE2 register.
+ * For error case, skip setting the value and use the default value.
+ */
+static void qusb2_phy_set_tune2_param(struct qusb2_phy *qphy)
+{
+   struct device *dev = &qphy->phy->dev;
+   u8 *val;
+
+   /*
+* Read efuse register having TUNE2 parameter's high nibble.
+* If efuse register shows value as 0x0, or if we fail to find
+* a valid efuse register settings, then use default value
+* as 0xB for high nibble that we have already set while
+* configuring phy.
+*/
+   val = nvmem_cell_read(qphy->cell, NULL);
+   if (IS_ERR(val) || !val[0]) {
+   dev_dbg(dev, "failed to read a valid hs-tx trim value\n");
+   return;
+   }
+
+   /* Fused TUNE2 value is the higher nibble only */
+   qusb2_setbits(qphy->base, QUSB2PHY_PORT_TUNE2, val[0] << 0x4);
+}
+
+static int qusb2_phy_poweron(struct phy *phy)
+{
+   struct qusb2_phy *qphy = phy_get_drvdata(phy);
+   int ret;
+
+   dev_vdbg(&phy->dev, "%s(): Powering-on QUSB2 phy\n", __func__);
+
+   /* turn on regulator supplies */
+   ret = qusb2_phy_toggle_power(qphy, true);

Call regulator_bulk_enable()


Sure.




+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(qphy->iface_clk);
+   if (ret)
+   dev_err(&phy->dev, "failed to enable iface_clk, %d\n", ret);
+
+   return ret;
+}
+
+static int qusb2_phy_poweroff(struct phy *phy)
+{
+   struct qusb2_phy *qphy = phy_get_drvdata(phy);
+
+   clk_disable_unprepare(qphy->iface_clk);
+
+   qusb2_phy_toggle_power(qphy, false);

Call regulator_bulk_disable()


Right, will do that.




+
+   return 0;
+}
+
+static int qusb2_phy_

Re: mmc: core: Fix access to HS400-ES devices

2017-03-10 Thread Heiko Stübner
Am Mittwoch, 1. März 2017, 14:11:47 CET schrieb Guenter Roeck:
> HS400-ES devices fail to initialize with the following error messages.
> 
> mmc1: power class selection to bus width 8 ddr 0 failed
> mmc1: error -110 whilst initialising MMC card
> 
> This was seen on Samsung Chromebook Plus. Code analysis points to
> commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
> high-speed mode"), which attempts to set the bus width for all but
> HS200 devices unconditionally. However, for HS400-ES, the bus width
> is already selected.
> 
> Cc: Anssi Hannula 
> Cc: Douglas Anderson 
> Cc: Brian Norris 
> Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...")
> Signed-off-by: Guenter Roeck 
> Reviewed-by: Douglas Anderson 
> Reviewed-by: Shawn Lin 

On a rk3399-kevin and the current mainline kernel from 20170309 it makes the 
issue go away and the emmc work again, so

Tested-by: Heiko Stuebner 



Re: Kbuild maintainership

2017-03-10 Thread Michal Marek
Dne 10.3.2017 v 03:07 Masahiro Yamada napsal(a):
> Hello Kbuild contributors,
> 
> 
> As you may notice, Michal has been busy since the beginning
> of this year, and it has been getting difficult for him to
> work on Kbuild on his regular basis.

Yes, that's unfortunately the case.


> Michal sent me an email a few days ago, and we discussed this locally.
> Then, I decided to be a new maintainer of Kbuild. [1]

Thanks a lot for this and I wish you good luck with this new challenge.

Michal



Re: Kernel panic on Lenovo X60 with tracing enabled

2017-03-10 Thread Paul Menzel

Dear Josh,


On 03/10/17 00:04, Josh Poimboeuf wrote:

On Thu, Mar 09, 2017 at 09:43:47PM +0100, Paul Menzel wrote:

On 2017-03-09 17:29, Steven Rostedt wrote:

On Thu, 9 Mar 2017 10:16:02 -0600 Josh Poimboeuf wrote:


On Thu, Mar 09, 2017 at 09:36:30AM -0500, Steven Rostedt wrote:

On Thu, 9 Mar 2017 13:12:28 +0100 Paul Menzel wrote:



Hopefully, I am contacting the right people for my issue.

Suspending a system with Linux 4.9.13 with tracing enabled, it fails
with the screen still enabled, and the LED blinking. Attaching a serial
console to the dock, shows the messages below.


I'm betting this is a compiler bug, as that bug that printed is the
internal ftrace check for it. (note the bug is only in x86-32 not
x86-64)

Funny, we are just talking about this bug in another thread, but with a
different symptom.

Josh, did you say this goes away if you disable optimize for size or
does it need to be enabled?


Yeah, assuming it's the same problem, then this is caused by
CONFIG_CC_OPTIMIZE_FOR_SIZE.  It would be fixed by changing it to
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.


Paul, do you have CONFIG_CC_OPTIMIZE_FOR_SIZE enabled? Can you set it
to PERFORMANCE and see if the problem goes away?


As far as I can see, the Debian Linux kernel is built with
`CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y`.

So it might be a different problem?


Is it a stock Debian kernel?  If so, do you have a link where it can be
downloaded?


Sure, hopefully [3] works for you.

```
dpkg -x 
linux-image-4.9.0-0.bpo.2-686-pae-unsigned_4.9.13-1~bpo8+1_i386.deb 
target-directory

```


Kind regards,

Paul


[1] 
https://packages.debian.org/jessie-backports/linux-image-4.9.0-0.bpo.2-686-pae-unsigned
[2] 
https://packages.debian.org/jessie-backports/i386/linux-image-4.9.0-0.bpo.2-686-pae-unsigned/download
[3] 
http://ftp.us.debian.org/debian/pool/main/l/linux/linux-image-4.9.0-0.bpo.2-686-pae-unsigned_4.9.13-1~bpo8+1_i386.deb

[4] https://linux.die.net/man/1/dpkg


Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

2017-03-10 Thread Sumit Semwal
Hi Laura,

Thanks for the patch.

On 3 March 2017 at 03:14, Laura Abbott  wrote:
>
> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
> useful to have an explicit name attached to each region. Store the name
> in each CMA structure.
>
> Signed-off-by: Laura Abbott 
> ---
>  drivers/base/dma-contiguous.c |  5 +++--
>  include/linux/cma.h   |  4 +++-
>  mm/cma.c  | 11 +--
>  mm/cma.h  |  1 +
>  mm/cma_debug.c|  2 +-
>  5 files changed, 17 insertions(+), 6 deletions(-)
>

> +const char *cma_get_name(const struct cma *cma)
> +{
> +   return cma->name ? cma->name : "(undefined)";
> +}
> +
Would it make sense to perhaps have the idx stored as the name,
instead of 'undefined'? That would make sure that the various cma
names are still unique.

>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>  int align_order)
>  {
> @@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
>   */
>  int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  unsigned int order_per_bit,
> +const char *name,
>  struct cma **res_cma)
>  {

Best regards,
Sumit.


Re: [PATCH 2/3] mm, vmscan: Only clear pgdat congested/dirty/writeback state when balanced

2017-03-10 Thread Vlastimil Babka
On 03/09/2017 08:56 AM, Mel Gorman wrote:
> A pgdat tracks if recent reclaim encountered too many dirty, writeback
> or congested pages. The flags control whether kswapd writes pages back
> from reclaim context, tags pages for immediate reclaim when IO completes,
> whether processes block on wait_iff_congested and whether kswapd blocks
> when too many pages marked for immediate reclaim are encountered.
> 
> The state is cleared in a check function with side-effects. With the patch
> "mm, vmscan: fix zone balance check in prepare_kswapd_sleep", the timing
> of when the bits get cleared changed. Due to the way the check works,
> it'll clear the bits if ZONE_DMA is balanced for a GFP_DMA allocation
> because it does not account for lowmem reserves properly.
> 
> For the simoop workload, kswapd is not stalling when it should due to
> the premature clearing, writing pages from reclaim context like crazy and
> generally being unhelpful.
> 
> This patch resets the pgdat bits related to page reclaim only when kswapd
> is going to sleep. The comparison with simoop is then
> 
>  4.11.0-rc14.11.0-rc1 
>4.11.0-rc1
> vanilla   fixcheck-v2 
>  clear-v2
> Ameanp50-Read 21670074.18 (  0.00%) 20464344.18 (  5.56%) 
> 19786774.76 (  8.69%)
> Ameanp95-Read 25456267.64 (  0.00%) 25721423.64 ( -1.04%) 
> 24101956.27 (  5.32%)
> Ameanp99-Read 29369064.73 (  0.00%) 30174230.76 ( -2.74%) 
> 27691872.71 (  5.71%)
> Ameanp50-Write1390.30 (  0.00%) 1395.28 ( -0.36%) 
> 1011.91 ( 27.22%)
> Ameanp95-Write  412901.57 (  0.00%)37737.74 ( 90.86%)
> 34874.98 ( 91.55%)
> Ameanp99-Write 6668722.09 (  0.00%)   666489.04 ( 90.01%)   
> 575449.60 ( 91.37%)
> Ameanp50-Allocation  78714.31 (  0.00%)86286.22 ( -9.62%)
> 84246.26 ( -7.03%)
> Ameanp95-Allocation 175533.51 (  0.00%)   351812.27 (-100.42%)   
> 400058.43 (-127.91%)
> Ameanp99-Allocation 247003.02 (  0.00%)  6291171.56 (-2447.00%) 
> 10905600.00 (-4315.17%)
> 
> Read latency is improved, write latency is mostly improved but allocation
> latency is regressed.  kswapd is still reclaiming inefficiently,
> pages are being written back from writeback context and a host of other
> issues. However, given the change, it needed to be spelled out why the
> side-effect was moved.
> 
> Signed-off-by: Mel Gorman 

Acked-by: Vlastimil Babka 



Re: [PATCH 1/3] mm, vmscan: fix zone balance check in prepare_kswapd_sleep

2017-03-10 Thread Vlastimil Babka
On 03/09/2017 08:56 AM, Mel Gorman wrote:
> From: Shantanu Goel 
> 
> The check in prepare_kswapd_sleep needs to match the one in balance_pgdat
> since the latter will return as soon as any one of the zones in the
> classzone is above the watermark.  This is specially important for higher
> order allocations since balance_pgdat will typically reset the order to
> zero relying on compaction to create the higher order pages.  Without this
> patch, prepare_kswapd_sleep fails to wake up kcompactd since the zone
> balance check fails.
> 
> It was first reported against 4.9.7 that kswapd is failing to wake up
> kcompactd due to a mismatch in the zone balance check between balance_pgdat()
> and prepare_kswapd_sleep().  balance_pgdat() returns as soon as a single
> zone satisfies the allocation but prepare_kswapd_sleep() requires all zones
> to do +the same.  This causes prepare_kswapd_sleep() to never succeed except
> in the order == 0 case and consequently, wakeup_kcompactd() is never called.
> For the machine that originally motivated this patch, the state of compaction
> from /proc/vmstat looked this way after a day and a half +of uptime:
> 
> compact_migrate_scanned 240496
> compact_free_scanned 76238632
> compact_isolated 123472
> compact_stall 1791
> compact_fail 29
> compact_success 1762
> compact_daemon_wake 0
> 
> After applying the patch and about 10 hours of uptime the state looks
> like this:
> 
> compact_migrate_scanned 59927299
> compact_free_scanned 2021075136
> compact_isolated 640926
> compact_stall 4
> compact_fail 2
> compact_success 2
> compact_daemon_wake 5160
> 
> Further notes from Mel that motivated him to pick this patch up and
> resend it;
> 
> It was observed for the simoop workload (pressures the VM similar to HADOOP)
> that kswapd was failing to keep ahead of direct reclaim. The investigation
> noted that there was a need to rationalise kswapd decisions to reclaim
> with kswapd decisions to sleep. With this patch on a 2-socket box, there
> was a 49% reduction in direct reclaim scanning.
> 
> However, the impact otherwise is extremely negative. Kswapd reclaim
> efficiency dropped from 98% to 76%. simoop has three latency-related
> metrics for read, write and allocation (an anonymous mmap and fault).
> 
>  4.11.0-rc14.11.0-rc1
> vanilla   fixcheck-v2
> Ameanp50-Read 21670074.18 (  0.00%) 20464344.18 (  5.56%)
> Ameanp95-Read 25456267.64 (  0.00%) 25721423.64 ( -1.04%)
> Ameanp99-Read 29369064.73 (  0.00%) 30174230.76 ( -2.74%)
> Ameanp50-Write1390.30 (  0.00%) 1395.28 ( -0.36%)
> Ameanp95-Write  412901.57 (  0.00%)37737.74 ( 90.86%)
> Ameanp99-Write 6668722.09 (  0.00%)   666489.04 ( 90.01%)
> Ameanp50-Allocation  78714.31 (  0.00%)86286.22 ( -9.62%)
> Ameanp95-Allocation 175533.51 (  0.00%)   351812.27 (-100.42%)
> Ameanp99-Allocation 247003.02 (  0.00%)  6291171.56 (-2447.00%)
> 
> Of greater concern is that the patch causes swapping and page writes
> from kswapd context rose from 0 pages to 4189753 pages during the hour
> the workload ran for. By and large, the patch has very bad behaviour but
> easily missed as the impact on a UMA machine is negligible.
> 
> This patch is included with the data in case a bisection leads to this area.
> This patch is also a pre-requisite for the rest of the series.
> 
> Signed-off-by: Shantanu Goel 
> Signed-off-by: Mel Gorman 
> Acked-by: Hillf Danton 

Acked-by: Vlastimil Babka 



Re: [PATCH v3 1/4] platform/x86: fujitsu-laptop: register backlight device in a separate function

2017-03-10 Thread Michał Kępień
> Move code responsible for backlight device registration to a separate
> function in order to simplify error handling and decrease indentation.
> Simplify initialization of struct backlight_properties.  Use
> KBUILD_MODNAME as device name to avoid repeating the same string literal
> throughout the module.
> 
> Signed-off-by: Michał Kępień 
> ---
>  drivers/platform/x86/fujitsu-laptop.c | 38 
> ---
>  1 file changed, 22 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c 
> b/drivers/platform/x86/fujitsu-laptop.c
> index e12cc3504d48..185c929898d9 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -685,6 +685,25 @@ static const struct dmi_system_id fujitsu_dmi_table[] 
> __initconst = {
>  
>  /* ACPI device for LCD brightness control */
>  
> +static int fujitsu_backlight_register(void)
> +{
> + struct backlight_properties props = {
> + .brightness = fujitsu_bl->brightness_level,
> + .max_brightness = fujitsu_bl->max_brightness - 1,
> + .type = BACKLIGHT_PLATFORM
> + };
> + struct backlight_device *bd;
> +
> + bd = backlight_device_register(KBUILD_MODNAME, NULL, NULL,
> +&fujitsu_bl_ops, &props);

I have only just now noticed that this effectively breaks userspace
interface as KBUILD_MODNAME is "fujitsu_laptop" while the previously
used device name was "fujitsu-laptop" (underscore vs. hyphen).

Jonathan, as this series is already long overdue, I suggest the
following course of action: please review these patches anyway and if
you find no other issues, please provide your Reviewed-by etc. as you
normally would.  Once you do that, I will post v4 which will use
"fujitsu-laptop" for backlight device name and will contain your v3
review tags.  Does that sound reasonable?

-- 
Best regards,
Michał Kępień


[PATCH 4.4 12/91] [media] uvcvideo: Fix a wrong macro

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Guennadi Liakhovetski 

commit 17c341ec0115837a610b2da15e32546e26068234 upstream.

Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes.

Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc")

Signed-off-by: Guennadi Liakhovetski 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/usb/uvc/uvc_queue.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -416,7 +416,7 @@ struct uvc_buffer *uvc_queue_next_buffer
nextbuf = NULL;
spin_unlock_irqrestore(&queue->irqlock, flags);
 
-   buf->state = buf->error ? VB2_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
+   buf->state = buf->error ? UVC_BUF_STATE_ERROR : UVC_BUF_STATE_DONE;
vb2_set_plane_payload(&buf->buf.vb2_buf, 0, buf->bytesused);
vb2_buffer_done(&buf->buf.vb2_buf, VB2_BUF_STATE_DONE);
 




[PATCH 4.4 11/91] [media] am437x-vpfe: always assign bpp variable

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolas Iooss 

commit 6ebf75774f823ddbdbd10921006989d4df222f4a upstream.

In vpfe_s_fmt(), when the sensor format and the requested format were
the same, bpp was assigned to vpfe->bpp without being initialized first.

Grab the bpp value that is currently used by using __vpfe_get_format()
instead of its wrapper, vpfe_try_fmt().

This use of uninitialized variable has been found by compiling the
kernel with clang.

Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver
support for AM437X")

Signed-off-by: Nicolas Iooss 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/platform/am437x/am437x-vpfe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -1576,7 +1576,7 @@ static int vpfe_s_fmt(struct file *file,
return -EBUSY;
}
 
-   ret = vpfe_try_fmt(file, priv, &format);
+   ret = __vpfe_get_format(vpfe, &format, &bpp);
if (ret)
return ret;
 




[PATCH 4.4 14/91] ARM: at91: define LPDDR types

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexandre Belloni 

commit e3f0a4017c2143b4b813df6a93e8cf79e3f76936 upstream.

The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their
types.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman 

---
 include/soc/at91/at91sam9_ddrsdr.h |3 +++
 1 file changed, 3 insertions(+)

--- a/include/soc/at91/at91sam9_ddrsdr.h
+++ b/include/soc/at91/at91sam9_ddrsdr.h
@@ -81,6 +81,7 @@
 #defineAT91_DDRSDRC_LPCB_POWER_DOWN2
 #defineAT91_DDRSDRC_LPCB_DEEP_POWER_DOWN   3
 #defineAT91_DDRSDRC_CLKFR  (1 << 2)/* Clock Frozen 
*/
+#defineAT91_DDRSDRC_LPDDR2_PWOFF   (1 << 3)/* 
LPDDR Power Off */
 #defineAT91_DDRSDRC_PASR   (7 << 4)/* Partial 
Array Self Refresh */
 #defineAT91_DDRSDRC_TCSR   (3 << 8)/* Temperature 
Compensated Self Refresh */
 #defineAT91_DDRSDRC_DS (3 << 10)   /* Drive 
Strength */
@@ -96,7 +97,9 @@
 #defineAT91_DDRSDRC_MD_SDR 0
 #defineAT91_DDRSDRC_MD_LOW_POWER_SDR   1
 #defineAT91_DDRSDRC_MD_LOW_POWER_DDR   3
+#defineAT91_DDRSDRC_MD_LPDDR3  5
 #defineAT91_DDRSDRC_MD_DDR26   /* 
[SAM9 Only] */
+#defineAT91_DDRSDRC_MD_LPDDR2  7
 #defineAT91_DDRSDRC_DBW(1 << 4)/* Data 
Bus Width */
 #defineAT91_DDRSDRC_DBW_32BITS (0 <<  4)
 #defineAT91_DDRSDRC_DBW_16BITS (1 <<  4)




[PATCH 4.4 10/91] MIPS: Handle microMIPS jumps in the same way as MIPS32/MIPS64 jumps

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit 096a0de427ea333f56f0ee00328cff2a2731bcf1 upstream.

is_jump_ins() checks for plain jump ("j") instructions since commit
e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info") but
that commit didn't make the same change to the microMIPS code, leaving
it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS
encoding of the jump instruction too such that it behaves consistently.

Signed-off-by: Paul Burton 
Fixes: e7438c4b893e ("MIPS: Fix sibling call handling in get_frame_info")
Cc: Tony Wu 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14533/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -289,6 +289,8 @@ static inline int is_jump_ins(union mips
return 0;
}
 
+   if (ip->j_format.opcode == mm_j32_op)
+   return 1;
if (ip->j_format.opcode == mm_jal32_op)
return 1;
if (ip->r_format.opcode != mm_pool32a_op ||




[PATCH 4.4 16/91] ARM: dts: at91: Enable DMA on sama5d2_xplained console

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexandre Belloni 

commit 78162d48466d23c45a784034630c5928af631e3d upstream.

Enable DMA on uart1 to get a more reliable console.

Acked-by: Nicolas Ferre 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/at91-sama5d2_xplained.dts |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -122,6 +122,8 @@
uart1: serial@f802 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1_default>;
+   atmel,use-dma-rx;
+   atmel,use-dma-tx;
status = "okay";
};
 




[PATCH 4.4 18/91] ALSA: hda - fix Lewisburg audio issue

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jaroslav Kysela 

commit e7480b34ad1ab84a63540b2c884cb92c0764ab74 upstream.

Like for Sunrise Point, the total stream number of Lewisburg's
input and output stream exceeds 15 (GCAP is 0x9701), which will
cause some streams do not work because of the overflow on
SDxCTL.STRM field if using the legacy stream tag allocation method.

Fixes: 5cf92c8b3dc5 ("ALSA: hda - Add Intel Lewisburg device IDs Audio")
Signed-off-by: Jaroslav Kysela 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/hda_intel.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2208,9 +2208,9 @@ static const struct pci_device_id azx_id
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Lewisburg */
{ PCI_DEVICE(0x8086, 0xa1f0),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
{ PCI_DEVICE(0x8086, 0xa270),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Lynx Point-LP */
{ PCI_DEVICE(0x8086, 0x9c20),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },




[PATCH 4.4 17/91] ALSA: hda/realtek - Cannot adjust speakers volume on a Dell AIO

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Kai-Heng Feng 

commit 9f1bc2c4c58fcb2d86e0e26437dc8f3a18ac3276 upstream.

The issue is the same as "dd9aa335c880 ALSA: hda/realtek - Can't adjust
speaker's volume on a Dell AIO", the output requires to connect to a node
with Amp-out capability.

Applying the same fixup "ALC298_FIXUP_SPK_VOLUME" can fix the issue.

Signed-off-by: Kai-Heng Feng 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/patch_realtek.c |6 ++
 1 file changed, 6 insertions(+)

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6047,6 +6047,12 @@ static const struct snd_hda_pin_quirk al
SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", 
ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
ALC298_STANDARD_PINS,
{0x17, 0x90170150}),
+   SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_SPK_VOLUME,
+   {0x12, 0xb7a60140},
+   {0x13, 0xb7a60150},
+   {0x17, 0x90170110},
+   {0x1a, 0x03011020},
+   {0x21, 0x03211030}),
{}
 };
 




[PATCH 4.4 05/91] MIPS: Clear ISA bit correctly in get_frame_info()

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit ccaf7caf2c73c6db920772bf08bf1d47b2170634 upstream.

get_frame_info() can be called in microMIPS kernels with the ISA bit
already clear. For example this happens when unwind_stack_by_address()
is called because we begin with a PC that has the ISA bit set & subtract
the (odd) offset from the preceding symbol (which does not have the ISA
bit set). Since get_frame_info() unconditionally subtracts 1 from the PC
in microMIPS kernels it incorrectly misaligns the address it then
attempts to access code at, leading to an address error exception.

Fix this by using msk_isa16_mode() to clear the ISA bit, which allows
get_frame_info() to function regardless of whether it is provided with a
PC that has the ISA bit set or not.

Signed-off-by: Paul Burton 
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14528/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -299,17 +299,14 @@ static inline int is_sp_move_ins(union m
 
 static int get_frame_info(struct mips_frame_info *info)
 {
-#ifdef CONFIG_CPU_MICROMIPS
-   union mips_instruction *ip = (void *) (((char *) info->func) - 1);
-#else
-   union mips_instruction *ip = info->func;
-#endif
+   union mips_instruction *ip;
unsigned max_insns = info->func_size / sizeof(union mips_instruction);
unsigned i;
 
info->pc_offset = -1;
info->frame_size = 0;
 
+   ip = (void *)msk_isa16_mode((ulong)info->func);
if (!ip)
goto err;
 




[PATCH 4.4 03/91] MIPS: OCTEON: Fix copy_from_user fault handling for large buffers

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: James Cowgill 

commit 884b426917e4b3c85f33b382c792a94305dfdd62 upstream.

If copy_from_user is called with a large buffer (>= 128 bytes) and the
userspace buffer refers partially to unreadable memory, then it is
possible for Octeon's copy_from_user to report the wrong number of bytes
have been copied. In the case where the buffer size is an exact multiple
of 128 and the fault occurs in the last 64 bytes, copy_from_user will
report that all the bytes were copied successfully but leave some
garbage in the destination buffer.

The bug is in the main __copy_user_common loop in octeon-memcpy.S where
in the middle of the loop, src and dst are incremented by 128 bytes. The
l_exc_copy fault handler is used after this but that assumes that
"src < THREAD_BUADDR($28)". This is not the case if src has already been
incremented.

Fix by adding an extra fault handler which rewinds the src and dst
pointers 128 bytes before falling though to l_exc_copy.

Thanks to the pwritev test from the strace test suite for originally
highlighting this bug!

Fixes: 5b3b16880f40 ("MIPS: Add Cavium OCTEON processor support ...")
Signed-off-by: James Cowgill 
Acked-by: David Daney 
Reviewed-by: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14978/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/cavium-octeon/octeon-memcpy.S |   20 
 1 file changed, 12 insertions(+), 8 deletions(-)

--- a/arch/mips/cavium-octeon/octeon-memcpy.S
+++ b/arch/mips/cavium-octeon/octeon-memcpy.S
@@ -208,18 +208,18 @@ EXC(  STORE   t2, UNIT(6)(dst),   s_exc_p10u)
ADD src, src, 16*NBYTES
 EXC(   STORE   t3, UNIT(7)(dst),   s_exc_p9u)
ADD dst, dst, 16*NBYTES
-EXC(   LOADt0, UNIT(-8)(src),  l_exc_copy)
-EXC(   LOADt1, UNIT(-7)(src),  l_exc_copy)
-EXC(   LOADt2, UNIT(-6)(src),  l_exc_copy)
-EXC(   LOADt3, UNIT(-5)(src),  l_exc_copy)
+EXC(   LOADt0, UNIT(-8)(src),  l_exc_copy_rewind16)
+EXC(   LOADt1, UNIT(-7)(src),  l_exc_copy_rewind16)
+EXC(   LOADt2, UNIT(-6)(src),  l_exc_copy_rewind16)
+EXC(   LOADt3, UNIT(-5)(src),  l_exc_copy_rewind16)
 EXC(   STORE   t0, UNIT(-8)(dst),  s_exc_p8u)
 EXC(   STORE   t1, UNIT(-7)(dst),  s_exc_p7u)
 EXC(   STORE   t2, UNIT(-6)(dst),  s_exc_p6u)
 EXC(   STORE   t3, UNIT(-5)(dst),  s_exc_p5u)
-EXC(   LOADt0, UNIT(-4)(src),  l_exc_copy)
-EXC(   LOADt1, UNIT(-3)(src),  l_exc_copy)
-EXC(   LOADt2, UNIT(-2)(src),  l_exc_copy)
-EXC(   LOADt3, UNIT(-1)(src),  l_exc_copy)
+EXC(   LOADt0, UNIT(-4)(src),  l_exc_copy_rewind16)
+EXC(   LOADt1, UNIT(-3)(src),  l_exc_copy_rewind16)
+EXC(   LOADt2, UNIT(-2)(src),  l_exc_copy_rewind16)
+EXC(   LOADt3, UNIT(-1)(src),  l_exc_copy_rewind16)
 EXC(   STORE   t0, UNIT(-4)(dst),  s_exc_p4u)
 EXC(   STORE   t1, UNIT(-3)(dst),  s_exc_p3u)
 EXC(   STORE   t2, UNIT(-2)(dst),  s_exc_p2u)
@@ -383,6 +383,10 @@ done:
 nop
END(memcpy)
 
+l_exc_copy_rewind16:
+   /* Rewind src and dst by 16*NBYTES for l_exc_copy */
+   SUB src, src, 16*NBYTES
+   SUB dst, dst, 16*NBYTES
 l_exc_copy:
/*
 * Copy bytes from src until faulting load address (or until a




[PATCH 4.4 07/91] MIPS: Fix get_frame_info() handling of microMIPS function size

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit b6c7a324df37bf05ef7a2c1580683cf10d082d97 upstream.

get_frame_info() is meant to iterate over up to the first 128
instructions within a function, but for microMIPS kernels it will not
reach that many instructions unless the function is 512 bytes long since
we calculate the maximum number of instructions to check by dividing the
function length by the 4 byte size of a union mips_instruction. In
microMIPS kernels this won't do since instructions are variable length.

Fix this by instead checking whether the pointer to the current
instruction has reached the end of the function, and use max_insns as a
simple constant to check the number of iterations against.

Signed-off-by: Paul Burton 
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14530/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |   12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -289,9 +289,9 @@ static inline int is_sp_move_ins(union m
 static int get_frame_info(struct mips_frame_info *info)
 {
bool is_mmips = IS_ENABLED(CONFIG_CPU_MICROMIPS);
-   union mips_instruction insn, *ip;
-   unsigned max_insns = info->func_size / sizeof(union mips_instruction);
-   unsigned i;
+   union mips_instruction insn, *ip, *ip_end;
+   const unsigned int max_insns = 128;
+   unsigned int i;
 
info->pc_offset = -1;
info->frame_size = 0;
@@ -300,11 +300,9 @@ static int get_frame_info(struct mips_fr
if (!ip)
goto err;
 
-   if (max_insns == 0)
-   max_insns = 128U;   /* unknown function size */
-   max_insns = min(128U, max_insns);
+   ip_end = (void *)ip + info->func_size;
 
-   for (i = 0; i < max_insns; i++, ip++) {
+   for (i = 0; i < max_insns && ip < ip_end; i++, ip++) {
if (is_mmips && mm_insn_16bit(ip->halfword[0])) {
insn.halfword[0] = 0;
insn.halfword[1] = ip->halfword[0];




[PATCH 4.4 04/91] MIPS: Lantiq: Keep ethernet enabled during boot

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 774f0c6419bb8f9d83901d33582c7fe3ba6a6cb3 upstream.

Disabling ethernet during reboot (only to enable it again when the
ethernet driver attaches) can put the chip into a faulty state where it
corrupts the header of all incoming packets.

This happens if packets arrive during the time window where the core is
disabled, and it can be easily reproduced by rebooting while sending a
flood ping to the broadcast address.

Fixes: 95135bfa7ead ("MIPS: Lantiq: Deactivate most of the devices by default")
Signed-off-by: Felix Fietkau 
Acked-by: John Crispin 
Cc: hauke.mehrt...@lantiq.com
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15078/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/lantiq/xway/sysctrl.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/mips/lantiq/xway/sysctrl.c
+++ b/arch/mips/lantiq/xway/sysctrl.c
@@ -545,7 +545,7 @@ void __init ltq_soc_init(void)
clkdev_add_pmu("1a80.pcie", "msi", 1, 1, PMU1_PCIE2_MSI);
clkdev_add_pmu("1a80.pcie", "pdi", 1, 1, PMU1_PCIE2_PDI);
clkdev_add_pmu("1a80.pcie", "ctl", 1, 1, PMU1_PCIE2_CTL);
-   clkdev_add_pmu("1e108000.eth", NULL, 1, 0, PMU_SWITCH | 
PMU_PPE_DP);
+   clkdev_add_pmu("1e108000.eth", NULL, 0, 0, PMU_SWITCH | 
PMU_PPE_DP);
clkdev_add_pmu("1da0.usif", "NULL", 1, 0, PMU_USIF);
clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
} else if (of_machine_is_compatible("lantiq,ar10")) {
@@ -553,7 +553,7 @@ void __init ltq_soc_init(void)
  ltq_ar10_fpi_hz(), ltq_ar10_pp32_hz());
clkdev_add_pmu("1e101000.usb", "ctl", 1, 0, PMU_USB0);
clkdev_add_pmu("1e106000.usb", "ctl", 1, 0, PMU_USB1);
-   clkdev_add_pmu("1e108000.eth", NULL, 1, 0, PMU_SWITCH |
+   clkdev_add_pmu("1e108000.eth", NULL, 0, 0, PMU_SWITCH |
   PMU_PPE_DP | PMU_PPE_TC);
clkdev_add_pmu("1da0.usif", "NULL", 1, 0, PMU_USIF);
clkdev_add_pmu("1f203000.rcu", "gphy", 1, 0, PMU_GPHY);
@@ -575,11 +575,11 @@ void __init ltq_soc_init(void)
clkdev_add_pmu(NULL, "ahb", 1, 0, PMU_AHBM | PMU_AHBS);
 
clkdev_add_pmu("1da0.usif", "NULL", 1, 0, PMU_USIF);
-   clkdev_add_pmu("1e108000.eth", NULL, 1, 0,
+   clkdev_add_pmu("1e108000.eth", NULL, 0, 0,
PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM |
PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 |
PMU_PPE_QSB | PMU_PPE_TOP);
-   clkdev_add_pmu("1f203000.rcu", "gphy", 1, 0, PMU_GPHY);
+   clkdev_add_pmu("1f203000.rcu", "gphy", 0, 0, PMU_GPHY);
clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO);
clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU);
clkdev_add_pmu("1e116000.mei", "dfe", 1, 0, PMU_DFE);




[PATCH 4.4 08/91] MIPS: Fix is_jump_ins() handling of 16b microMIPS instructions

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit 67c75057709a6d85c681c78b9b2f9b71191f01a2 upstream.

is_jump_ins() checks 16b instruction fields without verifying that the
instruction is indeed 16b, as is done by is_ra_save_ins() &
is_sp_move_ins(). Add the appropriate check.

Signed-off-by: Paul Burton 
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14531/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -237,9 +237,14 @@ static inline int is_jump_ins(union mips
 *
 * microMIPS is kind of more fun...
 */
-   if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
-   (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op) ||
-   ip->j_format.opcode == mm_jal32_op)
+   if (mm_insn_16bit(ip->halfword[1])) {
+   if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
+   (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op))
+   return 1;
+   return 0;
+   }
+
+   if (ip->j_format.opcode == mm_jal32_op)
return 1;
if (ip->r_format.opcode != mm_pool32a_op ||
ip->r_format.func != mm_pool32axf_op)




[PATCH 4.4 06/91] MIPS: Prevent unaligned accesses during stack unwinding

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit a3552dace7d1d0cabf573e88fc3025cb90c4a601 upstream.

During stack unwinding we call a number of functions to determine what
type of instruction we're looking at. The union mips_instruction pointer
provided to them may be pointing at a 2 byte, but not 4 byte, aligned
address & we thus cannot directly access the 4 byte wide members of the
union mips_instruction. To avoid this is_ra_save_ins() copies the
required half-words of the microMIPS instruction to a correctly aligned
union mips_instruction on the stack, which it can then access safely.
The is_jump_ins() & is_sp_move_ins() functions do not correctly perform
this temporary copy, and instead attempt to directly dereference 4 byte
fields which may be misaligned and lead to an address exception.

Fix this by copying the instruction halfwords to a temporary union
mips_instruction in get_frame_info() such that we can provide a 4 byte
aligned union mips_instruction to the is_*_ins() functions and they do
not need to deal with misalignment themselves.

Signed-off-by: Paul Burton 
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14529/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |   70 ++---
 1 file changed, 35 insertions(+), 35 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -194,8 +194,6 @@ struct mips_frame_info {
 static inline int is_ra_save_ins(union mips_instruction *ip)
 {
 #ifdef CONFIG_CPU_MICROMIPS
-   union mips_instruction mmi;
-
/*
 * swsp ra,offset
 * swm16 reglist,offset(sp)
@@ -205,23 +203,20 @@ static inline int is_ra_save_ins(union m
 *
 * microMIPS is way more fun...
 */
-   if (mm_insn_16bit(ip->halfword[0])) {
-   mmi.word = (ip->halfword[0] << 16);
-   return (mmi.mm16_r5_format.opcode == mm_swsp16_op &&
-   mmi.mm16_r5_format.rt == 31) ||
-  (mmi.mm16_m_format.opcode == mm_pool16c_op &&
-   mmi.mm16_m_format.func == mm_swm16_op);
+   if (mm_insn_16bit(ip->halfword[1])) {
+   return (ip->mm16_r5_format.opcode == mm_swsp16_op &&
+   ip->mm16_r5_format.rt == 31) ||
+  (ip->mm16_m_format.opcode == mm_pool16c_op &&
+   ip->mm16_m_format.func == mm_swm16_op);
}
else {
-   mmi.halfword[0] = ip->halfword[1];
-   mmi.halfword[1] = ip->halfword[0];
-   return (mmi.mm_m_format.opcode == mm_pool32b_op &&
-   mmi.mm_m_format.rd > 9 &&
-   mmi.mm_m_format.base == 29 &&
-   mmi.mm_m_format.func == mm_swm32_func) ||
-  (mmi.i_format.opcode == mm_sw32_op &&
-   mmi.i_format.rs == 29 &&
-   mmi.i_format.rt == 31);
+   return (ip->mm_m_format.opcode == mm_pool32b_op &&
+   ip->mm_m_format.rd > 9 &&
+   ip->mm_m_format.base == 29 &&
+   ip->mm_m_format.func == mm_swm32_func) ||
+  (ip->i_format.opcode == mm_sw32_op &&
+   ip->i_format.rs == 29 &&
+   ip->i_format.rt == 31);
}
 #else
/* sw / sd $ra, offset($sp) */
@@ -242,12 +237,8 @@ static inline int is_jump_ins(union mips
 *
 * microMIPS is kind of more fun...
 */
-   union mips_instruction mmi;
-
-   mmi.word = (ip->halfword[0] << 16);
-
-   if ((mmi.mm16_r5_format.opcode == mm_pool16c_op &&
-   (mmi.mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op) ||
+   if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
+   (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op) ||
ip->j_format.opcode == mm_jal32_op)
return 1;
if (ip->r_format.opcode != mm_pool32a_op ||
@@ -276,15 +267,13 @@ static inline int is_sp_move_ins(union m
 *
 * microMIPS is not more fun...
 */
-   if (mm_insn_16bit(ip->halfword[0])) {
-   union mips_instruction mmi;
-
-   mmi.word = (ip->halfword[0] << 16);
-   return (mmi.mm16_r3_format.opcode == mm_pool16d_op &&
-   mmi.mm16_r3_format.simmediate && mm_addiusp_func) ||
-  (mmi.mm16_r5_format.opcode == mm_pool16d_op &&
-   mmi.mm16_r5_format.rt == 29);
+   if (mm_insn_16bit(ip->halfword[1])) {
+   return (ip->mm16_r3_format.opcode == mm_pool16d_op &&
+   ip->mm16_r3_format.simmediate && mm_addiusp_func) ||
+  (ip->mm16_r5_format.opcode == 

[PATCH 4.4 38/91] scsi: use scsi_device_from_queue() for scsi_dh

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Hannes Reinecke 

commit 857de6e00778738dc3d61f75acbac35bdc48e533 upstream.

The device handler needs to check if a given queue belongs to a scsi
device; only then does it make sense to attach a device handler.

[mkp: dropped flags]

Signed-off-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/scsi_dh.c |   22 --
 drivers/scsi/scsi_lib.c|   23 +++
 include/scsi/scsi_device.h |1 +
 3 files changed, 28 insertions(+), 18 deletions(-)

--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -289,20 +289,6 @@ int scsi_unregister_device_handler(struc
 }
 EXPORT_SYMBOL_GPL(scsi_unregister_device_handler);
 
-static struct scsi_device *get_sdev_from_queue(struct request_queue *q)
-{
-   struct scsi_device *sdev;
-   unsigned long flags;
-
-   spin_lock_irqsave(q->queue_lock, flags);
-   sdev = q->queuedata;
-   if (!sdev || !get_device(&sdev->sdev_gendev))
-   sdev = NULL;
-   spin_unlock_irqrestore(q->queue_lock, flags);
-
-   return sdev;
-}
-
 /*
  * scsi_dh_activate - activate the path associated with the scsi_device
  *  corresponding to the given request queue.
@@ -321,7 +307,7 @@ int scsi_dh_activate(struct request_queu
struct scsi_device *sdev;
int err = SCSI_DH_NOSYS;
 
-   sdev = get_sdev_from_queue(q);
+   sdev = scsi_device_from_queue(q);
if (!sdev) {
if (fn)
fn(data, err);
@@ -368,7 +354,7 @@ int scsi_dh_set_params(struct request_qu
struct scsi_device *sdev;
int err = -SCSI_DH_NOSYS;
 
-   sdev = get_sdev_from_queue(q);
+   sdev = scsi_device_from_queue(q);
if (!sdev)
return err;
 
@@ -391,7 +377,7 @@ int scsi_dh_attach(struct request_queue
struct scsi_device_handler *scsi_dh;
int err = 0;
 
-   sdev = get_sdev_from_queue(q);
+   sdev = scsi_device_from_queue(q);
if (!sdev)
return -ENODEV;
 
@@ -429,7 +415,7 @@ const char *scsi_dh_attached_handler_nam
struct scsi_device *sdev;
const char *handler_name = NULL;
 
-   sdev = get_sdev_from_queue(q);
+   sdev = scsi_device_from_queue(q);
if (!sdev)
return NULL;
 
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2215,6 +2215,29 @@ void scsi_mq_destroy_tags(struct Scsi_Ho
blk_mq_free_tag_set(&shost->tag_set);
 }
 
+/**
+ * scsi_device_from_queue - return sdev associated with a request_queue
+ * @q: The request queue to return the sdev from
+ *
+ * Return the sdev associated with a request queue or NULL if the
+ * request_queue does not reference a SCSI device.
+ */
+struct scsi_device *scsi_device_from_queue(struct request_queue *q)
+{
+   struct scsi_device *sdev = NULL;
+
+   if (q->mq_ops) {
+   if (q->mq_ops == &scsi_mq_ops)
+   sdev = q->queuedata;
+   } else if (q->request_fn == scsi_request_fn)
+   sdev = q->queuedata;
+   if (!sdev || !get_device(&sdev->sdev_gendev))
+   sdev = NULL;
+
+   return sdev;
+}
+EXPORT_SYMBOL_GPL(scsi_device_from_queue);
+
 /*
  * Function:scsi_block_requests()
  *
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -307,6 +307,7 @@ extern void scsi_remove_device(struct sc
 extern int scsi_unregister_device_handler(struct scsi_device_handler *scsi_dh);
 void scsi_attach_vpd(struct scsi_device *sdev);
 
+extern struct scsi_device *scsi_device_from_queue(struct request_queue *q);
 extern int scsi_device_get(struct scsi_device *);
 extern void scsi_device_put(struct scsi_device *);
 extern struct scsi_device *scsi_device_lookup(struct Scsi_Host *,




[PATCH 4.4 31/91] ipc/shm: Fix shmat mmap nil-page protection

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Davidlohr Bueso 

commit 95e91b831f87ac8e1f8ed50c14d709089b4e01b8 upstream.

The issue is described here, with a nice testcase:

https://bugzilla.kernel.org/show_bug.cgi?id=192931

The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
the address rounded down to 0.  For the regular mmap case, the
protection mentioned above is that the kernel gets to generate the
address -- arch_get_unmapped_area() will always check for MAP_FIXED and
return that address.  So by the time we do security_mmap_addr(0) things
get funky for shmat().

The testcase itself shows that while a regular user crashes, root will
not have a problem attaching a nil-page.  There are two possible fixes
to this.  The first, and which this patch does, is to simply allow root
to crash as well -- this is also regular mmap behavior, ie when hacking
up the testcase and adding mmap(...  |MAP_FIXED).  While this approach
is the safer option, the second alternative is to ignore SHM_RND if the
rounded address is 0, thus only having MAP_SHARED flags.  This makes the
behavior of shmat() identical to the mmap() case.  The downside of this
is obviously user visible, but does make sense in that it maintains
semantics after the round-down wrt 0 address and mmap.

Passes shm related ltp tests.

Link: 
http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-d...@stgolabs.net
Signed-off-by: Davidlohr Bueso 
Reported-by: Gareth Evans 
Cc: Manfred Spraul 
Cc: Michael Kerrisk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 ipc/shm.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1083,8 +1083,8 @@ out_unlock1:
  * "raddr" thing points to kernel space, and there has to be a wrapper around
  * this.
  */
-long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr,
- unsigned long shmlba)
+long do_shmat(int shmid, char __user *shmaddr, int shmflg,
+ ulong *raddr, unsigned long shmlba)
 {
struct shmid_kernel *shp;
unsigned long addr;
@@ -1105,8 +1105,13 @@ long do_shmat(int shmid, char __user *sh
goto out;
else if ((addr = (ulong)shmaddr)) {
if (addr & (shmlba - 1)) {
-   if (shmflg & SHM_RND)
-   addr &= ~(shmlba - 1); /* round down */
+   /*
+* Round down to the nearest multiple of shmlba.
+* For sane do_mmap_pgoff() parameters, avoid
+* round downs that trigger nil-page and MAP_FIXED.
+*/
+   if ((shmflg & SHM_RND) && addr >= shmlba)
+   addr &= ~(shmlba - 1);
else
 #ifndef __ARCH_FORCE_SHMLBA
if (addr & ~PAGE_MASK)




[PATCH 4.4 20/91] ALSA: ctxfi: Fallback DMA mask to 32bit

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 15c75b09f8d190f89ab4db463b87d411ca349dfe upstream.

Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit
architectures, and bails out if it fails.  This causes a problem on
some platforms since the 64bit DMA isn't always guaranteed.  We should
fall back to the default 32bit DMA when 64bit DMA fails.

Fixes: 6d74b86d3c0f ("ALSA: ctxfi - Allow 64bit DMA")
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/ctxfi/cthw20k1.c |   19 ++-
 sound/pci/ctxfi/cthw20k2.c |   19 ++-
 2 files changed, 12 insertions(+), 26 deletions(-)

--- a/sound/pci/ctxfi/cthw20k1.c
+++ b/sound/pci/ctxfi/cthw20k1.c
@@ -27,12 +27,6 @@
 #include "cthw20k1.h"
 #include "ct20k1reg.h"
 
-#if BITS_PER_LONG == 32
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(32) /* 32 bit PTE */
-#else
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(64) /* 64 bit PTE */
-#endif
-
 struct hw20k1 {
struct hw hw;
spinlock_t reg_20k1_lock;
@@ -1904,19 +1898,18 @@ static int hw_card_start(struct hw *hw)
 {
int err;
struct pci_dev *pci = hw->pci;
+   const unsigned int dma_bits = BITS_PER_LONG;
 
err = pci_enable_device(pci);
if (err < 0)
return err;
 
/* Set DMA transfer mask */
-   if (dma_set_mask(&pci->dev, CT_XFI_DMA_MASK) < 0 ||
-   dma_set_coherent_mask(&pci->dev, CT_XFI_DMA_MASK) < 0) {
-   dev_err(hw->card->dev,
-   "architecture does not support PCI busmaster DMA with 
mask 0x%llx\n",
-   CT_XFI_DMA_MASK);
-   err = -ENXIO;
-   goto error1;
+   if (dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(dma_bits));
+   } else {
+   dma_set_mask(&pci->dev, DMA_BIT_MASK(32));
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(32));
}
 
if (!hw->io_base) {
--- a/sound/pci/ctxfi/cthw20k2.c
+++ b/sound/pci/ctxfi/cthw20k2.c
@@ -26,12 +26,6 @@
 #include "cthw20k2.h"
 #include "ct20k2reg.h"
 
-#if BITS_PER_LONG == 32
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(32) /* 32 bit PTE */
-#else
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(64) /* 64 bit PTE */
-#endif
-
 struct hw20k2 {
struct hw hw;
/* for i2c */
@@ -2029,19 +2023,18 @@ static int hw_card_start(struct hw *hw)
int err = 0;
struct pci_dev *pci = hw->pci;
unsigned int gctl;
+   const unsigned int dma_bits = BITS_PER_LONG;
 
err = pci_enable_device(pci);
if (err < 0)
return err;
 
/* Set DMA transfer mask */
-   if (dma_set_mask(&pci->dev, CT_XFI_DMA_MASK) < 0 ||
-   dma_set_coherent_mask(&pci->dev, CT_XFI_DMA_MASK) < 0) {
-   dev_err(hw->card->dev,
-   "architecture does not support PCI busmaster DMA with 
mask 0x%llx\n",
-   CT_XFI_DMA_MASK);
-   err = -ENXIO;
-   goto error1;
+   if (!dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(dma_bits));
+   } else {
+   dma_set_mask(&pci->dev, DMA_BIT_MASK(32));
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(32));
}
 
if (!hw->io_base) {




[PATCH 4.4 58/91] fuse: add missing FR_FORCE

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Miklos Szeredi 

commit 2e38bea99a80eab408adee27f873a188d57b76cb upstream.

fuse_file_put() was missing the "force" flag for the RELEASE request when
sending synchronously (fuseblk).

If this flag is not set, then a sync request may be interrupted before it
is dequeued by the userspace filesystem.  In this case the OPEN won't be
balanced with a RELEASE.

Signed-off-by: Miklos Szeredi 
Fixes: 5a18ec176c93 ("fuse: fix hang of single threaded fuseblk filesystem")
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -100,6 +100,7 @@ static void fuse_file_put(struct fuse_fi
iput(req->misc.release.inode);
fuse_put_request(ff->fc, req);
} else if (sync) {
+   __set_bit(FR_FORCE, &req->flags);
__clear_bit(FR_BACKGROUND, &req->flags);
fuse_request_send(ff->fc, req);
iput(req->misc.release.inode);




[PATCH 4.4 27/91] iommu/vt-d: Tylersburg isoch identity map check is done too late.

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Ashok Raj 

commit 21e722c4c8377b5bc82ad058fed12165af739c1b upstream.

The check to set identity map for tylersburg is done too late. It needs
to be done before the check for identity_map domain is done.

To: Joerg Roedel 
To: David Woodhouse 
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Ashok Raj 

Fixes: 86080ccc22 ("iommu/vt-d: Allocate si_domain in init_dmars()")
Signed-off-by: Ashok Raj 
Reported-by: Yunhong Jiang 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/iommu/intel-iommu.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3238,13 +3238,14 @@ static int __init init_dmars(void)
iommu_identity_mapping |= IDENTMAP_GFX;
 #endif
 
+   check_tylersburg_isoch();
+
if (iommu_identity_mapping) {
ret = si_domain_init(hw_pass_through);
if (ret)
goto free_iommu;
}
 
-   check_tylersburg_isoch();
 
/*
 * If we copied translations from a previous kernel in the kdump




[PATCH 4.4 30/91] mm: do not access page->mapping directly on page_endio

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Minchan Kim 

commit dd8416c47715cf324c9a16f13273f9fda87acfed upstream.

With rw_page, page_endio is used for completing IO on a page and it
propagates write error to the address space if the IO fails.  The
problem is it accesses page->mapping directly which might be okay for
file-backed pages but it shouldn't for anonymous page.  Otherwise, it
can corrupt one of field from anon_vma under us and system goes panic
randomly.

swap_writepage
  bdev_writepage
ops->rw_page

I encountered the BUG during developing new zram feature and it was
really hard to figure it out because it made random crash, somtime
mmap_sem lockdep, sometime other places where places never related to
zram/zsmalloc, and not reproducible with some configuration.

When I consider how that bug is subtle and people do fast-swap test with
brd, it's worth to add stable mark, I think.

Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()")
Signed-off-by: Minchan Kim 
Acked-by: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/filemap.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -865,9 +865,12 @@ void page_endio(struct page *page, int r
unlock_page(page);
} else { /* rw == WRITE */
if (err) {
+   struct address_space *mapping;
+
SetPageError(page);
-   if (page->mapping)
-   mapping_set_error(page->mapping, err);
+   mapping = page_mapping(page);
+   if (mapping)
+   mapping_set_error(mapping, err);
}
end_page_writeback(page);
}




[PATCH 4.4 29/91] mm: vmpressure: fix sending wrong events on underflow

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Vinayak Menon 

commit e1587a4945408faa58d0485002c110eb2454740c upstream.

At the end of a window period, if the reclaimed pages is greater than
scanned, an unsigned underflow can result in a huge pressure value and
thus a critical event.  Reclaimed pages is found to go higher than
scanned because of the addition of reclaimed slab pages to reclaimed in
shrink_node without a corresponding increment to scanned pages.

Minchan Kim mentioned that this can also happen in the case of a THP
page where the scanned is 1 and reclaimed could be 512.

Link: 
http://lkml.kernel.org/r/1486641577-11685-1-git-send-email-vinme...@codeaurora.org
Signed-off-by: Vinayak Menon 
Acked-by: Minchan Kim 
Acked-by: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Rik van Riel 
Cc: Vladimir Davydov 
Cc: Anton Vorontsov 
Cc: Shiraz Hashim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/vmpressure.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -112,9 +112,16 @@ static enum vmpressure_levels vmpressure
unsigned long reclaimed)
 {
unsigned long scale = scanned + reclaimed;
-   unsigned long pressure;
+   unsigned long pressure = 0;
 
/*
+* reclaimed can be greater than scanned in cases
+* like THP, where the scanned is 1 and reclaimed
+* could be 512
+*/
+   if (reclaimed >= scanned)
+   goto out;
+   /*
 * We calculate the ratio (in percents) of how many pages were
 * scanned vs. reclaimed in a given time frame (window). Note that
 * time is in VM reclaimer's "ticks", i.e. number of pages
@@ -124,6 +131,7 @@ static enum vmpressure_levels vmpressure
pressure = scale - (reclaimed * scale / scanned);
pressure = pressure * 100 / scale;
 
+out:
pr_debug("%s: %3lu  (s: %lu  r: %lu)\n", __func__, pressure,
 scanned, reclaimed);
 




[PATCH 4.4 28/91] mm/page_alloc: fix nodes for reclaim in fast path

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Gavin Shan 

commit e02dc017c3032dcdce1b993af0db135462e1b4b7 upstream.

When @node_reclaim_node isn't 0, the page allocator tries to reclaim
pages if the amount of free memory in the zones are below the low
watermark.  On Power platform, none of NUMA nodes are scanned for page
reclaim because no nodes match the condition in zone_allows_reclaim().
On Power platform, RECLAIM_DISTANCE is set to 10 which is the distance
of Node-A to Node-A.  So the preferred node even won't be scanned for
page reclaim.

   __alloc_pages_nodemask()
   get_page_from_freelist()
  zone_allows_reclaim()

Anton proposed the test code as below:

   # cat alloc.c
  :
   int main(int argc, char *argv[])
   {
void *p;
unsigned long size;
unsigned long start, end;

start = time(NULL);
size = strtoul(argv[1], NULL, 0);
printf("To allocate %ldGB memory\n", size);

size <<= 30;
p = malloc(size);
assert(p);
memset(p, 0, size);

end = time(NULL);
printf("Used time: %ld seconds\n", end - start);
sleep(3600);
return 0;
   }

The system I use for testing has two NUMA nodes.  Both have 128GB
memory.  In below scnario, the page caches on node#0 should be reclaimed
when it encounters pressure to accommodate request of allocation.

   # echo 2 > /proc/sys/vm/zone_reclaim_mode; \
 sync; \
 echo 3 > /proc/sys/vm/drop_caches; \
   # taskset -c 0 cat file.32G > /dev/null; \
 grep FilePages /sys/devices/system/node/node0/meminfo
 Node 0 FilePages:   33619712 kB
   # taskset -c 0 ./alloc 128
   # grep FilePages /sys/devices/system/node/node0/meminfo
 Node 0 FilePages:   33619840 kB
   # grep MemFree /sys/devices/system/node/node0/meminfo
 Node 0 MemFree:  186816 kB

With the patch applied, the pagecache on node-0 is reclaimed when its
free memory is running out.  It's the expected behaviour.

   # echo 2 > /proc/sys/vm/zone_reclaim_mode; \
 sync; \
 echo 3 > /proc/sys/vm/drop_caches
   # taskset -c 0 cat file.32G > /dev/null; \
 grep FilePages /sys/devices/system/node/node0/meminfo
 Node 0 FilePages:   33605568 kB
   # taskset -c 0 ./alloc 128
   # grep FilePages /sys/devices/system/node/node0/meminfo
 Node 0 FilePages:1379520 kB
   # grep MemFree /sys/devices/system/node/node0/meminfo
 Node 0 MemFree:   317120 kB

Fixes: 5f7a75acdb24 ("mm: page_alloc: do not cache reclaim distances")
Link: 
http://lkml.kernel.org/r/1486532455-29613-1-git-send-email-gws...@linux.vnet.ibm.com
Signed-off-by: Gavin Shan 
Acked-by: Mel Gorman 
Acked-by: Michal Hocko 
Cc: Anton Blanchard 
Cc: Michael Ellerman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2467,7 +2467,7 @@ static bool zone_local(struct zone *loca
 
 static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone)
 {
-   return node_distance(zone_to_nid(local_zone), zone_to_nid(zone)) <
+   return node_distance(zone_to_nid(local_zone), zone_to_nid(zone)) <=
RECLAIM_DISTANCE;
 }
 #else  /* CONFIG_NUMA */




[PATCH 4.4 73/91] RDMA/core: Fix incorrect structure packing for booleans

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jason Gunthorpe 

commit 55efcfcd7776165b294f8b5cd6e05ca00ec89b7c upstream.

The RDMA core uses ib_pack() to convert from unpacked CPU structs
to on-the-wire bitpacked structs.

This process requires that 1 bit fields are declared as u8 in the
unpacked struct, otherwise the packing process does not read the
value properly and the packed result is wired to 0. Several
places wrongly used int.

Crucially this means the kernel has never, set reversible
correctly in the path record request. It has always asked for
irreversible paths even if the ULP requests otherwise.

When the kernel is used with a SM that supports this feature, it
completely breaks communication management if reversible paths are
not properly requested.

The only reason this ever worked is because opensm ignores the
reversible bit.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman 

---
 include/rdma/ib_sa.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/include/rdma/ib_sa.h
+++ b/include/rdma/ib_sa.h
@@ -138,12 +138,12 @@ struct ib_sa_path_rec {
union ib_gid sgid;
__be16   dlid;
__be16   slid;
-   int  raw_traffic;
+   u8   raw_traffic;
/* reserved */
__be32   flow_label;
u8   hop_limit;
u8   traffic_class;
-   int  reversible;
+   u8   reversible;
u8   numb_path;
__be16   pkey;
__be16   qos_class;
@@ -204,7 +204,7 @@ struct ib_sa_mcmember_rec {
u8   hop_limit;
u8   scope;
u8   join_state;
-   int  proxy_join;
+   u8   proxy_join;
 };
 
 /* Service Record Component Mask Sec 15.2.5.14 Ver 1.1 */




[PATCH 4.4 75/91] gfs2: Add missing rcu locking for glock lookup

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Andrew Price 

commit f38e5fb95a1f8feda88531eedc98f69b24748712 upstream.

We must hold the rcu read lock across looking up glocks and trying to
bump their refcount to prevent the glocks from being freed in between.

Signed-off-by: Andrew Price 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Bob Peterson 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/gfs2/glock.c |5 +
 1 file changed, 5 insertions(+)

--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -651,9 +651,11 @@ int gfs2_glock_get(struct gfs2_sbd *sdp,
struct kmem_cache *cachep;
int ret, tries = 0;
 
+   rcu_read_lock();
gl = rhashtable_lookup_fast(&gl_hash_table, &name, ht_parms);
if (gl && !lockref_get_not_dead(&gl->gl_lockref))
gl = NULL;
+   rcu_read_unlock();
 
*glp = gl;
if (gl)
@@ -721,15 +723,18 @@ again:
 
if (ret == -EEXIST) {
ret = 0;
+   rcu_read_lock();
tmp = rhashtable_lookup_fast(&gl_hash_table, &name, ht_parms);
if (tmp == NULL || !lockref_get_not_dead(&tmp->gl_lockref)) {
if (++tries < 100) {
+   rcu_read_unlock();
cond_resched();
goto again;
}
tmp = NULL;
ret = -ENOMEM;
}
+   rcu_read_unlock();
} else {
WARN_ON_ONCE(ret);
}




[PATCH 4.4 80/91] NFSv4: Fix memory and state leak in _nfs4_open_and_get_state

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit a974deee477af89411e0f80456bfb344ac433c98 upstream.

If we exit because the file access check failed, we currently
leak the struct nfs4_state. We need to attach it to the
open context before returning.

Fixes: 3efb9722475e ("NFSv4: Refactor _nfs4_open_and_get_state..")
Signed-off-by: Trond Myklebust 
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2452,6 +2452,7 @@ static int _nfs4_open_and_get_state(stru
ret = PTR_ERR(state);
if (IS_ERR(state))
goto out;
+   ctx->state = state;
if (server->caps & NFS_CAP_POSIX_LOCK)
set_bit(NFS_STATE_POSIX_LOCKS, &state->flags);
 
@@ -2474,7 +2475,6 @@ static int _nfs4_open_and_get_state(stru
if (ret != 0)
goto out;
 
-   ctx->state = state;
if (d_inode(dentry) == state->inode) {
nfs_inode_attach_open_context(ctx);
if (read_seqcount_retry(&sp->so_reclaim_seqcount, seq))




[PATCH 4.4 63/91] w1: dont leak refcount on slave attach failure in w1_attach_slave_device()

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej S. Szmigiero 

commit d2ce4ea1a0b0162e5d2d7e7942ab6f5cc2063d5a upstream.

Near the beginning of w1_attach_slave_device() we increment a w1 master
reference count.
Later, when we are going to exit this function without actually attaching
a slave device (due to failure of __w1_attach_slave_device()) we need to
decrement this reference count back.

Signed-off-by: Maciej S. Szmigiero 
Fixes: 9fcbbac5ded489 ("w1: process w1 netlink commands in w1_process thread")
Cc: Evgeniy Polyakov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/w1/w1.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -763,6 +763,7 @@ int w1_attach_slave_device(struct w1_mas
dev_err(&dev->dev, "%s: Attaching %s failed.\n", __func__,
 sl->name);
w1_family_put(sl->family);
+   atomic_dec(&sl->master->refcnt);
kfree(sl);
return err;
}




[PATCH 4.4 62/91] can: usb_8dev: Fix memory leak of priv->cmd_msg_buffer

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Marc Kleine-Budde 

commit 7c42631376306fb3f34d51fda546b50a9b6dd6ec upstream.

The priv->cmd_msg_buffer is allocated in the probe function, but never
kfree()ed. This patch converts the kzalloc() to resource-managed
kzalloc.

Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/usb/usb_8dev.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -954,8 +954,8 @@ static int usb_8dev_probe(struct usb_int
for (i = 0; i < MAX_TX_URBS; i++)
priv->tx_contexts[i].echo_index = MAX_TX_URBS;
 
-   priv->cmd_msg_buffer = kzalloc(sizeof(struct usb_8dev_cmd_msg),
- GFP_KERNEL);
+   priv->cmd_msg_buffer = devm_kzalloc(&intf->dev, sizeof(struct 
usb_8dev_cmd_msg),
+   GFP_KERNEL);
if (!priv->cmd_msg_buffer)
goto cleanup_candev;
 
@@ -969,7 +969,7 @@ static int usb_8dev_probe(struct usb_int
if (err) {
netdev_err(netdev,
"couldn't register CAN device: %d\n", err);
-   goto cleanup_cmd_msg_buffer;
+   goto cleanup_candev;
}
 
err = usb_8dev_cmd_version(priv, &version);
@@ -990,9 +990,6 @@ static int usb_8dev_probe(struct usb_int
 cleanup_unregister_candev:
unregister_netdev(priv->netdev);
 
-cleanup_cmd_msg_buffer:
-   kfree(priv->cmd_msg_buffer);
-
 cleanup_candev:
free_candev(netdev);
 




[PATCH 4.4 88/91] powerpc/xmon: Fix data-breakpoint

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Ravi Bangoria 

commit c21a493a2b44650707d06741601894329486f2ad upstream.

Currently xmon data-breakpoint feature is broken.

Whenever there is a watchpoint match occurs, hw_breakpoint_handler will
be called by do_break via notifier chains mechanism. If watchpoint is
registered by xmon, hw_breakpoint_handler won't find any associated
perf_event and returns immediately with NOTIFY_STOP. Similarly, do_break
also returns without notifying to xmon.

Solve this by returning NOTIFY_DONE when hw_breakpoint_handler does not
find any perf_event associated with matched watchpoint, rather than
NOTIFY_STOP, which tells the core code to continue calling the other
breakpoint handlers including the xmon one.

Signed-off-by: Ravi Bangoria 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/powerpc/kernel/hw_breakpoint.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -227,8 +227,10 @@ int __kprobes hw_breakpoint_handler(stru
rcu_read_lock();
 
bp = __this_cpu_read(bp_per_reg);
-   if (!bp)
+   if (!bp) {
+   rc = NOTIFY_DONE;
goto out;
+   }
info = counter_arch_bp(bp);
 
/*




[PATCH 4.4 68/91] hv: allocate synic pages for all present CPUs

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Vitaly Kuznetsov 

commit 421b8f20d3c381b215f988b42428f56fc3b82405 upstream.

It may happen that not all CPUs are online when we do hv_synic_alloc() and
in case more CPUs come online later we may try accessing these allocated
structures.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hv/hv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -422,7 +422,7 @@ int hv_synic_alloc(void)
goto err;
}
 
-   for_each_online_cpu(cpu) {
+   for_each_present_cpu(cpu) {
hv_context.event_dpc[cpu] = kmalloc(size, GFP_ATOMIC);
if (hv_context.event_dpc[cpu] == NULL) {
pr_err("Unable to allocate event dpc\n");
@@ -485,7 +485,7 @@ void hv_synic_free(void)
int cpu;
 
kfree(hv_context.hv_numa_map);
-   for_each_online_cpu(cpu)
+   for_each_present_cpu(cpu)
hv_synic_free_cpu(cpu);
 }
 




[PATCH 4.9 013/153] [media] am437x-vpfe: always assign bpp variable

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicolas Iooss 

commit 6ebf75774f823ddbdbd10921006989d4df222f4a upstream.

In vpfe_s_fmt(), when the sensor format and the requested format were
the same, bpp was assigned to vpfe->bpp without being initialized first.

Grab the bpp value that is currently used by using __vpfe_get_format()
instead of its wrapper, vpfe_try_fmt().

This use of uninitialized variable has been found by compiling the
kernel with clang.

Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver
support for AM437X")

Signed-off-by: Nicolas Iooss 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/platform/am437x/am437x-vpfe.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -1576,7 +1576,7 @@ static int vpfe_s_fmt(struct file *file,
return -EBUSY;
}
 
-   ret = vpfe_try_fmt(file, priv, &format);
+   ret = __vpfe_get_format(vpfe, &format, &bpp);
if (ret)
return ret;
 




[PATCH 4.9 001/153] MIPS: pic32mzda: Fix linker error for pic32_get_pbclk()

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Purna Chandra Mandal 

commit a726f1d2dd4fee179aa4513176d688ad309de6cc upstream.

Early clock API pic32_get_pbclk() is defined in early_clk.c and used by
time.c and early_console.c. When CONFIG_EARLY_PRINTK isn't set,
early_clk.c isn't compiled and time.c fails to link.

Fix it by compiling early_clk.c always. Also sort files in alphabetical
order.

Fixes: 6e4ad1b41360 ("MIPS: pic32mzda: fix getting timer clock rate.")
Reported-by: Harvey Hunt 
Signed-off-by: Purna Chandra Mandal 
Reviewed-by: Harvey Hunt 
Cc: Ralf Baechle 
Cc: Joshua Henderson 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13383/
Signed-off-by: James Hogan 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/pic32/pic32mzda/Makefile |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/arch/mips/pic32/pic32mzda/Makefile
+++ b/arch/mips/pic32/pic32mzda/Makefile
@@ -2,8 +2,7 @@
 # Joshua Henderson, 
 # Copyright (C) 2015 Microchip Technology, Inc.  All rights reserved.
 #
-obj-y  := init.o time.o config.o
+obj-y  := config.o early_clk.o init.o time.o
 
 obj-$(CONFIG_EARLY_PRINTK) += early_console.o  \
-  early_pin.o  \
-  early_clk.o
+  early_pin.o




[PATCH 4.4 66/91] usb: host: xhci: plat: check hcc_params after add hcd

2017-03-10 Thread Greg Kroah-Hartman
4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: William wu 

commit 5de4e1ea9a731cad195ce5152705c21daef3bbba upstream.

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add primary hcd.

Signed-off-by: William wu 
Acked-by: Roger Quadros 
Fixes: 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them")
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -162,9 +162,6 @@ static int xhci_plat_probe(struct platfo
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
hcd->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
if (IS_ERR(hcd->usb_phy)) {
ret = PTR_ERR(hcd->usb_phy);
@@ -181,6 +178,9 @@ static int xhci_plat_probe(struct platfo
if (ret)
goto disable_usb_phy;
 
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto dealloc_usb2_hcd;




[PATCH 4.9 015/153] [media] media: fix dm1105.c build error

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

commit e3bb3cddd177550d63a3e4909cf1a7782f13414d upstream.

Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and
CONFIG_DVB_DM1105=y.

drivers/built-in.o: In function `dm1105_probe':
dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Cc: Javier Martinez Canillas 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/pci/dm1105/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/pci/dm1105/Kconfig
+++ b/drivers/media/pci/dm1105/Kconfig
@@ -1,6 +1,6 @@
 config DVB_DM1105
tristate "SDMC DM1105 based PCI cards"
-   depends on DVB_CORE && PCI && I2C
+   depends on DVB_CORE && PCI && I2C && I2C_ALGOBIT
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT
select DVB_STV0288 if MEDIA_SUBDRV_AUTOSELECT




[PATCH 4.9 017/153] [media] lirc_dev: LIRC_{G,S}ET_REC_MODE do not work

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit bd291208d7f5d6b2d6a033fee449a429230b06df upstream.

Since "273b902 [media] lirc_dev: use LIRC_CAN_REC() define" these
ioctls no longer work.

Signed-off-by: Sean Young 
Reviewed-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/rc/lirc_dev.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -589,7 +589,7 @@ long lirc_dev_fop_ioctl(struct file *fil
result = put_user(ir->d.features, (__u32 __user *)arg);
break;
case LIRC_GET_REC_MODE:
-   if (LIRC_CAN_REC(ir->d.features)) {
+   if (!LIRC_CAN_REC(ir->d.features)) {
result = -ENOTTY;
break;
}
@@ -599,7 +599,7 @@ long lirc_dev_fop_ioctl(struct file *fil
  (__u32 __user *)arg);
break;
case LIRC_SET_REC_MODE:
-   if (LIRC_CAN_REC(ir->d.features)) {
+   if (!LIRC_CAN_REC(ir->d.features)) {
result = -ENOTTY;
break;
}




[PATCH 4.9 018/153] [media] media: Properly pass through media entity types in entity enumeration

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Sakari Ailus 

commit 98d85f3cb912fde14593ead54dea4c1a00b3966f upstream.

When the functions replaced media entity types, the range which was
allowed for the types was incorrect. This meant that media entity types
for specific devices were not passed correctly to the userspace through
MEDIA_IOC_ENUM_ENTITIES. Fix it.

Fixes: commit b2cd27448b33 ("[media] media-device: map new functions into old 
types for legacy API")
Reported-and-tested-by: Antti Laakso 

Signed-off-by: Sakari Ailus 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -130,7 +130,7 @@ static long media_device_enum_entities(s
 * old range.
 */
if (ent->function < MEDIA_ENT_F_OLD_BASE ||
-   ent->function > MEDIA_ENT_T_DEVNODE_UNKNOWN) {
+   ent->function > MEDIA_ENT_F_TUNER) {
if (is_media_entity_v4l2_subdev(ent))
entd->type = MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN;
else if (ent->function != MEDIA_ENT_F_IO_V4L)




update timer frequencies

2017-03-10 Thread Vlad Zakharov
Hello,

I am trying to implement a cpufreq driver for ARC CPUs. 
The point is that ARC timers (including those are used for timekeeping) are 
driven by the same clock as ARC CPU core(s).

So if cpufreq driver changes CPU frequency timers frequency also updates. 
I added notification handler to ARC timer driver were I attempted to update 
clocksource frequency with
"__clocksource_update_freq_hz()" but I found that actually the frequency didn't 
update. 

During my further investigation I mentioned that timekeeping framework doesn't 
allow frequency changes for more than
11%. This is quiet frustratingly: ARC cores supports such adjustments 
themselves but current framework API doesn't give
us a chance to use this functionality and in fact it even forbids CPU frequency 
changes in runtime at all.

Maybe I am mistaken and there is some way to get this going? Or maybe we can 
add some minor changes to timekeeping
framework to resolve this issue (special flag that allows such changes or 
something like this?).

Thanks.

-- 
Best regards,
Vlad Zakharov 

[PATCH 4.9 022/153] ARM: dts: at91: Enable DMA on sama5d4_xplained console

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexandre Belloni 

commit ef8d02d4a2c36f7a93e74c95a9c419353b310117 upstream.

Enable DMA on usart3 to get a more reliable console. This is especially
useful for automation and kernelci were a kernel with PROVE_LOCKING enabled
is quite susceptible to character loss, resulting in tests failure.

Acked-by: Nicolas Ferre 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/boot/dts/at91-sama5d4_xplained.dts |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -110,6 +110,8 @@
};
 
usart3: serial@fc00c000 {
+   atmel,use-dma-rx;
+   atmel,use-dma-tx;
status = "okay";
};
 




[PATCH 4.9 007/153] MIPS: Prevent unaligned accesses during stack unwinding

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Paul Burton 

commit a3552dace7d1d0cabf573e88fc3025cb90c4a601 upstream.

During stack unwinding we call a number of functions to determine what
type of instruction we're looking at. The union mips_instruction pointer
provided to them may be pointing at a 2 byte, but not 4 byte, aligned
address & we thus cannot directly access the 4 byte wide members of the
union mips_instruction. To avoid this is_ra_save_ins() copies the
required half-words of the microMIPS instruction to a correctly aligned
union mips_instruction on the stack, which it can then access safely.
The is_jump_ins() & is_sp_move_ins() functions do not correctly perform
this temporary copy, and instead attempt to directly dereference 4 byte
fields which may be misaligned and lead to an address exception.

Fix this by copying the instruction halfwords to a temporary union
mips_instruction in get_frame_info() such that we can provide a 4 byte
aligned union mips_instruction to the is_*_ins() functions and they do
not need to deal with misalignment themselves.

Signed-off-by: Paul Burton 
Fixes: 34c2f668d0f6 ("MIPS: microMIPS: Add unaligned access support.")
Cc: Leonid Yegoshin 
Cc: linux-m...@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14529/
Signed-off-by: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/process.c |   70 ++---
 1 file changed, 35 insertions(+), 35 deletions(-)

--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -198,8 +198,6 @@ struct mips_frame_info {
 static inline int is_ra_save_ins(union mips_instruction *ip)
 {
 #ifdef CONFIG_CPU_MICROMIPS
-   union mips_instruction mmi;
-
/*
 * swsp ra,offset
 * swm16 reglist,offset(sp)
@@ -209,23 +207,20 @@ static inline int is_ra_save_ins(union m
 *
 * microMIPS is way more fun...
 */
-   if (mm_insn_16bit(ip->halfword[0])) {
-   mmi.word = (ip->halfword[0] << 16);
-   return (mmi.mm16_r5_format.opcode == mm_swsp16_op &&
-   mmi.mm16_r5_format.rt == 31) ||
-  (mmi.mm16_m_format.opcode == mm_pool16c_op &&
-   mmi.mm16_m_format.func == mm_swm16_op);
+   if (mm_insn_16bit(ip->halfword[1])) {
+   return (ip->mm16_r5_format.opcode == mm_swsp16_op &&
+   ip->mm16_r5_format.rt == 31) ||
+  (ip->mm16_m_format.opcode == mm_pool16c_op &&
+   ip->mm16_m_format.func == mm_swm16_op);
}
else {
-   mmi.halfword[0] = ip->halfword[1];
-   mmi.halfword[1] = ip->halfword[0];
-   return (mmi.mm_m_format.opcode == mm_pool32b_op &&
-   mmi.mm_m_format.rd > 9 &&
-   mmi.mm_m_format.base == 29 &&
-   mmi.mm_m_format.func == mm_swm32_func) ||
-  (mmi.i_format.opcode == mm_sw32_op &&
-   mmi.i_format.rs == 29 &&
-   mmi.i_format.rt == 31);
+   return (ip->mm_m_format.opcode == mm_pool32b_op &&
+   ip->mm_m_format.rd > 9 &&
+   ip->mm_m_format.base == 29 &&
+   ip->mm_m_format.func == mm_swm32_func) ||
+  (ip->i_format.opcode == mm_sw32_op &&
+   ip->i_format.rs == 29 &&
+   ip->i_format.rt == 31);
}
 #else
/* sw / sd $ra, offset($sp) */
@@ -246,12 +241,8 @@ static inline int is_jump_ins(union mips
 *
 * microMIPS is kind of more fun...
 */
-   union mips_instruction mmi;
-
-   mmi.word = (ip->halfword[0] << 16);
-
-   if ((mmi.mm16_r5_format.opcode == mm_pool16c_op &&
-   (mmi.mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op) ||
+   if ((ip->mm16_r5_format.opcode == mm_pool16c_op &&
+   (ip->mm16_r5_format.rt & mm_jr16_op) == mm_jr16_op) ||
ip->j_format.opcode == mm_jal32_op)
return 1;
if (ip->r_format.opcode != mm_pool32a_op ||
@@ -280,15 +271,13 @@ static inline int is_sp_move_ins(union m
 *
 * microMIPS is not more fun...
 */
-   if (mm_insn_16bit(ip->halfword[0])) {
-   union mips_instruction mmi;
-
-   mmi.word = (ip->halfword[0] << 16);
-   return (mmi.mm16_r3_format.opcode == mm_pool16d_op &&
-   mmi.mm16_r3_format.simmediate && mm_addiusp_func) ||
-  (mmi.mm16_r5_format.opcode == mm_pool16d_op &&
-   mmi.mm16_r5_format.rt == 29);
+   if (mm_insn_16bit(ip->halfword[1])) {
+   return (ip->mm16_r3_format.opcode == mm_pool16d_op &&
+   ip->mm16_r3_format.simmediate && mm_addiusp_func) ||
+  (ip->mm16_r5_format.opcode == 

[PATCH 4.9 034/153] staging/lustre/lnet: Fix allocation size for sv_cpt_data

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Oleg Drokin 

commit dc7ffefdcc28a45214aa707fdc3df6a5e611ba09 upstream.

This is unbreaking another of those "stealth" janitor
patches that got in and subtly broke some things.

sv_cpt_data is a pointer to pointer, so need to
dereference it twice to allocate the correct structure size.

Fixes: 9899cb68c6c2 ("Staging: lustre: rpc: Use sizeof type *pointer instead of 
sizeof type.")
CC: Sandhya Bankar 
Signed-off-by: Oleg Drokin 
Reviewed-by: James Simmons 
Reviewed-by: Doug Oucharek 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/lustre/lnet/selftest/rpc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/lustre/lnet/selftest/rpc.c
+++ b/drivers/staging/lustre/lnet/selftest/rpc.c
@@ -252,7 +252,7 @@ srpc_service_init(struct srpc_service *s
svc->sv_shuttingdown = 0;
 
svc->sv_cpt_data = cfs_percpt_alloc(lnet_cpt_table(),
-   sizeof(*svc->sv_cpt_data));
+   sizeof(**svc->sv_cpt_data));
if (!svc->sv_cpt_data)
return -ENOMEM;
 




[PATCH 4.9 035/153] staging: rtl: fix possible NULL pointer dereference

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnd Bergmann 

commit 6e017006022abfea5d2466cad936065f45763ad1 upstream.

gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with
a destination argument that an earlier function call may have set to NULL:

staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr':
staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where 
non-null expected [-Wnonnull]
staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr':
staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null 
expected [-Wnonnull]

I'm fixing this by adding a NULL pointer check and returning failure
from the function, which is hopefully already handled properly.

This seems to date back to when the drivers were originally added,
so backporting the fix to stable seems appropriate. There are other
related realtek drivers in the kernel, but none of them contain a
function with a similar name or produce this warning.

Fixes: 1cc18a22b96b ("staging: r8188eu: Add files for new driver - part 5")
Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline 
kernel")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/rtl8188eu/core/rtw_recv.c |3 +++
 drivers/staging/rtl8712/rtl871x_recv.c|7 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -1383,6 +1383,9 @@ static int wlanhdr_to_ethhdr(struct recv
ptr = recvframe_pull(precvframe, (rmv_len-sizeof(struct ethhdr) 
+ (bsnaphdr ? 2 : 0)));
}
 
+   if (!ptr)
+   return _FAIL;
+
memcpy(ptr, pattrib->dst, ETH_ALEN);
memcpy(ptr+ETH_ALEN, pattrib->src, ETH_ALEN);
 
--- a/drivers/staging/rtl8712/rtl871x_recv.c
+++ b/drivers/staging/rtl8712/rtl871x_recv.c
@@ -643,11 +643,16 @@ sint r8712_wlanhdr_to_ethhdr(union recv_
/* append rx status for mp test packets */
ptr = recvframe_pull(precvframe, (rmv_len -
  sizeof(struct ethhdr) + 2) - 24);
+   if (!ptr)
+   return _FAIL;
memcpy(ptr, get_rxmem(precvframe), 24);
ptr += 24;
-   } else
+   } else {
ptr = recvframe_pull(precvframe, (rmv_len -
  sizeof(struct ethhdr) + (bsnaphdr ? 2 : 0)));
+   if (!ptr)
+   return _FAIL;
+   }
 
memcpy(ptr, pattrib->dst, ETH_ALEN);
memcpy(ptr + ETH_ALEN, pattrib->src, ETH_ALEN);




[PATCH 4.9 038/153] tpm_tis: fix the error handling of init_tis()

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Wei Yongjun 

commit 5939eaf4f9d432586dd2cdeea778506471e8088e upstream.

Add the missing platform_driver_unregister() and remove the duplicate
platform_device_unregister(force_pdev) in the error handling case.

Fixes: 00194826e6be ("tpm_tis: Clean up the force=1 module parameter")
Signed-off-by: Wei Yongjun 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/char/tpm/tpm_tis.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -421,7 +421,7 @@ err_pnp:
acpi_bus_unregister_driver(&tis_acpi_driver);
 err_acpi:
 #endif
-   platform_device_unregister(force_pdev);
+   platform_driver_unregister(&tis_drv);
 err_platform:
if (force_pdev)
platform_device_unregister(force_pdev);




[PATCH 4.9 039/153] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: CQ Tang 

commit aaa59306b0b7e0ca4ba92cc04c5db101cbb1c096 upstream.

Some of the macros are incorrect with wrong bit-shifts resulting in picking
the incorrect invalidation granularity. Incorrect Source-ID in extended
devtlb invalidation caused device side errors.

To: Joerg Roedel 
To: David Woodhouse 
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: CQ Tang 
Cc: Ashok Raj 

Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support")
Signed-off-by: CQ Tang 
Signed-off-by: Ashok Raj 
Tested-by: CQ Tang 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/intel-iommu.h |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -153,8 +153,8 @@ static inline void dmar_writeq(void __io
 #define DMA_TLB_GLOBAL_FLUSH (((u64)1) << 60)
 #define DMA_TLB_DSI_FLUSH (((u64)2) << 60)
 #define DMA_TLB_PSI_FLUSH (((u64)3) << 60)
-#define DMA_TLB_IIRG(type) ((type >> 60) & 7)
-#define DMA_TLB_IAIG(val) (((val) >> 57) & 7)
+#define DMA_TLB_IIRG(type) ((type >> 60) & 3)
+#define DMA_TLB_IAIG(val) (((val) >> 57) & 3)
 #define DMA_TLB_READ_DRAIN (((u64)1) << 49)
 #define DMA_TLB_WRITE_DRAIN (((u64)1) << 48)
 #define DMA_TLB_DID(id)(((u64)((id) & 0x)) << 32)
@@ -164,9 +164,9 @@ static inline void dmar_writeq(void __io
 
 /* INVALID_DESC */
 #define DMA_CCMD_INVL_GRANU_OFFSET  61
-#define DMA_ID_TLB_GLOBAL_FLUSH(((u64)1) << 3)
-#define DMA_ID_TLB_DSI_FLUSH   (((u64)2) << 3)
-#define DMA_ID_TLB_PSI_FLUSH   (((u64)3) << 3)
+#define DMA_ID_TLB_GLOBAL_FLUSH(((u64)1) << 4)
+#define DMA_ID_TLB_DSI_FLUSH   (((u64)2) << 4)
+#define DMA_ID_TLB_PSI_FLUSH   (((u64)3) << 4)
 #define DMA_ID_TLB_READ_DRAIN  (((u64)1) << 7)
 #define DMA_ID_TLB_WRITE_DRAIN (((u64)1) << 6)
 #define DMA_ID_TLB_DID(id) (((u64)((id & 0x) << 16)))
@@ -316,8 +316,8 @@ enum {
 #define QI_DEV_EIOTLB_SIZE (((u64)1) << 11)
 #define QI_DEV_EIOTLB_GLOB(g)  ((u64)g)
 #define QI_DEV_EIOTLB_PASID(p) (((u64)p) << 32)
-#define QI_DEV_EIOTLB_SID(sid) ((u64)((sid) & 0x) << 32)
-#define QI_DEV_EIOTLB_QDEP(qd) (((qd) & 0x1f) << 16)
+#define QI_DEV_EIOTLB_SID(sid) ((u64)((sid) & 0x) << 16)
+#define QI_DEV_EIOTLB_QDEP(qd) ((u64)((qd) & 0x1f) << 4)
 #define QI_DEV_EIOTLB_MAX_INVS 32
 
 #define QI_PGRP_IDX(idx)   (((u64)(idx)) << 55)




[PATCH 4.9 040/153] iommu/vt-d: Tylersburg isoch identity map check is done too late.

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ashok Raj 

commit 21e722c4c8377b5bc82ad058fed12165af739c1b upstream.

The check to set identity map for tylersburg is done too late. It needs
to be done before the check for identity_map domain is done.

To: Joerg Roedel 
To: David Woodhouse 
Cc: io...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: Ashok Raj 

Fixes: 86080ccc22 ("iommu/vt-d: Allocate si_domain in init_dmars()")
Signed-off-by: Ashok Raj 
Reported-by: Yunhong Jiang 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/iommu/intel-iommu.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3325,13 +3325,14 @@ static int __init init_dmars(void)
iommu_identity_mapping |= IDENTMAP_GFX;
 #endif
 
+   check_tylersburg_isoch();
+
if (iommu_identity_mapping) {
ret = si_domain_init(hw_pass_through);
if (ret)
goto free_iommu;
}
 
-   check_tylersburg_isoch();
 
/*
 * If we copied translations from a previous kernel in the kdump




[PATCH 4.9 033/153] staging: greybus: loopback: fix broken udelay

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Johan Hovold 

commit 33b8807a6fe10d0e675e070373a6fad93188 upstream.

The loopback driver allows the user to set a minimum delay of up to one
second to be inserted between test iterations (i.e. request
submissions). The delay is currently specified in microseconds and is
implemented using udelay.

Busy looping for long periods is not just anti-social; udelay must not
be used for delays longer than a few milliseconds due to the risk of
integer overflow.

Replace the broken udelay with a usleep_range with a 100 us range for
short delays (< 20 ms) and otherwise revert to using msleep.

Fixes: b36f04fa9417 ("greybus: loopback: Convert thread delay to microseconds")
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/greybus/loopback.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1051,8 +1051,13 @@ static int gb_loopback_fn(void *data)
gb_loopback_calculate_stats(gb, !!error);
}
gb->send_count++;
-   if (us_wait)
-   udelay(us_wait);
+
+   if (us_wait) {
+   if (us_wait < 2)
+   usleep_range(us_wait, us_wait + 100);
+   else
+   msleep(us_wait / 1000);
+   }
}
 
gb_pm_runtime_put_autosuspend(bundle);




[PATCH 4.9 050/153] ipc/shm: Fix shmat mmap nil-page protection

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Davidlohr Bueso 

commit 95e91b831f87ac8e1f8ed50c14d709089b4e01b8 upstream.

The issue is described here, with a nice testcase:

https://bugzilla.kernel.org/show_bug.cgi?id=192931

The problem is that shmat() calls do_mmap_pgoff() with MAP_FIXED, and
the address rounded down to 0.  For the regular mmap case, the
protection mentioned above is that the kernel gets to generate the
address -- arch_get_unmapped_area() will always check for MAP_FIXED and
return that address.  So by the time we do security_mmap_addr(0) things
get funky for shmat().

The testcase itself shows that while a regular user crashes, root will
not have a problem attaching a nil-page.  There are two possible fixes
to this.  The first, and which this patch does, is to simply allow root
to crash as well -- this is also regular mmap behavior, ie when hacking
up the testcase and adding mmap(...  |MAP_FIXED).  While this approach
is the safer option, the second alternative is to ignore SHM_RND if the
rounded address is 0, thus only having MAP_SHARED flags.  This makes the
behavior of shmat() identical to the mmap() case.  The downside of this
is obviously user visible, but does make sense in that it maintains
semantics after the round-down wrt 0 address and mmap.

Passes shm related ltp tests.

Link: 
http://lkml.kernel.org/r/1486050195-18629-1-git-send-email-d...@stgolabs.net
Signed-off-by: Davidlohr Bueso 
Reported-by: Gareth Evans 
Cc: Manfred Spraul 
Cc: Michael Kerrisk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 ipc/shm.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1085,8 +1085,8 @@ out_unlock1:
  * "raddr" thing points to kernel space, and there has to be a wrapper around
  * this.
  */
-long do_shmat(int shmid, char __user *shmaddr, int shmflg, ulong *raddr,
- unsigned long shmlba)
+long do_shmat(int shmid, char __user *shmaddr, int shmflg,
+ ulong *raddr, unsigned long shmlba)
 {
struct shmid_kernel *shp;
unsigned long addr;
@@ -1107,8 +1107,13 @@ long do_shmat(int shmid, char __user *sh
goto out;
else if ((addr = (ulong)shmaddr)) {
if (addr & (shmlba - 1)) {
-   if (shmflg & SHM_RND)
-   addr &= ~(shmlba - 1); /* round down */
+   /*
+* Round down to the nearest multiple of shmlba.
+* For sane do_mmap_pgoff() parameters, avoid
+* round downs that trigger nil-page and MAP_FIXED.
+*/
+   if ((shmflg & SHM_RND) && addr >= shmlba)
+   addr &= ~(shmlba - 1);
else
 #ifndef __ARCH_FORCE_SHMLBA
if (addr & ~PAGE_MASK)




[PATCH 4.9 045/153] mm: do not access page->mapping directly on page_endio

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Minchan Kim 

commit dd8416c47715cf324c9a16f13273f9fda87acfed upstream.

With rw_page, page_endio is used for completing IO on a page and it
propagates write error to the address space if the IO fails.  The
problem is it accesses page->mapping directly which might be okay for
file-backed pages but it shouldn't for anonymous page.  Otherwise, it
can corrupt one of field from anon_vma under us and system goes panic
randomly.

swap_writepage
  bdev_writepage
ops->rw_page

I encountered the BUG during developing new zram feature and it was
really hard to figure it out because it made random crash, somtime
mmap_sem lockdep, sometime other places where places never related to
zram/zsmalloc, and not reproducible with some configuration.

When I consider how that bug is subtle and people do fast-swap test with
brd, it's worth to add stable mark, I think.

Fixes: dd6bd0d9c7db ("swap: use bdev_read_page() / bdev_write_page()")
Signed-off-by: Minchan Kim 
Acked-by: Michal Hocko 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/filemap.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -910,9 +910,12 @@ void page_endio(struct page *page, bool
unlock_page(page);
} else {
if (err) {
+   struct address_space *mapping;
+
SetPageError(page);
-   if (page->mapping)
-   mapping_set_error(page->mapping, err);
+   mapping = page_mapping(page);
+   if (mapping)
+   mapping_set_error(mapping, err);
}
end_page_writeback(page);
}




[PATCH 4.9 044/153] mm: vmpressure: fix sending wrong events on underflow

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Vinayak Menon 

commit e1587a4945408faa58d0485002c110eb2454740c upstream.

At the end of a window period, if the reclaimed pages is greater than
scanned, an unsigned underflow can result in a huge pressure value and
thus a critical event.  Reclaimed pages is found to go higher than
scanned because of the addition of reclaimed slab pages to reclaimed in
shrink_node without a corresponding increment to scanned pages.

Minchan Kim mentioned that this can also happen in the case of a THP
page where the scanned is 1 and reclaimed could be 512.

Link: 
http://lkml.kernel.org/r/1486641577-11685-1-git-send-email-vinme...@codeaurora.org
Signed-off-by: Vinayak Menon 
Acked-by: Minchan Kim 
Acked-by: Michal Hocko 
Cc: Johannes Weiner 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Rik van Riel 
Cc: Vladimir Davydov 
Cc: Anton Vorontsov 
Cc: Shiraz Hashim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 mm/vmpressure.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -112,9 +112,16 @@ static enum vmpressure_levels vmpressure
unsigned long reclaimed)
 {
unsigned long scale = scanned + reclaimed;
-   unsigned long pressure;
+   unsigned long pressure = 0;
 
/*
+* reclaimed can be greater than scanned in cases
+* like THP, where the scanned is 1 and reclaimed
+* could be 512
+*/
+   if (reclaimed >= scanned)
+   goto out;
+   /*
 * We calculate the ratio (in percents) of how many pages were
 * scanned vs. reclaimed in a given time frame (window). Note that
 * time is in VM reclaimer's "ticks", i.e. number of pages
@@ -124,6 +131,7 @@ static enum vmpressure_levels vmpressure
pressure = scale - (reclaimed * scale / scanned);
pressure = pressure * 100 / scale;
 
+out:
pr_debug("%s: %3lu  (s: %lu  r: %lu)\n", __func__, pressure,
 scanned, reclaimed);
 




[PATCH 4.9 054/153] dm cache: fix corruption seen when using cache > 2TB

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Joe Thornber 

commit ca763d0a53b264a650342cee206512bc92ac7050 upstream.

A rounding bug due to compiler generated temporary being 32bit was found
in remap_to_cache().  A localized cast in remap_to_cache() fixes the
corruption but this preferred fix (changing from uint32_t to sector_t)
eliminates potential for future rounding errors elsewhere.

Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-cache-target.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -248,7 +248,7 @@ struct cache {
/*
 * Fields for converting from sectors to blocks.
 */
-   uint32_t sectors_per_block;
+   sector_t sectors_per_block;
int sectors_per_block_shift;
 
spinlock_t lock;
@@ -3546,11 +3546,11 @@ static void cache_status(struct dm_targe
 
residency = policy_residency(cache->policy);
 
-   DMEMIT("%u %llu/%llu %u %llu/%llu %u %u %u %u %u %u %lu ",
+   DMEMIT("%u %llu/%llu %llu %llu/%llu %u %u %u %u %u %u %lu ",
   (unsigned)DM_CACHE_METADATA_BLOCK_SIZE,
   (unsigned long long)(nr_blocks_metadata - 
nr_free_blocks_metadata),
   (unsigned long long)nr_blocks_metadata,
-  cache->sectors_per_block,
+  (unsigned long long)cache->sectors_per_block,
   (unsigned long long) from_cblock(residency),
   (unsigned long long) from_cblock(cache->cache_size),
   (unsigned) atomic_read(&cache->stats.read_hit),




[PATCH 4.9 058/153] scsi: storvsc: use tagged SRB requests if supported by the device

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Long Li 

commit 3cd6d3d9b1abab8dcdf0800224ce26daac24eea2 upstream.

Properly set SRB flags when hosting device supports tagged queuing.
This patch improves the performance on Fiber Channel disks.

Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/storvsc_drv.c |9 +
 1 file changed, 9 insertions(+)

--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -136,6 +136,8 @@ struct hv_fc_wwn_packet {
 #define SRB_FLAGS_PORT_DRIVER_RESERVED 0x0F00
 #define SRB_FLAGS_CLASS_DRIVER_RESERVED0xF000
 
+#define SP_UNTAGGED((unsigned char) ~0)
+#define SRB_SIMPLE_TAG_REQUEST 0x20
 
 /*
  * Platform neutral description of a scsi request -
@@ -1451,6 +1453,13 @@ static int storvsc_queuecommand(struct S
vm_srb->win8_extension.srb_flags |=
SRB_FLAGS_DISABLE_SYNCH_TRANSFER;
 
+   if (scmnd->device->tagged_supported) {
+   vm_srb->win8_extension.srb_flags |=
+   (SRB_FLAGS_QUEUE_ACTION_ENABLE | SRB_FLAGS_NO_QUEUE_FREEZE);
+   vm_srb->win8_extension.queue_tag = SP_UNTAGGED;
+   vm_srb->win8_extension.queue_action = SRB_SIMPLE_TAG_REQUEST;
+   }
+
/* Build the SRB */
switch (scmnd->sc_data_direction) {
case DMA_TO_DEVICE:




[PATCH 4.9 060/153] scsi: storvsc: properly set residual data length on errors

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Long Li 

commit 40630f462824ee24bc00d692865c86c3828094e0 upstream.

On I/O errors, the Windows driver doesn't set data_transfer_length
on error conditions other than SRB_STATUS_DATA_OVERRUN.
In these cases we need to set data_transfer_length to 0,
indicating there is no data transferred. On SRB_STATUS_DATA_OVERRUN,
data_transfer_length is set by the Windows driver to the actual data 
transferred.

Reported-by: Shiva Krishna 
Signed-off-by: Long Li 
Reviewed-by: K. Y. Srinivasan 
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/storvsc_drv.c |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -377,6 +377,7 @@ enum storvsc_request_type {
 #define SRB_STATUS_SUCCESS 0x01
 #define SRB_STATUS_ABORTED 0x02
 #define SRB_STATUS_ERROR   0x04
+#define SRB_STATUS_DATA_OVERRUN0x12
 
 #define SRB_STATUS(status) \
(status & ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
@@ -962,6 +963,7 @@ static void storvsc_command_completion(s
struct scsi_cmnd *scmnd = cmd_request->cmd;
struct scsi_sense_hdr sense_hdr;
struct vmscsi_request *vm_srb;
+   u32 data_transfer_length;
struct Scsi_Host *host;
u32 payload_sz = cmd_request->payload_sz;
void *payload = cmd_request->payload;
@@ -969,6 +971,7 @@ static void storvsc_command_completion(s
host = stor_dev->host;
 
vm_srb = &cmd_request->vstor_packet.vm_srb;
+   data_transfer_length = vm_srb->data_transfer_length;
 
scmnd->result = vm_srb->scsi_status;
 
@@ -982,13 +985,20 @@ static void storvsc_command_completion(s
 &sense_hdr);
}
 
-   if (vm_srb->srb_status != SRB_STATUS_SUCCESS)
+   if (vm_srb->srb_status != SRB_STATUS_SUCCESS) {
storvsc_handle_error(vm_srb, scmnd, host, sense_hdr.asc,
 sense_hdr.ascq);
+   /*
+* The Windows driver set data_transfer_length on
+* SRB_STATUS_DATA_OVERRUN. On other errors, this value
+* is untouched.  In these cases we set it to 0.
+*/
+   if (vm_srb->srb_status != SRB_STATUS_DATA_OVERRUN)
+   data_transfer_length = 0;
+   }
 
scsi_set_resid(scmnd,
-   cmd_request->payload->range.len -
-   vm_srb->data_transfer_length);
+   cmd_request->payload->range.len - data_transfer_length);
 
scmnd->scsi_done(scmnd);
 




[PATCH 4.9 025/153] ALSA: hda - fix Lewisburg audio issue

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jaroslav Kysela 

commit e7480b34ad1ab84a63540b2c884cb92c0764ab74 upstream.

Like for Sunrise Point, the total stream number of Lewisburg's
input and output stream exceeds 15 (GCAP is 0x9701), which will
cause some streams do not work because of the overflow on
SDxCTL.STRM field if using the legacy stream tag allocation method.

Fixes: 5cf92c8b3dc5 ("ALSA: hda - Add Intel Lewisburg device IDs Audio")
Signed-off-by: Jaroslav Kysela 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/hda/hda_intel.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2197,9 +2197,9 @@ static const struct pci_device_id azx_id
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Lewisburg */
{ PCI_DEVICE(0x8086, 0xa1f0),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
{ PCI_DEVICE(0x8086, 0xa270),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Lynx Point-LP */
{ PCI_DEVICE(0x8086, 0x9c20),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },




[PATCH 4.9 057/153] dm raid: fix data corruption on reshape request

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Heinz Mauelshagen 

commit d36a19541fe8f392778ac137d60f9be8dfdd8f9d upstream.

The lvm2 sequence to manage dm-raid constructor flags that trigger a
rebuild or a reshape is defined as:

1) load table with flags (e.g. rebuild/delta_disks/data_offset)
2) clear out the flags in lvm2 metadata
3) store the lvm2 metadata, reload the table to reset the flags
   previously established during the initial load (1) -- in order to
   prevent repeatedly requesting a rebuild or a reshape on activation

Currently, loading an inactive table with rebuild/reshape flags
specified will cause dm-raid to rebuild/reshape on resume and thus start
updating the raid metadata (about the progress).  When the second table
reload, to reset the flags, occurs the constructor accesses the volatile
progress state kept in the raid superblocks.  Because the active mapping
is still processing the rebuild/reshape, that position will be stale by
the time the device is resumed.

In the reshape case, this causes data corruption by processing already
reshaped stripes again.  In the rebuild case, it does _not_ cause data
corruption but instead involves superfluous rebuilds.

Fix by keeping the raid set frozen during the first resume and then
allow the rebuild/reshape during the second resume.

Fixes: 9dbd1aa3a ("dm raid: add reshaping support to the target")
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-raid.c |   12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -3621,6 +3621,8 @@ static int raid_preresume(struct dm_targ
return r;
 }
 
+#define RESUME_STAY_FROZEN_FLAGS (CTR_FLAG_DELTA_DISKS | CTR_FLAG_DATA_OFFSET)
+
 static void raid_resume(struct dm_target *ti)
 {
struct raid_set *rs = ti->private;
@@ -3638,7 +3640,15 @@ static void raid_resume(struct dm_target
mddev->ro = 0;
mddev->in_sync = 0;
 
-   clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
+   /*
+* Keep the RAID set frozen if reshape/rebuild flags are set.
+* The RAID set is unfrozen once the next table load/resume,
+* which clears the reshape/rebuild flags, occurs.
+* This ensures that the constructor for the inactive table
+* retrieves an up-to-date reshape_position.
+*/
+   if (!(rs->ctr_flags & RESUME_STAY_FROZEN_FLAGS))
+   clear_bit(MD_RECOVERY_FROZEN, &mddev->recovery);
 
if (mddev->suspended)
mddev_resume(mddev);




[PATCH 4.9 051/153] ima: fix ima_d_path() possible race with rename

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mimi Zohar 

commit bc15ed663e7e53ee4dc3e60f8d09c93a0528c694 upstream.

On failure to return a pathname from ima_d_path(), a pointer to
dname is returned, which is subsequently used in the IMA measurement
list, the IMA audit records, and other audit logging.  Saving the
pointer to dname for later use has the potential to race with rename.

Intead of returning a pointer to dname on failure, this patch returns
a pointer to a copy of the filename.

Reported-by: Al Viro 
Signed-off-by: Mimi Zohar 
Signed-off-by: Greg Kroah-Hartman 

---
 security/integrity/ima/ima.h  |2 +-
 security/integrity/ima/ima_api.c  |   20 ++--
 security/integrity/ima/ima_main.c |8 +---
 3 files changed, 24 insertions(+), 6 deletions(-)

--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -173,7 +173,7 @@ int ima_store_template(struct ima_templa
   struct inode *inode,
   const unsigned char *filename, int pcr);
 void ima_free_template_entry(struct ima_template_entry *entry);
-const char *ima_d_path(const struct path *path, char **pathbuf);
+const char *ima_d_path(const struct path *path, char **pathbuf, char 
*filename);
 
 /* IMA policy related functions */
 int ima_match_policy(struct inode *inode, enum ima_hooks func, int mask,
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -318,7 +318,17 @@ void ima_audit_measurement(struct integr
iint->flags |= IMA_AUDITED;
 }
 
-const char *ima_d_path(const struct path *path, char **pathbuf)
+/*
+ * ima_d_path - return a pointer to the full pathname
+ *
+ * Attempt to return a pointer to the full pathname for use in the
+ * IMA measurement list, IMA audit records, and auditing logs.
+ *
+ * On failure, return a pointer to a copy of the filename, not dname.
+ * Returning a pointer to dname, could result in using the pointer
+ * after the memory has been freed.
+ */
+const char *ima_d_path(const struct path *path, char **pathbuf, char *namebuf)
 {
char *pathname = NULL;
 
@@ -331,5 +341,11 @@ const char *ima_d_path(const struct path
pathname = NULL;
}
}
-   return pathname ?: (const char *)path->dentry->d_name.name;
+
+   if (!pathname) {
+   strlcpy(namebuf, path->dentry->d_name.name, NAME_MAX);
+   pathname = namebuf;
+   }
+
+   return pathname;
 }
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -83,6 +83,7 @@ static void ima_rdwr_violation_check(str
 const char **pathname)
 {
struct inode *inode = file_inode(file);
+   char filename[NAME_MAX];
fmode_t mode = file->f_mode;
bool send_tomtou = false, send_writers = false;
 
@@ -102,7 +103,7 @@ static void ima_rdwr_violation_check(str
if (!send_tomtou && !send_writers)
return;
 
-   *pathname = ima_d_path(&file->f_path, pathbuf);
+   *pathname = ima_d_path(&file->f_path, pathbuf, filename);
 
if (send_tomtou)
ima_add_violation(file, *pathname, iint,
@@ -161,6 +162,7 @@ static int process_measurement(struct fi
struct integrity_iint_cache *iint = NULL;
struct ima_template_desc *template_desc;
char *pathbuf = NULL;
+   char filename[NAME_MAX];
const char *pathname = NULL;
int rc = -ENOMEM, action, must_appraise;
int pcr = CONFIG_IMA_MEASURE_PCR_IDX;
@@ -239,8 +241,8 @@ static int process_measurement(struct fi
goto out_digsig;
}
 
-   if (!pathname)  /* ima_rdwr_violation possibly pre-fetched */
-   pathname = ima_d_path(&file->f_path, &pathbuf);
+   if (!pathbuf)   /* ima_rdwr_violation possibly pre-fetched */
+   pathname = ima_d_path(&file->f_path, &pathbuf, filename);
 
if (action & IMA_MEASURE)
ima_store_measurement(iint, file, pathname,




[PATCH 4.9 056/153] dm round robin: revert "use percpu repeat_count and current_path"

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mike Snitzer 

commit 37a098e9d10db6e2efc05fe61e3a6ff2e9802c53 upstream.

The sloppy nature of lockless access to percpu pointers
(s->current_path) in rr_select_path(), from multiple threads, is
causing some paths to used more than others -- which results in less
IO performance being observed.

Revert these upstream commits to restore truly symmetric round-robin
IO submission in DM multipath:

b0b477c dm round robin: use percpu 'repeat_count' and 'current_path'
802934b dm round robin: do not use this_cpu_ptr() without having preemption 
disabled

There is no benefit to all this complexity if repeat_count = 1 (which is
the recommended default).

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

---
 drivers/md/dm-round-robin.c |   67 +---
 1 file changed, 14 insertions(+), 53 deletions(-)

--- a/drivers/md/dm-round-robin.c
+++ b/drivers/md/dm-round-robin.c
@@ -17,8 +17,8 @@
 #include 
 
 #define DM_MSG_PREFIX "multipath round-robin"
-#define RR_MIN_IO 1000
-#define RR_VERSION"1.1.0"
+#define RR_MIN_IO 1
+#define RR_VERSION"1.2.0"
 
 /*-
  * Path-handling code, paths are held in lists
@@ -47,44 +47,19 @@ struct selector {
struct list_head valid_paths;
struct list_head invalid_paths;
spinlock_t lock;
-   struct dm_path * __percpu *current_path;
-   struct percpu_counter repeat_count;
 };
 
-static void set_percpu_current_path(struct selector *s, struct dm_path *path)
-{
-   int cpu;
-
-   for_each_possible_cpu(cpu)
-   *per_cpu_ptr(s->current_path, cpu) = path;
-}
-
 static struct selector *alloc_selector(void)
 {
struct selector *s = kmalloc(sizeof(*s), GFP_KERNEL);
 
-   if (!s)
-   return NULL;
-
-   INIT_LIST_HEAD(&s->valid_paths);
-   INIT_LIST_HEAD(&s->invalid_paths);
-   spin_lock_init(&s->lock);
-
-   s->current_path = alloc_percpu(struct dm_path *);
-   if (!s->current_path)
-   goto out_current_path;
-   set_percpu_current_path(s, NULL);
-
-   if (percpu_counter_init(&s->repeat_count, 0, GFP_KERNEL))
-   goto out_repeat_count;
+   if (s) {
+   INIT_LIST_HEAD(&s->valid_paths);
+   INIT_LIST_HEAD(&s->invalid_paths);
+   spin_lock_init(&s->lock);
+   }
 
return s;
-
-out_repeat_count:
-   free_percpu(s->current_path);
-out_current_path:
-   kfree(s);
-   return NULL;;
 }
 
 static int rr_create(struct path_selector *ps, unsigned argc, char **argv)
@@ -105,8 +80,6 @@ static void rr_destroy(struct path_selec
 
free_paths(&s->valid_paths);
free_paths(&s->invalid_paths);
-   free_percpu(s->current_path);
-   percpu_counter_destroy(&s->repeat_count);
kfree(s);
ps->context = NULL;
 }
@@ -157,6 +130,11 @@ static int rr_add_path(struct path_selec
return -EINVAL;
}
 
+   if (repeat_count > 1) {
+   DMWARN_LIMIT("repeat_count > 1 is deprecated, using 1 instead");
+   repeat_count = 1;
+   }
+
/* allocate the path */
pi = kmalloc(sizeof(*pi), GFP_KERNEL);
if (!pi) {
@@ -183,9 +161,6 @@ static void rr_fail_path(struct path_sel
struct path_info *pi = p->pscontext;
 
spin_lock_irqsave(&s->lock, flags);
-   if (p == *this_cpu_ptr(s->current_path))
-   set_percpu_current_path(s, NULL);
-
list_move(&pi->list, &s->invalid_paths);
spin_unlock_irqrestore(&s->lock, flags);
 }
@@ -208,29 +183,15 @@ static struct dm_path *rr_select_path(st
unsigned long flags;
struct selector *s = ps->context;
struct path_info *pi = NULL;
-   struct dm_path *current_path = NULL;
 
-   local_irq_save(flags);
-   current_path = *this_cpu_ptr(s->current_path);
-   if (current_path) {
-   percpu_counter_dec(&s->repeat_count);
-   if (percpu_counter_read_positive(&s->repeat_count) > 0) {
-   local_irq_restore(flags);
-   return current_path;
-   }
-   }
-
-   spin_lock(&s->lock);
+   spin_lock_irqsave(&s->lock, flags);
if (!list_empty(&s->valid_paths)) {
pi = list_entry(s->valid_paths.next, struct path_info, list);
list_move_tail(&pi->list, &s->valid_paths);
-   percpu_counter_set(&s->repeat_count, pi->repeat_count);
-   set_percpu_current_path(s, pi->path);
-   current_path = pi->path;
}
spin_unlock_irqrestore(&s->lock, flags);
 
-   return current_path;
+   return pi ? pi->path : NULL;
 }
 
 static struct path_selector_type rr_ps = {




[PATCH 4.9 026/153] ALSA: timer: Reject user params with too small ticks

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 71321eb3f2d0df4e6c327e0b936eec4458a12054 upstream.

When a user sets a too small ticks with a fine-grained timer like
hrtimer, the kernel tries to fire up the timer irq too frequently.
This may lead to the condensed locks, eventually the kernel spinlock
lockup with warnings.

For avoiding such a situation, we define a lower limit of the
resolution, namely 1ms.  When the user passes a too small tick value
that results in less than that, the kernel returns -EINVAL now.

Reported-by: Dmitry Vyukov 
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/core/timer.c |   18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -1702,9 +1702,21 @@ static int snd_timer_user_params(struct
return -EBADFD;
if (copy_from_user(¶ms, _params, sizeof(params)))
return -EFAULT;
-   if (!(t->hw.flags & SNDRV_TIMER_HW_SLAVE) && params.ticks < 1) {
-   err = -EINVAL;
-   goto _end;
+   if (!(t->hw.flags & SNDRV_TIMER_HW_SLAVE)) {
+   u64 resolution;
+
+   if (params.ticks < 1) {
+   err = -EINVAL;
+   goto _end;
+   }
+
+   /* Don't allow resolution less than 1ms */
+   resolution = snd_timer_resolution(tu->timeri);
+   resolution *= params.ticks;
+   if (resolution < 100) {
+   err = -EINVAL;
+   goto _end;
+   }
}
if (params.queue_size > 0 &&
(params.queue_size < 32 || params.queue_size > 1024)) {




[PATCH 4.9 063/153] power: reset: at91-poweroff: timely shutdown LPDDR memories

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexandre Belloni 

commit 0b0408745e7ff24757cbfd571d69026c0ddb803c upstream.

LPDDR memories can only handle up to 400 uncontrolled power off. Ensure the
proper power off sequence is used before shutting down the platform.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Sebastian Reichel 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/power/reset/Kconfig  |2 -
 drivers/power/reset/at91-poweroff.c  |   54 ++-
 drivers/power/reset/at91-sama5d2_shdwc.c |   49 +++-
 3 files changed, 102 insertions(+), 3 deletions(-)

--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -32,7 +32,7 @@ config POWER_RESET_AT91_RESET
 
 config POWER_RESET_AT91_SAMA5D2_SHDWC
tristate "Atmel AT91 SAMA5D2-Compatible shutdown controller driver"
-   depends on ARCH_AT91 || COMPILE_TEST
+   depends on ARCH_AT91
default SOC_SAMA5
help
  This driver supports the alternate shutdown controller for some Atmel
--- a/drivers/power/reset/at91-poweroff.c
+++ b/drivers/power/reset/at91-poweroff.c
@@ -14,9 +14,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#include 
+
 #define AT91_SHDW_CR   0x00/* Shut Down Control Register */
 #define AT91_SHDW_SHDW BIT(0)  /* Shut Down command */
 #define AT91_SHDW_KEY  (0xa5 << 24)/* KEY Password */
@@ -50,6 +53,7 @@ static const char *shdwc_wakeup_modes[]
 
 static void __iomem *at91_shdwc_base;
 static struct clk *sclk;
+static void __iomem *mpddrc_base;
 
 static void __init at91_wakeup_status(void)
 {
@@ -73,6 +77,29 @@ static void at91_poweroff(void)
writel(AT91_SHDW_KEY | AT91_SHDW_SHDW, at91_shdwc_base + AT91_SHDW_CR);
 }
 
+static void at91_lpddr_poweroff(void)
+{
+   asm volatile(
+   /* Align to cache lines */
+   ".balign 32\n\t"
+
+   /* Ensure AT91_SHDW_CR is in the TLB by reading it */
+   "   ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+   /* Power down SDRAM0 */
+   "   str %1, [%0, #" __stringify(AT91_DDRSDRC_LPR) 
"]\n\t"
+   /* Shutdown CPU */
+   "   str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
+
+   "   b   .\n\t"
+   :
+   : "r" (mpddrc_base),
+ "r" cpu_to_le32(AT91_DDRSDRC_LPDDR2_PWOFF),
+ "r" (at91_shdwc_base),
+ "r" cpu_to_le32(AT91_SHDW_KEY | AT91_SHDW_SHDW)
+   : "r0");
+}
+
 static int at91_poweroff_get_wakeup_mode(struct device_node *np)
 {
const char *pm;
@@ -124,6 +151,8 @@ static void at91_poweroff_dt_set_wakeup_
 static int __init at91_poweroff_probe(struct platform_device *pdev)
 {
struct resource *res;
+   struct device_node *np;
+   u32 ddr_type;
int ret;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -150,12 +179,30 @@ static int __init at91_poweroff_probe(st
 
pm_power_off = at91_poweroff;
 
+   np = of_find_compatible_node(NULL, NULL, "atmel,sama5d3-ddramc");
+   if (!np)
+   return 0;
+
+   mpddrc_base = of_iomap(np, 0);
+   of_node_put(np);
+
+   if (!mpddrc_base)
+   return 0;
+
+   ddr_type = readl(mpddrc_base + AT91_DDRSDRC_MDR) & AT91_DDRSDRC_MD;
+   if ((ddr_type == AT91_DDRSDRC_MD_LPDDR2) ||
+   (ddr_type == AT91_DDRSDRC_MD_LPDDR3))
+   pm_power_off = at91_lpddr_poweroff;
+   else
+   iounmap(mpddrc_base);
+
return 0;
 }
 
 static int __exit at91_poweroff_remove(struct platform_device *pdev)
 {
-   if (pm_power_off == at91_poweroff)
+   if (pm_power_off == at91_poweroff ||
+   pm_power_off == at91_lpddr_poweroff)
pm_power_off = NULL;
 
clk_disable_unprepare(sclk);
@@ -163,6 +210,11 @@ static int __exit at91_poweroff_remove(s
return 0;
 }
 
+static const struct of_device_id at91_ramc_of_match[] = {
+   { .compatible = "atmel,sama5d3-ddramc", },
+   { /* sentinel */ }
+};
+
 static const struct of_device_id at91_poweroff_of_match[] = {
{ .compatible = "atmel,at91sam9260-shdwc", },
{ .compatible = "atmel,at91sam9rl-shdwc", },
--- a/drivers/power/reset/at91-sama5d2_shdwc.c
+++ b/drivers/power/reset/at91-sama5d2_shdwc.c
@@ -22,9 +22,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
+#include 
+
 #define SLOW_CLOCK_FREQ32768
 
 #define AT91_SHDW_CR   0x00/* Shut Down Control Register */
@@ -75,6 +78,7 @@ struct shdwc {
  */
 static struct shdwc *at91_shdwc;
 static struct clk *sclk;
+static void __iomem *mpddrc_base;
 
 static const unsigned long long sdwc_dbc_period[] = {
0, 3, 32, 512, 4096, 32768,
@@ -108,6 +112,29 @@ static void at

[PATCH 4.9 061/153] scsi: aacraid: Reorder Adapter status check

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Raghava Aditya Renukunta 

commit c421530bf848604e97d0785a03b3fe2c62775083 upstream.

The driver currently checks the SELF_TEST_FAILED first and then
KERNEL_PANIC next. Under error conditions(boot code failure) both
SELF_TEST_FAILED and KERNEL_PANIC can be set at the same time.

The driver has the capability to reset the controller on an KERNEL_PANIC,
but not on SELF_TEST_FAILED.

Fixed by first checking KERNEL_PANIC and then the others.

Fixes: e8b12f0fb835223752 ([SCSI] aacraid: Add new code for PMC-Sierra's SRC 
base controller family)
Signed-off-by: Raghava Aditya Renukunta 
Reviewed-by: David Carroll 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/scsi/aacraid/src.c |   21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

--- a/drivers/scsi/aacraid/src.c
+++ b/drivers/scsi/aacraid/src.c
@@ -414,16 +414,23 @@ static int aac_src_check_health(struct a
u32 status = src_readl(dev, MUnit.OMR);
 
/*
+*  Check to see if the board panic'd.
+*/
+   if (unlikely(status & KERNEL_PANIC))
+   goto err_blink;
+
+   /*
 *  Check to see if the board failed any self tests.
 */
if (unlikely(status & SELF_TEST_FAILED))
-   return -1;
+   goto err_out;
 
/*
-*  Check to see if the board panic'd.
+*  Check to see if the board failed any self tests.
 */
-   if (unlikely(status & KERNEL_PANIC))
-   return (status >> 16) & 0xFF;
+   if (unlikely(status & MONITOR_PANIC))
+   goto err_out;
+
/*
 *  Wait for the adapter to be up and running.
 */
@@ -433,6 +440,12 @@ static int aac_src_check_health(struct a
 *  Everything is OK
 */
return 0;
+
+err_out:
+   return -1;
+
+err_blink:
+   return (status > 16) & 0xFF;
 }
 
 /**




[PATCH 4.9 029/153] ALSA: hda - Add subwoofer support for Dell Inspiron 17 7000 Gaming

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 493de342748cc6f52938096f5480cf291da58a0b upstream.

Dell Inspiron 17 7000 Gaming laptop needs a similar quirk like
Inspiron 7599 to support its subwoofer speaker.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194191
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

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

--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5577,6 +5577,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x0725, "Dell Inspiron 3162", 
ALC255_FIXUP_DELL_SPK_NOISE),
SND_PCI_QUIRK(0x1028, 0x075b, "Dell XPS 13 9360", 
ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
SND_PCI_QUIRK(0x1028, 0x075d, "Dell AIO", ALC298_FIXUP_SPK_VOLUME),
+   SND_PCI_QUIRK(0x1028, 0x0798, "Dell Inspiron 17 7000 Gaming", 
ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", 
ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x103c, 0x1586, "HP", ALC269_FIXUP_HP_MUTE_LED_MIC2),




[PATCH 4.9 027/153] ALSA: ctxfi: Fallback DMA mask to 32bit

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Takashi Iwai 

commit 15c75b09f8d190f89ab4db463b87d411ca349dfe upstream.

Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit
architectures, and bails out if it fails.  This causes a problem on
some platforms since the 64bit DMA isn't always guaranteed.  We should
fall back to the default 32bit DMA when 64bit DMA fails.

Fixes: 6d74b86d3c0f ("ALSA: ctxfi - Allow 64bit DMA")
Signed-off-by: Takashi Iwai 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/pci/ctxfi/cthw20k1.c |   19 ++-
 sound/pci/ctxfi/cthw20k2.c |   19 ++-
 2 files changed, 12 insertions(+), 26 deletions(-)

--- a/sound/pci/ctxfi/cthw20k1.c
+++ b/sound/pci/ctxfi/cthw20k1.c
@@ -27,12 +27,6 @@
 #include "cthw20k1.h"
 #include "ct20k1reg.h"
 
-#if BITS_PER_LONG == 32
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(32) /* 32 bit PTE */
-#else
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(64) /* 64 bit PTE */
-#endif
-
 struct hw20k1 {
struct hw hw;
spinlock_t reg_20k1_lock;
@@ -1904,19 +1898,18 @@ static int hw_card_start(struct hw *hw)
 {
int err;
struct pci_dev *pci = hw->pci;
+   const unsigned int dma_bits = BITS_PER_LONG;
 
err = pci_enable_device(pci);
if (err < 0)
return err;
 
/* Set DMA transfer mask */
-   if (dma_set_mask(&pci->dev, CT_XFI_DMA_MASK) < 0 ||
-   dma_set_coherent_mask(&pci->dev, CT_XFI_DMA_MASK) < 0) {
-   dev_err(hw->card->dev,
-   "architecture does not support PCI busmaster DMA with 
mask 0x%llx\n",
-   CT_XFI_DMA_MASK);
-   err = -ENXIO;
-   goto error1;
+   if (dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(dma_bits));
+   } else {
+   dma_set_mask(&pci->dev, DMA_BIT_MASK(32));
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(32));
}
 
if (!hw->io_base) {
--- a/sound/pci/ctxfi/cthw20k2.c
+++ b/sound/pci/ctxfi/cthw20k2.c
@@ -26,12 +26,6 @@
 #include "cthw20k2.h"
 #include "ct20k2reg.h"
 
-#if BITS_PER_LONG == 32
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(32) /* 32 bit PTE */
-#else
-#define CT_XFI_DMA_MASKDMA_BIT_MASK(64) /* 64 bit PTE */
-#endif
-
 struct hw20k2 {
struct hw hw;
/* for i2c */
@@ -2029,19 +2023,18 @@ static int hw_card_start(struct hw *hw)
int err = 0;
struct pci_dev *pci = hw->pci;
unsigned int gctl;
+   const unsigned int dma_bits = BITS_PER_LONG;
 
err = pci_enable_device(pci);
if (err < 0)
return err;
 
/* Set DMA transfer mask */
-   if (dma_set_mask(&pci->dev, CT_XFI_DMA_MASK) < 0 ||
-   dma_set_coherent_mask(&pci->dev, CT_XFI_DMA_MASK) < 0) {
-   dev_err(hw->card->dev,
-   "architecture does not support PCI busmaster DMA with 
mask 0x%llx\n",
-   CT_XFI_DMA_MASK);
-   err = -ENXIO;
-   goto error1;
+   if (!dma_set_mask(&pci->dev, DMA_BIT_MASK(dma_bits))) {
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(dma_bits));
+   } else {
+   dma_set_mask(&pci->dev, DMA_BIT_MASK(32));
+   dma_set_coherent_mask(&pci->dev, DMA_BIT_MASK(32));
}
 
if (!hw->io_base) {




[PATCH 4.9 077/153] mei: remove support for broken parallel read

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Alexander Usyskin 

commit cb97fbbcac15982406e0c74cd5512a8b6fcf10b3 upstream.

Parallel reads from multiple threads on a file descriptor
are not well defined and racy. It is safer to return to original
behavior and simply fail the additional read.
The solution is to remove request for next read credit.

Fixes: ff1586a7ea57 ("mei: enqueue consecutive reads")
Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/misc/mei/main.c |   48 ++--
 1 file changed, 26 insertions(+), 22 deletions(-)

--- a/drivers/misc/mei/main.c
+++ b/drivers/misc/mei/main.c
@@ -182,32 +182,36 @@ static ssize_t mei_read(struct file *fil
goto out;
}
 
-   if (rets == -EBUSY &&
-   !mei_cl_enqueue_ctrl_wr_cb(cl, length, MEI_FOP_READ, file)) {
-   rets = -ENOMEM;
-   goto out;
+
+again:
+   mutex_unlock(&dev->device_lock);
+   if (wait_event_interruptible(cl->rx_wait,
+!list_empty(&cl->rd_completed) ||
+!mei_cl_is_connected(cl))) {
+   if (signal_pending(current))
+   return -EINTR;
+   return -ERESTARTSYS;
}
+   mutex_lock(&dev->device_lock);
 
-   do {
-   mutex_unlock(&dev->device_lock);
+   if (!mei_cl_is_connected(cl)) {
+   rets = -ENODEV;
+   goto out;
+   }
 
-   if (wait_event_interruptible(cl->rx_wait,
-(!list_empty(&cl->rd_completed)) ||
-(!mei_cl_is_connected(cl {
-
-   if (signal_pending(current))
-   return -EINTR;
-   return -ERESTARTSYS;
-   }
-
-   mutex_lock(&dev->device_lock);
-   if (!mei_cl_is_connected(cl)) {
-   rets = -ENODEV;
-   goto out;
-   }
+   cb = mei_cl_read_cb(cl, file);
+   if (!cb) {
+   /*
+* For amthif all the waiters are woken up,
+* but only fp with matching cb->fp get the cb,
+* the others have to return to wait on read.
+*/
+   if (cl == &dev->iamthif_cl)
+   goto again;
 
-   cb = mei_cl_read_cb(cl, file);
-   } while (!cb);
+   rets = 0;
+   goto out;
+   }
 
 copy_buffer:
/* now copy the data to user space */




[PATCH 4.9 081/153] ath9k: use correct OTP register offsets for the AR9340 and AR9550

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Christian Lamparter 

commit c9f1e32600816d695f817477d56490bfc2ba43c6 upstream.

This patch fixes the OTP register definitions for the AR934x and AR9550
WMAC SoC.

Previously, the ath9k driver was unable to initialize the integrated
WMAC on an Aerohive AP121:

| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x0007 != 
0x0004
| ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x0007 != 
0x0004
| ath: phy0: Unable to initialize hardware; initialization status: -5
| ath9k ar934x_wmac: failed to initialize device
| ath9k: probe of ar934x_wmac failed with error -5

It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
definitions contain a typo.

Cc: Gabor Juhos 
Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550"
Signed-off-by: Christian Lamparter 
Signed-off-by: Chris Blake 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -73,13 +73,13 @@
 #define AR9300_OTP_BASE \
((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3 : 0x14000)
 #define AR9300_OTP_STATUS \
-   ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x30018 : 0x15f18)
+   ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x31018 : 0x15f18)
 #define AR9300_OTP_STATUS_TYPE 0x7
 #define AR9300_OTP_STATUS_VALID0x4
 #define AR9300_OTP_STATUS_ACCESS_BUSY  0x2
 #define AR9300_OTP_STATUS_SM_BUSY  0x1
 #define AR9300_OTP_READ_DATA \
-   ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3001c : 0x15f1c)
+   ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3101c : 0x15f1c)
 
 enum targetPowerHTRates {
HT_TARGET_RATE_0_8_16,




[PATCH 4.9 073/153] ext4: fix inline data error paths

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit eb5efbcb762aee4b454b04f7115f73ccbcf8f0ef upstream.

The write_end() function must always unlock the page and drop its ref
count, even on an error.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/inline.c |9 -
 fs/ext4/inode.c  |   20 +++-
 2 files changed, 23 insertions(+), 6 deletions(-)

--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -933,8 +933,15 @@ int ext4_da_write_inline_data_end(struct
  struct page *page)
 {
int i_size_changed = 0;
+   int ret;
 
-   copied = ext4_write_inline_data_end(inode, pos, len, copied, page);
+   ret = ext4_write_inline_data_end(inode, pos, len, copied, page);
+   if (ret < 0) {
+   unlock_page(page);
+   put_page(page);
+   return ret;
+   }
+   copied = ret;
 
/*
 * No need to use i_size_read() here, the i_size
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1324,8 +1324,11 @@ static int ext4_write_end(struct file *f
if (ext4_has_inline_data(inode)) {
ret = ext4_write_inline_data_end(inode, pos, len,
 copied, page);
-   if (ret < 0)
+   if (ret < 0) {
+   unlock_page(page);
+   put_page(page);
goto errout;
+   }
copied = ret;
} else
copied = block_write_end(file, mapping, pos,
@@ -1427,10 +1430,16 @@ static int ext4_journalled_write_end(str
 
BUG_ON(!ext4_handle_valid(handle));
 
-   if (ext4_has_inline_data(inode))
-   copied = ext4_write_inline_data_end(inode, pos, len,
-   copied, page);
-   else if (unlikely(copied < len) && !PageUptodate(page)) {
+   if (ext4_has_inline_data(inode)) {
+   ret = ext4_write_inline_data_end(inode, pos, len,
+copied, page);
+   if (ret < 0) {
+   unlock_page(page);
+   put_page(page);
+   goto errout;
+   }
+   copied = ret;
+   } else if (unlikely(copied < len) && !PageUptodate(page)) {
copied = 0;
ext4_journalled_zero_new_buffers(handle, page, from, to);
} else {
@@ -1465,6 +1474,7 @@ static int ext4_journalled_write_end(str
 */
ext4_orphan_add(handle, inode);
 
+errout:
ret2 = ext4_journal_stop(handle);
if (!ret)
ret = ret2;




[PATCH 4.9 084/153] PCI: altera: Fix TLP_CFG_DW0 for TLP write

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ley Foon Tan 

commit 2a7275a3d867b228216886aae35e1f64291180b1 upstream.

eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage") used
TLP_FMTTYPE_CFGRD* (instead of TLP_FMTTYPE_CFGWR*) for TLP writes, which
causes writing to configuration space to fail.  Fix it by using correct
FMTTYPE for write operation.

Fixes: eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage")
Signed-off-by: Ley Foon Tan 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/pci/host/pcie-altera.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -57,10 +57,14 @@
 #define TLP_WRITE_TAG  0x10
 #define RP_DEVFN   0
 #define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
-#define TLP_CFG_DW0(pcie, bus) \
+#define TLP_CFGRD_DW0(pcie, bus)   \
 bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGRD0 \
: TLP_FMTTYPE_CFGRD1) << 24) |  \
  TLP_PAYLOAD_SIZE)
+#define TLP_CFGWR_DW0(pcie, bus)   \
+bus == pcie->root_bus_nr) ? TLP_FMTTYPE_CFGWR0 \
+   : TLP_FMTTYPE_CFGWR1) << 24) |  \
+ TLP_PAYLOAD_SIZE)
 #define TLP_CFG_DW1(pcie, tag, be) \
 (((TLP_REQ_ID(pcie->root_bus_nr,  RP_DEVFN)) << 16) | (tag << 8) | (be))
 #define TLP_CFG_DW2(bus, devfn, offset)\
@@ -222,7 +226,7 @@ static int tlp_cfg_dword_read(struct alt
 {
u32 headers[TLP_HDR_SIZE];
 
-   headers[0] = TLP_CFG_DW0(pcie, bus);
+   headers[0] = TLP_CFGRD_DW0(pcie, bus);
headers[1] = TLP_CFG_DW1(pcie, TLP_READ_TAG, byte_en);
headers[2] = TLP_CFG_DW2(bus, devfn, where);
 
@@ -237,7 +241,7 @@ static int tlp_cfg_dword_write(struct al
u32 headers[TLP_HDR_SIZE];
int ret;
 
-   headers[0] = TLP_CFG_DW0(pcie, bus);
+   headers[0] = TLP_CFGWR_DW0(pcie, bus);
headers[1] = TLP_CFG_DW1(pcie, TLP_WRITE_TAG, byte_en);
headers[2] = TLP_CFG_DW2(bus, devfn, where);
 




[PATCH 4.9 065/153] jbd2: dont leak modified metadata buffers on an aborted journal

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Theodore Ts'o 

commit e112666b4959b25a8552d63bc564e1059be703e8 upstream.

If the journal has been aborted, we shouldn't mark the underlying
buffer head as dirty, since that will cause the metadata block to get
modified.  And if the journal has been aborted, we shouldn't allow
this since it will almost certainly lead to a corrupted file system.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/jbd2/transaction.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1863,7 +1863,9 @@ static void __jbd2_journal_temp_unlink_b
 
__blist_del_buffer(list, jh);
jh->b_jlist = BJ_None;
-   if (test_clear_buffer_jbddirty(bh))
+   if (transaction && is_journal_aborted(transaction->t_journal))
+   clear_buffer_jbddirty(bh);
+   else if (test_clear_buffer_jbddirty(bh))
mark_buffer_dirty(bh);  /* Expose it to the VM */
 }
 




[PATCH 4.9 090/153] arm/arm64: KVM: Enforce unconditional flush to PoC when mapping to stage-2

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Marc Zyngier 

commit 8f36ebaf21fdae99c091c67e8b6fab33969f2667 upstream.

When we fault in a page, we flush it to the PoC (Point of Coherency)
if the faulting vcpu has its own caches off, so that it can observe
the page we just brought it.

But if the vcpu has its caches on, we skip that step. Bad things
happen when *another* vcpu tries to access that page with its own
caches disabled. At that point, there is no garantee that the
data has made it to the PoC, and we access stale data.

The obvious fix is to always flush to PoC when a page is faulted
in, no matter what the state of the vcpu is.

Fixes: 2d58b733c876 ("arm64: KVM: force cache clean on page fault when caches 
are off")
Reviewed-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm/include/asm/kvm_mmu.h   |9 +
 arch/arm64/include/asm/kvm_mmu.h |3 +--
 2 files changed, 2 insertions(+), 10 deletions(-)

--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -150,18 +150,12 @@ static inline void __coherent_cache_gues
 * and iterate over the range.
 */
 
-   bool need_flush = !vcpu_has_cache_enabled(vcpu) || ipa_uncached;
-
VM_BUG_ON(size & ~PAGE_MASK);
 
-   if (!need_flush && !icache_is_pipt())
-   goto vipt_cache;
-
while (size) {
void *va = kmap_atomic_pfn(pfn);
 
-   if (need_flush)
-   kvm_flush_dcache_to_poc(va, PAGE_SIZE);
+   kvm_flush_dcache_to_poc(va, PAGE_SIZE);
 
if (icache_is_pipt())
__cpuc_coherent_user_range((unsigned long)va,
@@ -173,7 +167,6 @@ static inline void __coherent_cache_gues
kunmap_atomic(va);
}
 
-vipt_cache:
if (!icache_is_pipt() && !icache_is_vivt_asid_tagged()) {
/* any kind of VIPT cache */
__flush_icache_all();
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -241,8 +241,7 @@ static inline void __coherent_cache_gues
 {
void *va = page_address(pfn_to_page(pfn));
 
-   if (!vcpu_has_cache_enabled(vcpu) || ipa_uncached)
-   kvm_flush_dcache_to_poc(va, size);
+   kvm_flush_dcache_to_poc(va, size);
 
if (!icache_is_aliasing()) {/* PIPT */
flush_icache_range((unsigned long)va,




[PATCH 4.9 080/153] ath9k: fix race condition in enabling/disabling IRQs

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Felix Fietkau 

commit 3a5e969bb2f6692a256352649355d56d018d6b88 upstream.

The code currently relies on refcounting to disable IRQs from within the
IRQ handler and re-enabling them again after the tasklet has run.

However, due to race conditions sometimes the IRQ handler might be
called twice, or the tasklet may not run at all (if interrupted in the
middle of a reset).

This can cause nasty imbalances in the irq-disable refcount which will
get the driver permanently stuck until the entire radio has been stopped
and started again (ath_reset will not recover from this).

Instead of using this fragile logic, change the code to ensure that
running the irq handler during tasklet processing is safe, and leave the
refcount untouched.

Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/ath/ath9k/ath9k.h |1 
 drivers/net/wireless/ath/ath9k/init.c  |1 
 drivers/net/wireless/ath/ath9k/mac.c   |   44 +
 drivers/net/wireless/ath/ath9k/mac.h   |1 
 drivers/net/wireless/ath/ath9k/main.c  |   27 
 5 files changed, 48 insertions(+), 26 deletions(-)

--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -959,6 +959,7 @@ struct ath_softc {
struct survey_info *cur_survey;
struct survey_info survey[ATH9K_NUM_CHANNELS];
 
+   spinlock_t intr_lock;
struct tasklet_struct intr_tq;
struct tasklet_struct bcon_tasklet;
struct ath_hw *sc_ah;
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -626,6 +626,7 @@ static int ath9k_init_softc(u16 devid, s
common->bt_ant_diversity = 1;
 
spin_lock_init(&common->cc_lock);
+   spin_lock_init(&sc->intr_lock);
spin_lock_init(&sc->sc_serial_rw);
spin_lock_init(&sc->sc_pm_lock);
spin_lock_init(&sc->chan_lock);
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -805,21 +805,12 @@ void ath9k_hw_disable_interrupts(struct
 }
 EXPORT_SYMBOL(ath9k_hw_disable_interrupts);
 
-void ath9k_hw_enable_interrupts(struct ath_hw *ah)
+static void __ath9k_hw_enable_interrupts(struct ath_hw *ah)
 {
struct ath_common *common = ath9k_hw_common(ah);
u32 sync_default = AR_INTR_SYNC_DEFAULT;
u32 async_mask;
 
-   if (!(ah->imask & ATH9K_INT_GLOBAL))
-   return;
-
-   if (!atomic_inc_and_test(&ah->intr_ref_cnt)) {
-   ath_dbg(common, INTERRUPT, "Do not enable IER ref count %d\n",
-   atomic_read(&ah->intr_ref_cnt));
-   return;
-   }
-
if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
AR_SREV_9561(ah))
sync_default &= ~AR_INTR_SYNC_HOST1_FATAL;
@@ -841,6 +832,39 @@ void ath9k_hw_enable_interrupts(struct a
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
 }
+
+void ath9k_hw_resume_interrupts(struct ath_hw *ah)
+{
+   struct ath_common *common = ath9k_hw_common(ah);
+
+   if (!(ah->imask & ATH9K_INT_GLOBAL))
+   return;
+
+   if (atomic_read(&ah->intr_ref_cnt) != 0) {
+   ath_dbg(common, INTERRUPT, "Do not enable IER ref count %d\n",
+   atomic_read(&ah->intr_ref_cnt));
+   return;
+   }
+
+   __ath9k_hw_enable_interrupts(ah);
+}
+EXPORT_SYMBOL(ath9k_hw_resume_interrupts);
+
+void ath9k_hw_enable_interrupts(struct ath_hw *ah)
+{
+   struct ath_common *common = ath9k_hw_common(ah);
+
+   if (!(ah->imask & ATH9K_INT_GLOBAL))
+   return;
+
+   if (!atomic_inc_and_test(&ah->intr_ref_cnt)) {
+   ath_dbg(common, INTERRUPT, "Do not enable IER ref count %d\n",
+   atomic_read(&ah->intr_ref_cnt));
+   return;
+   }
+
+   __ath9k_hw_enable_interrupts(ah);
+}
 EXPORT_SYMBOL(ath9k_hw_enable_interrupts);
 
 void ath9k_hw_set_interrupts(struct ath_hw *ah)
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -744,6 +744,7 @@ void ath9k_hw_set_interrupts(struct ath_
 void ath9k_hw_enable_interrupts(struct ath_hw *ah);
 void ath9k_hw_disable_interrupts(struct ath_hw *ah);
 void ath9k_hw_kill_interrupts(struct ath_hw *ah);
+void ath9k_hw_resume_interrupts(struct ath_hw *ah);
 
 void ar9002_hw_attach_mac_ops(struct ath_hw *ah);
 
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -373,21 +373,20 @@ void ath9k_tasklet(unsigned long data)
struct ath_common *common = ath9k_hw_common(ah);
enum ath_reset_type type;
unsigned long flags;
-   u32 status = sc->intrstatus;
+   u32 status;
u32 rxmask;
 
+   spin_lock_irqsave(&sc->intr_

[PATCH 4.9 064/153] Fix: Disable sys_membarrier when nohz_full is enabled

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mathieu Desnoyers 

commit 907565337ebf998a68cb5c5b2174ce5e5da065eb upstream.

Userspace applications should be allowed to expect the membarrier system
call with MEMBARRIER_CMD_SHARED command to issue memory barriers on
nohz_full CPUs, but synchronize_sched() does not take those into
account.

Given that we do not want unrelated processes to be able to affect
real-time sensitive nohz_full CPUs, simply return ENOSYS when membarrier
is invoked on a kernel with enabled nohz_full CPUs.

Signed-off-by: Mathieu Desnoyers 
CC: Josh Triplett 
CC: Steven Rostedt 
Signed-off-by: Paul E. McKenney 
Cc: Frederic Weisbecker 
Cc: Chris Metcalf 
Cc: Rik van Riel 
Acked-by: Lai Jiangshan 
Reviewed-by: Josh Triplett 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/membarrier.c |4 
 1 file changed, 4 insertions(+)

--- a/kernel/membarrier.c
+++ b/kernel/membarrier.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * Bitmask made from a "or" of all commands within enum membarrier_cmd,
@@ -51,6 +52,9 @@
  */
 SYSCALL_DEFINE2(membarrier, int, cmd, int, flags)
 {
+   /* MEMBARRIER_CMD_SHARED is not compatible with nohz_full. */
+   if (tick_nohz_full_enabled())
+   return -ENOSYS;
if (unlikely(flags))
return -EINVAL;
switch (cmd) {




[PATCH 4.9 087/153] crypto: testmgr - Pad aes_ccm_enc_tv_template vector

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Laura Abbott 

commit 1c68bb0f62bf8de8bb30123ea840d5168f25abea upstream.

Running with KASAN and crypto tests currently gives

 BUG: KASAN: global-out-of-bounds in __test_aead+0x9d9/0x2200 at addr 
8212fca0
 Read of size 16 by task cryptomgr_test/1107
 Address belongs to variable 0x8212fca0
 CPU: 0 PID: 1107 Comm: cryptomgr_test Not tainted 4.10.0+ #45
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 
04/01/2014
 Call Trace:
  dump_stack+0x63/0x8a
  kasan_report.part.1+0x4a7/0x4e0
  ? __test_aead+0x9d9/0x2200
  ? crypto_ccm_init_crypt+0x218/0x3c0 [ccm]
  kasan_report+0x20/0x30
  check_memory_region+0x13c/0x1a0
  memcpy+0x23/0x50
  __test_aead+0x9d9/0x2200
  ? kasan_unpoison_shadow+0x35/0x50
  ? alg_test_akcipher+0xf0/0xf0
  ? crypto_skcipher_init_tfm+0x2e3/0x310
  ? crypto_spawn_tfm2+0x37/0x60
  ? crypto_ccm_init_tfm+0xa9/0xd0 [ccm]
  ? crypto_aead_init_tfm+0x7b/0x90
  ? crypto_alloc_tfm+0xc4/0x190
  test_aead+0x28/0xc0
  alg_test_aead+0x54/0xd0
  alg_test+0x1eb/0x3d0
  ? alg_find_test+0x90/0x90
  ? __sched_text_start+0x8/0x8
  ? __wake_up_common+0x70/0xb0
  cryptomgr_test+0x4d/0x60
  kthread+0x173/0x1c0
  ? crypto_acomp_scomp_free_ctx+0x60/0x60
  ? kthread_create_on_node+0xa0/0xa0
  ret_from_fork+0x2c/0x40
 Memory state around the buggy address:
  8212fb80: 00 00 00 00 01 fa fa fa fa fa fa fa 00 00 00 00
  8212fc00: 00 01 fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
 >8212fc80: fa fa fa fa 00 05 fa fa fa fa fa fa 00 00 00 00
   ^
  8212fd00: 01 fa fa fa fa fa fa fa 00 00 00 00 01 fa fa fa
  8212fd80: fa fa fa fa 00 00 00 00 00 05 fa fa fa fa fa fa

This always happens on the same IV which is less than 16 bytes.

Per Ard,

"CCM IVs are 16 bytes, but due to the way they are constructed
internally, the final couple of bytes of input IV are dont-cares.

Apparently, we do read all 16 bytes, which triggers the KASAN errors."

Fix this by padding the IV with null bytes to be at least 16 bytes.

Fixes: 0bc5a6c5c79a ("crypto: testmgr - Disable rfc4309 test and convert test 
vectors")
Acked-by: Ard Biesheuvel 
Signed-off-by: Laura Abbott 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman 

---
 crypto/testmgr.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -22813,7 +22813,7 @@ static struct aead_testvec aes_ccm_enc_t
  "\x09\x75\x9a\x9b\x3c\x9b\x27\x39",
.klen   = 32,
.iv = "\x03\xf9\xd9\x4e\x63\xb5\x3d\x9d"
- "\x43\xf6\x1e\x50",
+ "\x43\xf6\x1e\x50\0\0\0\0",
.assoc  = "\x57\xf5\x6b\x8b\x57\x5c\x3d\x3b"
  "\x13\x02\x01\x0c\x83\x4c\x96\x35"
  "\x8e\xd6\x39\xcf\x7d\x14\x9b\x94"




[PATCH 4.9 093/153] KVM: arm/arm64: vgic: Stop injecting the MSI occurrence twice

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Shanker Donthineni 

commit 0bdbf3b071986ba80731203683cf623d5c0cacb1 upstream.

The IRQFD framework calls the architecture dependent function
twice if the corresponding GSI type is edge triggered. For ARM,
the function kvm_set_msi() is getting called twice whenever the
IRQFD receives the event signal. The rest of the code path is
trying to inject the MSI without any validation checks. No need
to call the function vgic_its_inject_msi() second time to avoid
an unnecessary overhead in IRQ queue logic. It also avoids the
possibility of VM seeing the MSI twice.

Simple fix, return -1 if the argument 'level' value is zero.

Reviewed-by: Eric Auger 
Reviewed-by: Christoffer Dall 
Signed-off-by: Shanker Donthineni 
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman 

---
 virt/kvm/arm/vgic/vgic-irqfd.c |3 +++
 1 file changed, 3 insertions(+)

--- a/virt/kvm/arm/vgic/vgic-irqfd.c
+++ b/virt/kvm/arm/vgic/vgic-irqfd.c
@@ -99,6 +99,9 @@ int kvm_set_msi(struct kvm_kernel_irq_ro
if (!vgic_has_its(kvm))
return -ENODEV;
 
+   if (!level)
+   return -1;
+
return vgic_its_inject_msi(kvm, &msi);
 }
 




[PATCH 4.9 091/153] arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Robin Murphy 

commit adbe7e26f4257f72817495b9bce114284060b0d7 upstream.

When bypassing SWIOTLB on small-memory systems, we need to avoid calling
into swiotlb_dma_mapping_error() in exactly the same way as we avoid
swiotlb_dma_supported(), because the former also relies on SWIOTLB state
being initialised.

Under the assumptions for which we skip SWIOTLB, dma_map_{single,page}()
will only ever return the DMA-offset-adjusted physical address of the
page passed in, thus we can report success unconditionally.

Fixes: b67a8b29df7e ("arm64: mm: only initialize swiotlb when necessary")
CC: Jisheng Zhang 
Reported-by: Aaro Koskinen 
Signed-off-by: Robin Murphy 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/arm64/mm/dma-mapping.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -352,6 +352,13 @@ static int __swiotlb_dma_supported(struc
return 1;
 }
 
+static int __swiotlb_dma_mapping_error(struct device *hwdev, dma_addr_t addr)
+{
+   if (swiotlb)
+   return swiotlb_dma_mapping_error(hwdev, addr);
+   return 0;
+}
+
 static struct dma_map_ops swiotlb_dma_ops = {
.alloc = __dma_alloc,
.free = __dma_free,
@@ -366,7 +373,7 @@ static struct dma_map_ops swiotlb_dma_op
.sync_sg_for_cpu = __swiotlb_sync_sg_for_cpu,
.sync_sg_for_device = __swiotlb_sync_sg_for_device,
.dma_supported = __swiotlb_dma_supported,
-   .mapping_error = swiotlb_dma_mapping_error,
+   .mapping_error = __swiotlb_dma_mapping_error,
 };
 
 static int __init atomic_pool_init(void)




[PATCH 4.9 068/153] ext4: Include forgotten start block on fallocate insert range

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Roman Pen 

commit 2a9b8cba62c0741109c33a2be700ff3d7703a7c2 upstream.

While doing 'insert range' start block should be also shifted right.
The bug can be easily reproduced by the following test:

ptr = malloc(4096);
assert(ptr);

fd = open("./ext4.file", O_CREAT | O_TRUNC | O_RDWR, 0600);
assert(fd >= 0);

rc = fallocate(fd, 0, 0, 8192);
assert(rc == 0);
for (i = 0; i < 2048; i++)
*((unsigned short *)ptr + i) = 0xbeef;
rc = pwrite(fd, ptr, 4096, 0);
assert(rc == 4096);
rc = pwrite(fd, ptr, 4096, 4096);
assert(rc == 4096);

for (block = 2; block < 1000; block++) {
rc = fallocate(fd, FALLOC_FL_INSERT_RANGE, 4096, 4096);
assert(rc == 0);

for (i = 0; i < 2048; i++)
*((unsigned short *)ptr + i) = block;

rc = pwrite(fd, ptr, 4096, 4096);
assert(rc == 4096);
}

Because start block is not included in the range the hole appears at
the wrong offset (just after the desired offset) and the following
pwrite() overwrites already existent block, keeping hole untouched.

Simple way to verify wrong behaviour is to check zeroed blocks after
the test:

   $ hexdump ./ext4.file | grep ' '

The root cause of the bug is a wrong range (start, stop], where start
should be inclusive, i.e. [start, stop].

This patch fixes the problem by including start into the range.  But
not to break left shift (range collapse) stop points to the beginning
of the a block, not to the end.

The other not obvious change is an iterator check on validness in a
main loop.  Because iterator is unsigned the following corner case
should be considered with care: insert a block at 0 offset, when stop
variables overflows and never becomes less than start, which is 0.
To handle this special case iterator is set to NULL to indicate that
end of the loop is reached.

Fixes: 331573febb6a2
Signed-off-by: Roman Pen 
Signed-off-by: Theodore Ts'o 
Cc: Namjae Jeon 
Cc: Andreas Dilger 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/extents.c |   18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -5353,8 +5353,7 @@ ext4_ext_shift_extents(struct inode *ino
if (!extent)
goto out;
 
-   stop = le32_to_cpu(extent->ee_block) +
-   ext4_ext_get_actual_len(extent);
+   stop = le32_to_cpu(extent->ee_block);
 
/*
 * In case of left shift, Don't start shifting extents until we make
@@ -5393,8 +5392,12 @@ ext4_ext_shift_extents(struct inode *ino
else
iterator = &stop;
 
-   /* Its safe to start updating extents */
-   while (start < stop) {
+   /*
+* Its safe to start updating extents.  Start and stop are unsigned, so
+* in case of right shift if extent with 0 block is reached, iterator
+* becomes NULL to indicate the end of the loop.
+*/
+   while (iterator && start <= stop) {
path = ext4_find_extent(inode, *iterator, &path, 0);
if (IS_ERR(path))
return PTR_ERR(path);
@@ -5422,8 +5425,11 @@ ext4_ext_shift_extents(struct inode *ino
ext4_ext_get_actual_len(extent);
} else {
extent = EXT_FIRST_EXTENT(path[depth].p_hdr);
-   *iterator =  le32_to_cpu(extent->ee_block) > 0 ?
-   le32_to_cpu(extent->ee_block) - 1 : 0;
+   if (le32_to_cpu(extent->ee_block) > 0)
+   *iterator = le32_to_cpu(extent->ee_block) - 1;
+   else
+   /* Beginning is reached, end of the loop */
+   iterator = NULL;
/* Update path extent in case we need to stop */
while (le32_to_cpu(extent->ee_block) < start)
extent++;




[PATCH 4.9 099/153] w1: ds2490: USB transfer buffers need to be DMAable

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Maciej S. Szmigiero 

commit 61cd1b4cd1e8f7f7642ab64529d9bd52e8374641 upstream.

ds2490 driver was doing USB transfers from / to buffers on a stack.
This is not permitted and made the driver non-working with vmapped stacks.

Since all these transfers are done under the same bus_mutex lock we can
simply use shared buffers in a device private structure for two most common
of them.

While we are at it, let's also fix a comparison between int and size_t in
ds9490r_search() which made the driver spin in this function if state
register get requests were failing.

Signed-off-by: Maciej S. Szmigiero 
Acked-by: Evgeniy Polyakov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/w1/masters/ds2490.c |  142 ++--
 1 file changed, 84 insertions(+), 58 deletions(-)

--- a/drivers/w1/masters/ds2490.c
+++ b/drivers/w1/masters/ds2490.c
@@ -153,6 +153,9 @@ struct ds_device
 */
u16 spu_bit;
 
+   u8  st_buf[ST_SIZE];
+   u8  byte_buf;
+
struct w1_bus_mastermaster;
 };
 
@@ -174,7 +177,6 @@ struct ds_status
u8  data_in_buffer_status;
u8  reserved1;
u8  reserved2;
-
 };
 
 static struct usb_device_id ds_id_table [] = {
@@ -244,28 +246,6 @@ static int ds_send_control(struct ds_dev
return err;
 }
 
-static int ds_recv_status_nodump(struct ds_device *dev, struct ds_status *st,
-unsigned char *buf, int size)
-{
-   int count, err;
-
-   memset(st, 0, sizeof(*st));
-
-   count = 0;
-   err = usb_interrupt_msg(dev->udev, usb_rcvintpipe(dev->udev,
-   dev->ep[EP_STATUS]), buf, size, &count, 1000);
-   if (err < 0) {
-   pr_err("Failed to read 1-wire data from 0x%x: err=%d.\n",
-  dev->ep[EP_STATUS], err);
-   return err;
-   }
-
-   if (count >= sizeof(*st))
-   memcpy(st, buf, sizeof(*st));
-
-   return count;
-}
-
 static inline void ds_print_msg(unsigned char *buf, unsigned char *str, int 
off)
 {
pr_info("%45s: %8x\n", str, buf[off]);
@@ -324,6 +304,35 @@ static void ds_dump_status(struct ds_dev
}
 }
 
+static int ds_recv_status(struct ds_device *dev, struct ds_status *st,
+ bool dump)
+{
+   int count, err;
+
+   if (st)
+   memset(st, 0, sizeof(*st));
+
+   count = 0;
+   err = usb_interrupt_msg(dev->udev,
+   usb_rcvintpipe(dev->udev,
+  dev->ep[EP_STATUS]),
+   dev->st_buf, sizeof(dev->st_buf),
+   &count, 1000);
+   if (err < 0) {
+   pr_err("Failed to read 1-wire data from 0x%x: err=%d.\n",
+  dev->ep[EP_STATUS], err);
+   return err;
+   }
+
+   if (dump)
+   ds_dump_status(dev, dev->st_buf, count);
+
+   if (st && count >= sizeof(*st))
+   memcpy(st, dev->st_buf, sizeof(*st));
+
+   return count;
+}
+
 static void ds_reset_device(struct ds_device *dev)
 {
ds_send_control_cmd(dev, CTL_RESET_DEVICE, 0);
@@ -344,7 +353,6 @@ static void ds_reset_device(struct ds_de
 static int ds_recv_data(struct ds_device *dev, unsigned char *buf, int size)
 {
int count, err;
-   struct ds_status st;
 
/* Careful on size.  If size is less than what is available in
 * the input buffer, the device fails the bulk transfer and
@@ -359,14 +367,9 @@ static int ds_recv_data(struct ds_device
err = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev, 
dev->ep[EP_DATA_IN]),
buf, size, &count, 1000);
if (err < 0) {
-   u8 buf[ST_SIZE];
-   int count;
-
pr_info("Clearing ep0x%x.\n", dev->ep[EP_DATA_IN]);
usb_clear_halt(dev->udev, usb_rcvbulkpipe(dev->udev, 
dev->ep[EP_DATA_IN]));
-
-   count = ds_recv_status_nodump(dev, &st, buf, sizeof(buf));
-   ds_dump_status(dev, buf, count);
+   ds_recv_status(dev, NULL, true);
return err;
}
 
@@ -404,7 +407,6 @@ int ds_stop_pulse(struct ds_device *dev,
 {
struct ds_status st;
int count = 0, err = 0;
-   u8 buf[ST_SIZE];
 
do {
err = ds_send_control(dev, CTL_HALT_EXE_IDLE, 0);
@@ -413,7 +415,7 @@ int ds_stop_pulse(struct ds_device *dev,
err = ds_send_control(dev, CTL_RESUME_EXE, 0);
if (err)
break;
-   err = ds_recv_status_nodump(dev, &st, buf, sizeof(buf));
+   err = ds_recv_status(dev, &st, false);
if (err)
break;
 
@@ -456,18 

[PATCH 4.9 097/153] can: usb_8dev: Fix memory leak of priv->cmd_msg_buffer

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Marc Kleine-Budde 

commit 7c42631376306fb3f34d51fda546b50a9b6dd6ec upstream.

The priv->cmd_msg_buffer is allocated in the probe function, but never
kfree()ed. This patch converts the kzalloc() to resource-managed
kzalloc.

Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/usb/usb_8dev.c |9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -951,8 +951,8 @@ static int usb_8dev_probe(struct usb_int
for (i = 0; i < MAX_TX_URBS; i++)
priv->tx_contexts[i].echo_index = MAX_TX_URBS;
 
-   priv->cmd_msg_buffer = kzalloc(sizeof(struct usb_8dev_cmd_msg),
- GFP_KERNEL);
+   priv->cmd_msg_buffer = devm_kzalloc(&intf->dev, sizeof(struct 
usb_8dev_cmd_msg),
+   GFP_KERNEL);
if (!priv->cmd_msg_buffer)
goto cleanup_candev;
 
@@ -966,7 +966,7 @@ static int usb_8dev_probe(struct usb_int
if (err) {
netdev_err(netdev,
"couldn't register CAN device: %d\n", err);
-   goto cleanup_cmd_msg_buffer;
+   goto cleanup_candev;
}
 
err = usb_8dev_cmd_version(priv, &version);
@@ -987,9 +987,6 @@ static int usb_8dev_probe(struct usb_int
 cleanup_unregister_candev:
unregister_netdev(priv->netdev);
 
-cleanup_cmd_msg_buffer:
-   kfree(priv->cmd_msg_buffer);
-
 cleanup_candev:
free_candev(netdev);
 




[PATCH 4.9 066/153] block/loop: fix race between I/O and set_status

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ming Lei 

commit ecdd09597a57251323b0de50e3d45e69298c4a83 upstream.

Inside set_status, transfer need to setup again, so
we have to drain IO before the transition, otherwise
oops may be triggered like the following:

divide error:  [#1] SMP KASAN
CPU: 0 PID: 2935 Comm: loop7 Not tainted 4.10.0-rc7+ #213
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
task: 88006ba1e840 task.stack: 880067338000
RIP: 0010:transfer_xor+0x1d1/0x440 drivers/block/loop.c:110
RSP: 0018:88006733f108 EFLAGS: 00010246
RAX:  RBX: 8800688d7000 RCX: 0059
RDX:  RSI: 11000d743f43 RDI: 880068891c08
RBP: 88006733f160 R08: 8800688d7001 R09: 
R10:  R11:  R12: 8800688d7000
R13: 880067b7d000 R14: dc00 R15: 
FS:  () GS:88006d00()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006c17e0 CR3: 66e3b000 CR4: 001406f0
Call Trace:
 lo_do_transfer drivers/block/loop.c:251 [inline]
 lo_read_transfer drivers/block/loop.c:392 [inline]
 do_req_filebacked drivers/block/loop.c:541 [inline]
 loop_handle_cmd drivers/block/loop.c:1677 [inline]
 loop_queue_work+0xda0/0x49b0 drivers/block/loop.c:1689
 kthread_worker_fn+0x4c3/0xa30 kernel/kthread.c:630
 kthread+0x326/0x3f0 kernel/kthread.c:227
 ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Code: 03 83 e2 07 41 29 df 42 0f b6 04 30 4d 8d 44 24 01 38 d0 7f 08
84 c0 0f 85 62 02 00 00 44 89 f8 41 0f b6 48 ff 25 ff 01 00 00 99 
7d c8 48 63 d2 48 03 55 d0 48 89 d0 48 89 d7 48 c1 e8 03 83
RIP: transfer_xor+0x1d1/0x440 drivers/block/loop.c:110 RSP:
88006733f108
---[ end trace 0166f7bd3b0c0933 ]---

Reported-by: Dmitry Vyukov 
Signed-off-by: Ming Lei 
Tested-by: Dmitry Vyukov 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/block/loop.c |   17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1097,9 +1097,12 @@ loop_set_status(struct loop_device *lo,
if ((unsigned int) info->lo_encrypt_key_size > LO_KEY_SIZE)
return -EINVAL;
 
+   /* I/O need to be drained during transfer transition */
+   blk_mq_freeze_queue(lo->lo_queue);
+
err = loop_release_xfer(lo);
if (err)
-   return err;
+   goto exit;
 
if (info->lo_encrypt_type) {
unsigned int type = info->lo_encrypt_type;
@@ -1114,12 +1117,14 @@ loop_set_status(struct loop_device *lo,
 
err = loop_init_xfer(lo, xfer, info);
if (err)
-   return err;
+   goto exit;
 
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit)
-   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit))
-   return -EFBIG;
+   if (figure_loop_size(lo, info->lo_offset, info->lo_sizelimit)) {
+   err = -EFBIG;
+   goto exit;
+   }
 
loop_config_discard(lo);
 
@@ -1156,7 +1161,9 @@ loop_set_status(struct loop_device *lo,
/* update dio if lo_offset or transfer is changed */
__loop_update_dio(lo, lo->use_dio);
 
-   return 0;
+ exit:
+   blk_mq_unfreeze_queue(lo->lo_queue);
+   return err;
 }
 
 static int




[PATCH 4.9 096/153] can: gs_usb: Dont use stack memory for USB transfers

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ethan Zonca 

commit c919a3069c775c1c876bec55e00b2305d5125caa upstream.

Fixes: 05ca5270005c can: gs_usb: add ethtool set_phys_id callback to locate 
physical device

The gs_usb driver is performing USB transfers using buffers allocated on
the stack. This causes the driver to not function with vmapped stacks.
Instead, allocate memory for the transfer buffers.

Signed-off-by: Ethan Zonca 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/can/usb/gs_usb.c |   40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

--- a/drivers/net/can/usb/gs_usb.c
+++ b/drivers/net/can/usb/gs_usb.c
@@ -908,10 +908,14 @@ static int gs_usb_probe(struct usb_inter
struct gs_usb *dev;
int rc = -ENOMEM;
unsigned int icount, i;
-   struct gs_host_config hconf = {
-   .byte_order = 0xbeef,
-   };
-   struct gs_device_config dconf;
+   struct gs_host_config *hconf;
+   struct gs_device_config *dconf;
+
+   hconf = kmalloc(sizeof(*hconf), GFP_KERNEL);
+   if (!hconf)
+   return -ENOMEM;
+
+   hconf->byte_order = 0xbeef;
 
/* send host config */
rc = usb_control_msg(interface_to_usbdev(intf),
@@ -920,16 +924,22 @@ static int gs_usb_probe(struct usb_inter
 USB_DIR_OUT|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
 1,
 intf->altsetting[0].desc.bInterfaceNumber,
-&hconf,
-sizeof(hconf),
+hconf,
+sizeof(*hconf),
 1000);
 
+   kfree(hconf);
+
if (rc < 0) {
dev_err(&intf->dev, "Couldn't send data format (err=%d)\n",
rc);
return rc;
}
 
+   dconf = kmalloc(sizeof(*dconf), GFP_KERNEL);
+   if (!dconf)
+   return -ENOMEM;
+
/* read device config */
rc = usb_control_msg(interface_to_usbdev(intf),
 usb_rcvctrlpipe(interface_to_usbdev(intf), 0),
@@ -937,28 +947,33 @@ static int gs_usb_probe(struct usb_inter
 USB_DIR_IN|USB_TYPE_VENDOR|USB_RECIP_INTERFACE,
 1,
 intf->altsetting[0].desc.bInterfaceNumber,
-&dconf,
-sizeof(dconf),
+dconf,
+sizeof(*dconf),
 1000);
if (rc < 0) {
dev_err(&intf->dev, "Couldn't get device config: (err=%d)\n",
rc);
+   kfree(dconf);
return rc;
}
 
-   icount = dconf.icount + 1;
+   icount = dconf->icount + 1;
dev_info(&intf->dev, "Configuring for %d interfaces\n", icount);
 
if (icount > GS_MAX_INTF) {
dev_err(&intf->dev,
"Driver cannot handle more that %d CAN interfaces\n",
GS_MAX_INTF);
+   kfree(dconf);
return -EINVAL;
}
 
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
-   if (!dev)
+   if (!dev) {
+   kfree(dconf);
return -ENOMEM;
+   }
+
init_usb_anchor(&dev->rx_submitted);
 
atomic_set(&dev->active_channels, 0);
@@ -967,7 +982,7 @@ static int gs_usb_probe(struct usb_inter
dev->udev = interface_to_usbdev(intf);
 
for (i = 0; i < icount; i++) {
-   dev->canch[i] = gs_make_candev(i, intf, &dconf);
+   dev->canch[i] = gs_make_candev(i, intf, dconf);
if (IS_ERR_OR_NULL(dev->canch[i])) {
/* save error code to return later */
rc = PTR_ERR(dev->canch[i]);
@@ -978,12 +993,15 @@ static int gs_usb_probe(struct usb_inter
gs_destroy_candev(dev->canch[i]);
 
usb_kill_anchored_urbs(&dev->rx_submitted);
+   kfree(dconf);
kfree(dev);
return rc;
}
dev->canch[i]->parent = dev;
}
 
+   kfree(dconf);
+
return 0;
 }
 




[PATCH 4.9 111/153] Drivers: hv: vmbus: Prevent sending data on a rescinded channel

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: K. Y. Srinivasan 

commit e7e97dd8b77ee7366f2f8c70a033bf5fa05ec2e0 upstream.

After the channel is rescinded, the host does not read from the rescinded 
channel.
Fail writes to a channel that has already been rescinded. If we permit writes 
on a
rescinded channel, since the host will not respond we will have situations where
we will be unable to unload vmbus drivers that cannot have any outstanding 
requests
to the host at the point they are unoaded.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hv/ring_buffer.c |7 +++
 1 file changed, 7 insertions(+)

--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -298,6 +298,9 @@ int hv_ringbuffer_write(struct vmbus_cha
unsigned long flags = 0;
struct hv_ring_buffer_info *outring_info = &channel->outbound;
 
+   if (channel->rescind)
+   return -ENODEV;
+
for (i = 0; i < kv_count; i++)
totalbytes_towrite += kv_list[i].iov_len;
 
@@ -350,6 +353,10 @@ int hv_ringbuffer_write(struct vmbus_cha
spin_unlock_irqrestore(&outring_info->ring_lock, flags);
 
hv_signal_on_write(old_write, channel, kick_q);
+
+   if (channel->rescind)
+   return -ENODEV;
+
return 0;
 }
 




[PATCH 4.9 101/153] usb: dwc3: gadget: skip Set/Clear Halt when invalid

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Felipe Balbi 

commit ffb80fc672c3a7b6afd0cefcb1524fb99917b2f3 upstream.

At least macOS seems to be sending
ClearFeature(ENDPOINT_HALT) to endpoints which
aren't Halted. This makes DWC3's CLEARSTALL command
time out which causes several issues for the driver.

Instead, let's just return 0 and bail out early.

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

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

--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1234,6 +1234,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc
unsigned transfer_in_flight;
unsigned started;
 
+   if (dep->flags & DWC3_EP_STALL)
+   return 0;
+
if (dep->number > 1)
trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
else
@@ -1258,6 +1261,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc
else
dep->flags |= DWC3_EP_STALL;
} else {
+   if (!(dep->flags & DWC3_EP_STALL))
+   return 0;
 
ret = dwc3_send_clear_stall_ep_cmd(dep);
if (ret)




[PATCH 4.9 071/153] ext4: fix data corruption in data=journal mode

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 3b136499e906460919f0d21a49db1aaccf0ae963 upstream.

ext4_journalled_write_end() did not propely handle all the cases when
generic_perform_write() did not copy all the data into the target page
and could mark buffers with uninitialized contents as uptodate and dirty
leading to possible data corruption (which would be quickly fixed by
generic_perform_write() retrying the write but still). Fix the problem
by carefully handling the case when the page that is written to is not
uptodate.

Reported-by: Al Viro 
Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/ext4/inode.c |   23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1379,7 +1379,9 @@ errout:
  * set the buffer to be dirty, since in data=journalled mode we need
  * to call ext4_handle_dirty_metadata() instead.
  */
-static void zero_new_buffers(struct page *page, unsigned from, unsigned to)
+static void ext4_journalled_zero_new_buffers(handle_t *handle,
+   struct page *page,
+   unsigned from, unsigned to)
 {
unsigned int block_start = 0, block_end;
struct buffer_head *head, *bh;
@@ -1396,7 +1398,7 @@ static void zero_new_buffers(struct page
size = min(to, block_end) - start;
 
zero_user(page, start, size);
-   set_buffer_uptodate(bh);
+   write_end_fn(handle, bh);
}
clear_buffer_new(bh);
}
@@ -1428,15 +1430,16 @@ static int ext4_journalled_write_end(str
if (ext4_has_inline_data(inode))
copied = ext4_write_inline_data_end(inode, pos, len,
copied, page);
-   else {
-   if (copied < len) {
-   if (!PageUptodate(page))
-   copied = 0;
-   zero_new_buffers(page, from+copied, to);
-   }
-
+   else if (unlikely(copied < len) && !PageUptodate(page)) {
+   copied = 0;
+   ext4_journalled_zero_new_buffers(handle, page, from, to);
+   } else {
+   if (unlikely(copied < len))
+   ext4_journalled_zero_new_buffers(handle, page,
+from + copied, to);
ret = ext4_walk_page_buffers(handle, page_buffers(page), from,
-to, &partial, write_end_fn);
+from + copied, &partial,
+write_end_fn);
if (!partial)
SetPageUptodate(page);
}




[PATCH 4.9 112/153] Drivers: hv: vmbus: Fix a rescind handling bug

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: K. Y. Srinivasan 

commit ccb61f8a99e6c29df4fb96a65dad4fad740d5be9 upstream.

The host can rescind a channel that has been offered to the
guest and once the channel is rescinded, the host does not
respond to any requests on that channel. Deal with the case where
the guest may be blocked waiting for a response from the host.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hv/channel.c  |   18 ++
 drivers/hv/channel_mgmt.c |   25 +
 include/linux/hyperv.h|1 +
 3 files changed, 44 insertions(+)

--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -157,6 +157,7 @@ int vmbus_open(struct vmbus_channel *new
}
 
init_completion(&open_info->waitevent);
+   open_info->waiting_channel = newchannel;
 
open_msg = (struct vmbus_channel_open_channel *)open_info->msg;
open_msg->header.msgtype = CHANNELMSG_OPENCHANNEL;
@@ -194,6 +195,11 @@ int vmbus_open(struct vmbus_channel *new
list_del(&open_info->msglistentry);
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
 
+   if (newchannel->rescind) {
+   err = -ENODEV;
+   goto error_free_gpadl;
+   }
+
if (open_info->response.open_result.status) {
err = -EAGAIN;
goto error_free_gpadl;
@@ -405,6 +411,7 @@ int vmbus_establish_gpadl(struct vmbus_c
return ret;
 
init_completion(&msginfo->waitevent);
+   msginfo->waiting_channel = channel;
 
gpadlmsg = (struct vmbus_channel_gpadl_header *)msginfo->msg;
gpadlmsg->header.msgtype = CHANNELMSG_GPADL_HEADER;
@@ -441,6 +448,11 @@ int vmbus_establish_gpadl(struct vmbus_c
}
wait_for_completion(&msginfo->waitevent);
 
+   if (channel->rescind) {
+   ret = -ENODEV;
+   goto cleanup;
+   }
+
/* At this point, we received the gpadl created msg */
*gpadl_handle = gpadlmsg->gpadl;
 
@@ -474,6 +486,7 @@ int vmbus_teardown_gpadl(struct vmbus_ch
return -ENOMEM;
 
init_completion(&info->waitevent);
+   info->waiting_channel = channel;
 
msg = (struct vmbus_channel_gpadl_teardown *)info->msg;
 
@@ -493,6 +506,11 @@ int vmbus_teardown_gpadl(struct vmbus_ch
 
wait_for_completion(&info->waitevent);
 
+   if (channel->rescind) {
+   ret = -ENODEV;
+   goto post_msg_err;
+   }
+
 post_msg_err:
spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
list_del(&info->msglistentry);
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -147,6 +147,29 @@ static const struct {
{ HV_RDV_GUID   },
 };
 
+/*
+ * The rescinded channel may be blocked waiting for a response from the host;
+ * take care of that.
+ */
+static void vmbus_rescind_cleanup(struct vmbus_channel *channel)
+{
+   struct vmbus_channel_msginfo *msginfo;
+   unsigned long flags;
+
+
+   spin_lock_irqsave(&vmbus_connection.channelmsg_lock, flags);
+
+   list_for_each_entry(msginfo, &vmbus_connection.chn_msg_list,
+   msglistentry) {
+
+   if (msginfo->waiting_channel == channel) {
+   complete(&msginfo->waitevent);
+   break;
+   }
+   }
+   spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
+}
+
 static bool is_unsupported_vmbus_devs(const uuid_le *guid)
 {
int i;
@@ -825,6 +848,8 @@ static void vmbus_onoffer_rescind(struct
channel->rescind = true;
spin_unlock_irqrestore(&channel->lock, flags);
 
+   vmbus_rescind_cleanup(channel);
+
if (channel->device_obj) {
if (channel->chn_rescind_callback) {
channel->chn_rescind_callback(channel);
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -641,6 +641,7 @@ struct vmbus_channel_msginfo {
 
/* Synchronize the request/response if needed */
struct completion  waitevent;
+   struct vmbus_channel *waiting_channel;
union {
struct vmbus_channel_version_supported version_supported;
struct vmbus_channel_open_result open_result;




[PATCH 4.9 114/153] Drivers: hv: util: Fcopy: Fix a rescind processing issue

2017-03-10 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: K. Y. Srinivasan 

commit 20951c7535b5e6af46bc37b7142105f716df739c upstream.

Fcopy may use a char device to support the communication between
the user level daemon and the driver. When the Fcopy channel is rescinded
we need to make sure that the char device is fully cleaned up before
we can process a new Fcopy offer from the host. Implement this logic.

Signed-off-by: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hv/hv_fcopy.c |4 
 1 file changed, 4 insertions(+)

--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -61,6 +61,7 @@ static DECLARE_WORK(fcopy_send_work, fco
 static const char fcopy_devname[] = "vmbus/hv_fcopy";
 static u8 *recv_buffer;
 static struct hvutil_transport *hvt;
+static struct completion release_event;
 /*
  * This state maintains the version number registered by the daemon.
  */
@@ -317,6 +318,7 @@ static void fcopy_on_reset(void)
 
if (cancel_delayed_work_sync(&fcopy_timeout_work))
fcopy_respond_to_host(HV_E_FAIL);
+   complete(&release_event);
 }
 
 int hv_fcopy_init(struct hv_util_service *srv)
@@ -324,6 +326,7 @@ int hv_fcopy_init(struct hv_util_service
recv_buffer = srv->recv_buffer;
fcopy_transaction.recv_channel = srv->channel;
 
+   init_completion(&release_event);
/*
 * When this driver loads, the user level daemon that
 * processes the host requests may not yet be running.
@@ -345,4 +348,5 @@ void hv_fcopy_deinit(void)
fcopy_transaction.state = HVUTIL_DEVICE_DYING;
cancel_delayed_work_sync(&fcopy_timeout_work);
hvutil_transport_destroy(hvt);
+   wait_for_completion(&release_event);
 }




  1   2   3   4   5   6   7   8   9   10   >