Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1585288 > unrolled thread

[PATCH 4.4 00/15] 4.4.51-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 11/15] printk: use rcuidle console tracepoint Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 09/15] futex: Move futex_init() to core_initcall Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 06/15] Input: elan_i2c - add ELAN0605 to the ACPI table Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 12/15] NTB: ntb_transport: fix debugfs_remove_recursive Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 10/15] ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:10 +0100
    [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
      Re: [PATCH 4.4 02/15] [media] siano: make it work again with  CONFIG_VMAP_STACK Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-02-22 22:40 +0100
      Re: [PATCH 4.4 02/15] [media] siano: make it work again with  CONFIG_VMAP_STACK Eddie Chapman <eddie@ehuk.net> - 2017-02-22 22:50 +0100
    [PATCH 4.4 05/15] Fix missing sanity check in /dev/sg Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 04/15] scsi: dont BUG_ON() empty DMA transfers Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 03/15] fuse: fix use after free issue in fuse_dev_do_read() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 14/15] bcache: Make gc wakeup sane, remove set_task_state() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 15/15] mmc: core: fix multi-bit bus width without high-speed mode Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 13/15] ntb_transport: Pick an unused queue Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    [PATCH 4.4 08/15] drm/dp/mst: fix kernel oops when turning off secondary monitor Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-21 14:20 +0100
    Re: [PATCH 4.4 00/15] 4.4.51-stable review Guenter Roeck <linux@roeck-us.net> - 2017-02-21 17:20 +0100
    Re: [PATCH 4.4 00/15] 4.4.51-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-02-22 00:50 +0100

#1585288 — [PATCH 4.4 00/15] 4.4.51-stable review

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

Responses should be made by Thu Feb 23 13:01:31 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.51-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.51-rc1

Anssi Hannula <anssi.hannula@bitwise.fi>
    mmc: core: fix multi-bit bus width without high-speed mode

Kent Overstreet <kent.overstreet@gmail.com>
    bcache: Make gc wakeup sane, remove set_task_state()

Thomas VanSelus <tvanselus@xes-inc.com>
    ntb_transport: Pick an unused queue

Allen Hubbe <Allen.Hubbe@dell.com>
    NTB: ntb_transport: fix debugfs_remove_recursive

Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
    printk: use rcuidle console tracepoint

Kees Cook <keescook@chromium.org>
    ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()

Yang Yang <yang.yang29@zte.com.cn>
    futex: Move futex_init() to core_initcall

Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    drm/dp/mst: fix kernel oops when turning off secondary monitor

Michel Dänzer <michel.daenzer@amd.com>
    drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor

IHARA Hiroka <ihara_h@live.jp>
    Input: elan_i2c - add ELAN0605 to the ACPI table

Al Viro <viro@ZenIV.linux.org.uk>
    Fix missing sanity check in /dev/sg

Johannes Thumshirn <jthumshirn@suse.de>
    scsi: don't BUG_ON() empty DMA transfers

Sahitya Tummala <stummala@codeaurora.org>
    fuse: fix use after free issue in fuse_dev_do_read()

Mauro Carvalho Chehab <mchehab@s-opensource.com>
    siano: make it work again with CONFIG_VMAP_STACK

Miklos Szeredi <mszeredi@redhat.com>
    vfs: fix uninitialized flags in splice_to_pipe()


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

Diffstat:

 Makefile                               |  4 ++--
 arch/arm/lib/getuser.S                 |  2 +-
 drivers/gpu/drm/drm_dp_mst_topology.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_cursor.c |  4 ++--
 drivers/input/mouse/elan_i2c_core.c    |  1 +
 drivers/md/bcache/bcache.h             |  4 ++--
 drivers/md/bcache/btree.c              | 40 +++++++++++++++++-----------------
 drivers/md/bcache/btree.h              |  3 +--
 drivers/md/bcache/request.c            |  4 +---
 drivers/md/bcache/super.c              |  2 ++
 drivers/media/usb/siano/smsusb.c       | 18 ++++++++++-----
 drivers/mmc/core/mmc.c                 |  4 ++--
 drivers/ntb/ntb_transport.c            |  5 ++---
 drivers/scsi/scsi_lib.c                |  3 ++-
 drivers/scsi/sg.c                      |  4 ++++
 fs/fuse/dev.c                          |  4 ++++
 fs/splice.c                            |  1 +
 kernel/futex.c                         |  2 +-
 kernel/printk/printk.c                 |  2 +-
 19 files changed, 63 insertions(+), 46 deletions(-)

