[PATCH AUTOSEL 4.4 19/30] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 4.4 08/30] kbuild: add .DELETE_ON_ERROR special target

2018-09-06 Thread Sasha Levin
From: Masahiro Yamada 

[ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ]

If Make gets a fatal signal while a shell is executing, it may delete
the target file that the recipe was supposed to update.  This is needed
to make sure that it is remade from scratch when Make is next run; if
Make is interrupted after the recipe has begun to write the target file,
it results in an incomplete file whose time stamp is newer than that
of the prerequisites files.  Make automatically deletes the incomplete
file on interrupt unless the target is marked .PRECIOUS.

The situation is just the same as when the shell fails for some reasons.
Usually when a recipe line fails, if it has changed the target file at
all, the file is corrupted, or at least it is not completely updated.
Yet the file’s time stamp says that it is now up to date, so the next
time Make runs, it will not try to update that file.

However, Make does not cater to delete the incomplete target file in
this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
to request it.

scripts/Kbuild.include seems a suitable place to add it because it is
included from almost all sub-makes.

Please note .DELETE_ON_ERROR is not effective for phony targets.

The external module building should never ever touch the kernel tree.
The following recipe fails if include/generated/autoconf.h is missing.
However, include/config/auto.conf is not deleted since it is a phony
target.

 PHONY += include/config/auto.conf

 include/config/auto.conf:
 $(Q)test -e include/generated/autoconf.h -a -e $@ || (  \
 echo >&2;   \
 echo >&2 "  ERROR: Kernel configuration is invalid.";   \
 echo >&2 " include/generated/autoconf.h or $@ are missing.";\
 echo >&2 " Run 'make oldconfig && make prepare' on kernel src 
to fix it."; \
 echo >&2 ;  \
 /bin/false)

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/Kbuild.include | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 31a981d6229d..5897fc3857a0 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -359,3 +359,6 @@ endif
 endef
 #
 ###
+
+# delete partially updated (i.e. corrupted) files on error
+.DELETE_ON_ERROR:
-- 
2.17.1


[PATCH AUTOSEL 4.4 19/30] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 4.4 08/30] kbuild: add .DELETE_ON_ERROR special target

2018-09-06 Thread Sasha Levin
From: Masahiro Yamada 

[ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ]

If Make gets a fatal signal while a shell is executing, it may delete
the target file that the recipe was supposed to update.  This is needed
to make sure that it is remade from scratch when Make is next run; if
Make is interrupted after the recipe has begun to write the target file,
it results in an incomplete file whose time stamp is newer than that
of the prerequisites files.  Make automatically deletes the incomplete
file on interrupt unless the target is marked .PRECIOUS.

The situation is just the same as when the shell fails for some reasons.
Usually when a recipe line fails, if it has changed the target file at
all, the file is corrupted, or at least it is not completely updated.
Yet the file’s time stamp says that it is now up to date, so the next
time Make runs, it will not try to update that file.

However, Make does not cater to delete the incomplete target file in
this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
to request it.

scripts/Kbuild.include seems a suitable place to add it because it is
included from almost all sub-makes.

Please note .DELETE_ON_ERROR is not effective for phony targets.

The external module building should never ever touch the kernel tree.
The following recipe fails if include/generated/autoconf.h is missing.
However, include/config/auto.conf is not deleted since it is a phony
target.

 PHONY += include/config/auto.conf

 include/config/auto.conf:
 $(Q)test -e include/generated/autoconf.h -a -e $@ || (  \
 echo >&2;   \
 echo >&2 "  ERROR: Kernel configuration is invalid.";   \
 echo >&2 " include/generated/autoconf.h or $@ are missing.";\
 echo >&2 " Run 'make oldconfig && make prepare' on kernel src 
to fix it."; \
 echo >&2 ;  \
 /bin/false)

Signed-off-by: Masahiro Yamada 
Signed-off-by: Sasha Levin 
---
 scripts/Kbuild.include | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 31a981d6229d..5897fc3857a0 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -359,3 +359,6 @@ endif
 endef
 #
 ###
+
+# delete partially updated (i.e. corrupted) files on error
+.DELETE_ON_ERROR:
-- 
2.17.1


[PATCH AUTOSEL 4.4 22/30] powerpc/powernv: opal_put_chars partial write fix

2018-09-06 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]

The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.

This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.

Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index e48826aa314c..b40606051efe 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -371,7 +371,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int 
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
-   written = total_len;
+   written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
-- 
2.17.1


[PATCH AUTOSEL 4.4 22/30] powerpc/powernv: opal_put_chars partial write fix

2018-09-06 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]

The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.

This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.

Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index e48826aa314c..b40606051efe 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -371,7 +371,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int 
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
-   written = total_len;
+   written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
-- 
2.17.1


[PATCH AUTOSEL 3.18 07/19] gfs2: Don't reject a supposedly full bitmap if we have blocks reserved

2018-09-06 Thread Sasha Levin
From: Bob Peterson 

[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]

Before this patch, you could get into situations like this:

1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
   bitmap is full because process 1's reservation is skipped over.
   So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
   since the GBF_FULL bit is set, it skips over the rgrp and searches
   elsewhere, thus not using its own reservation.

This patch adds an additional check to allow processes to use their
own reservations.

Signed-off-by: Bob Peterson 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/rgrp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 7474c413ffd1..54bc68acc10c 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1643,7 +1643,8 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state, 
u32 *minext,
 
while(1) {
bi = rbm_bi(rbm);
-   if (test_bit(GBF_FULL, >bi_flags) &&
+   if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+   test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
 
-- 
2.17.1


[PATCH AUTOSEL 3.18 07/19] gfs2: Don't reject a supposedly full bitmap if we have blocks reserved

2018-09-06 Thread Sasha Levin
From: Bob Peterson 

[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]

Before this patch, you could get into situations like this:

1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
   bitmap is full because process 1's reservation is skipped over.
   So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
   since the GBF_FULL bit is set, it skips over the rgrp and searches
   elsewhere, thus not using its own reservation.

This patch adds an additional check to allow processes to use their
own reservations.

Signed-off-by: Bob Peterson 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/rgrp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index 7474c413ffd1..54bc68acc10c 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1643,7 +1643,8 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state, 
u32 *minext,
 
while(1) {
bi = rbm_bi(rbm);
-   if (test_bit(GBF_FULL, >bi_flags) &&
+   if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+   test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
 
-- 
2.17.1


[PATCH AUTOSEL 3.18 06/19] mtd/maps: fix solutionengine.c printk format warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]

Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".

Fixes these build warnings:

../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
  ^
  %08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x

Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov 

Signed-off-by: Randy Dunlap 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
---
 drivers/mtd/maps/solutionengine.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/solutionengine.c 
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
-   printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 
0x%08lx\n",
-  soleng_flash_map.phys & 0x1fff,
-  soleng_eprom_map.phys & 0x1fff);
+   printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 
0x%pap\n",
+  _flash_map.phys,
+  _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
 
eprom_mtd = do_map_probe("map_rom", _eprom_map);
-- 
2.17.1


[PATCH AUTOSEL 4.4 23/30] MIPS: jz4740: Bump zload address

2018-09-06 Thread Sasha Levin
From: Paul Cercueil 

[ Upstream commit c6ea7e9747318e5a6774995f4f8e3e0f7c0fa8ba ]

Having the zload address at 0x8060. means the size of the
uncompressed kernel cannot be bigger than around 6 MiB, as it is
deflated at address 0x8001..

This limit is too small; a kernel with some built-in drivers and things
like debugfs enabled will already be over 6 MiB in size, and so will
fail to extract properly.

To fix this, we bump the zload address from 0x8060. to 0x8100..

This is fine, as all the boards featuring Ingenic JZ SoCs have at least
32 MiB of RAM, and use u-boot or compatible bootloaders which won't
hardcode the load address but read it from the uImage's header.

Signed-off-by: Paul Cercueil 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19787/
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin 
---
 arch/mips/jz4740/Platform | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform
index 28448d358c10..a2a5a85ea1f9 100644
--- a/arch/mips/jz4740/Platform
+++ b/arch/mips/jz4740/Platform
@@ -1,4 +1,4 @@
 platform-$(CONFIG_MACH_INGENIC)+= jz4740/
 cflags-$(CONFIG_MACH_INGENIC)  += 
-I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_INGENIC)+= 0x8001
-zload-$(CONFIG_MACH_INGENIC)   += 0x8060
+zload-$(CONFIG_MACH_INGENIC)   += 0x8100
-- 
2.17.1


[PATCH AUTOSEL 3.18 06/19] mtd/maps: fix solutionengine.c printk format warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]

Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".

Fixes these build warnings:

../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
  ^
  %08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x

Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov 

Signed-off-by: Randy Dunlap 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
---
 drivers/mtd/maps/solutionengine.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/solutionengine.c 
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
-   printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 
0x%08lx\n",
-  soleng_flash_map.phys & 0x1fff,
-  soleng_eprom_map.phys & 0x1fff);
+   printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 
0x%pap\n",
+  _flash_map.phys,
+  _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
 
eprom_mtd = do_map_probe("map_rom", _eprom_map);
-- 
2.17.1


[PATCH AUTOSEL 4.4 23/30] MIPS: jz4740: Bump zload address

2018-09-06 Thread Sasha Levin
From: Paul Cercueil 

[ Upstream commit c6ea7e9747318e5a6774995f4f8e3e0f7c0fa8ba ]

Having the zload address at 0x8060. means the size of the
uncompressed kernel cannot be bigger than around 6 MiB, as it is
deflated at address 0x8001..

This limit is too small; a kernel with some built-in drivers and things
like debugfs enabled will already be over 6 MiB in size, and so will
fail to extract properly.

To fix this, we bump the zload address from 0x8060. to 0x8100..

This is fine, as all the boards featuring Ingenic JZ SoCs have at least
32 MiB of RAM, and use u-boot or compatible bootloaders which won't
hardcode the load address but read it from the uImage's header.

Signed-off-by: Paul Cercueil 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19787/
Cc: Ralf Baechle 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sasha Levin 
---
 arch/mips/jz4740/Platform | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform
index 28448d358c10..a2a5a85ea1f9 100644
--- a/arch/mips/jz4740/Platform
+++ b/arch/mips/jz4740/Platform
@@ -1,4 +1,4 @@
 platform-$(CONFIG_MACH_INGENIC)+= jz4740/
 cflags-$(CONFIG_MACH_INGENIC)  += 
-I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_INGENIC)+= 0x8001
-zload-$(CONFIG_MACH_INGENIC)   += 0x8060
+zload-$(CONFIG_MACH_INGENIC)   += 0x8100
-- 
2.17.1


[PATCH AUTOSEL 3.18 01/19] ALSA: msnd: Fix the default sample sizes

2018-09-06 Thread Sasha Levin
From: Takashi Iwai 

[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]

The default sample sizes set by msnd driver are bogus; it sets ALSA
PCM format, not the actual bit width.

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/isa/msnd/msnd_pinnacle.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/isa/msnd/msnd_pinnacle.c b/sound/isa/msnd/msnd_pinnacle.c
index cf70dba80124..741714332365 100644
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -82,10 +82,10 @@
 
 static void set_default_audio_parameters(struct snd_msnd *chip)
 {
-   chip->play_sample_size = DEFSAMPLESIZE;
+   chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->play_sample_rate = DEFSAMPLERATE;
chip->play_channels = DEFCHANNELS;
-   chip->capture_sample_size = DEFSAMPLESIZE;
+   chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->capture_sample_rate = DEFSAMPLERATE;
chip->capture_channels = DEFCHANNELS;
 }
-- 
2.17.1


[PATCH AUTOSEL 4.4 24/30] mac80211: restrict delayed tailroom needed decrement

2018-09-06 Thread Sasha Levin
From: Manikanta Pubbisetty 

[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]

As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.

For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.

* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
  (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
  there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
  (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)

Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.

Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)

Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.

Signed-off-by: Manikanta Pubbisetty 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/cfg.c |  2 +-
 net/mac80211/key.c | 24 +++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 00a8cc572a22..1f930032253a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -286,7 +286,7 @@ static int ieee80211_del_key(struct wiphy *wiphy, struct 
net_device *dev,
goto out_unlock;
}
 
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
 
