* [PATCH 4.4 01/15] vfs: fix uninitialized flags in splice_to_pipe()
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
@ 2017-02-21 13:01 ` Greg Kroah-Hartman
2017-02-21 13:01 ` [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK Greg Kroah-Hartman
` (14 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Miklos Szeredi, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <mszeredi@redhat.com>
commit 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac upstream.
Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the
unused part of the pipe ring buffer. Previously splice_to_pipe() left
the flags value alone, which could result in incorrect behavior.
Uninitialized flags appears to have been there from the introduction of
the splice syscall.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/splice.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -211,6 +211,7 @@ ssize_t splice_to_pipe(struct pipe_inode
buf->len = spd->partial[page_nr].len;
buf->private = spd->partial[page_nr].private;
buf->ops = spd->ops;
+ buf->flags = 0;
if (spd->flags & SPLICE_F_GIFT)
buf->flags |= PIPE_BUF_FLAG_GIFT;
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
2017-02-21 13:01 ` [PATCH 4.4 01/15] vfs: fix uninitialized flags in splice_to_pipe() Greg Kroah-Hartman
@ 2017-02-21 13:01 ` Greg Kroah-Hartman
2017-02-22 21:07 ` Eddie Chapman
2017-02-21 13:02 ` [PATCH 4.4 03/15] fuse: fix use after free issue in fuse_dev_do_read() Greg Kroah-Hartman
` (13 subsequent siblings)
15 siblings, 1 reply; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:01 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Mauro Carvalho Chehab
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[] = {
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK
2017-02-21 13:01 ` [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK Greg Kroah-Hartman
@ 2017-02-22 21:07 ` Eddie Chapman
2017-02-22 21:20 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 19+ messages in thread
From: Eddie Chapman @ 2017-02-22 21:07 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel; +Cc: stable, Mauro Carvalho Chehab
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK
2017-02-22 21:07 ` Eddie Chapman
@ 2017-02-22 21:20 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 19+ messages in thread
From: Mauro Carvalho Chehab @ 2017-02-22 21:20 UTC (permalink / raw)
To: Eddie Chapman; +Cc: Greg Kroah-Hartman, linux-kernel, stable
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 4.4 03/15] fuse: fix use after free issue in fuse_dev_do_read()
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
2017-02-21 13:01 ` [PATCH 4.4 01/15] vfs: fix uninitialized flags in splice_to_pipe() Greg Kroah-Hartman
2017-02-21 13:01 ` [PATCH 4.4 02/15] [media] siano: make it work again with CONFIG_VMAP_STACK Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 04/15] scsi: dont BUG_ON() empty DMA transfers Greg Kroah-Hartman
` (12 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sahitya Tummala, Miklos Szeredi
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);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 04/15] scsi: dont BUG_ON() empty DMA transfers
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 03/15] fuse: fix use after free issue in fuse_dev_do_read() Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 05/15] Fix missing sanity check in /dev/sg Greg Kroah-Hartman
` (11 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Johannes Thumshirn, Dmitry Vyukov,
James Bottomley, Al Viro, Linus Torvalds
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)
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 05/15] Fix missing sanity check in /dev/sg
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 04/15] scsi: dont BUG_ON() empty DMA transfers Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 06/15] Input: elan_i2c - add ELAN0605 to the ACPI table Greg Kroah-Hartman
` (10 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Al Viro, Dmitry Vyukov,
Christoph Hellwig, Linus Torvalds
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);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 06/15] Input: elan_i2c - add ELAN0605 to the ACPI table
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 05/15] Fix missing sanity check in /dev/sg Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 08/15] drm/dp/mst: fix kernel oops when turning off secondary monitor Greg Kroah-Hartman
` (9 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hiroka IHARA, Dmitry Torokhov
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 },
{ }
};
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 08/15] drm/dp/mst: fix kernel oops when turning off secondary monitor
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 06/15] Input: elan_i2c - add ELAN0605 to the ACPI table Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 09/15] futex: Move futex_init() to core_initcall Greg Kroah-Hartman
` (8 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dave Airlie, Chris Wilson,
Nathan D Ciobanu, Dhinakaran Pandiyan, Sean Paul,
Pierre-Louis Bossart, Jani Nikula
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;
}
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 09/15] futex: Move futex_init() to core_initcall
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 08/15] drm/dp/mst: fix kernel oops when turning off secondary monitor Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 10/15] ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user() Greg Kroah-Hartman
` (7 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yang Yang, jiang.biao2,
jiang.zhengxiong, zhong.weidong, deng.huali, Peter Zijlstra,
Thomas Gleixner
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);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 10/15] ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user()
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 09/15] futex: Move futex_init() to core_initcall Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 11/15] printk: use rcuidle console tracepoint Greg Kroah-Hartman
` (6 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kees Cook, Russell King
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]
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 11/15] printk: use rcuidle console tracepoint
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 10/15] ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user() Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 12/15] NTB: ntb_transport: fix debugfs_remove_recursive Greg Kroah-Hartman
` (5 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sergey Senozhatsky, Tony Lindgren,
Paul E. McKenney, Steven Rostedt (VMware),
Petr Mladek, Peter Zijlstra, Thomas Gleixner, Russell King,
Andrew Morton, Linus Torvalds
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;
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 12/15] NTB: ntb_transport: fix debugfs_remove_recursive
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 11/15] printk: use rcuidle console tracepoint Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 13/15] ntb_transport: Pick an unused queue Greg Kroah-Hartman
` (4 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Allen Hubbe, Jon Mason
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);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 13/15] ntb_transport: Pick an unused queue
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 12/15] NTB: ntb_transport: fix debugfs_remove_recursive Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 14/15] bcache: Make gc wakeup sane, remove set_task_state() Greg Kroah-Hartman
` (3 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas VanSelus, Aaron Sierra,
Allen Hubbe, Jon Mason
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;
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 14/15] bcache: Make gc wakeup sane, remove set_task_state()
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 13/15] ntb_transport: Pick an unused queue Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 13:02 ` [PATCH 4.4 15/15] mmc: core: fix multi-bit bus width without high-speed mode Greg Kroah-Hartman
` (2 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kent Overstreet
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);
^ permalink raw reply [flat|nested] 19+ messages in thread* [PATCH 4.4 15/15] mmc: core: fix multi-bit bus width without high-speed mode
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 14/15] bcache: Make gc wakeup sane, remove set_task_state() Greg Kroah-Hartman
@ 2017-02-21 13:02 ` Greg Kroah-Hartman
2017-02-21 16:15 ` [PATCH 4.4 00/15] 4.4.51-stable review Guenter Roeck
2017-02-21 23:40 ` Shuah Khan
15 siblings, 0 replies; 19+ messages in thread
From: Greg Kroah-Hartman @ 2017-02-21 13:02 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Anssi Hannula, Ulf Hansson
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;
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 4.4 00/15] 4.4.51-stable review
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-02-21 13:02 ` [PATCH 4.4 15/15] mmc: core: fix multi-bit bus width without high-speed mode Greg Kroah-Hartman
@ 2017-02-21 16:15 ` Guenter Roeck
2017-02-21 23:40 ` Shuah Khan
15 siblings, 0 replies; 19+ messages in thread
From: Guenter Roeck @ 2017-02-21 16:15 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH 4.4 00/15] 4.4.51-stable review
2017-02-21 13:01 [PATCH 4.4 00/15] 4.4.51-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-02-21 16:15 ` [PATCH 4.4 00/15] 4.4.51-stable review Guenter Roeck
@ 2017-02-21 23:40 ` Shuah Khan
15 siblings, 0 replies; 19+ messages in thread
From: Shuah Khan @ 2017-02-21 23:40 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
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
^ permalink raw reply [flat|nested] 19+ messages in thread