[toc] | [next] | [standalone]

#1585293 — [PATCH 4.4 11/15] printk: use rcuidle console tracepoint

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

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

From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>

commit fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c upstream.

Use rcuidle console tracepoint because, apparently, it may be issued
from an idle CPU:

  hw-breakpoint: Failed to enable monitor mode on CPU 0.
  hw-breakpoint: CPU 0 failed to disable vector catch

  ===============================
  [ ERR: suspicious RCU usage.  ]
  4.10.0-rc8-next-20170215+ #119 Not tainted
  -------------------------------
  ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  RCU used illegally from idle CPU!
  rcu_scheduler_active = 2, debug_locks = 0
  RCU used illegally from extended quiescent state!
  2 locks held by swapper/0/0:
   #0:  (cpu_pm_notifier_lock){......}, at: [<c0237e2c>] cpu_pm_exit+0x10/0x54
   #1:  (console_lock){+.+.+.}, at: [<c01ab350>] vprintk_emit+0x264/0x474

  stack backtrace:
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119
  Hardware name: Generic OMAP4 (Flattened Device Tree)
    console_unlock
    vprintk_emit
    vprintk_default
    printk
    reset_ctrl_regs
    dbg_cpu_pm_notify
    notifier_call_chain
    cpu_pm_exit
    omap_enter_idle_coupled
    cpuidle_enter_state
    cpuidle_enter_state_coupled
    do_idle
    cpu_startup_entry
    start_kernel

This RCU warning, however, is suppressed by lockdep_off() in printk().
lockdep_off() increments the ->lockdep_recursion counter and thus
disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want
lockdep to be enabled "current->lockdep_recursion == 0".

Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/printk/printk.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1436,7 +1436,7 @@ static void call_console_drivers(int lev
 {
 	struct console *con;
 
-	trace_console(text, len);
+	trace_console_rcuidle(text, len);
 
 	if (level >= console_loglevel && !ignore_loglevel)
 		return;

[toc] | [prev] | [next] | [standalone]

#1585294 — [PATCH 4.4 09/15] futex: Move futex_init() to core_initcall

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

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

From: Yang Yang <yang.yang29@zte.com.cn>

commit 25f71d1c3e98ef0e52371746220d66458eac75bc upstream.

The UEVENT user mode helper is enabled before the initcalls are executed
and is available when the root filesystem has been mounted.

The user mode helper is triggered by device init calls and the executable
might use the futex syscall.

futex_init() is marked __initcall which maps to device_initcall, but there
is no guarantee that futex_init() is invoked _before_ the first device init
call which triggers the UEVENT user mode helper.

If the user mode helper uses the futex syscall before futex_init() then the
syscall crashes with a NULL pointer dereference because the futex subsystem
has not been initialized yet.

Move futex_init() to core_initcall so futexes are initialized before the
root filesystem is mounted and the usermode helper becomes available.

[ tglx: Rewrote changelog ]

Signed-off-by: Yang Yang <yang.yang29@zte.com.cn>
Cc: jiang.biao2@zte.com.cn
Cc: jiang.zhengxiong@zte.com.cn
Cc: zhong.weidong@zte.com.cn
Cc: deng.huali@zte.com.cn
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1483085875-6130-1-git-send-email-yang.yang29@zte.com.cn
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/futex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3199,4 +3199,4 @@ static int __init futex_init(void)
 
 	return 0;
 }
-__initcall(futex_init);
+core_initcall(futex_init);

[toc] | [prev] | [next] | [standalone]

#1585296 — [PATCH 4.4 06/15] Input: elan_i2c - add ELAN0605 to the ACPI table

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

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

From: IHARA Hiroka <ihara_h@live.jp>

commit 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 upstream.

ELAN0605 has been confirmed to be a variant of ELAN0600, which is
blacklisted in the hid-core to be managed by elan_i2c. This device can be
found in Lenovo ideapad 310s (80U4000).

Signed-off-by: Hiroka IHARA <ihara_h@live.jp>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/mouse/elan_i2c_core.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1232,6 +1232,7 @@ static const struct acpi_device_id elan_
 	{ "ELAN0000", 0 },
 	{ "ELAN0100", 0 },
 	{ "ELAN0600", 0 },
+	{ "ELAN0605", 0 },
 	{ "ELAN1000", 0 },
 	{ }
 };