ret = 0;
  out_unlock:
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 4a72c0d1e56f..91a4e606edcd 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -647,11 +647,15 @@ int ieee80211_key_link(struct ieee80211_key *key,
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
-   int idx, ret;
-   bool pairwise;
-
-   pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
-   idx = key->conf.keyidx;
+   int idx = key->conf.keyidx;
+   bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+   /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+   bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+   int ret;
 
mutex_lock(>local->key_mtx);
 
@@ -679,14 +683,14 @@ int ieee80211_key_link(struct ieee80211_key *key,
increment_tailroom_need_count(sdata);
 
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
-   ieee80211_key_destroy(old_key, true);
+   ieee80211_key_destroy(old_key, delay_tailroom);
 
ieee80211_debugfs_key_add(key);
 
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -874,7 +878,8 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local,
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
-   __ieee80211_key_destroy(key, true);
+   

[PATCH AUTOSEL 3.18 01/19] ALSA: msnd: Fix the default sample sizes

2018-09-06 Thread Sasha Levin
From: Takashi Iwai 

[ Upstream commit 7c500f9ea139d0c9b80fdea5a9c911db3166ea54 ]

The default sample sizes set by msnd driver are bogus; it sets ALSA
PCM format, not the actual bit width.

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/isa/msnd/msnd_pinnacle.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/isa/msnd/msnd_pinnacle.c b/sound/isa/msnd/msnd_pinnacle.c
index cf70dba80124..741714332365 100644
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -82,10 +82,10 @@
 
 static void set_default_audio_parameters(struct snd_msnd *chip)
 {
-   chip->play_sample_size = DEFSAMPLESIZE;
+   chip->play_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->play_sample_rate = DEFSAMPLERATE;
chip->play_channels = DEFCHANNELS;
-   chip->capture_sample_size = DEFSAMPLESIZE;
+   chip->capture_sample_size = snd_pcm_format_width(DEFSAMPLESIZE);
chip->capture_sample_rate = DEFSAMPLERATE;
chip->capture_channels = DEFCHANNELS;
 }
-- 
2.17.1


[PATCH AUTOSEL 4.4 24/30] mac80211: restrict delayed tailroom needed decrement

2018-09-06 Thread Sasha Levin
From: Manikanta Pubbisetty 

[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]

As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.

For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.

* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
  (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
  there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
  (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)

Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.

Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)

Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.

Signed-off-by: Manikanta Pubbisetty 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/cfg.c |  2 +-
 net/mac80211/key.c | 24 +++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 00a8cc572a22..1f930032253a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -286,7 +286,7 @@ static int ieee80211_del_key(struct wiphy *wiphy, struct 
net_device *dev,
goto out_unlock;
}
 
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
 
ret = 0;
  out_unlock:
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 4a72c0d1e56f..91a4e606edcd 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -647,11 +647,15 @@ int ieee80211_key_link(struct ieee80211_key *key,
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
-   int idx, ret;
-   bool pairwise;
-
-   pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
-   idx = key->conf.keyidx;
+   int idx = key->conf.keyidx;
+   bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+   /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+   bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+   int ret;
 
mutex_lock(>local->key_mtx);
 
@@ -679,14 +683,14 @@ int ieee80211_key_link(struct ieee80211_key *key,
increment_tailroom_need_count(sdata);
 
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
-   ieee80211_key_destroy(old_key, true);
+   ieee80211_key_destroy(old_key, delay_tailroom);
 
ieee80211_debugfs_key_add(key);
 
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -874,7 +878,8 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local,
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
-   __ieee80211_key_destroy(key, true);
+   

[PATCH AUTOSEL 3.18 02/19] ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro

2018-09-06 Thread Sasha Levin
From: Takashi Iwai 

[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]

AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC()
for expanding idVendor and idProduct fields.  However, the latter
macro adds also match_flags and bInterfaceClass, which are different
from the values AU0828_DEVICE() macro sets after that.

For fixing them, just expand idVendor and idProduct fields manually in
AU0828_DEVICE().

This fixes sparse warnings like:
  sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/usb/quirks-table.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index adec087725d1..e86fecaa26ec 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2910,7 +2910,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
  */
 
 #define AU0828_DEVICE(vid, pid, vname, pname) { \
-   USB_DEVICE_VENDOR_SPEC(vid, pid), \
+   .idVendor = vid, \
+   .idProduct = pid, \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
   USB_DEVICE_ID_MATCH_INT_CLASS | \
   USB_DEVICE_ID_MATCH_INT_SUBCLASS, \
-- 
2.17.1


[PATCH AUTOSEL 4.4 29/30] platform/x86: toshiba_acpi: Fix defined but not used build warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]

Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show' 
defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Azael Avalos 
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/toshiba_acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index f774cb576ffa..1ff95b5a429d 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -34,6 +34,7 @@
 #define TOSHIBA_ACPI_VERSION   "0.23"
 #define PROC_INTERFACE_VERSION 1
 
+#include 
 #include 
 #include 
 #include 
@@ -1472,7 +1473,7 @@ static const struct file_operations keys_proc_fops = {
.write  = keys_proc_write,
 };
 
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
 {
seq_printf(m, "driver:  %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface:  %d\n", PROC_INTERFACE_VERSION);
-- 
2.17.1


[PATCH AUTOSEL 4.4 28/30] s390/qeth: reset layer2 attribute on layer switch

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_sys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index fa844b0ff847..7bcf0dae3a65 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -419,6 +419,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+   card->options.layer2 = -1;
}
 
rc = qeth_core_load_discipline(card, newdis);
-- 
2.17.1


[PATCH AUTOSEL 4.4 28/30] s390/qeth: reset layer2 attribute on layer switch

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_sys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index fa844b0ff847..7bcf0dae3a65 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -419,6 +419,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+   card->options.layer2 = -1;
}
 
rc = qeth_core_load_discipline(card, newdis);
-- 
2.17.1


[PATCH AUTOSEL 3.18 02/19] ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro

2018-09-06 Thread Sasha Levin
From: Takashi Iwai 

[ Upstream commit bd1cd0eb2ce9141100628d476ead4de485501b29 ]

AU0828_DEVICE() macro in quirks-table.h uses USB_DEVICE_VENDOR_SPEC()
for expanding idVendor and idProduct fields.  However, the latter
macro adds also match_flags and bInterfaceClass, which are different
from the values AU0828_DEVICE() macro sets after that.

For fixing them, just expand idVendor and idProduct fields manually in
AU0828_DEVICE().

This fixes sparse warnings like:
  sound/usb/quirks-table.h:2892:1: warning: Initializer entry defined twice

Signed-off-by: Takashi Iwai 
Signed-off-by: Sasha Levin 
---
 sound/usb/quirks-table.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index adec087725d1..e86fecaa26ec 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2910,7 +2910,8 @@ YAMAHA_DEVICE(0x7010, "UB99"),
  */
 
 #define AU0828_DEVICE(vid, pid, vname, pname) { \
-   USB_DEVICE_VENDOR_SPEC(vid, pid), \
+   .idVendor = vid, \
+   .idProduct = pid, \
.match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
   USB_DEVICE_ID_MATCH_INT_CLASS | \
   USB_DEVICE_ID_MATCH_INT_SUBCLASS, \
-- 
2.17.1


[PATCH AUTOSEL 4.4 29/30] platform/x86: toshiba_acpi: Fix defined but not used build warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]

Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show' 
defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Azael Avalos 
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/toshiba_acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index f774cb576ffa..1ff95b5a429d 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -34,6 +34,7 @@
 #define TOSHIBA_ACPI_VERSION   "0.23"
 #define PROC_INTERFACE_VERSION 1
 
+#include 
 #include 
 #include 
 #include 
@@ -1472,7 +1473,7 @@ static const struct file_operations keys_proc_fops = {
.write  = keys_proc_write,
 };
 
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
 {
seq_printf(m, "driver:  %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface:  %d\n", PROC_INTERFACE_VERSION);
-- 
2.17.1


[PATCH AUTOSEL 3.18 08/19] iio: ad9523: Fix displayed phase

2018-09-06 Thread Sasha Levin
From: Lars-Peter Clausen 

[ Upstream commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e ]

Fix the displayed phase for the ad9523 driver. Currently the most
significant decimal place is dropped and all other digits are shifted one
to the left. This is due to a multiplication by 10, which is not necessary,
so remove it.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Alexandru Ardelean 
Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock 
Generator")
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/frequency/ad9523.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c
index 7c5245d9f99c..abc21d913ef0 100644
--- a/drivers/iio/frequency/ad9523.c
+++ b/drivers/iio/frequency/ad9523.c
@@ -641,7 +641,7 @@ static int ad9523_read_raw(struct iio_dev *indio_dev,
code = (AD9523_CLK_DIST_DIV_PHASE_REV(ret) * 3141592) /
AD9523_CLK_DIST_DIV_REV(ret);
*val = code / 100;
-   *val2 = (code % 100) * 10;
+   *val2 = code % 100;
return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
-- 
2.17.1


[PATCH AUTOSEL 3.18 08/19] iio: ad9523: Fix displayed phase

2018-09-06 Thread Sasha Levin
From: Lars-Peter Clausen 

[ Upstream commit 5a4e33c1c53ae7d4425f7d94e60e4458a37b349e ]

Fix the displayed phase for the ad9523 driver. Currently the most
significant decimal place is dropped and all other digits are shifted one
to the left. This is due to a multiplication by 10, which is not necessary,
so remove it.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Alexandru Ardelean 
Fixes: cd1678f9632 ("iio: frequency: New driver for AD9523 SPI Low Jitter Clock 
Generator")
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin 
---
 drivers/iio/frequency/ad9523.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c
index 7c5245d9f99c..abc21d913ef0 100644
--- a/drivers/iio/frequency/ad9523.c
+++ b/drivers/iio/frequency/ad9523.c
@@ -641,7 +641,7 @@ static int ad9523_read_raw(struct iio_dev *indio_dev,
code = (AD9523_CLK_DIST_DIV_PHASE_REV(ret) * 3141592) /
AD9523_CLK_DIST_DIV_REV(ret);
*val = code / 100;
-   *val2 = (code % 100) * 10;
+   *val2 = code % 100;
return IIO_VAL_INT_PLUS_MICRO;
default:
return -EINVAL;
-- 
2.17.1


[PATCH AUTOSEL 3.18 13/19] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 388f7971494b..620d9ec664e1 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -533,7 +533,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -542,10 +542,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -586,7 +586,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -637,9 +638,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -708,11 +717,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 4.4 18/30] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index bd630c222e65..9d1f6e976a5a 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 4.9 40/43] KVM: arm/arm64: Fix vgic init race

2018-09-06 Thread Sasha Levin
From: Christoffer Dall 

[ Upstream commit 1d47191de7e15900f8fbfe7cccd7c6e1c2d7c31a ]

The vgic_init function can race with kvm_arch_vcpu_create() which does
not hold kvm_lock() and we therefore have no synchronization primitives
to ensure we're doing the right thing.

As the user is trying to initialize or run the VM while at the same time
creating more VCPUs, we just have to refuse to initialize the VGIC in
this case rather than silently failing with a broken VCPU.

Reviewed-by: Eric Auger 
Signed-off-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 virt/kvm/arm/vgic/vgic-init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 539d3f5cb619..80d549ee 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -241,6 +241,10 @@ int vgic_init(struct kvm *kvm)
if (vgic_initialized(kvm))
return 0;
 
+   /* Are we also in the middle of creating a VCPU? */
+   if (kvm->created_vcpus != atomic_read(>online_vcpus))
+   return -EBUSY;
+
/* freeze the number of spis */
if (!dist->nr_spis)
dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
-- 
2.17.1


[PATCH AUTOSEL 3.18 09/19] fbdev: omapfb: off by one in omapfb_register_client()

2018-09-06 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 
Cc: Imre Deak 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index d8d028d98711..42cf6381e449 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -982,7 +982,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
-- 
2.17.1


[PATCH AUTOSEL 3.18 03/19] xfrm: fix 'passing zero to ERR_PTR()' warning

2018-09-06 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]

Fix a static code checker warning:

  net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing 
zero to 'ERR_PTR'

xfrm_tmpl_resolve return 0 just means no xdst found, return NULL
instead of passing zero to ERR_PTR.

Fixes: d809ec895505 ("xfrm: do not assume that template resolving always 
returns xfrms")
Signed-off-by: YueHaibing 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_policy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index d81f27046582..84c4228fbbe7 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1809,7 +1809,10 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy 
**pols, int num_pols,
/* Try to instantiate a bundle */
err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
if (err <= 0) {
-   if (err != 0 && err != -EAGAIN)
+   if (err == 0)
+   return NULL;
+
+   if (err != -EAGAIN)
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
return ERR_PTR(err);
}
-- 
2.17.1


[PATCH AUTOSEL 4.4 27/30] s390/qeth: fix race in used-buffer accounting

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]

By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 95c631125a20..09ac56317f1b 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3505,13 +3505,14 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q 
*queue, int index,
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+   atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
 queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
-   atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
-- 
2.17.1


[PATCH AUTOSEL 3.18 15/19] powerpc/powernv: opal_put_chars partial write fix

2018-09-06 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]

The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.

This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.

Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index d019b081df9d..ff3e1fe4936b 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -452,7 +452,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int 
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
-   written = total_len;
+   written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
-- 
2.17.1


[PATCH AUTOSEL 3.18 05/19] MIPS: ath79: fix system restart

2018-09-06 Thread Sasha Levin
From: Felix Fietkau 

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed
due to pending interrupts.

Signed-off-by: Felix Fietkau 
Signed-off-by: John Crispin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19913/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Signed-off-by: Sasha Levin 
---
 arch/mips/ath79/setup.c  | 1 +
 arch/mips/include/asm/mach-ath79/ath79.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 64807a4809d0..2b3b66780152 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -40,6 +40,7 @@ static char ath79_sys_type[ATH79_SYS_TYPE_LEN];
 
 static void ath79_restart(char *command)
 {
+   local_irq_disable();
ath79_device_reset_set(AR71XX_RESET_FULL_CHIP);
for (;;)
if (cpu_wait)
diff --git a/arch/mips/include/asm/mach-ath79/ath79.h 
b/arch/mips/include/asm/mach-ath79/ath79.h
index 1557934aaca9..39a10a136f53 100644
--- a/arch/mips/include/asm/mach-ath79/ath79.h
+++ b/arch/mips/include/asm/mach-ath79/ath79.h
@@ -132,6 +132,7 @@ static inline u32 ath79_pll_rr(unsigned reg)
 static inline void ath79_reset_wr(unsigned reg, u32 val)
 {
__raw_writel(val, ath79_reset_base + reg);
+   (void) __raw_readl(ath79_reset_base + reg); /* flush */
 }
 
 static inline u32 ath79_reset_rr(unsigned reg)
-- 
2.17.1


[PATCH AUTOSEL 3.18 10/19] video: goldfishfb: fix memory leak on driver remove

2018-09-06 Thread Sasha Levin
From: Anton Vasilyev 

[ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ]

goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does
not have deallocation of fb, which leads to memory leak on probe/remove.

The patch adds deallocation into goldfish_fb_remove().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Cc: Aleksandar Markovic 
Cc: Miodrag Dinic 
Cc: Goran Ferenc 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/goldfishfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6cfc6c..14a93cb21310 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, framesize, (void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
iounmap(fb->reg_base);
+   kfree(fb);
return 0;
 }
 
-- 
2.17.1


[PATCH AUTOSEL 4.4 18/30] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index bd630c222e65..9d1f6e976a5a 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 4.9 40/43] KVM: arm/arm64: Fix vgic init race

2018-09-06 Thread Sasha Levin
From: Christoffer Dall 

[ Upstream commit 1d47191de7e15900f8fbfe7cccd7c6e1c2d7c31a ]

The vgic_init function can race with kvm_arch_vcpu_create() which does
not hold kvm_lock() and we therefore have no synchronization primitives
to ensure we're doing the right thing.

As the user is trying to initialize or run the VM while at the same time
creating more VCPUs, we just have to refuse to initialize the VGIC in
this case rather than silently failing with a broken VCPU.

Reviewed-by: Eric Auger 
Signed-off-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 virt/kvm/arm/vgic/vgic-init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 539d3f5cb619..80d549ee 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -241,6 +241,10 @@ int vgic_init(struct kvm *kvm)
if (vgic_initialized(kvm))
return 0;
 
+   /* Are we also in the middle of creating a VCPU? */
+   if (kvm->created_vcpus != atomic_read(>online_vcpus))
+   return -EBUSY;
+
/* freeze the number of spis */
if (!dist->nr_spis)
dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
-- 
2.17.1


[PATCH AUTOSEL 3.18 09/19] fbdev: omapfb: off by one in omapfb_register_client()

2018-09-06 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 
Cc: Imre Deak 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index d8d028d98711..42cf6381e449 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -982,7 +982,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
-- 
2.17.1


[PATCH AUTOSEL 3.18 03/19] xfrm: fix 'passing zero to ERR_PTR()' warning

2018-09-06 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]

Fix a static code checker warning:

  net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing 
zero to 'ERR_PTR'

xfrm_tmpl_resolve return 0 just means no xdst found, return NULL
instead of passing zero to ERR_PTR.

Fixes: d809ec895505 ("xfrm: do not assume that template resolving always 
returns xfrms")
Signed-off-by: YueHaibing 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_policy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index d81f27046582..84c4228fbbe7 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1809,7 +1809,10 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy 
**pols, int num_pols,
/* Try to instantiate a bundle */
err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
if (err <= 0) {
-   if (err != 0 && err != -EAGAIN)
+   if (err == 0)
+   return NULL;
+
+   if (err != -EAGAIN)
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
return ERR_PTR(err);
}
-- 
2.17.1


[PATCH AUTOSEL 4.4 27/30] s390/qeth: fix race in used-buffer accounting

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]

By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 95c631125a20..09ac56317f1b 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3505,13 +3505,14 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q 
*queue, int index,
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+   atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
 queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
-   atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
-- 
2.17.1


[PATCH AUTOSEL 3.18 15/19] powerpc/powernv: opal_put_chars partial write fix

2018-09-06 Thread Sasha Levin
From: Nicholas Piggin 

[ Upstream commit bd90284cc6c1c9e8e48c8eadd0c79574fcce0b81 ]

The intention here is to consume and discard the remaining buffer
upon error. This works if there has not been a previous partial write.
If there has been, then total_len is no longer total number of bytes
to copy. total_len is always "bytes left to copy", so it should be
added to written bytes.

This code may not be exercised any more if partial writes will not be
hit, but this is a small bugfix before a larger change.

Reviewed-by: Benjamin Herrenschmidt 
Signed-off-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/platforms/powernv/opal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index d019b081df9d..ff3e1fe4936b 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -452,7 +452,7 @@ int opal_put_chars(uint32_t vtermno, const char *data, int 
total_len)
/* Closed or other error drop */
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY &&
rc != OPAL_BUSY_EVENT) {
-   written = total_len;
+   written += total_len;
break;
}
if (rc == OPAL_SUCCESS) {
-- 
2.17.1


[PATCH AUTOSEL 3.18 13/19] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 388f7971494b..620d9ec664e1 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -533,7 +533,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -542,10 +542,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -586,7 +586,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -637,9 +638,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -708,11 +717,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 3.18 05/19] MIPS: ath79: fix system restart

2018-09-06 Thread Sasha Levin
From: Felix Fietkau 

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed
due to pending interrupts.

Signed-off-by: Felix Fietkau 
Signed-off-by: John Crispin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19913/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Signed-off-by: Sasha Levin 
---
 arch/mips/ath79/setup.c  | 1 +
 arch/mips/include/asm/mach-ath79/ath79.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 64807a4809d0..2b3b66780152 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -40,6 +40,7 @@ static char ath79_sys_type[ATH79_SYS_TYPE_LEN];
 
 static void ath79_restart(char *command)
 {
+   local_irq_disable();
ath79_device_reset_set(AR71XX_RESET_FULL_CHIP);
for (;;)
if (cpu_wait)
diff --git a/arch/mips/include/asm/mach-ath79/ath79.h 
b/arch/mips/include/asm/mach-ath79/ath79.h
index 1557934aaca9..39a10a136f53 100644
--- a/arch/mips/include/asm/mach-ath79/ath79.h
+++ b/arch/mips/include/asm/mach-ath79/ath79.h
@@ -132,6 +132,7 @@ static inline u32 ath79_pll_rr(unsigned reg)
 static inline void ath79_reset_wr(unsigned reg, u32 val)
 {
__raw_writel(val, ath79_reset_base + reg);
+   (void) __raw_readl(ath79_reset_base + reg); /* flush */
 }
 
 static inline u32 ath79_reset_rr(unsigned reg)
-- 
2.17.1


[PATCH AUTOSEL 3.18 10/19] video: goldfishfb: fix memory leak on driver remove

2018-09-06 Thread Sasha Levin
From: Anton Vasilyev 

[ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ]

goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does
not have deallocation of fb, which leads to memory leak on probe/remove.

The patch adds deallocation into goldfish_fb_remove().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Cc: Aleksandar Markovic 
Cc: Miodrag Dinic 
Cc: Goran Ferenc 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/goldfishfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6cfc6c..14a93cb21310 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, framesize, (void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
iounmap(fb->reg_base);
+   kfree(fb);
return 0;
 }
 
-- 
2.17.1


[PATCH AUTOSEL 3.18 18/19] s390/qeth: reset layer2 attribute on layer switch

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_sys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index 9d5f746faf72..9eeabfe30747 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -456,6 +456,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+   card->options.layer2 = -1;
}
 
rc = qeth_core_load_discipline(card, newdis);
-- 
2.17.1


[PATCH AUTOSEL 3.18 16/19] mac80211: restrict delayed tailroom needed decrement

2018-09-06 Thread Sasha Levin
From: Manikanta Pubbisetty 

[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]

As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.

For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.

* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
  (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
  there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
  (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)

Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.

Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)

Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.

Signed-off-by: Manikanta Pubbisetty 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/cfg.c |  2 +-
 net/mac80211/key.c | 24 +++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index d061814d1ae1..9d224151f639 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -276,7 +276,7 @@ static int ieee80211_del_key(struct wiphy *wiphy, struct 
net_device *dev,
goto out_unlock;
}
 
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
 