[toc] | [prev] | [next] | [standalone]

#1585304 — [PATCH 4.4 12/15] NTB: ntb_transport: fix debugfs_remove_recursive

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

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

From: Allen Hubbe <Allen.Hubbe@dell.com>

commit dd62245e73de9138333cb0e7a42c8bc1215c3ce6 upstream.

The call to debugfs_remove_recursive(qp->debugfs_dir) of the sub-level
directory must not be later than
debugfs_remove_recursive(nt_debugfs_dir) of the top-level directory.
Otherwise, the sub-level directory will not exist, and it would be
invalid (panic) to attempt to remove it.  This removes the top-level
directory last, after sub-level directories have been cleaned up.

Signed-off-by: Allen Hubbe <Allen.Hubbe@dell.com>
Fixes: e26a5843f ("NTB: Split ntb_hw_intel and ntb_transport drivers")
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/ntb/ntb_transport.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -2082,9 +2082,8 @@ module_init(ntb_transport_init);
 
 static void __exit ntb_transport_exit(void)
 {
-	debugfs_remove_recursive(nt_debugfs_dir);
-
 	ntb_unregister_client(&ntb_transport_client);
 	bus_unregister(&ntb_transport_bus);
+	debugfs_remove_recursive(nt_debugfs_dir);
 }
 module_exit(ntb_transport_exit);

[toc] | [prev] | [next] | [standalone]

#1585308 — [PATCH 4.4 10/15] ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()

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

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

From: Kees Cook <keescook@chromium.org>

commit 9e3440481845b2ec22508f60837ee2cab2b6054f upstream.

The 64-bit get_user() wasn't clearing the high word due to a typo in the
error handler. The exception handler entry was already correct, though.
Noticed during recent usercopy test additions in lib/test_user_copy.c.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/lib/getuser.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -67,7 +67,7 @@ ENTRY(__get_user_4)
 ENDPROC(__get_user_4)
 
 ENTRY(__get_user_8)