ret = 0;
  out_unlock:
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 375ff902a142..6bd74d2556ae 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -515,11 +515,15 @@ int ieee80211_key_link(struct ieee80211_key *key,
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
-   int idx, ret;
-   bool pairwise;
-
-   pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
-   idx = key->conf.keyidx;
+   int idx = key->conf.keyidx;
+   bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+   /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+   bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+   int ret;
 
mutex_lock(>local->key_mtx);
 
@@ -547,14 +551,14 @@ int ieee80211_key_link(struct ieee80211_key *key,
increment_tailroom_need_count(sdata);
 
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
-   ieee80211_key_destroy(old_key, true);
+   ieee80211_key_destroy(old_key, delay_tailroom);
 
ieee80211_debugfs_key_add(key);
 
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -705,7 +709,8 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local,
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
-   __ieee80211_key_destroy(key, true);
+   

[PATCH AUTOSEL 3.18 18/19] s390/qeth: reset layer2 attribute on layer switch

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_sys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index 9d5f746faf72..9eeabfe30747 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -456,6 +456,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+   card->options.layer2 = -1;
}
 
rc = qeth_core_load_discipline(card, newdis);
-- 
2.17.1


[PATCH AUTOSEL 3.18 16/19] mac80211: restrict delayed tailroom needed decrement

2018-09-06 Thread Sasha Levin
From: Manikanta Pubbisetty 

[ Upstream commit 133bf90dbb8b873286f8ec2e81ba26e863114b8c ]

As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed
decrement for other iftypes may be unnecessary.

For example, let's consider the case of a 4-addr client connecting to
an AP for which AP_VLAN interface is also created, let the initial
value for tailroom_needed on the AP be 1.

* 4-addr client connects to the AP (AP: tailroom_needed = 1)
* AP will clear old keys, delay decrement of tailroom_needed count
* AP_VLAN is created, it takes the tailroom count from master
  (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
* Install new key for the station, assume key is plumbed in the HW,
  there won't be any change in tailroom_needed count on AP iface
* Delayed decrement of tailroom_needed count on AP
  (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)

Because of the delayed decrement on AP iface, tailroom_needed count goes
out of sync between AP(master iface) and AP_VLAN(slave iface) and
there would be unnecessary tailroom created for the packets going
through AP_VLAN iface.

Also, WARN_ONs were observed while trying to bring down the AP_VLAN
interface:
(warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
(warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
(ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
(ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
(ieee80211_stop) (__dev_close_many+0x94/0xb8)
(__dev_close_many) (dev_close_many+0x5c/0xc8)

Restricting delayed decrement to station interface alone fixes the problem
and it makes sense to do so because delayed decrement is done to improve
roam time which is applicable only for client devices.

Signed-off-by: Manikanta Pubbisetty 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin 
---
 net/mac80211/cfg.c |  2 +-
 net/mac80211/key.c | 24 +++-
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index d061814d1ae1..9d224151f639 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -276,7 +276,7 @@ static int ieee80211_del_key(struct wiphy *wiphy, struct 
net_device *dev,
goto out_unlock;
}
 
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, sdata->vif.type == NL80211_IFTYPE_STATION);
 
ret = 0;
  out_unlock:
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index 375ff902a142..6bd74d2556ae 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -515,11 +515,15 @@ int ieee80211_key_link(struct ieee80211_key *key,
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_key *old_key;
-   int idx, ret;
-   bool pairwise;
-
-   pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
-   idx = key->conf.keyidx;
+   int idx = key->conf.keyidx;
+   bool pairwise = key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE;
+   /*
+* We want to delay tailroom updates only for station - in that
+* case it helps roaming speed, but in other cases it hurts and
+* can cause warnings to appear.
+*/
+   bool delay_tailroom = sdata->vif.type == NL80211_IFTYPE_STATION;
+   int ret;
 
mutex_lock(>local->key_mtx);
 
@@ -547,14 +551,14 @@ int ieee80211_key_link(struct ieee80211_key *key,
increment_tailroom_need_count(sdata);
 
ieee80211_key_replace(sdata, sta, pairwise, old_key, key);
-   ieee80211_key_destroy(old_key, true);
+   ieee80211_key_destroy(old_key, delay_tailroom);
 
ieee80211_debugfs_key_add(key);
 
if (!local->wowlan) {
ret = ieee80211_key_enable_hw_accel(key);
if (ret)
-   ieee80211_key_free(key, true);
+   ieee80211_key_free(key, delay_tailroom);
} else {
ret = 0;
}
@@ -705,7 +709,8 @@ void ieee80211_free_sta_keys(struct ieee80211_local *local,
ieee80211_key_replace(key->sdata, key->sta,
key->conf.flags & IEEE80211_KEY_FLAG_PAIRWISE,
key, NULL);
-   __ieee80211_key_destroy(key, true);
+   

[PATCH AUTOSEL 4.4 26/30] arm64: dts: qcom: db410c: Fix Bluetooth LED trigger

2018-09-06 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit e53db018315b7660bb7000a29e79faff2496c2c2 ]

Current LED trigger, 'bt', is not known/used by any existing driver.
Fix this by renaming it to 'bluetooth-power' trigger which is
controlled by the Bluetooth subsystem.

Fixes: 9943230c8860 ("arm64: dts: qcom: Add apq8016-sbc board LED's related 
device nodes")
Signed-off-by: Loic Poulain 
Signed-off-by: Andy Gross 
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6b8abbe68746..3011c88bd2f3 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -105,7 +105,7 @@
led@6 {
label = "apq8016-sbc:blue:bt";
gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "bt";
+   linux,default-trigger = "bluetooth-power";
default-state = "off";
};
};
-- 
2.17.1


[PATCH AUTOSEL 3.18 17/19] s390/qeth: fix race in used-buffer accounting

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]

By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 906e8014ebb9..595c140cc79c 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3489,13 +3489,14 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q 
*queue, int index,
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+   atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
 queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
-   atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
-- 
2.17.1


[PATCH AUTOSEL 3.18 12/19] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index 8e24f39f9158..b070893bfcfe 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 3.18 19/19] platform/x86: toshiba_acpi: Fix defined but not used build warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]

Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show' 
defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Azael Avalos 
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/toshiba_acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index ab6151f05420..c0b64e571a5e 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -41,6 +41,7 @@
 #define TOSHIBA_ACPI_VERSION   "0.20"
 #define PROC_INTERFACE_VERSION 1
 
+#include 
 #include 
 #include 
 #include 
@@ -1233,7 +1234,7 @@ static const struct file_operations keys_proc_fops = {
.write  = keys_proc_write,
 };
 
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
 {
seq_printf(m, "driver:  %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface:  %d\n", PROC_INTERFACE_VERSION);
-- 
2.17.1


[PATCH AUTOSEL 3.18 04/19] gfs2: Special-case rindex for gfs2_grow

2018-09-06 Thread Sasha Levin
From: Andreas Gruenbacher 

[ Upstream commit 776125785a87ff05d49938bd5b9f336f2a05bff6 ]

To speed up the common case of appending to a file,
gfs2_write_alloc_required presumes that writing beyond the end of a file
will always require additional blocks to be allocated.  This assumption
is incorrect for preallocates files, but there are no negative
consequences as long as *some* space is still left on the filesystem.

One special file that always has some space preallocated beyond the end
of the file is the rindex: when growing a filesystem, gfs2_grow adds one
or more new resource groups and appends records describing those
resource groups to the rindex; the preallocated space ensures that this
is always possible.

However, when a filesystem is completely full, gfs2_write_alloc_required
will indicate that an additional allocation is required, and appending
the next record to the rindex will fail even though space for that
record has already been preallocated.  To fix that, skip the incorrect
optimization in gfs2_write_alloc_required, but for the rindex only.
Other writes to preallocated space beyond the end of the file are still
allowed to fail on completely full filesystems.

Signed-off-by: Andreas Gruenbacher 
Reviewed-by: Bob Peterson 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/bmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
index f0b945ab853e..2f29c2a81448 100644
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -1476,7 +1476,7 @@ int gfs2_write_alloc_required(struct gfs2_inode *ip, u64 
offset,
end_of_file = (i_size_read(>i_inode) + sdp->sd_sb.sb_bsize - 1) >> 
shift;
lblock = offset >> shift;
lblock_stop = (offset + len + sdp->sd_sb.sb_bsize - 1) >> shift;
-   if (lblock_stop > end_of_file)
+   if (lblock_stop > end_of_file && ip != GFS2_I(sdp->sd_rindex))
return 1;
 
size = (lblock_stop - lblock) << shift;
-- 
2.17.1


[PATCH AUTOSEL 4.4 25/30] xen-netfront: fix queue name setting

2018-09-06 Thread Sasha Levin
From: Vitaly Kuznetsov 

[ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]

Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:

 60:139  0   xen-dyn-event eth%d-q0-tx
 61:265  0   xen-dyn-event eth%d-q0-rx
 62:234  0   xen-dyn-event eth%d-q1-tx
 63:  1  0   xen-dyn-event eth%d-q1-rx

and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.

Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like

 62:202  0   xen-dyn-event device/vif/0-q0-tx
 63:317  0   xen-dyn-event device/vif/0-q0-rx
 64:262  0   xen-dyn-event device/vif/0-q1-tx
 65: 17  0   xen-dyn-event device/vif/0-q1-rx

Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Ross Lagerwall 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/xen-netfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 68d0a5c9d437..2c0db518fe14 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1616,7 +1616,7 @@ static int xennet_init_queue(struct netfront_queue *queue)
(unsigned long)queue);
 
snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->netdev->name, queue->id);
+queue->info->xbdev->nodename, queue->id);
 
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
-- 
2.17.1


[PATCH AUTOSEL 3.18 14/19] perf powerpc: Fix callchain ip filtering

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit c715fcfda5a08edabaa15508742be926b7ee51db ]

For powerpc64, redundant entries in the callchain are filtered out by
determining the state of the return address and the stack frame using
DWARF debug information.

For making these filtering decisions we must analyze the debug
information for the location corresponding to the program counter value,
i.e. the first entry in the callchain, and not the LR value; otherwise,
perf may filter out either the second or the third entry in the
callchain incorrectly.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28).
 Return address is still in LR and a new stack frame is not yet
 allocated. The LR value, i.e. the second entry, should not be
 filtered out.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0010eb10 :
  ...
10fa48:   78 bb e4 7e mr  r4,r23
10fa4c:   0a 00 60 38 li  r3,10
10fa50:   d9 b4 04 48 bl  15af28 
10fa54:   00 00 00 60 nop
10fa58:   ac f4 ff 4b b   10ef04 
  ...
  00110450 :
  ...
1105a8:   54 00 ff 38 addir7,r31,84
1105ac:   58 00 df 38 addir6,r31,88
1105b0:   69 e5 ff 4b bl  10eb18 
1105b4:   78 1b 71 7c mr  r17,r3
1105b8:   50 01 7f e8 ld  r3,336(r31)
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
  7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
  7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 13fb52d70 _init+0xbfc (/usr/bin/ping)
  7fffa7c836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
  7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
  7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 13fb52d70 _init+0xbfc (/usr/bin/ping)
  7fffa7c836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10).
 Return address in still in LR and a new stack frame has already
 been allocated but not used. The caller's caller, i.e. the third
 entry, is invalid and should be filtered out and not the second
 one.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0009cd90 <_int_malloc>:
 9cd90:   17 00 4c 3c addis   r2,r12,23
 9cd94:   70 a3 42 38 addir2,r2,-23696
 9cd98:   26 00 80 7d mfcrr12
 9cd9c:   f8 ff e1 fb std r31,-8(r1)
 9cda0:   17 00 e4 3b addir31,r4,23
 9cda4:   d8 ff 61 fb std r27,-40(r1)
 9cda8:   78 23 9b 7c mr  r27,r4
 9cdac:   1f 00 bf 2b cmpldi  cr7,r31,31
 9cdb0:   f0 ff c1 fb std r30,-16(r1)
 9cdb4:   b0 ff c1 fa std r22,-80(r1)
 9cdb8:   78 1b 7e 7c mr  r30,r3
 9cdbc:   08 00 81 91 stw r12,8(r1)
 9cdc0:   11 ff 21 f8 stdur1,-240(r1)
 9cdc4:   4c 01 9d 41 bgt cr7,9cf10 <_int_malloc+0x180>
 9cdc8:   20 00 a4 2b cmpldi  cr7,r4,32
  ...
 9cf08:   00 00 00 60 nop
 9cf0c:   00 00 42 60 ori r2,r2,0
 9cf10:   e4 06 ff 7b rldicr  r31,r31,0,59
 9cf14:   40 f8 a4 7f cmpld   cr7,r4,r31
 9cf18:   68 05 9d 41 bgt cr7,9d480 <_int_malloc+0x6f0>
  ...
  0009e3c0 :
  ...
 9e420:   40 02 80 38 li  r4,576
 9e424:   78 fb e3 7f mr  r3,r31
 9e428:   71 e9 ff 4b bl  9cd98 <_int_malloc+0x8>
 9e42c:   00 00 a3 2f cmpdi   cr7,r3,0
 9e430:   78 1b 7e 7c mr  r30,r3
  ...
  0009f7a0 <__libc_malloc>:
  ...
 9f8f8:   00 00 89 2f cmpwi   cr7,r9,0
 9f8fc:   1c ff 9e 40 bne cr7,9f818 <__libc_malloc+0x78>
 9f900:   c9 ea ff 4b bl  9e3c8 
 9f904:   00 00 00 60 nop
 9f908:

[PATCH AUTOSEL 4.4 26/30] arm64: dts: qcom: db410c: Fix Bluetooth LED trigger

2018-09-06 Thread Sasha Levin
From: Loic Poulain 

[ Upstream commit e53db018315b7660bb7000a29e79faff2496c2c2 ]

Current LED trigger, 'bt', is not known/used by any existing driver.
Fix this by renaming it to 'bluetooth-power' trigger which is
controlled by the Bluetooth subsystem.

Fixes: 9943230c8860 ("arm64: dts: qcom: Add apq8016-sbc board LED's related 
device nodes")
Signed-off-by: Loic Poulain 
Signed-off-by: Andy Gross 
Signed-off-by: Sasha Levin 
---
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi 
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 6b8abbe68746..3011c88bd2f3 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -105,7 +105,7 @@
led@6 {
label = "apq8016-sbc:blue:bt";
gpios = <_mpps 3 GPIO_ACTIVE_HIGH>;
-   linux,default-trigger = "bt";
+   linux,default-trigger = "bluetooth-power";
default-state = "off";
};
};
-- 
2.17.1


[PATCH AUTOSEL 3.18 17/19] s390/qeth: fix race in used-buffer accounting

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit a702349a4099cd5a7bab0904689d8e0bf8dcd622 ]

By updating q->used_buffers only _after_ do_QDIO() has completed, there
is a potential race against the buffer's TX completion. In the unlikely
case that the TX completion path wins, qeth_qdio_output_handler() would
decrement the counter before qeth_flush_buffers() even incremented it.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/s390/net/qeth_core_main.c 
b/drivers/s390/net/qeth_core_main.c
index 906e8014ebb9..595c140cc79c 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -3489,13 +3489,14 @@ static void qeth_flush_buffers(struct qeth_qdio_out_q 
*queue, int index,
qdio_flags = QDIO_FLAG_SYNC_OUTPUT;
if (atomic_read(>set_pci_flags_count))
qdio_flags |= QDIO_FLAG_PCI_OUT;
+   atomic_add(count, >used_buffers);
+
rc = do_QDIO(CARD_DDEV(queue->card), qdio_flags,
 queue->queue_no, index, count);
if (queue->card->options.performance_stats)
queue->card->perf_stats.outbound_do_qdio_time +=
qeth_get_micros() -
queue->card->perf_stats.outbound_do_qdio_start_time;
-   atomic_add(count, >used_buffers);
if (rc) {
queue->card->stats.tx_errors += count;
/* ignore temporary SIGA errors without busy condition */
-- 
2.17.1


[PATCH AUTOSEL 3.18 12/19] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index 8e24f39f9158..b070893bfcfe 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 3.18 19/19] platform/x86: toshiba_acpi: Fix defined but not used build warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit c2e2a618eb7104e18fdcf739d4d911563812a81c ]

Fix a build warning in toshiba_acpi.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/platform/x86/toshiba_acpi.c:1685:12: warning: 'version_proc_show' 
defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Azael Avalos 
Cc: platform-driver-...@vger.kernel.org
Cc: Andy Shevchenko 
Signed-off-by: Darren Hart (VMware) 
Signed-off-by: Sasha Levin 
---
 drivers/platform/x86/toshiba_acpi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/toshiba_acpi.c 
b/drivers/platform/x86/toshiba_acpi.c
index ab6151f05420..c0b64e571a5e 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -41,6 +41,7 @@
 #define TOSHIBA_ACPI_VERSION   "0.20"
 #define PROC_INTERFACE_VERSION 1
 
+#include 
 #include 
 #include 
 #include 
@@ -1233,7 +1234,7 @@ static const struct file_operations keys_proc_fops = {
.write  = keys_proc_write,
 };
 