-	check_uaccess r0, 8, r1, r2, __get_user_bad
+	check_uaccess r0, 8, r1, r2, __get_user_bad8
 #ifdef CONFIG_THUMB2_KERNEL
 5: TUSER(ldr)	r2, [r0]
 6: TUSER(ldr)	r3, [r0, #4]

[toc] | [prev] | [next] | [standalone]

#1585316 — [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK

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

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

From: Mauro Carvalho Chehab <mchehab@s-opensource.com>

commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.

Reported as a Kaffeine bug:
	https://bugs.kde.org/show_bug.cgi?id=375811

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

On Kernel 4.9, the default is to not accept DMA on stack anymore
on x86 architecture. On other architectures, this has been a
requirement since Kernel 2.2. So, after this patch, this driver
should likely work fine on all archs.

Tested with USB ID 2040:5510: Hauppauge Windham

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/media/usb/siano/smsusb.c |   18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

--- a/drivers/media/usb/siano/smsusb.c
+++ b/drivers/media/usb/siano/smsusb.c
@@ -200,22 +200,30 @@ static int smsusb_start_streaming(struct
 static int smsusb_sendrequest(void *context, void *buffer, size_t size)
 {
 	struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
-	struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
-	int dummy;
+	struct sms_msg_hdr *phdr;
+	int dummy, ret;
 
 	if (dev->state != SMSUSB_ACTIVE) {
 		pr_debug("Device not active yet\n");
 		return -ENOENT;
 	}
 
+	phdr = kmalloc(size, GFP_KERNEL);
+	if (!phdr)
+		return -ENOMEM;
+	memcpy(phdr, buffer, size);
+
 	pr_debug("sending %s(%d) size: %d\n",
 		  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
 		  phdr->msg_length);
 
 	smsendian_handle_tx_message((struct sms_msg_data *) phdr);
-	smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
-	return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
-			    buffer, size, &dummy, 1000);
+	smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
+	ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
+			    phdr, size, &dummy, 1000);
+
+	kfree(phdr);
+	return ret;
 }
 
 static char *smsusb1_fw_lkup[] = {

[toc] | [prev] | [next] | [standalone]

#1586504 — Re: [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK

Em Wed, 22 Feb 2017 21:07:24 +0000
Eddie Chapman <eddie@ehuk.net> escreveu:

> On 21/02/17 13:01, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> >
> > commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.
> >
> > Reported as a Kaffeine bug:
> > 	https://bugs.kde.org/show_bug.cgi?id=375811
> >
> > The USB control messages require DMA to work. We cannot pass
> > a stack-allocated buffer, as it is not warranted that the
> > stack would be into a DMA enabled area.
> >
> > On Kernel 4.9, the default is to not accept DMA on stack anymore
> > on x86 architecture. On other architectures, this has been a
> > requirement since Kernel 2.2. So, after this patch, this driver
> > should likely work fine on all archs.
> >
> > Tested with USB ID 2040:5510: Hauppauge Windham
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > ---
> >  drivers/media/usb/siano/smsusb.c |   18 +++++++++++++-----
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > --- a/drivers/media/usb/siano/smsusb.c
> > +++ b/drivers/media/usb/siano/smsusb.c
> > @@ -200,22 +200,30 @@ static int smsusb_start_streaming(struct
> >  static int smsusb_sendrequest(void *context, void *buffer, size_t size)
> >  {
> >  	struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
> > -	struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
> > -	int dummy;
> > +	struct sms_msg_hdr *phdr;
> > +	int dummy, ret;
> >
> >  	if (dev->state != SMSUSB_ACTIVE) {
> >  		pr_debug("Device not active yet\n");
> >  		return -ENOENT;
> >  	}
> >
> > +	phdr = kmalloc(size, GFP_KERNEL);
> > +	if (!phdr)
> > +		return -ENOMEM;
> > +	memcpy(phdr, buffer, size);
> > +
> >  	pr_debug("sending %s(%d) size: %d\n",
> >  		  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
> >  		  phdr->msg_length);
> >
> >  	smsendian_handle_tx_message((struct sms_msg_data *) phdr);
> > -	smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
> > -	return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
> > -			    buffer, size, &dummy, 1000);
> > +	smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
> > +	ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
> > +			    phdr, size, &dummy, 1000);
> > +
> > +	kfree(phdr);
> > +	return ret;
> >  }
> >
> >  static char *smsusb1_fw_lkup[] = {  
> 
> Hello Greg,
> 
> According to the bug report linked to in the commit message this is only 
> needed in 4.9 and higher.

Actually, it makes this device work on ARM platforms too.

The thing is, although forbidden since Kernel 2.2, on x86, using
the stack used to work (on most cases). So, there are many drivers
that were written without taking care of not using the stack before
sending an URB.

So, the best is to backport this patch to -stable Kernels as well,
as it will avoid potential (rare) issues on x86, but it will also
make the driver to work on non-x86 archs.

I updated the patch description to reflect it, but maybe I was not
too clear ;)


Thanks,
Mauro

[toc] | [prev] | [next] | [standalone]

#1586512 — Re: [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK

On 21/02/17 13:01, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
>
> ------------------
>
> From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>
> commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream.
>
> Reported as a Kaffeine bug:
> 	https://bugs.kde.org/show_bug.cgi?id=375811
>
> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
>
> On Kernel 4.9, the default is to not accept DMA on stack anymore
> on x86 architecture. On other architectures, this has been a
> requirement since Kernel 2.2. So, after this patch, this driver
> should likely work fine on all archs.
>
> Tested with USB ID 2040:5510: Hauppauge Windham
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
>  drivers/media/usb/siano/smsusb.c |   18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> --- a/drivers/media/usb/siano/smsusb.c
> +++ b/drivers/media/usb/siano/smsusb.c
> @@ -200,22 +200,30 @@ static int smsusb_start_streaming(struct
>  static int smsusb_sendrequest(void *context, void *buffer, size_t size)
>  {
>  	struct smsusb_device_t *dev = (struct smsusb_device_t *) context;
> -	struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer;
> -	int dummy;
> +	struct sms_msg_hdr *phdr;
> +	int dummy, ret;
>
>  	if (dev->state != SMSUSB_ACTIVE) {
>  		pr_debug("Device not active yet\n");
>  		return -ENOENT;
>  	}
>
> +	phdr = kmalloc(size, GFP_KERNEL);
> +	if (!phdr)
> +		return -ENOMEM;
> +	memcpy(phdr, buffer, size);
> +
>  	pr_debug("sending %s(%d) size: %d\n",
>  		  smscore_translate_msg(phdr->msg_type), phdr->msg_type,
>  		  phdr->msg_length);
>
>  	smsendian_handle_tx_message((struct sms_msg_data *) phdr);
> -	smsendian_handle_message_header((struct sms_msg_hdr *)buffer);
> -	return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
> -			    buffer, size, &dummy, 1000);
> +	smsendian_handle_message_header((struct sms_msg_hdr *)phdr);
> +	ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2),
> +			    phdr, size, &dummy, 1000);
> +
> +	kfree(phdr);
> +	return ret;
>  }
>
>  static char *smsusb1_fw_lkup[] = {

Hello Greg,

According to the bug report linked to in the commit message this is only 
needed in 4.9 and higher.

Eddie

[toc] | [prev] | [next] | [standalone]

#1585318 — [PATCH 4.4 05/15] Fix missing sanity check in /dev/sg

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

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

From: Al Viro <viro@ZenIV.linux.org.uk>

commit 137d01df511b3afe1f05499aea05f3bafc0fb221 upstream.

What happens is that a write to /dev/sg is given a request with non-zero
->iovec_count combined with zero ->dxfer_len.  Or with ->dxferp pointing
to an array full of empty iovecs.

Having write permission to /dev/sg shouldn't be equivalent to the
ability to trigger BUG_ON() while holding spinlocks...

Found by Dmitry Vyukov and syzkaller.

[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the
  underlying issue.  - Linus ]

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/sg.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1763,6 +1763,10 @@ sg_start_req(Sg_request *srp, unsigned c
 			return res;
 
 		iov_iter_truncate(&i, hp->dxfer_len);
+		if (!iov_iter_count(&i)) {
+			kfree(iov);
+			return -EINVAL;
+		}
 
 		res = blk_rq_map_user_iov(q, rq, md, &i, GFP_ATOMIC);
 		kfree(iov);

[toc] | [prev] | [next] | [standalone]

#1585319 — [PATCH 4.4 04/15] scsi: dont BUG_ON() empty DMA transfers

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

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

From: Johannes Thumshirn <jthumshirn@suse.de>

commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream.

Don't crash the machine just because of an empty transfer. Use WARN_ON()
combined with returning an error.

Found by Dmitry Vyukov and syzkaller.

[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
  cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
  might still be a cause of excessive log spamming.

  NOTE! If this warning ever triggers, we may end up leaking resources,
  since this doesn't bother to try to clean the command up. So this
  WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
  much worse.

  People really need to stop using BUG_ON() for "this shouldn't ever
  happen". It makes pretty much any bug worse.     - Linus ]

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: James Bottomley <jejb@linux.vnet.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1120,7 +1120,8 @@ int scsi_init_io(struct scsi_cmnd *cmd)
 	bool is_mq = (rq->mq_ctx != NULL);
 	int error;
 
-	BUG_ON(!rq->nr_phys_segments);
+	if (WARN_ON_ONCE(!rq->nr_phys_segments))
+		return -EINVAL;
 
 	error = scsi_init_sgtable(rq, &cmd->sdb);
 	if (error)

[toc] | [prev] | [next] | [standalone]

#1585320 — [PATCH 4.4 03/15] fuse: fix use after free issue in fuse_dev_do_read()

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

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

From: Sahitya Tummala <stummala@codeaurora.org>

commit 6ba4d2722d06960102c981322035239cd66f7316 upstream.

There is a potential race between fuse_dev_do_write()
and request_wait_answer() contexts as shown below:

TASK 1:
__fuse_request_send():
  |--spin_lock(&fiq->waitq.lock);
  |--queue_request();
  |--spin_unlock(&fiq->waitq.lock);
  |--request_wait_answer():
       |--if (test_bit(FR_SENT, &req->flags))
       <gets pre-empted after it is validated true>
                                   TASK 2:
                                   fuse_dev_do_write():
                                     |--clears bit FR_SENT,
                                     |--request_end():
                                        |--sets bit FR_FINISHED
                                        |--spin_lock(&fiq->waitq.lock);
                                        |--list_del_init(&req->intr_entry);
                                        |--spin_unlock(&fiq->waitq.lock);
                                        |--fuse_put_request();
       |--queue_interrupt();
       <request gets queued to interrupts list>
            |--wake_up_locked(&fiq->waitq);
       |--wait_event_freezable();
       <as FR_FINISHED is set, it returns and then
       the caller frees this request>

Now, the next fuse_dev_do_read(), see interrupts list is not empty
and then calls fuse_read_interrupt() which tries to access the request
which is already free'd and gets the below crash:

[11432.401266] Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b6b
...
[11432.418518] Kernel BUG at ffffff80083720e0
[11432.456168] PC is at __list_del_entry+0x6c/0xc4
[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474
...
[11432.679999] [<ffffff80083720e0>] __list_del_entry+0x6c/0xc4
[11432.687794] [<ffffff80082c65e0>] fuse_dev_do_read+0x1ac/0x474
[11432.693180] [<ffffff80082c6b14>] fuse_dev_read+0x6c/0x78
[11432.699082] [<ffffff80081d5638>] __vfs_read+0xc0/0xe8
[11432.704459] [<ffffff80081d5efc>] vfs_read+0x90/0x108
[11432.709406] [<ffffff80081d67f0>] SyS_read+0x58/0x94

As FR_FINISHED bit is set before deleting the intr_entry with input
queue lock in request completion path, do the testing of this flag and
queueing atomically with the same lock in queue_interrupt().

Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/fuse/dev.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/fs/fuse/dev.c
+++ b/fs/fuse/dev.c
@@ -418,6 +418,10 @@ static void request_end(struct fuse_conn
 static void queue_interrupt(struct fuse_iqueue *fiq, struct fuse_req *req)
 {
 	spin_lock(&fiq->waitq.lock);
+	if (test_bit(FR_FINISHED, &req->flags)) {
+		spin_unlock(&fiq->waitq.lock);
+		return;
+	}
 	if (list_empty(&req->intr_entry)) {
 		list_add_tail(&req->intr_entry, &fiq->interrupts);
 		wake_up_locked(&fiq->waitq);

[toc] | [prev] | [next] | [standalone]

#1585322 — [PATCH 4.4 14/15] bcache: Make gc wakeup sane, remove set_task_state()

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

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

From: Kent Overstreet <kent.overstreet@gmail.com>

commit be628be09563f8f6e81929efbd7cf3f45c344416 upstream.

Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/bcache/bcache.h  |    4 ++--
 drivers/md/bcache/btree.c   |   40 ++++++++++++++++++++--------------------
 drivers/md/bcache/btree.h   |    3 +--
 drivers/md/bcache/request.c |    4 +---
 drivers/md/bcache/super.c   |    2 ++
 5 files changed, 26 insertions(+), 27 deletions(-)

--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -425,7 +425,7 @@ struct cache {
 	 * until a gc finishes - otherwise we could pointlessly burn a ton of
 	 * cpu
 	 */
-	unsigned		invalidate_needs_gc:1;
+	unsigned		invalidate_needs_gc;
 
 	bool			discard; /* Get rid of? */
 
@@ -593,8 +593,8 @@ struct cache_set {
 
 	/* Counts how many sectors bio_insert has added to the cache */
 	atomic_t		sectors_to_gc;
+	wait_queue_head_t	gc_wait;
 
-	wait_queue_head_t	moving_gc_wait;
 	struct keybuf		moving_gc_keys;
 	/* Number of moving GC bios in flight */
 	struct semaphore	moving_in_flight;
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1762,33 +1762,34 @@ static void bch_btree_gc(struct cache_se
 	bch_moving_gc(c);
 }
 
-static int bch_gc_thread(void *arg)
+static bool gc_should_run(struct cache_set *c)
 {
-	struct cache_set *c = arg;
 	struct cache *ca;
 	unsigned i;
 
-	while (1) {
-again:
-		bch_btree_gc(c);
+	for_each_cache(ca, c, i)
+		if (ca->invalidate_needs_gc)
+			return true;
 
-		set_current_state(TASK_INTERRUPTIBLE);
-		if (kthread_should_stop())
-			break;
+	if (atomic_read(&c->sectors_to_gc) < 0)
+		return true;
 
-		mutex_lock(&c->bucket_lock);
+	return false;
+}
 
-		for_each_cache(ca, c, i)
-			if (ca->invalidate_needs_gc) {
-				mutex_unlock(&c->bucket_lock);
-				set_current_state(TASK_RUNNING);
-				goto again;
-			}
+static int bch_gc_thread(void *arg)
+{
+	struct cache_set *c = arg;
 
-		mutex_unlock(&c->bucket_lock);
+	while (1) {
+		wait_event_interruptible(c->gc_wait,
+			   kthread_should_stop() || gc_should_run(c));
 
-		try_to_freeze();
-		schedule();
+		if (kthread_should_stop())
+			break;
+
+		set_gc_sectors(c);
+		bch_btree_gc(c);
 	}
 
 	return 0;
@@ -1796,11 +1797,10 @@ again:
 
 int bch_gc_thread_start(struct cache_set *c)
 {
-	c->gc_thread = kthread_create(bch_gc_thread, c, "bcache_gc");
+	c->gc_thread = kthread_run(bch_gc_thread, c, "bcache_gc");
 	if (IS_ERR(c->gc_thread))
 		return PTR_ERR(c->gc_thread);
 
-	set_task_state(c->gc_thread, TASK_INTERRUPTIBLE);
 	return 0;
 }
 
--- a/drivers/md/bcache/btree.h
+++ b/drivers/md/bcache/btree.h
@@ -260,8 +260,7 @@ void bch_initial_mark_key(struct cache_s
 
 static inline void wake_up_gc(struct cache_set *c)
 {
-	if (c->gc_thread)
-		wake_up_process(c->gc_thread);
+	wake_up(&c->gc_wait);
 }
 
 #define MAP_DONE	0
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -196,10 +196,8 @@ static void bch_data_insert_start(struct
 	struct data_insert_op *op = container_of(cl, struct data_insert_op, cl);
 	struct bio *bio = op->bio, *n;
 
-	if (atomic_sub_return(bio_sectors(bio), &op->c->sectors_to_gc) < 0) {
-		set_gc_sectors(op->c);
+	if (atomic_sub_return(bio_sectors(bio), &op->c->sectors_to_gc) < 0)
 		wake_up_gc(op->c);
-	}
 
 	if (op->bypass)
 		return bch_data_invalidate(cl);
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1489,6 +1489,7 @@ struct cache_set *bch_cache_set_alloc(st
 	mutex_init(&c->bucket_lock);
 	init_waitqueue_head(&c->btree_cache_wait);
 	init_waitqueue_head(&c->bucket_wait);
+	init_waitqueue_head(&c->gc_wait);
 	sema_init(&c->uuid_write_mutex, 1);
 
 	spin_lock_init(&c->btree_gc_time.lock);
@@ -1547,6 +1548,7 @@ static void run_cache_set(struct cache_s
 
 	for_each_cache(ca, c, i)
 		c->nbuckets += ca->sb.nbuckets;
+	set_gc_sectors(c);
 
 	if (CACHE_SYNC(&c->sb)) {
 		LIST_HEAD(journal);

[toc] | [prev] | [next] | [standalone]

#1585323 — [PATCH 4.4 15/15] mmc: core: fix multi-bit bus width without high-speed mode

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

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

From: Anssi Hannula <anssi.hannula@bitwise.fi>

commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 upstream.

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
[anssi.hannula@bitwise.fi: backported for the different err variable
 check on v4.4 and tested]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---

Here is a trivial backport as the upstream commit did not apply cleanly
to 4.4-stable.

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

--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1581,10 +1581,10 @@ static int mmc_init_card(struct mmc_host
 		err = mmc_select_hs400(card);
 		if (err)
 			goto free_card;
-	} else if (mmc_card_hs(card)) {
+	} else {
 		/* Select the desired bus width optionally */
 		err = mmc_select_bus_width(card);
-		if (!IS_ERR_VALUE(err)) {
+		if (!IS_ERR_VALUE(err) && mmc_card_hs(card)) {
 			err = mmc_select_hs_ddr(card);
 			if (err)
 				goto free_card;

[toc] | [prev] | [next] | [standalone]

#1585325 — [PATCH 4.4 13/15] ntb_transport: Pick an unused queue

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

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

From: Thomas VanSelus <tvanselus@xes-inc.com>

commit 8fcd0950c021d7be8493280541332b924b9de962 upstream.

Fix typo causing ntb_transport_create_queue to select the first
queue every time, instead of using the next free queue.

Signed-off-by: Thomas VanSelus <tvanselus@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Acked-by: Allen Hubbe <Allen.Hubbe@dell.com>
Fixes: fce8a7bb5 ("PCI-Express Non-Transparent Bridge Support")
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/ntb/ntb_transport.c
+++ b/drivers/ntb/ntb_transport.c
@@ -1623,7 +1623,7 @@ ntb_transport_create_queue(void *data, s
 
 	node = dev_to_node(&ndev->dev);
 
-	free_queue = ffs(nt->qp_bitmap);
+	free_queue = ffs(nt->qp_bitmap_free);
 	if (!free_queue)
 		goto err;
 

[toc] | [prev] | [next] | [standalone]

#1585327 — [PATCH 4.4 08/15] drm/dp/mst: fix kernel oops when turning off secondary monitor

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

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

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

commit bb08c04dc867b5f392caec635c097d5d5fcd8c9f upstream.

100% reproducible issue found on SKL SkullCanyon NUC with two external
DP daisy-chained monitors in DP/MST mode. When turning off or changing
the input of the second monitor the machine stops with a kernel
oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly.

This issue is traced to an inconsistent control flow in
drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the
same time as 'req_payload.num_slots' is set to zero, but the pointer is
dereferenced even when req_payload.num_slot is zero.

The problematic dereference was introduced in commit dfda0df34
("drm/mst: rework payload table allocation to conform better") and may
impact all versions since v3.18

The fix suggested by Chris Wilson removes the kernel oops and was found to
work well after 10mn of monkey-testing with the second monitor power and
input buttons

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990
Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1812,7 +1812,7 @@ int drm_dp_update_payload_part1(struct d
 				mgr->payloads[i].num_slots = req_payload.num_slots;
 			} else if (mgr->payloads[i].num_slots) {
 				mgr->payloads[i].num_slots = 0;
-				drm_dp_destroy_payload_step1(mgr, port, port->vcpi.vcpi, &mgr->payloads[i]);
+				drm_dp_destroy_payload_step1(mgr, port, mgr->payloads[i].vcpi, &mgr->payloads[i]);
 				req_payload.payload_state = mgr->payloads[i].payload_state;
 				mgr->payloads[i].start_slot = 0;
 			}

[toc] | [prev] | [next] | [standalone]

#1585486

On Tue, Feb 21, 2017 at 02:01:57PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.51 release.
> There are 15 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Feb 23 13:01:31 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]

#1585811

On 02/21/2017 06:01 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.51 release.
> There are 15 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Feb 23 13:01:31 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.51-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web