-static int version_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused version_proc_show(struct seq_file *m, void *v)
 {
seq_printf(m, "driver:  %s\n", TOSHIBA_ACPI_VERSION);
seq_printf(m, "proc_interface:  %d\n", PROC_INTERFACE_VERSION);
-- 
2.17.1


[PATCH AUTOSEL 3.18 04/19] gfs2: Special-case rindex for gfs2_grow

2018-09-06 Thread Sasha Levin
From: Andreas Gruenbacher 

[ Upstream commit 776125785a87ff05d49938bd5b9f336f2a05bff6 ]

To speed up the common case of appending to a file,
gfs2_write_alloc_required presumes that writing beyond the end of a file
will always require additional blocks to be allocated.  This assumption
is incorrect for preallocates files, but there are no negative
consequences as long as *some* space is still left on the filesystem.

One special file that always has some space preallocated beyond the end
of the file is the rindex: when growing a filesystem, gfs2_grow adds one
or more new resource groups and appends records describing those
resource groups to the rindex; the preallocated space ensures that this
is always possible.

However, when a filesystem is completely full, gfs2_write_alloc_required
will indicate that an additional allocation is required, and appending
the next record to the rindex will fail even though space for that
record has already been preallocated.  To fix that, skip the incorrect
optimization in gfs2_write_alloc_required, but for the rindex only.
Other writes to preallocated space beyond the end of the file are still
allowed to fail on completely full filesystems.

Signed-off-by: Andreas Gruenbacher 
Reviewed-by: Bob Peterson 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/bmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/gfs2/bmap.c b/fs/gfs2/bmap.c
index f0b945ab853e..2f29c2a81448 100644
--- a/fs/gfs2/bmap.c
+++ b/fs/gfs2/bmap.c
@@ -1476,7 +1476,7 @@ int gfs2_write_alloc_required(struct gfs2_inode *ip, u64 
offset,
end_of_file = (i_size_read(>i_inode) + sdp->sd_sb.sb_bsize - 1) >> 
shift;
lblock = offset >> shift;
lblock_stop = (offset + len + sdp->sd_sb.sb_bsize - 1) >> shift;
-   if (lblock_stop > end_of_file)
+   if (lblock_stop > end_of_file && ip != GFS2_I(sdp->sd_rindex))
return 1;
 
size = (lblock_stop - lblock) << shift;
-- 
2.17.1


[PATCH AUTOSEL 4.4 25/30] xen-netfront: fix queue name setting

2018-09-06 Thread Sasha Levin
From: Vitaly Kuznetsov 

[ Upstream commit 2d408c0d4574b01b9ed45e02516888bf925e11a9 ]

Commit f599c64fdf7d ("xen-netfront: Fix race between device setup and
open") changed the initialization order: xennet_create_queues() now
happens before we do register_netdev() so using netdev->name in
xennet_init_queue() is incorrect, we end up with the following in
/proc/interrupts:

 60:139  0   xen-dyn-event eth%d-q0-tx
 61:265  0   xen-dyn-event eth%d-q0-rx
 62:234  0   xen-dyn-event eth%d-q1-tx
 63:  1  0   xen-dyn-event eth%d-q1-rx

and this looks ugly. Actually, using early netdev name (even when it's
already set) is also not ideal: nowadays we tend to rename eth devices
and queue name may end up not corresponding to the netdev name.

Use nodename from xenbus device for queue naming: this can't change in VM's
lifetime. Now /proc/interrupts looks like

 62:202  0   xen-dyn-event device/vif/0-q0-tx
 63:317  0   xen-dyn-event device/vif/0-q0-rx
 64:262  0   xen-dyn-event device/vif/0-q1-tx
 65: 17  0   xen-dyn-event device/vif/0-q1-rx

Fixes: f599c64fdf7d ("xen-netfront: Fix race between device setup and open")
Signed-off-by: Vitaly Kuznetsov 
Reviewed-by: Ross Lagerwall 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/xen-netfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 68d0a5c9d437..2c0db518fe14 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1616,7 +1616,7 @@ static int xennet_init_queue(struct netfront_queue *queue)
(unsigned long)queue);
 
snprintf(queue->name, sizeof(queue->name), "%s-q%u",
-queue->info->netdev->name, queue->id);
+queue->info->xbdev->nodename, queue->id);
 
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
-- 
2.17.1


[PATCH AUTOSEL 3.18 14/19] perf powerpc: Fix callchain ip filtering

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit c715fcfda5a08edabaa15508742be926b7ee51db ]

For powerpc64, redundant entries in the callchain are filtered out by
determining the state of the return address and the stack frame using
DWARF debug information.

For making these filtering decisions we must analyze the debug
information for the location corresponding to the program counter value,
i.e. the first entry in the callchain, and not the LR value; otherwise,
perf may filter out either the second or the third entry in the
callchain incorrectly.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28).
 Return address is still in LR and a new stack frame is not yet
 allocated. The LR value, i.e. the second entry, should not be
 filtered out.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0010eb10 :
  ...
10fa48:   78 bb e4 7e mr  r4,r23
10fa4c:   0a 00 60 38 li  r3,10
10fa50:   d9 b4 04 48 bl  15af28 
10fa54:   00 00 00 60 nop
10fa58:   ac f4 ff 4b b   10ef04 
  ...
  00110450 :
  ...
1105a8:   54 00 ff 38 addir7,r31,84
1105ac:   58 00 df 38 addir6,r31,88
1105b0:   69 e5 ff 4b bl  10eb18 
1105b4:   78 1b 71 7c mr  r17,r3
1105b8:   50 01 7f e8 ld  r3,336(r31)
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
  7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
  7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 13fb52d70 _init+0xbfc (/usr/bin/ping)
  7fffa7c836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
  7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
  7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 13fb52d70 _init+0xbfc (/usr/bin/ping)
  7fffa7c836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10).
 Return address in still in LR and a new stack frame has already
 been allocated but not used. The caller's caller, i.e. the third
 entry, is invalid and should be filtered out and not the second
 one.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0009cd90 <_int_malloc>:
 9cd90:   17 00 4c 3c addis   r2,r12,23
 9cd94:   70 a3 42 38 addir2,r2,-23696
 9cd98:   26 00 80 7d mfcrr12
 9cd9c:   f8 ff e1 fb std r31,-8(r1)
 9cda0:   17 00 e4 3b addir31,r4,23
 9cda4:   d8 ff 61 fb std r27,-40(r1)
 9cda8:   78 23 9b 7c mr  r27,r4
 9cdac:   1f 00 bf 2b cmpldi  cr7,r31,31
 9cdb0:   f0 ff c1 fb std r30,-16(r1)
 9cdb4:   b0 ff c1 fa std r22,-80(r1)
 9cdb8:   78 1b 7e 7c mr  r30,r3
 9cdbc:   08 00 81 91 stw r12,8(r1)
 9cdc0:   11 ff 21 f8 stdur1,-240(r1)
 9cdc4:   4c 01 9d 41 bgt cr7,9cf10 <_int_malloc+0x180>
 9cdc8:   20 00 a4 2b cmpldi  cr7,r4,32
  ...
 9cf08:   00 00 00 60 nop
 9cf0c:   00 00 42 60 ori r2,r2,0
 9cf10:   e4 06 ff 7b rldicr  r31,r31,0,59
 9cf14:   40 f8 a4 7f cmpld   cr7,r4,r31
 9cf18:   68 05 9d 41 bgt cr7,9d480 <_int_malloc+0x6f0>
  ...
  0009e3c0 :
  ...
 9e420:   40 02 80 38 li  r4,576
 9e424:   78 fb e3 7f mr  r3,r31
 9e428:   71 e9 ff 4b bl  9cd98 <_int_malloc+0x8>
 9e42c:   00 00 a3 2f cmpdi   cr7,r3,0
 9e430:   78 1b 7e 7c mr  r30,r3
  ...
  0009f7a0 <__libc_malloc>:
  ...
 9f8f8:   00 00 89 2f cmpwi   cr7,r9,0
 9f8fc:   1c ff 9e 40 bne cr7,9f818 <__libc_malloc+0x78>
 9f900:   c9 ea ff 4b bl  9e3c8 
 9f904:   00 00 00 60 nop
 9f908:

[PATCH AUTOSEL 3.18 11/19] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index 325c43c6ff97..34bafcd904d2 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 3.18 11/19] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index 325c43c6ff97..34bafcd904d2 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 4.4 20/30] ARM: exynos: Clear global variable on init error path

2018-09-06 Thread Sasha Levin
From: Krzysztof Kozlowski 

[ Upstream commit cd4806911cee3901bc2b5eb95603cf1958720b57 ]

For most of Exynos SoCs, Power Management Unit (PMU) address space is
mapped into global variable 'pmu_base_addr' very early when initializing
PMU interrupt controller.  A lot of other machine code depends on it so
when doing iounmap() on this address, clear the global as well to avoid
usage of invalid value (pointing to unmapped memory region).

Properly mapped PMU address space is a requirement for all other machine
code so this fix is purely theoretical.  Boot will fail immediately in
many other places after following this error path.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-exynos/suspend.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index c169cc3049aa..e8adb428dddb 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -260,6 +260,7 @@ static int __init exynos_pmu_irq_init(struct device_node 
*node,
  NULL);
if (!domain) {
iounmap(pmu_base_addr);
+   pmu_base_addr = NULL;
return -ENOMEM;
}
 
-- 
2.17.1


[PATCH AUTOSEL 4.4 20/30] ARM: exynos: Clear global variable on init error path

2018-09-06 Thread Sasha Levin
From: Krzysztof Kozlowski 

[ Upstream commit cd4806911cee3901bc2b5eb95603cf1958720b57 ]

For most of Exynos SoCs, Power Management Unit (PMU) address space is
mapped into global variable 'pmu_base_addr' very early when initializing
PMU interrupt controller.  A lot of other machine code depends on it so
when doing iounmap() on this address, clear the global as well to avoid
usage of invalid value (pointing to unmapped memory region).

Properly mapped PMU address space is a requirement for all other machine
code so this fix is purely theoretical.  Boot will fail immediately in
many other places after following this error path.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Sasha Levin 
---
 arch/arm/mach-exynos/suspend.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index c169cc3049aa..e8adb428dddb 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -260,6 +260,7 @@ static int __init exynos_pmu_irq_init(struct device_node 
*node,
  NULL);
if (!domain) {
iounmap(pmu_base_addr);
+   pmu_base_addr = NULL;
return -ENOMEM;
}
 
-- 
2.17.1


[PATCH AUTOSEL 4.9 43/43] crypto: sharah - Unregister correct algorithms for SAHARA 3

2018-09-06 Thread Sasha Levin
From: Michael Müller 

[ Upstream commit 0e7d4d932ffc23f75efb31a8c2ac2396c1b81c55 ]

This patch fixes two typos related to unregistering algorithms supported by
SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered
in case of an error. In sahara_unregister_algs the wrong array is used to
determine the iteration count.

Signed-off-by: Michael Müller 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/sahara.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 0c49956ee0ce..4d0ec7bb3bc9 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -1352,7 +1352,7 @@ static int sahara_register_algs(struct sahara_dev *dev)
 
 err_sha_v3_algs:
for (j = 0; j < k; j++)
-   crypto_unregister_ahash(_v4_algs[j]);
+   crypto_unregister_ahash(_v3_algs[j]);
 
 err_aes_algs:
for (j = 0; j < i; j++)
@@ -1368,7 +1368,7 @@ static void sahara_unregister_algs(struct sahara_dev *dev)
for (i = 0; i < ARRAY_SIZE(aes_algs); i++)
crypto_unregister_alg(_algs[i]);
 
-   for (i = 0; i < ARRAY_SIZE(sha_v4_algs); i++)
+   for (i = 0; i < ARRAY_SIZE(sha_v3_algs); i++)
crypto_unregister_ahash(_v3_algs[i]);
 
if (dev->version > SAHARA_VERSION_3)
-- 
2.17.1


[PATCH AUTOSEL 4.4 05/30] xfrm: fix 'passing zero to ERR_PTR()' warning

2018-09-06 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]

Fix a static code checker warning:

  net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing 
zero to 'ERR_PTR'

xfrm_tmpl_resolve return 0 just means no xdst found, return NULL
instead of passing zero to ERR_PTR.

Fixes: d809ec895505 ("xfrm: do not assume that template resolving always 
returns xfrms")
Signed-off-by: YueHaibing 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_policy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index f9a13b67df5e..ca690d7ebde9 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1845,7 +1845,10 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy 
**pols, int num_pols,
/* Try to instantiate a bundle */
err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
if (err <= 0) {
-   if (err != 0 && err != -EAGAIN)
+   if (err == 0)
+   return NULL;
+
+   if (err != -EAGAIN)
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
return ERR_PTR(err);
}
-- 
2.17.1


[PATCH AUTOSEL 4.4 16/30] video: goldfishfb: fix memory leak on driver remove

2018-09-06 Thread Sasha Levin
From: Anton Vasilyev 

[ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ]

goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does
not have deallocation of fb, which leads to memory leak on probe/remove.

The patch adds deallocation into goldfish_fb_remove().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Cc: Aleksandar Markovic 
Cc: Miodrag Dinic 
Cc: Goran Ferenc 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/goldfishfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6cfc6c..14a93cb21310 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, framesize, (void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
iounmap(fb->reg_base);
+   kfree(fb);
return 0;
 }
 
-- 
2.17.1


[PATCH AUTOSEL 4.4 17/30] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index badee04ef496..71b5dca95bdb 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 4.4 13/30] gfs2: Don't reject a supposedly full bitmap if we have blocks reserved

2018-09-06 Thread Sasha Levin
From: Bob Peterson 

[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]

Before this patch, you could get into situations like this:

1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
   bitmap is full because process 1's reservation is skipped over.
   So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
   since the GBF_FULL bit is set, it skips over the rgrp and searches
   elsewhere, thus not using its own reservation.

This patch adds an additional check to allow processes to use their
own reservations.

Signed-off-by: Bob Peterson 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/rgrp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index c134c0462cee..220f9f767307 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1691,7 +1691,8 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state, 
u32 *minext,
 
while(1) {
bi = rbm_bi(rbm);
-   if (test_bit(GBF_FULL, >bi_flags) &&
+   if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+   test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
 
-- 
2.17.1


[PATCH AUTOSEL 4.9 43/43] crypto: sharah - Unregister correct algorithms for SAHARA 3

2018-09-06 Thread Sasha Levin
From: Michael Müller 

[ Upstream commit 0e7d4d932ffc23f75efb31a8c2ac2396c1b81c55 ]

This patch fixes two typos related to unregistering algorithms supported by
SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered
in case of an error. In sahara_unregister_algs the wrong array is used to
determine the iteration count.

Signed-off-by: Michael Müller 
Signed-off-by: Herbert Xu 
Signed-off-by: Sasha Levin 
---
 drivers/crypto/sahara.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 0c49956ee0ce..4d0ec7bb3bc9 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -1352,7 +1352,7 @@ static int sahara_register_algs(struct sahara_dev *dev)
 
 err_sha_v3_algs:
for (j = 0; j < k; j++)
-   crypto_unregister_ahash(_v4_algs[j]);
+   crypto_unregister_ahash(_v3_algs[j]);
 
 err_aes_algs:
for (j = 0; j < i; j++)
@@ -1368,7 +1368,7 @@ static void sahara_unregister_algs(struct sahara_dev *dev)
for (i = 0; i < ARRAY_SIZE(aes_algs); i++)
crypto_unregister_alg(_algs[i]);
 
-   for (i = 0; i < ARRAY_SIZE(sha_v4_algs); i++)
+   for (i = 0; i < ARRAY_SIZE(sha_v3_algs); i++)
crypto_unregister_ahash(_v3_algs[i]);
 
if (dev->version > SAHARA_VERSION_3)
-- 
2.17.1


[PATCH AUTOSEL 4.4 05/30] xfrm: fix 'passing zero to ERR_PTR()' warning

2018-09-06 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 934ffce1343f22ed5e2d0bd6da4440f4848074de ]

Fix a static code checker warning:

  net/xfrm/xfrm_policy.c:1836 xfrm_resolve_and_create_bundle() warn: passing 
zero to 'ERR_PTR'

xfrm_tmpl_resolve return 0 just means no xdst found, return NULL
instead of passing zero to ERR_PTR.

Fixes: d809ec895505 ("xfrm: do not assume that template resolving always 
returns xfrms")
Signed-off-by: YueHaibing 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_policy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index f9a13b67df5e..ca690d7ebde9 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1845,7 +1845,10 @@ xfrm_resolve_and_create_bundle(struct xfrm_policy 
**pols, int num_pols,
/* Try to instantiate a bundle */
err = xfrm_tmpl_resolve(pols, num_pols, fl, xfrm, family);
if (err <= 0) {
-   if (err != 0 && err != -EAGAIN)
+   if (err == 0)
+   return NULL;
+
+   if (err != -EAGAIN)
XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTPOLERROR);
return ERR_PTR(err);
}
-- 
2.17.1


[PATCH AUTOSEL 4.4 16/30] video: goldfishfb: fix memory leak on driver remove

2018-09-06 Thread Sasha Levin
From: Anton Vasilyev 

[ Upstream commit 5958fde72d04e7b8c6de3669d1f794a90997e3eb ]

goldfish_fb_probe() allocates memory for fb, but goldfish_fb_remove() does
not have deallocation of fb, which leads to memory leak on probe/remove.

The patch adds deallocation into goldfish_fb_remove().

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
Cc: Aleksandar Markovic 
Cc: Miodrag Dinic 
Cc: Goran Ferenc 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/goldfishfb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6cfc6c..14a93cb21310 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -301,6 +301,7 @@ static int goldfish_fb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, framesize, (void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
iounmap(fb->reg_base);
+   kfree(fb);
return 0;
 }
 
-- 
2.17.1


[PATCH AUTOSEL 4.4 17/30] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index badee04ef496..71b5dca95bdb 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 4.4 13/30] gfs2: Don't reject a supposedly full bitmap if we have blocks reserved

2018-09-06 Thread Sasha Levin
From: Bob Peterson 

[ Upstream commit e79e0e1428188b24c3b57309ffa54a33c4ae40c4 ]

Before this patch, you could get into situations like this:

1. Process 1 searches for X free blocks, finds them, makes a reservation
2. Process 2 searches for free blocks in the same rgrp, but now the
   bitmap is full because process 1's reservation is skipped over.
   So it marks the bitmap as GBF_FULL.
3. Process 1 tries to allocate blocks from its own reservation, but
   since the GBF_FULL bit is set, it skips over the rgrp and searches
   elsewhere, thus not using its own reservation.

This patch adds an additional check to allow processes to use their
own reservations.

Signed-off-by: Bob Peterson 
Signed-off-by: Andreas Gruenbacher 
Signed-off-by: Sasha Levin 
---
 fs/gfs2/rgrp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
index c134c0462cee..220f9f767307 100644
--- a/fs/gfs2/rgrp.c
+++ b/fs/gfs2/rgrp.c
@@ -1691,7 +1691,8 @@ static int gfs2_rbm_find(struct gfs2_rbm *rbm, u8 state, 
u32 *minext,
 
while(1) {
bi = rbm_bi(rbm);
-   if (test_bit(GBF_FULL, >bi_flags) &&
+   if ((ip == NULL || !gfs2_rs_active(>i_res)) &&
+   test_bit(GBF_FULL, >bi_flags) &&
(state == GFS2_BLKST_FREE))
goto next_bitmap;
 
-- 
2.17.1


[PATCH AUTOSEL 4.4 01/30] usb: usbtest: use irqsave() in USB's complete callback

2018-09-06 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/misc/usbtest.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index bc92a498ec03..4632a29d5403 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1053,11 +1053,12 @@ static void ctrl_complete(struct urb *urb)
struct usb_ctrlrequest  *reqp;
struct subcase  *subcase;
int status = urb->status;
+   unsigned long   flags;
 
reqp = (struct usb_ctrlrequest *)urb->setup_packet;
subcase = container_of(reqp, struct subcase, setup);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
ctx->pending--;
 
@@ -1156,7 +1157,7 @@ static void ctrl_complete(struct urb *urb)
/* signal completion when nothing's queued */
if (ctx->pending == 0)
complete(>complete);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static int
@@ -1832,8 +1833,9 @@ struct transfer_context {
 static void complicated_callback(struct urb *urb)
 {
struct transfer_context *ctx = urb->context;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
 
ctx->packet_count += urb->number_of_packets;
@@ -1873,7 +1875,7 @@ static void complicated_callback(struct urb *urb)
complete(>done);
}
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static struct urb *iso_alloc_urb(
-- 
2.17.1


[PATCH AUTOSEL 4.4 12/30] mtd/maps: fix solutionengine.c printk format warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]

Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".

Fixes these build warnings:

../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
  ^
  %08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x

Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov 

Signed-off-by: Randy Dunlap 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
---
 drivers/mtd/maps/solutionengine.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/solutionengine.c 
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
-   printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 
0x%08lx\n",
-  soleng_flash_map.phys & 0x1fff,
-  soleng_eprom_map.phys & 0x1fff);
+   printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 
0x%pap\n",
+  _flash_map.phys,
+  _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
 
eprom_mtd = do_map_probe("map_rom", _eprom_map);
-- 
2.17.1


[PATCH AUTOSEL 4.4 01/30] usb: usbtest: use irqsave() in USB's complete callback

2018-09-06 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/misc/usbtest.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index bc92a498ec03..4632a29d5403 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1053,11 +1053,12 @@ static void ctrl_complete(struct urb *urb)
struct usb_ctrlrequest  *reqp;
struct subcase  *subcase;
int status = urb->status;
+   unsigned long   flags;
 
reqp = (struct usb_ctrlrequest *)urb->setup_packet;
subcase = container_of(reqp, struct subcase, setup);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
ctx->pending--;
 
@@ -1156,7 +1157,7 @@ static void ctrl_complete(struct urb *urb)
/* signal completion when nothing's queued */
if (ctx->pending == 0)
complete(>complete);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static int
@@ -1832,8 +1833,9 @@ struct transfer_context {
 static void complicated_callback(struct urb *urb)
 {
struct transfer_context *ctx = urb->context;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
 
ctx->packet_count += urb->number_of_packets;
@@ -1873,7 +1875,7 @@ static void complicated_callback(struct urb *urb)
complete(>done);
}
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static struct urb *iso_alloc_urb(
-- 
2.17.1


[PATCH AUTOSEL 4.4 12/30] mtd/maps: fix solutionengine.c printk format warnings

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit 1d25e3eeed1d987404e2d2e451eebac8c15cecc1 ]

Fix 2 printk format warnings (this driver is currently only used by
arch/sh/) by using "%pap" instead of "%lx".

Fixes these build warnings:

../drivers/mtd/maps/solutionengine.c: In function 'init_soleng_maps':
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 2 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:54: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
  ^
  %08x
../include/linux/kern_levels.h:5:18: warning: format '%lx' expects argument of 
type 'long unsigned int', but argument 3 has type 'resource_size_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/mtd/maps/solutionengine.c:62:72: note: format string is defined here
  printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 0x%08lx\n",
^
%08x

Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Boris Brezillon 
Cc: Marek Vasut 
Cc: Richard Weinberger 
Cc: linux-...@lists.infradead.org
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: linux...@vger.kernel.org
Cc: Sergei Shtylyov 

Signed-off-by: Randy Dunlap 
Signed-off-by: Boris Brezillon 
Signed-off-by: Sasha Levin 
---
 drivers/mtd/maps/solutionengine.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/maps/solutionengine.c 
b/drivers/mtd/maps/solutionengine.c
index bb580bc16445..c07f21b20463 100644
--- a/drivers/mtd/maps/solutionengine.c
+++ b/drivers/mtd/maps/solutionengine.c
@@ -59,9 +59,9 @@ static int __init init_soleng_maps(void)
return -ENXIO;
}
}
-   printk(KERN_NOTICE "Solution Engine: Flash at 0x%08lx, EPROM at 
0x%08lx\n",
-  soleng_flash_map.phys & 0x1fff,
-  soleng_eprom_map.phys & 0x1fff);
+   printk(KERN_NOTICE "Solution Engine: Flash at 0x%pap, EPROM at 
0x%pap\n",
+  _flash_map.phys,
+  _eprom_map.phys);
flash_mtd->owner = THIS_MODULE;
 
eprom_mtd = do_map_probe("map_rom", _eprom_map);
-- 
2.17.1


[PATCH AUTOSEL 4.9 01/43] usb: usbtest: use irqsave() in USB's complete callback

2018-09-06 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/misc/usbtest.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index e31f72b3a22c..cc1dad83ec1d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1080,11 +1080,12 @@ static void ctrl_complete(struct urb *urb)
struct usb_ctrlrequest  *reqp;
struct subcase  *subcase;
int status = urb->status;
+   unsigned long   flags;
 
reqp = (struct usb_ctrlrequest *)urb->setup_packet;
subcase = container_of(reqp, struct subcase, setup);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
ctx->pending--;
 
@@ -1183,7 +1184,7 @@ static void ctrl_complete(struct urb *urb)
/* signal completion when nothing's queued */
if (ctx->pending == 0)
complete(>complete);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static int
@@ -1859,8 +1860,9 @@ struct transfer_context {
 static void complicated_callback(struct urb *urb)
 {
struct transfer_context *ctx = urb->context;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
 
ctx->packet_count += urb->number_of_packets;
@@ -1900,7 +1902,7 @@ static void complicated_callback(struct urb *urb)
complete(>done);
}
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static struct urb *iso_alloc_urb(
-- 
2.17.1


[PATCH AUTOSEL 4.4 07/30] clk: imx6ul: fix missing of_node_put()

2018-09-06 Thread Sasha Levin
From: Nicholas Mc Guire 

[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]

of_find_compatible_node() is returning a device node with refcount
incremented and must be explicitly decremented after the last use
which is right after the us in of_iomap() here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
---
 drivers/clk/imx/clk-imx6ul.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 01718d05e952..9e8f0e255de2 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -120,6 +120,7 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-anatop");
base = of_iomap(np, 0);
+   of_node_put(np);
WARN_ON(!base);
 
clks[IMX6UL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src", base + 
0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
-- 
2.17.1


[PATCH AUTOSEL 4.9 21/43] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index badee04ef496..71b5dca95bdb 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 4.9 24/43] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 4.9 19/43] fbdev: omapfb: off by one in omapfb_register_client()

2018-09-06 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 
Cc: Imre Deak 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 6429f33167f5..77c97c697fea 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -956,7 +956,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
-- 
2.17.1


[PATCH AUTOSEL 4.4 10/30] MIPS: ath79: fix system restart

2018-09-06 Thread Sasha Levin
From: Felix Fietkau 

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed
due to pending interrupts.

Signed-off-by: Felix Fietkau 
Signed-off-by: John Crispin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19913/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Signed-off-by: Sasha Levin 
---
 arch/mips/ath79/setup.c  | 1 +
 arch/mips/include/asm/mach-ath79/ath79.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 8755d618e116..961c393c0f55 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -44,6 +44,7 @@ static char ath79_sys_type[ATH79_SYS_TYPE_LEN];
 
 static void ath79_restart(char *command)
 {
+   local_irq_disable();
ath79_device_reset_set(AR71XX_RESET_FULL_CHIP);
for (;;)
if (cpu_wait)
diff --git a/arch/mips/include/asm/mach-ath79/ath79.h 
b/arch/mips/include/asm/mach-ath79/ath79.h
index 4eee221b0cf0..d2be8e4f7a35 100644
--- a/arch/mips/include/asm/mach-ath79/ath79.h
+++ b/arch/mips/include/asm/mach-ath79/ath79.h
@@ -133,6 +133,7 @@ static inline u32 ath79_pll_rr(unsigned reg)
 static inline void ath79_reset_wr(unsigned reg, u32 val)
 {
__raw_writel(val, ath79_reset_base + reg);
+   (void) __raw_readl(ath79_reset_base + reg); /* flush */
 }
 
 static inline u32 ath79_reset_rr(unsigned reg)
-- 
2.17.1


[PATCH AUTOSEL 4.9 01/43] usb: usbtest: use irqsave() in USB's complete callback

2018-09-06 Thread Sasha Levin
From: Sebastian Andrzej Siewior 

[ Upstream commit 6f3fde684d0232e66ada3410f016a58e09a87689 ]

The USB completion callback does not disable interrupts while acquiring
the lock. We want to remove the local_irq_disable() invocation from
__usb_hcd_giveback_urb() and therefore it is required for the callback
handler to disable the interrupts while acquiring the lock.
The callback may be invoked either in IRQ or BH context depending on the
USB host controller.
Use the _irqsave() variant of the locking primitives.

Cc: Greg Kroah-Hartman 
Acked-by: Alan Stern 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/misc/usbtest.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index e31f72b3a22c..cc1dad83ec1d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1080,11 +1080,12 @@ static void ctrl_complete(struct urb *urb)
struct usb_ctrlrequest  *reqp;
struct subcase  *subcase;
int status = urb->status;
+   unsigned long   flags;
 
reqp = (struct usb_ctrlrequest *)urb->setup_packet;
subcase = container_of(reqp, struct subcase, setup);
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
ctx->pending--;
 
@@ -1183,7 +1184,7 @@ static void ctrl_complete(struct urb *urb)
/* signal completion when nothing's queued */
if (ctx->pending == 0)
complete(>complete);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static int
@@ -1859,8 +1860,9 @@ struct transfer_context {
 static void complicated_callback(struct urb *urb)
 {
struct transfer_context *ctx = urb->context;
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
ctx->count--;
 
ctx->packet_count += urb->number_of_packets;
@@ -1900,7 +1902,7 @@ static void complicated_callback(struct urb *urb)
complete(>done);
}
 done:
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static struct urb *iso_alloc_urb(
-- 
2.17.1


[PATCH AUTOSEL 4.4 07/30] clk: imx6ul: fix missing of_node_put()

2018-09-06 Thread Sasha Levin
From: Nicholas Mc Guire 

[ Upstream commit 11177e7a7aaef95935592072985526ebf0a3df43 ]

of_find_compatible_node() is returning a device node with refcount
incremented and must be explicitly decremented after the last use
which is right after the us in of_iomap() here.

Signed-off-by: Nicholas Mc Guire 
Fixes: 787b4271a6a0 ("clk: imx: add imx6ul clk tree support")
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
---
 drivers/clk/imx/clk-imx6ul.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 01718d05e952..9e8f0e255de2 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -120,6 +120,7 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
 
np = of_find_compatible_node(NULL, NULL, "fsl,imx6ul-anatop");
base = of_iomap(np, 0);
+   of_node_put(np);
WARN_ON(!base);
 
clks[IMX6UL_PLL1_BYPASS_SRC] = imx_clk_mux("pll1_bypass_src", base + 
0x00, 14, 1, pll_bypass_src_sels, ARRAY_SIZE(pll_bypass_src_sels));
-- 
2.17.1


[PATCH AUTOSEL 4.9 21/43] fbdev/via: fix defined but not used warning

2018-09-06 Thread Sasha Levin
From: Randy Dunlap 

[ Upstream commit b6566b47a67e07fdca44cf51abb14e2fbe17d3eb ]

Fix a build warning in viafbdev.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/video/fbdev/via/viafbdev.c:1471:12: warning: 
'viafb_sup_odev_proc_show' defined but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Florian Tobias Schandinat 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/via/viafbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/via/viafbdev.c 
b/drivers/video/fbdev/via/viafbdev.c
index badee04ef496..71b5dca95bdb 100644
--- a/drivers/video/fbdev/via/viafbdev.c
+++ b/drivers/video/fbdev/via/viafbdev.c
@@ -19,6 +19,7 @@
  * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1468,7 +1469,7 @@ static const struct file_operations 
viafb_vt1636_proc_fops = {
 
 #endif /* CONFIG_FB_VIA_DIRECT_PROCFS */
 
-static int viafb_sup_odev_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused viafb_sup_odev_proc_show(struct seq_file *m, void *v)
 {
via_odev_to_seq(m, supported_odev_map[
viaparinfo->shared->chip_info.gfx_chip_name]);
-- 
2.17.1


[PATCH AUTOSEL 4.9 24/43] fbdev: Distinguish between interlaced and progressive modes

2018-09-06 Thread Sasha Levin
From: Fredrik Noring 

[ Upstream commit 1ba0a59cea41ea05fda92daaf2a2958a2246b9cf ]

I discovered the problem when developing a frame buffer driver for the
PlayStation 2 (not yet merged), using the following video modes for the
PlayStation 3 in drivers/video/fbdev/ps3fb.c:

}, {
/* 1080if */
"1080if", 50, 1920, 1080, 13468, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_INTERLACED
}, {
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},

In ps3fb_probe, the mode_option module parameter is used with fb_find_mode
but it can only select the interlaced variant of 1920x1080 since the loop
matching the modes does not take the difference between interlaced and
progressive modes into account.

In short, without the patch, progressive 1920x1080 cannot be chosen as a
mode_option parameter since fb_find_mode (falsely) thinks interlace is a
perfect match.

Signed-off-by: Fredrik Noring 
Cc: "Maciej W. Rozycki" 
[b.zolnierkie: updated patch description]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/core/modedb.c | 41 ++-
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 2510fa728d77..de119f11b78f 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -644,7 +644,7 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *
  * Valid mode specifiers for @mode_option:
  *
- * x[M][R][-][@][i][m] or
+ * x[M][R][-][@][i][p][m] or
  * [-][@]
  *
  * with , ,  and  decimal numbers and
@@ -653,10 +653,10 @@ static int fb_try_mode(struct fb_var_screeninfo *var, 
struct fb_info *info,
  *  If 'M' is present after yres (and before refresh/bpp if present),
  *  the function will compute the timings using VESA(tm) Coordinated
  *  Video Timings (CVT).  If 'R' is present after 'M', will compute with
- *  reduced blanking (for flatpanels).  If 'i' is present, compute
- *  interlaced mode.  If 'm' is present, add margins equal to 1.8%
- *  of xres rounded down to 8 pixels, and 1.8% of yres. The char
- *  'i' and 'm' must be after 'M' and 'R'. Example:
+ *  reduced blanking (for flatpanels).  If 'i' or 'p' are present, compute
+ *  interlaced or progressive mode.  If 'm' is present, add margins equal
+ *  to 1.8% of xres rounded down to 8 pixels, and 1.8% of yres. The chars
+ *  'i', 'p' and 'm' must be after 'M' and 'R'. Example:
  *
  *  1024x768MR-8@60m - Reduced blank with margins at 60Hz.
  *
@@ -697,7 +697,8 @@ int fb_find_mode(struct fb_var_screeninfo *var,
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0, refresh_specified = 0;
unsigned int xres = 0, yres = 0, bpp = default_bpp, refresh = 0;
-   int yres_specified = 0, cvt = 0, rb = 0, interlace = 0;
+   int yres_specified = 0, cvt = 0, rb = 0;
+   int interlace_specified = 0, interlace = 0;
int margins = 0;
u32 best, diff, tdiff;
 
@@ -748,9 +749,17 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if (!cvt)
margins = 1;
break;
+   case 'p':
+   if (!cvt) {
+   interlace = 0;
+   interlace_specified = 1;
+   }
+   break;
case 'i':
-   if (!cvt)
+   if (!cvt) {
interlace = 1;
+   interlace_specified = 1;
+   }
break;
default:
goto done;
@@ -819,11 +828,21 @@ int fb_find_mode(struct fb_var_screeninfo *var,
if ((name_matches(db[i], name, namelen) ||
 (res_specified && res_matches(db[i], xres, yres))) 
&&
!fb_try_mode(var, info, [i], bpp)) {
-   if (refresh_specified && db[i].refresh == 
refresh)
-   return 1;
+   const int db_interlace = (db[i].vmode &
+   FB_VMODE_INTERLACED ? 1 : 0);
+   int score = abs(db[i].refresh - refresh);
+
+   if (interlace_specified)
+   score += abs(db_interlace - interlace);
+
+   if (!interlace_specified ||
+   

[PATCH AUTOSEL 4.9 19/43] fbdev: omapfb: off by one in omapfb_register_client()

2018-09-06 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 5ec1ec35b2979b59d0b33381e7c9aac17e159d16 ]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 
Cc: Imre Deak 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 6429f33167f5..77c97c697fea 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -956,7 +956,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
-- 
2.17.1


[PATCH AUTOSEL 4.4 10/30] MIPS: ath79: fix system restart

2018-09-06 Thread Sasha Levin
From: Felix Fietkau 

[ Upstream commit f8a7bfe1cb2c1ebfa07775c9c8ac0ad3ba8e5ff5 ]

This patch disables irq on reboot to fix hang issues that were observed
due to pending interrupts.

Signed-off-by: Felix Fietkau 
Signed-off-by: John Crispin 
Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/19913/
Cc: James Hogan 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
Signed-off-by: Sasha Levin 
---
 arch/mips/ath79/setup.c  | 1 +
 arch/mips/include/asm/mach-ath79/ath79.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 8755d618e116..961c393c0f55 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -44,6 +44,7 @@ static char ath79_sys_type[ATH79_SYS_TYPE_LEN];
 
 static void ath79_restart(char *command)
 {
+   local_irq_disable();
ath79_device_reset_set(AR71XX_RESET_FULL_CHIP);
for (;;)
if (cpu_wait)
diff --git a/arch/mips/include/asm/mach-ath79/ath79.h 
b/arch/mips/include/asm/mach-ath79/ath79.h
index 4eee221b0cf0..d2be8e4f7a35 100644
--- a/arch/mips/include/asm/mach-ath79/ath79.h
+++ b/arch/mips/include/asm/mach-ath79/ath79.h
@@ -133,6 +133,7 @@ static inline u32 ath79_pll_rr(unsigned reg)
 static inline void ath79_reset_wr(unsigned reg, u32 val)
 {
__raw_writel(val, ath79_reset_base + reg);
+   (void) __raw_readl(ath79_reset_base + reg); /* flush */
 }
 
 static inline u32 ath79_reset_rr(unsigned reg)
-- 
2.17.1


[PATCH AUTOSEL 4.14 63/67] dmaengine: mv_xor_v2: kill the tasklets upon exit

2018-09-06 Thread Sasha Levin
From: Hanna Hawa 

[ Upstream commit 8bbafed8dd5cfa81071b50ead5cb60367fdef3a9 ]

The mv_xor_v2 driver uses a tasklet, initialized during the probe()
routine. However, it forgets to cleanup the tasklet using
tasklet_kill() function during the remove() routine, which this patch
fixes. This prevents the tasklet from potentially running after the
module has been removed.

Fixes: 19a340b1a820 ("dmaengine: mv_xor_v2: new driver")

Signed-off-by: Hanna Hawa 
Reviewed-by: Thomas Petazzoni 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/mv_xor_v2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
index 3548caa9e933..75eef589d0ec 100644
--- a/drivers/dma/mv_xor_v2.c
+++ b/drivers/dma/mv_xor_v2.c
@@ -898,6 +898,8 @@ static int mv_xor_v2_remove(struct platform_device *pdev)
 
platform_msi_domain_free_irqs(>dev);
 
+   tasklet_kill(_dev->irq_tasklet);
+
clk_disable_unprepare(xor_dev->clk);
 
return 0;
-- 
2.17.1


[PATCH AUTOSEL 4.14 60/67] KVM: arm/arm64: Fix vgic init race

2018-09-06 Thread Sasha Levin
From: Christoffer Dall 

[ Upstream commit 1d47191de7e15900f8fbfe7cccd7c6e1c2d7c31a ]

The vgic_init function can race with kvm_arch_vcpu_create() which does
not hold kvm_lock() and we therefore have no synchronization primitives
to ensure we're doing the right thing.

As the user is trying to initialize or run the VM while at the same time
creating more VCPUs, we just have to refuse to initialize the VGIC in
this case rather than silently failing with a broken VCPU.

Reviewed-by: Eric Auger 
Signed-off-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 virt/kvm/arm/vgic/vgic-init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5801261f3add..6f7f26ae72b4 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -277,6 +277,10 @@ int vgic_init(struct kvm *kvm)
if (vgic_initialized(kvm))
return 0;
 
+   /* Are we also in the middle of creating a VCPU? */
+   if (kvm->created_vcpus != atomic_read(>online_vcpus))
+   return -EBUSY;
+
/* freeze the number of spis */
if (!dist->nr_spis)
dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
-- 
2.17.1


[PATCH AUTOSEL 4.9 22/43] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index bd630c222e65..9d1f6e976a5a 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 4.9 23/43] video: fbdev: pxafb: clear allocated memory for video modes

2018-09-06 Thread Sasha Levin
From: Daniel Mack 

[ Upstream commit b951d80aaf224b1f774e10def672f5e37488e4ee ]

When parsing the video modes from DT properties, make sure to zero out
memory before using it. This is important because not all fields in the mode
struct are explicitly initialized, even though they are used later on.

Fixes: 420a488278e86 ("video: fbdev: pxafb: initial devicetree conversion")
Reviewed-by: Robert Jarzmik 
Signed-off-by: Daniel Mack 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/pxafb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index ef73f14d7ba0..8503310a3816 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2128,8 +2128,8 @@ static int of_get_pxafb_display(struct device *dev, 
struct device_node *disp,
return -EINVAL;
 
ret = -ENOMEM;
-   info->modes = kmalloc_array(timings->num_timings,
-   sizeof(info->modes[0]), GFP_KERNEL);
+   info->modes = kcalloc(timings->num_timings, sizeof(info->modes[0]),
+ GFP_KERNEL);
if (!info->modes)
goto out;
info->num_modes = timings->num_timings;
-- 
2.17.1


[PATCH AUTOSEL 4.14 63/67] dmaengine: mv_xor_v2: kill the tasklets upon exit

2018-09-06 Thread Sasha Levin
From: Hanna Hawa 

[ Upstream commit 8bbafed8dd5cfa81071b50ead5cb60367fdef3a9 ]

The mv_xor_v2 driver uses a tasklet, initialized during the probe()
routine. However, it forgets to cleanup the tasklet using
tasklet_kill() function during the remove() routine, which this patch
fixes. This prevents the tasklet from potentially running after the
module has been removed.

Fixes: 19a340b1a820 ("dmaengine: mv_xor_v2: new driver")

Signed-off-by: Hanna Hawa 
Reviewed-by: Thomas Petazzoni 
Signed-off-by: Vinod Koul 
Signed-off-by: Sasha Levin 
---
 drivers/dma/mv_xor_v2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/dma/mv_xor_v2.c b/drivers/dma/mv_xor_v2.c
index 3548caa9e933..75eef589d0ec 100644
--- a/drivers/dma/mv_xor_v2.c
+++ b/drivers/dma/mv_xor_v2.c
@@ -898,6 +898,8 @@ static int mv_xor_v2_remove(struct platform_device *pdev)
 
platform_msi_domain_free_irqs(>dev);
 
+   tasklet_kill(_dev->irq_tasklet);
+
clk_disable_unprepare(xor_dev->clk);
 
return 0;
-- 
2.17.1


[PATCH AUTOSEL 4.14 60/67] KVM: arm/arm64: Fix vgic init race

2018-09-06 Thread Sasha Levin
From: Christoffer Dall 

[ Upstream commit 1d47191de7e15900f8fbfe7cccd7c6e1c2d7c31a ]

The vgic_init function can race with kvm_arch_vcpu_create() which does
not hold kvm_lock() and we therefore have no synchronization primitives
to ensure we're doing the right thing.

As the user is trying to initialize or run the VM while at the same time
creating more VCPUs, we just have to refuse to initialize the VGIC in
this case rather than silently failing with a broken VCPU.

Reviewed-by: Eric Auger 
Signed-off-by: Christoffer Dall 
Signed-off-by: Marc Zyngier 
Signed-off-by: Sasha Levin 
---
 virt/kvm/arm/vgic/vgic-init.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index 5801261f3add..6f7f26ae72b4 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -277,6 +277,10 @@ int vgic_init(struct kvm *kvm)
if (vgic_initialized(kvm))
return 0;
 
+   /* Are we also in the middle of creating a VCPU? */
+   if (kvm->created_vcpus != atomic_read(>online_vcpus))
+   return -EBUSY;
+
/* freeze the number of spis */
if (!dist->nr_spis)
dist->nr_spis = VGIC_NR_IRQS_LEGACY - VGIC_NR_PRIVATE_IRQS;
-- 
2.17.1


[PATCH AUTOSEL 4.9 22/43] perf powerpc: Fix callchain ip filtering when return address is in a register

2018-09-06 Thread Sasha Levin
From: Sandipan Das 

[ Upstream commit 9068533e4f470daf2b0f29c71d865990acd8826e ]

For powerpc64, perf will filter out the second entry in the callchain,
i.e. the LR value, if the return address of the function corresponding
to the probed location has already been saved on its caller's stack.

The state of the return address is determined using debug information.
At any point within a function, if the return address is already saved
somewhere, a DWARF expression can tell us about its location. If the
return address in still in LR only, no DWARF expression would exist.

Typically, the instructions in a function's prologue first copy the LR
value to R0 and then pushes R0 on to the stack. If LR has already been
copied to R0 but R0 is yet to be pushed to the stack, we can still get a
DWARF expression that says that the return address is in R0. This is
indicating that getting a DWARF expression for the return address does
not guarantee the fact that it has already been saved on the stack.

This can be observed on a powerpc64le system running Fedora 27 as shown
below.

  # objdump -d /usr/lib64/libc-2.26.so | less
  ...
  0015af20 :
15af20:   0b 00 4c 3c addis   r2,r12,11
15af24:   e0 c1 42 38 addir2,r2,-15904
15af28:   a6 02 08 7c mflrr0
15af2c:   f0 ff c1 fb std r30,-16(r1)
15af30:   f8 ff e1 fb std r31,-8(r1)
15af34:   78 1b 7f 7c mr  r31,r3
15af38:   78 23 83 7c mr  r3,r4
15af3c:   78 2b be 7c mr  r30,r5
15af40:   10 00 01 f8 std r0,16(r1)
15af44:   c1 ff 21 f8 stdur1,-64(r1)
15af48:   28 00 81 f8 std r4,40(r1)
  ...

  # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
  ...
  00027024 0024 00027028 FDE cie= 
pc=0015af20..0015af88
 LOC   CFA  r30   r31   ra
  0015af20 r1+0 u u u
  0015af34 r1+0 c-16  c-8   r0
  0015af48 r1+64c-16  c-8   c+16
  0015af5c r1+0 c-16  c-8   c+16
  0015af78 r1+0 u u
  ...

  # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
  # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
  # perf script

Before:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

After:

  ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
  7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
  7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
  7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
 12f152d70 _init+0xbfc (/usr/bin/ping)
  7fff7e1836a0 generic_start_main.isra.0+0x140 
(/usr/lib64/libc-2.26.so)
  7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
 0 [unknown] ([unknown])

Reported-by: Ravi Bangoria 
Signed-off-by: Sandipan Das 
Cc: Jiri Olsa 
Cc: Maynard Johnson 
Cc: Naveen N. Rao 
Cc: Ravi Bangoria 
Cc: Sukadev Bhattiprolu 
Link: 
http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandi...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
---
 tools/perf/arch/powerpc/util/skip-callchain-idx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/arch/powerpc/util/skip-callchain-idx.c 
b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
index bd630c222e65..9d1f6e976a5a 100644
--- a/tools/perf/arch/powerpc/util/skip-callchain-idx.c
+++ b/tools/perf/arch/powerpc/util/skip-callchain-idx.c
@@ -58,9 +58,13 @@ static int check_return_reg(int ra_regno, Dwarf_Frame *frame)
}
 
/*
-* Check if return address is on the stack.
+* Check if return address is on the stack. If return address
+* is in a register (typically R0), it is yet to be saved on
+* the stack.
 */
-   if (nops != 0 || ops != NULL)
+   if ((nops != 0 || ops != NULL) &&
+   !(nops == 1 && ops[0].atom == DW_OP_regx &&
+   ops[0].number2 == 0 && ops[0].offset == 0))
return 0;
 
/*
-- 
2.17.1


[PATCH AUTOSEL 4.9 23/43] video: fbdev: pxafb: clear allocated memory for video modes

2018-09-06 Thread Sasha Levin
From: Daniel Mack 

[ Upstream commit b951d80aaf224b1f774e10def672f5e37488e4ee ]

When parsing the video modes from DT properties, make sure to zero out
memory before using it. This is important because not all fields in the mode
struct are explicitly initialized, even though they are used later on.

Fixes: 420a488278e86 ("video: fbdev: pxafb: initial devicetree conversion")
Reviewed-by: Robert Jarzmik 
Signed-off-by: Daniel Mack 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/pxafb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index ef73f14d7ba0..8503310a3816 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -2128,8 +2128,8 @@ static int of_get_pxafb_display(struct device *dev, 
struct device_node *disp,
return -EINVAL;
 
ret = -ENOMEM;
-   info->modes = kmalloc_array(timings->num_timings,
-   sizeof(info->modes[0]), GFP_KERNEL);
+   info->modes = kcalloc(timings->num_timings, sizeof(info->modes[0]),
+ GFP_KERNEL);
if (!info->modes)
goto out;
info->num_modes = timings->num_timings;
-- 
2.17.1


[PATCH AUTOSEL 4.14 58/67] s390/qeth: reset layer2 attribute on layer switch

2018-09-06 Thread Sasha Levin
From: Julian Wiedmann 

[ Upstream commit 70551dc46ffa3555a0b5f3545b0cd87ab67fd002 ]

After the subdriver's remove() routine has completed, the card's layer
mode is undetermined again. Reflect this in the layer2 field.

If qeth_dev_layer2_store() hits an error after remove() was called, the
card _always_ requires a setup(), even if the previous layer mode is
requested again.
But qeth_dev_layer2_store() bails out early if the requested layer mode
still matches the current one. So unless we reset the layer2 field,
re-probing the card back to its previous mode is currently not possible.

Signed-off-by: Julian Wiedmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/s390/net/qeth_core_sys.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/s390/net/qeth_core_sys.c b/drivers/s390/net/qeth_core_sys.c
index d1ee9e30c68b..21e91fbb2860 100644
--- a/drivers/s390/net/qeth_core_sys.c
+++ b/drivers/s390/net/qeth_core_sys.c
@@ -423,6 +423,7 @@ static ssize_t qeth_dev_layer2_store(struct device *dev,
if (card->discipline) {
card->discipline->remove(card->gdev);
qeth_core_free_discipline(card);
+   card->options.layer2 = -1;
}
 
rc = qeth_core_load_discipline(card, newdis);
-- 
2.17.1


[PATCH AUTOSEL 4.14 65/67] x86/pti: Check the return value of pti_user_pagetable_walk_p4d()

2018-09-06 Thread Sasha Levin
From: Jiang Biao 

[ Upstream commit b2b7d986a89b6c94b1331a909de1217214fb08c1 ]

pti_user_pagetable_walk_p4d() can return NULL, so the return value should
be checked to prevent a NULL pointer dereference.

Add the check and a warning when the P4D allocation fails.

Signed-off-by: Jiang Biao 
Signed-off-by: Thomas Gleixner 
Cc: dave.han...@linux.intel.com
Cc: l...@kernel.org
Cc: h...@zytor.com
Cc: albca...@gmail.com
Cc: zhong.weid...@zte.com.cn
Link: 
https://lkml.kernel.org/r/1532045192-49622-1-git-send-email-jiang.bi...@zte.com.cn
Signed-off-by: Sasha Levin 
---
 arch/x86/mm/pti.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index d6f11accd37a..63afd15b32a5 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -162,7 +162,7 @@ static __init p4d_t *pti_user_pagetable_walk_p4d(unsigned 
long address)
 
if (pgd_none(*pgd)) {
unsigned long new_p4d_page = __get_free_page(gfp);
-   if (!new_p4d_page)
+   if (WARN_ON_ONCE(!new_p4d_page))
return NULL;
 
set_pgd(pgd, __pgd(_KERNPG_TABLE | __pa(new_p4d_page)));
@@ -181,9 +181,13 @@ static __init p4d_t *pti_user_pagetable_walk_p4d(unsigned 
long address)
 static __init pmd_t *pti_user_pagetable_walk_pmd(unsigned long address)
 {
gfp_t gfp = (GFP_KERNEL | __GFP_NOTRACK | __GFP_ZERO);
-   p4d_t *p4d = pti_user_pagetable_walk_p4d(address);
+   p4d_t *p4d;
pud_t *pud;
 
+   p4d = pti_user_pagetable_walk_p4d(address);
+   if (!p4d)
+   return NULL;
+
BUILD_BUG_ON(p4d_large(*p4d) != 0);
if (p4d_none(*p4d)) {
unsigned long new_pud_page = __get_free_page(gfp);
@@ -319,6 +323,9 @@ static void __init pti_clone_p4d(unsigned long addr)
pgd_t *kernel_pgd;
 
user_p4d = pti_user_pagetable_walk_p4d(addr);
+   if (!user_p4d)
+   return;
+
kernel_pgd = pgd_offset_k(addr);
kernel_p4d = p4d_offset(kernel_pgd, addr);
*user_p4d = *kernel_p4d;
-- 
2.17.1


<    1   2   3   4   5   6   7   8   9   10   >