* [PATCH 4.4 01/40] ALSA: timer: Add missing mutex lock for compat ioctls
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
` (40 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, syzbot, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.
The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl. As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.
The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.
Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/timer_compat.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -106,7 +106,8 @@ enum {
#endif /* CONFIG_X86_X32 */
};
-static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
+static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+ unsigned long arg)
{
void __user *argp = compat_ptr(arg);
@@ -127,7 +128,7 @@ static long snd_timer_user_ioctl_compat(
case SNDRV_TIMER_IOCTL_PAUSE:
case SNDRV_TIMER_IOCTL_PAUSE_OLD:
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
- return snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+ return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
case SNDRV_TIMER_IOCTL_INFO32:
return snd_timer_user_info_compat(file, argp);
case SNDRV_TIMER_IOCTL_STATUS32:
@@ -139,3 +140,15 @@ static long snd_timer_user_ioctl_compat(
}
return -ENOIOCTLCMD;
}
+
+static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct snd_timer_user *tu = file->private_data;
+ long ret;
+
+ mutex_lock(&tu->ioctl_lock);
+ ret = __snd_timer_user_ioctl_compat(file, cmd, arg);
+ mutex_unlock(&tu->ioctl_lock);
+ return ret;
+}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 01/40] ALSA: timer: Add missing mutex lock for compat ioctls
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, syzbot, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 79fb0518fec8c8b4ea7f1729f54f293724b3dbb0 upstream.
The races among ioctl and other operations were protected by the
commit af368027a49a ("ALSA: timer: Fix race among timer ioctls") and
later fixes, but one code path was forgotten in the scenario: the
32bit compat ioctl. As syzkaller recently spotted, a very similar
use-after-free may happen with the combination of compat ioctls.
The fix is simply to apply the same ioctl_lock to the compat_ioctl
callback, too.
Fixes: af368027a49a ("ALSA: timer: Fix race among timer ioctls")
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+e5f3c9783e7048a74233054febbe9f1bdf54b6da@syzkaller.appspotmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/timer_compat.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/sound/core/timer_compat.c
+++ b/sound/core/timer_compat.c
@@ -106,7 +106,8 @@ enum {
#endif /* CONFIG_X86_X32 */
};
-static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd, unsigned long arg)
+static long __snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+ unsigned long arg)
{
void __user *argp = compat_ptr(arg);
@@ -127,7 +128,7 @@ static long snd_timer_user_ioctl_compat(
case SNDRV_TIMER_IOCTL_PAUSE:
case SNDRV_TIMER_IOCTL_PAUSE_OLD:
case SNDRV_TIMER_IOCTL_NEXT_DEVICE:
- return snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
+ return __snd_timer_user_ioctl(file, cmd, (unsigned long)argp);
case SNDRV_TIMER_IOCTL_INFO32:
return snd_timer_user_info_compat(file, argp);
case SNDRV_TIMER_IOCTL_STATUS32:
@@ -139,3 +140,15 @@ static long snd_timer_user_ioctl_compat(
}
return -ENOIOCTLCMD;
}
+
+static long snd_timer_user_ioctl_compat(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ struct snd_timer_user *tu = file->private_data;
+ long ret;
+
+ mutex_lock(&tu->ioctl_lock);
+ ret = __snd_timer_user_ioctl_compat(file, cmd, arg);
+ mutex_unlock(&tu->ioctl_lock);
+ return ret;
+}
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 02/40] ALSA: seq: Fix nested rwsem annotation for lockdep splat
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
` (40 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot, Dmitry Vyukov, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.
syzkaller reported the lockdep splat due to the possible deadlock of
grp->list_mutex of each sequencer client object. Actually this is
rather a false-positive report due to the missing nested lock
annotations. The sequencer client may deliver the event directly to
another client which takes another own lock.
For addressing this issue, this patch replaces the simple down_read()
with down_read_nested(). As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -676,7 +676,7 @@ static int deliver_to_subscribers(struct
if (atomic)
read_lock(&grp->list_lock);
else
- down_read(&grp->list_mutex);
+ down_read_nested(&grp->list_mutex, hop);
list_for_each_entry(subs, &grp->list_head, src_list) {
/* both ports ready? */
if (atomic_read(&subs->ref_count) != 2)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 02/40] ALSA: seq: Fix nested rwsem annotation for lockdep splat
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot, Dmitry Vyukov, Takashi Iwai
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 1f20f9ff57ca23b9f5502fca85ce3977e8496cb1 upstream.
syzkaller reported the lockdep splat due to the possible deadlock of
grp->list_mutex of each sequencer client object. Actually this is
rather a false-positive report due to the missing nested lock
annotations. The sequencer client may deliver the event directly to
another client which takes another own lock.
For addressing this issue, this patch replaces the simple down_read()
with down_read_nested(). As a lock subclass, the already existing
"hop" can be re-used, which indicates the depth of the call.
Reference: http://lkml.kernel.org/r/089e082686ac9b482e055c832617@google.com
Reported-by: syzbot <bot+7feb8de6b4d6bf810cf098bef942cc387e79d0ad@syzkaller.appspotmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/core/seq/seq_clientmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -676,7 +676,7 @@ static int deliver_to_subscribers(struct
if (atomic)
read_lock(&grp->list_lock);
else
- down_read(&grp->list_mutex);
+ down_read_nested(&grp->list_mutex, hop);
list_for_each_entry(subs, &grp->list_head, src_list) {
/* both ports ready? */
if (atomic_read(&subs->ref_count) != 2)
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 03/40] cifs: check MaxPathNameComponentLength != 0 before using it
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 04/40] KEYS: return full count in keyring_read() if buffer is too small Greg Kroah-Hartman
` (38 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ronnie Sahlberg, Steve French,
David Disseldorp
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ronnie Sahlberg <lsahlber@redhat.com>
commit f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 upstream.
And fix tcon leak in error path.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/cifs/dir.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -193,7 +193,8 @@ check_name(struct dentry *direntry, stru
struct cifs_sb_info *cifs_sb = CIFS_SB(direntry->d_sb);
int i;
- if (unlikely(direntry->d_name.len >
+ if (unlikely(tcon->fsAttrInfo.MaxPathNameComponentLength &&
+ direntry->d_name.len >
le32_to_cpu(tcon->fsAttrInfo.MaxPathNameComponentLength)))
return -ENAMETOOLONG;
@@ -509,7 +510,7 @@ cifs_atomic_open(struct inode *inode, st
rc = check_name(direntry, tcon);
if (rc)
- goto out_free_xid;
+ goto out;
server = tcon->ses->server;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 04/40] KEYS: return full count in keyring_read() if buffer is too small
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 03/40] cifs: check MaxPathNameComponentLength != 0 before using it Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 05/40] KEYS: fix out-of-bounds read during ASN.1 parsing Greg Kroah-Hartman
` (37 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ben Hutchings, Eric Biggers,
David Howells, James Morris
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f upstream.
Commit e645016abc80 ("KEYS: fix writing past end of user-supplied buffer
in keyring_read()") made keyring_read() stop corrupting userspace memory
when the user-supplied buffer is too small. However it also made the
return value in that case be the short buffer size rather than the size
required, yet keyctl_read() is actually documented to return the size
required. Therefore, switch it over to the documented behavior.
Note that for now we continue to have it fill the short buffer, since it
did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably
relies on it.
Fixes: e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()")
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/keys/keyring.c | 39 +++++++++++++++++++--------------------
1 file changed, 19 insertions(+), 20 deletions(-)
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -452,34 +452,33 @@ static long keyring_read(const struct ke
char __user *buffer, size_t buflen)
{
struct keyring_read_iterator_context ctx;
- unsigned long nr_keys;
- int ret;
+ long ret;
kenter("{%d},,%zu", key_serial(keyring), buflen);
if (buflen & (sizeof(key_serial_t) - 1))
return -EINVAL;
- nr_keys = keyring->keys.nr_leaves_on_tree;
- if (nr_keys == 0)
- return 0;
-
- /* Calculate how much data we could return */
- if (!buffer || !buflen)
- return nr_keys * sizeof(key_serial_t);
-
- /* Copy the IDs of the subscribed keys into the buffer */
- ctx.buffer = (key_serial_t __user *)buffer;
- ctx.buflen = buflen;
- ctx.count = 0;
- ret = assoc_array_iterate(&keyring->keys, keyring_read_iterator, &ctx);
- if (ret < 0) {
- kleave(" = %d [iterate]", ret);
- return ret;
+ /* Copy as many key IDs as fit into the buffer */
+ if (buffer && buflen) {
+ ctx.buffer = (key_serial_t __user *)buffer;
+ ctx.buflen = buflen;
+ ctx.count = 0;
+ ret = assoc_array_iterate(&keyring->keys,
+ keyring_read_iterator, &ctx);
+ if (ret < 0) {
+ kleave(" = %ld [iterate]", ret);
+ return ret;
+ }
}
- kleave(" = %zu [ok]", ctx.count);
- return ctx.count;
+ /* Return the size of the buffer needed */
+ ret = keyring->keys.nr_leaves_on_tree * sizeof(key_serial_t);
+ if (ret <= buflen)
+ kleave("= %ld [ok]", ret);
+ else
+ kleave("= %ld [buffer too small]", ret);
+ return ret;
}
/*
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 05/40] KEYS: fix out-of-bounds read during ASN.1 parsing
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 04/40] KEYS: return full count in keyring_read() if buffer is too small Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 06/40] ASoC: adau17x1: Workaround for noise bug in ADC Greg Kroah-Hartman
` (36 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, David Howells, James Morris
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 2eb9eabf1e868fda15808954fb29b0f105ed65f1 upstream.
syzkaller with KASAN reported an out-of-bounds read in
asn1_ber_decoder(). It can be reproduced by the following command,
assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y:
keyctl add asymmetric desc $'\x30\x30' @s
The bug is that the length of an ASN.1 data value isn't validated in the
case where it is encoded using the short form, causing the decoder to
read past the end of the input buffer. Fix it by validating the length.
The bug report was:
BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
Read of size 1 at addr ffff88003cccfa02 by task syz-executor0/6818
CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted 4.14.0-rc7-00008-g5f479447d983 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xb3/0x10b lib/dump_stack.c:52
print_address_description+0x79/0x2a0 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x236/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x347/0xb20 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x447c89
RSP: 002b:00007fca7a5d3bd8 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
RAX: ffffffffffffffda RBX: 00007fca7a5d46cc RCX: 0000000000447c89
RDX: 0000000020006f4a RSI: 0000000020006000 RDI: 0000000020001ff5
RBP: 0000000000000046 R08: fffffffffffffffd R09: 0000000000000000
R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007fca7a5d49c0 R15: 00007fca7a5d4700
Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/asn1_decoder.c | 3 +++
1 file changed, 3 insertions(+)
--- a/lib/asn1_decoder.c
+++ b/lib/asn1_decoder.c
@@ -283,6 +283,9 @@ next_op:
if (unlikely(len > datalen - dp))
goto data_overrun_error;
}
+ } else {
+ if (unlikely(len > datalen - dp))
+ goto data_overrun_error;
}
if (flags & FLAG_CONS) {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 06/40] ASoC: adau17x1: Workaround for noise bug in ADC
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 05/40] KEYS: fix out-of-bounds read during ASN.1 parsing Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit Greg Kroah-Hartman
` (35 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ricard Wanderlof, Mark Brown
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ricard Wanderlof <ricard.wanderlof@axis.com>
commit 1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream.
The ADC in the ADAU1361 (and possibly other Analog Devices codecs)
exhibits a cyclic variation in the noise floor (in our test setup between
-87 and -93 dB), a new value being attained within this range whenever a
new capture stream is started. The cycle repeats after about 10 or 11
restarts.
The workaround recommended by the manufacturer is to toggle the ADOSR bit
in the Converter Control 0 register each time a new capture stream is
started.
I have verified that the patch fixes this problem on the ADAU1361, and
according to the manufacturer toggling the bit in question in this manner
will at least have no detrimental effect on other chips served by this
driver.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/soc/codecs/adau17x1.c | 24 +++++++++++++++++++++++-
sound/soc/codecs/adau17x1.h | 2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
--- a/sound/soc/codecs/adau17x1.c
+++ b/sound/soc/codecs/adau17x1.c
@@ -89,6 +89,27 @@ static int adau17x1_pll_event(struct snd
return 0;
}
+static int adau17x1_adc_fixup(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_codec *codec = snd_soc_dapm_to_codec(w->dapm);
+ struct adau *adau = snd_soc_codec_get_drvdata(codec);
+
+ /*
+ * If we are capturing, toggle the ADOSR bit in Converter Control 0 to
+ * avoid losing SNR (workaround from ADI). This must be done after
+ * the ADC(s) have been enabled. According to the data sheet, it is
+ * normally illegal to set this bit when the sampling rate is 96 kHz,
+ * but according to ADI it is acceptable for this workaround.
+ */
+ regmap_update_bits(adau->regmap, ADAU17X1_CONVERTER0,
+ ADAU17X1_CONVERTER0_ADOSR, ADAU17X1_CONVERTER0_ADOSR);
+ regmap_update_bits(adau->regmap, ADAU17X1_CONVERTER0,
+ ADAU17X1_CONVERTER0_ADOSR, 0);
+
+ return 0;
+}
+
static const char * const adau17x1_mono_stereo_text[] = {
"Stereo",
"Mono Left Channel (L+R)",
@@ -120,7 +141,8 @@ static const struct snd_soc_dapm_widget
SND_SOC_DAPM_MUX("Right DAC Mode Mux", SND_SOC_NOPM, 0, 0,
&adau17x1_dac_mode_mux),
- SND_SOC_DAPM_ADC("Left Decimator", NULL, ADAU17X1_ADC_CONTROL, 0, 0),
+ SND_SOC_DAPM_ADC_E("Left Decimator", NULL, ADAU17X1_ADC_CONTROL, 0, 0,
+ adau17x1_adc_fixup, SND_SOC_DAPM_POST_PMU),
SND_SOC_DAPM_ADC("Right Decimator", NULL, ADAU17X1_ADC_CONTROL, 1, 0),
SND_SOC_DAPM_DAC("Left DAC", NULL, ADAU17X1_DAC_CONTROL0, 0, 0),
SND_SOC_DAPM_DAC("Right DAC", NULL, ADAU17X1_DAC_CONTROL0, 1, 0),
--- a/sound/soc/codecs/adau17x1.h
+++ b/sound/soc/codecs/adau17x1.h
@@ -123,5 +123,7 @@ bool adau17x1_has_dsp(struct adau *adau)
#define ADAU17X1_CONVERTER0_CONVSR_MASK 0x7
+#define ADAU17X1_CONVERTER0_ADOSR BIT(3)
+
#endif
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 06/40] ASoC: adau17x1: Workaround for noise bug in ADC Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-13 19:05 ` Ben Hutchings
2017-11-06 9:44 ` [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill Greg Kroah-Hartman
` (34 subsequent siblings)
41 siblings, 1 reply; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Will Deacon, Mark Rutland, Catalin Marinas
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <mark.rutland@arm.com>
commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.
Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.
Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.
Fixes: 60ffc30d5652810d ("arm64: Exception handling")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/kernel/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -129,7 +129,7 @@ static void dump_instr(const char *lvl,
for (i = -4; i < 1; i++) {
unsigned int val, bad;
- bad = __get_user(val, &((u32 *)addr)[i]);
+ bad = get_user(val, &((u32 *)addr)[i]);
if (!bad)
p += sprintf(p, i == 0 ? "(%08x) " : "%08x ", val);
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-06 9:44 ` [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit Greg Kroah-Hartman
@ 2017-11-13 19:05 ` Ben Hutchings
2017-11-14 13:52 ` Catalin Marinas
2017-11-15 13:28 ` Ben Hutchings
0 siblings, 2 replies; 62+ messages in thread
From: Ben Hutchings @ 2017-11-13 19:05 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Will Deacon, Mark Rutland, Catalin Marinas
On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Mark Rutland <mark.rutland@arm.com>
>
> commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
>
> It's possible for a user to deliberately trigger __dump_instr with a
> chosen kernel address.
>
> Let's avoid problems resulting from this by using get_user() rather than
> __get_user(), ensuring that we don't erroneously access kernel memory.
>
> Where we use __dump_instr() on kernel text, we already switch to
> KERNEL_DS, so this shouldn't adversely affect those cases.
>
> Fixes: 60ffc30d5652810d ("arm64: Exception handling")
[...]
This seems harmless, but I don't think it will fix the bug in 4.4
unless you also cherry-pick:
commit c5cea06be060f38e5400d796e61cfc8c36e52924
Author: Mark Rutland <mark.rutland@arm.com>
Date: Mon Jun 13 11:15:14 2016 +0100
arm64: fix dump_instr when PAN and UAO are in use
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-13 19:05 ` Ben Hutchings
@ 2017-11-14 13:52 ` Catalin Marinas
2017-11-15 13:28 ` Ben Hutchings
1 sibling, 0 replies; 62+ messages in thread
From: Catalin Marinas @ 2017-11-14 13:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Greg Kroah-Hartman, linux-kernel, stable, Will Deacon, Mark Rutland
On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Mark Rutland <mark.rutland@arm.com>
> >
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> >
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> >
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> >
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> >
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> [...]
>
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
>
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date: Mon Jun 13 11:15:14 2016 +0100
>
> arm64: fix dump_instr when PAN and UAO are in use
I agree. In 4.4 dump_instr() doesn't do any checks, just
set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
Override"; merged in 4.6), it also makes sense on its own as a security
improvement for 4.4.
Mark is currently on holiday but he'll follow up next week if any
patches need back-porting.
--
Catalin
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
@ 2017-11-14 13:52 ` Catalin Marinas
0 siblings, 0 replies; 62+ messages in thread
From: Catalin Marinas @ 2017-11-14 13:52 UTC (permalink / raw)
To: Ben Hutchings
Cc: Greg Kroah-Hartman, linux-kernel, stable, Will Deacon, Mark Rutland
On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.��If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Mark Rutland <mark.rutland@arm.com>
> >
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> >
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> >
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> >
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> >
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> [...]
>
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
>
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date:���Mon Jun 13 11:15:14 2016 +0100
>
> ����arm64: fix dump_instr when PAN and UAO are in use
I agree. In 4.4 dump_instr() doesn't do any checks, just
set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
Override"; merged in 4.6), it also makes sense on its own as a security
improvement for 4.4.
Mark is currently on holiday but he'll follow up next week if any
patches need back-porting.
--
Catalin
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-14 13:52 ` Catalin Marinas
(?)
@ 2017-11-14 16:18 ` Mark Rutland
2017-11-19 10:29 ` Greg Kroah-Hartman
-1 siblings, 1 reply; 62+ messages in thread
From: Mark Rutland @ 2017-11-14 16:18 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ben Hutchings, Greg Kroah-Hartman, linux-kernel, stable, Will Deacon
On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Mark Rutland <mark.rutland@arm.com>
> > >
> > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > >
> > > It's possible for a user to deliberately trigger __dump_instr with a
> > > chosen kernel address.
> > >
> > > Let's avoid problems resulting from this by using get_user() rather than
> > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > >
> > > Where we use __dump_instr() on kernel text, we already switch to
> > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > >
> > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > [...]
> >
> > This seems harmless, but I don't think it will fix the bug in 4.4
> > unless you also cherry-pick:
> >
> > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > Author: Mark Rutland <mark.rutland@arm.com>
> > Date: Mon Jun 13 11:15:14 2016 +0100
> >
> > arm64: fix dump_instr when PAN and UAO are in use
>
> I agree. In 4.4 dump_instr() doesn't do any checks, just
> set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> Override"; merged in 4.6), it also makes sense on its own as a security
> improvement for 4.4.
>
> Mark is currently on holiday but he'll follow up next week if any
> patches need back-porting.
I accidentally glanced at my gmail filter this morning; so I can reply today.
;)
I agree that we need both patches. On its own (in the absence of PAN/UAO),
57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
can dump kernel instructions when we intend to, with 7a7003b1da010d2b
backported.
Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
I hadn't realised you could list prerequisites in a stable Cc -- I'll try to do
that in future.
Thanks,
Mark.
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-14 16:18 ` Mark Rutland
@ 2017-11-19 10:29 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 10:29 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Ben Hutchings, linux-kernel, stable, Will Deacon
On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch. If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Mark Rutland <mark.rutland@arm.com>
> > > >
> > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > >
> > > > It's possible for a user to deliberately trigger __dump_instr with a
> > > > chosen kernel address.
> > > >
> > > > Let's avoid problems resulting from this by using get_user() rather than
> > > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > > >
> > > > Where we use __dump_instr() on kernel text, we already switch to
> > > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > >
> > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > > [...]
> > >
> > > This seems harmless, but I don't think it will fix the bug in 4.4
> > > unless you also cherry-pick:
> > >
> > > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > > Author: Mark Rutland <mark.rutland@arm.com>
> > > Date: Mon Jun 13 11:15:14 2016 +0100
> > >
> > > arm64: fix dump_instr when PAN and UAO are in use
> >
> > I agree. In 4.4 dump_instr() doesn't do any checks, just
> > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> > Override"; merged in 4.6), it also makes sense on its own as a security
> > improvement for 4.4.
> >
> > Mark is currently on holiday but he'll follow up next week if any
> > patches need back-porting.
>
> I accidentally glanced at my gmail filter this morning; so I can reply today.
> ;)
>
> I agree that we need both patches. On its own (in the absence of PAN/UAO),
> 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> backported.
>
> Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
But that is a "new feature", are you sure about this?
So, just apply that one patch and we are all ok? Nothing else?
confused,
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
@ 2017-11-19 10:29 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-19 10:29 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Ben Hutchings, linux-kernel, stable, Will Deacon
On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> On Tue, Nov 14, 2017 at 01:52:14PM +0000, Catalin Marinas wrote:
> > On Mon, Nov 13, 2017 at 07:05:12PM +0000, Ben Hutchings wrote:
> > > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > > 4.4-stable review patch.��If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Mark Rutland <mark.rutland@arm.com>
> > > >
> > > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > > >
> > > > It's possible for a user to deliberately trigger __dump_instr with a
> > > > chosen kernel address.
> > > >
> > > > Let's avoid problems resulting from this by using get_user() rather than
> > > > __get_user(), ensuring that we don't erroneously access kernel memory.
> > > >
> > > > Where we use __dump_instr() on kernel text, we already switch to
> > > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > > >
> > > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> > > [...]
> > >
> > > This seems harmless, but I don't think it will fix the bug in 4.4
> > > unless you also cherry-pick:
> > >
> > > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > > Author: Mark Rutland <mark.rutland@arm.com>
> > > Date:���Mon Jun 13 11:15:14 2016 +0100
> > >
> > > ����arm64: fix dump_instr when PAN and UAO are in use
> >
> > I agree. In 4.4 dump_instr() doesn't do any checks, just
> > set_fs(KERNEL_DS) and __get_user(). While commit c5cea06b was added to
> > fix 57f4959bad0a154a ("arm64: kernel: Add support for User Access
> > Override"; merged in 4.6), it also makes sense on its own as a security
> > improvement for 4.4.
> >
> > Mark is currently on holiday but he'll follow up next week if any
> > patches need back-porting.
>
> I accidentally glanced at my gmail filter this morning; so I can reply today.
> ;)
>
> I agree that we need both patches. On its own (in the absence of PAN/UAO),
> 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> backported.
>
> Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
But that is a "new feature", are you sure about this?
So, just apply that one patch and we are all ok? Nothing else?
confused,
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-19 10:29 ` Greg Kroah-Hartman
(?)
@ 2017-11-20 11:26 ` Mark Rutland
2017-11-21 16:55 ` Greg Kroah-Hartman
-1 siblings, 1 reply; 62+ messages in thread
From: Mark Rutland @ 2017-11-20 11:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Catalin Marinas, Ben Hutchings, linux-kernel, stable, Will Deacon
On Sun, Nov 19, 2017 at 11:29:35AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> > I agree that we need both patches. On its own (in the absence of PAN/UAO),
> > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> > can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> > backported.
> >
> > Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
>
> But that is a "new feature", are you sure about this?
Sorry, I copied the wrong commit ID when replying. I meant to say that
we should backport commit:
c5cea06be060f38e ("arm64: fix dump_instr when PAN and UAO are in use")
... which on its own does nothing, but will prevent 7a7003b1da010d2b
from breaking kernel dumps.
We should *not* backport commit:
57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")
> So, just apply that one patch and we are all ok? Nothing else?
Just apply c5cea06be060f38e as a prerequisite for 7a7003b1da010d2b, and
I think we're good. I'm not aware of anything else we need.
> confused,
Sorry about that. Hopefully the above clarified things?
Thanks,
Mark.
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-20 11:26 ` Mark Rutland
@ 2017-11-21 16:55 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-21 16:55 UTC (permalink / raw)
To: Mark Rutland
Cc: Catalin Marinas, Ben Hutchings, linux-kernel, stable, Will Deacon
On Mon, Nov 20, 2017 at 11:26:20AM +0000, Mark Rutland wrote:
> On Sun, Nov 19, 2017 at 11:29:35AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 14, 2017 at 04:18:23PM +0000, Mark Rutland wrote:
> > > I agree that we need both patches. On its own (in the absence of PAN/UAO),
> > > 57f4959bad0a154a wouldn't have any effect, but it is critical to ensure that we
> > > can dump kernel instructions when we intend to, with 7a7003b1da010d2b
> > > backported.
> > >
> > > Backporting 57f4959bad0a154a as a prerequisite makes sense to me.
> >
> > But that is a "new feature", are you sure about this?
>
> Sorry, I copied the wrong commit ID when replying. I meant to say that
> we should backport commit:
>
> c5cea06be060f38e ("arm64: fix dump_instr when PAN and UAO are in use")
>
> ... which on its own does nothing, but will prevent 7a7003b1da010d2b
> from breaking kernel dumps.
>
> We should *not* backport commit:
>
> 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")
>
> > So, just apply that one patch and we are all ok? Nothing else?
>
> Just apply c5cea06be060f38e as a prerequisite for 7a7003b1da010d2b, and
> I think we're good. I'm not aware of anything else we need.
>
> > confused,
>
> Sorry about that. Hopefully the above clarified things?
Yes, it did, thanks, I think I've queued up the right patches now, if
not, please let me know :)
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread
* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-13 19:05 ` Ben Hutchings
2017-11-14 13:52 ` Catalin Marinas
@ 2017-11-15 13:28 ` Ben Hutchings
2017-11-15 13:36 ` Ben Hutchings
1 sibling, 1 reply; 62+ messages in thread
From: Ben Hutchings @ 2017-11-15 13:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Will Deacon, Mark Rutland, Catalin Marinas
On Mon, 2017-11-13 at 19:05 +0000, Ben Hutchings wrote:
> On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > > > From: Mark Rutland <mark.rutland@arm.com>
> >
> > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> >
> > It's possible for a user to deliberately trigger __dump_instr with a
> > chosen kernel address.
> >
> > Let's avoid problems resulting from this by using get_user() rather than
> > __get_user(), ensuring that we don't erroneously access kernel memory.
> >
> > Where we use __dump_instr() on kernel text, we already switch to
> > KERNEL_DS, so this shouldn't adversely affect those cases.
> >
> > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
>
> [...]
>
> This seems harmless, but I don't think it will fix the bug in 4.4
> unless you also cherry-pick:
>
> commit c5cea06be060f38e5400d796e61cfc8c36e52924
> Author: Mark Rutland <mark.rutland@arm.com>
> Date: Mon Jun 13 11:15:14 2016 +0100
>
> arm64: fix dump_instr when PAN and UAO are in use
Oops, now I see you already have that as patch #36.
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit
2017-11-15 13:28 ` Ben Hutchings
@ 2017-11-15 13:36 ` Ben Hutchings
0 siblings, 0 replies; 62+ messages in thread
From: Ben Hutchings @ 2017-11-15 13:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Will Deacon, Mark Rutland, Catalin Marinas
On Wed, 2017-11-15 at 13:28 +0000, Ben Hutchings wrote:
> On Mon, 2017-11-13 at 19:05 +0000, Ben Hutchings wrote:
> > On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote:
> > > 4.4-stable review patch. If anyone has any objections, please
> > > let me know.
> > >
> > > ------------------
> > >
> > > > > From: Mark Rutland <mark.rutland@arm.com>
> > >
> > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
> > >
> > > It's possible for a user to deliberately trigger __dump_instr
> > > with a
> > > chosen kernel address.
> > >
> > > Let's avoid problems resulting from this by using get_user()
> > > rather than
> > > __get_user(), ensuring that we don't erroneously access kernel
> > > memory.
> > >
> > > Where we use __dump_instr() on kernel text, we already switch to
> > > KERNEL_DS, so this shouldn't adversely affect those cases.
> > >
> > > Fixes: 60ffc30d5652810d ("arm64: Exception handling")
> >
> > [...]
> >
> > This seems harmless, but I don't think it will fix the bug in 4.4
> > unless you also cherry-pick:
> >
> > commit c5cea06be060f38e5400d796e61cfc8c36e52924
> > Author: Mark Rutland <mark.rutland@arm.com>
> > Date: Mon Jun 13 11:15:14 2016 +0100
> >
> > arm64: fix dump_instr when PAN and UAO are in use
>
> Oops, now I see you already have that as patch #36.
Only not, because I'm confusing arm and arm64.
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-07 23:06 ` Sebastian Gottschall
2017-11-06 9:44 ` [PATCH 4.4 09/40] ARM: 8715/1: add a private asm/unaligned.h Greg Kroah-Hartman
` (33 subsequent siblings)
41 siblings, 1 reply; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yan Markman, Igal Liberman,
Nadav Haklai, Gregory CLEMENT
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yan Markman <ymarkman@marvell.com>
commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.
Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.
The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.
Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.
Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
Signed-off-by: Yan Markman <ymarkman@marvell.com>
Signed-off-by: Igal Liberman <igall@marvell.com>
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
[gregory.clement@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
arch/arm/boot/dts/armada-38x.dtsi | 4 ++--
arch/arm/boot/dts/armada-39x.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -176,9 +176,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
- arm,double-linefill-incr = <1>;
+ arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
- arm,double-linefill = <1>;
+ arm,double-linefill = <0>;
prefetch-data = <1>;
};
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -143,9 +143,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
- arm,double-linefill-incr = <1>;
+ arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
- arm,double-linefill = <1>;
+ arm,double-linefill = <0>;
prefetch-data = <1>;
};
--- a/arch/arm/boot/dts/armada-39x.dtsi
+++ b/arch/arm/boot/dts/armada-39x.dtsi
@@ -104,9 +104,9 @@
reg = <0x8000 0x1000>;
cache-unified;
cache-level = <2>;
- arm,double-linefill-incr = <1>;
+ arm,double-linefill-incr = <0>;
arm,double-linefill-wrap = <0>;
- arm,double-linefill = <1>;
+ arm,double-linefill = <0>;
prefetch-data = <1>;
};
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill
2017-11-06 9:44 ` [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill Greg Kroah-Hartman
@ 2017-11-07 23:06 ` Sebastian Gottschall
2017-11-08 8:44 ` Greg Kroah-Hartman
0 siblings, 1 reply; 62+ messages in thread
From: Sebastian Gottschall @ 2017-11-07 23:06 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Yan Markman, Igal Liberman, Nadav Haklai, Gregory CLEMENT
what about 4.9?
Am 06.11.2017 um 10:44 schrieb Greg Kroah-Hartman:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Yan Markman <ymarkman@marvell.com>
>
> commit cda80a82ac3e89309706c027ada6ab232be1d640 upstream.
>
> Under heavy system stress mvebu SoC using Cortex A9 sporadically
> encountered instability issues.
>
> The "double linefill" feature of L2 cache was identified as causing
> dependency between read and write which lead to the deadlock.
>
> Especially, it was the cause of deadlock seen under heavy PCIe traffic,
> as this dependency violates PCIE overtaking rule.
>
> Fixes: c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
> Signed-off-by: Yan Markman <ymarkman@marvell.com>
> Signed-off-by: Igal Liberman <igall@marvell.com>
> Signed-off-by: Nadav Haklai <nadavh@marvell.com>
> [gregory.clement@free-electrons.com: reformulate commit log, add Armada
> 375 and add Fixes tag]
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> arch/arm/boot/dts/armada-375.dtsi | 4 ++--
> arch/arm/boot/dts/armada-38x.dtsi | 4 ++--
> arch/arm/boot/dts/armada-39x.dtsi | 4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -176,9 +176,9 @@
> reg = <0x8000 0x1000>;
> cache-unified;
> cache-level = <2>;
> - arm,double-linefill-incr = <1>;
> + arm,double-linefill-incr = <0>;
> arm,double-linefill-wrap = <0>;
> - arm,double-linefill = <1>;
> + arm,double-linefill = <0>;
> prefetch-data = <1>;
> };
>
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -143,9 +143,9 @@
> reg = <0x8000 0x1000>;
> cache-unified;
> cache-level = <2>;
> - arm,double-linefill-incr = <1>;
> + arm,double-linefill-incr = <0>;
> arm,double-linefill-wrap = <0>;
> - arm,double-linefill = <1>;
> + arm,double-linefill = <0>;
> prefetch-data = <1>;
> };
>
> --- a/arch/arm/boot/dts/armada-39x.dtsi
> +++ b/arch/arm/boot/dts/armada-39x.dtsi
> @@ -104,9 +104,9 @@
> reg = <0x8000 0x1000>;
> cache-unified;
> cache-level = <2>;
> - arm,double-linefill-incr = <1>;
> + arm,double-linefill-incr = <0>;
> arm,double-linefill-wrap = <0>;
> - arm,double-linefill = <1>;
> + arm,double-linefill = <0>;
> prefetch-data = <1>;
> };
>
>
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill
2017-11-07 23:06 ` Sebastian Gottschall
@ 2017-11-08 8:44 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-08 8:44 UTC (permalink / raw)
To: Sebastian Gottschall
Cc: linux-kernel, stable, Yan Markman, Igal Liberman, Nadav Haklai,
Gregory CLEMENT
On Wed, Nov 08, 2017 at 12:06:48AM +0100, Sebastian Gottschall wrote:
> what about 4.9?
Ok, that was odd, I don't know what happened there, now added to the 4.9
tree, thanks for catching that.
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 09/40] ARM: 8715/1: add a private asm/unaligned.h
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 08/40] ARM: dts: mvebu: pl310-cache disable double-linefill Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 10/40] ocfs2: fstrim: Fix start offset of first cluster group during fstrim Greg Kroah-Hartman
` (32 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Russell King
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
commit 1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream.
The asm-generic/unaligned.h header provides two different implementations
for accessing unaligned variables: the access_ok.h version used when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
are in fact aligned, while the le_struct.h version convinces gcc that the
alignment of a pointer is '1', to make it issue the correct load/store
instructions depending on the architecture flags.
On ARMv5 and older, we always use the second version, to let the compiler
use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
version, so the compiler can use any instruction including stm/ldm and
ldrd/strd that will cause an alignment trap. This trap can significantly
impact performance when we have to do a lot of fixups and, worse, has
led to crashes in the LZ4 decompressor code that does not have a trap
handler.
This adds an ARM specific version of asm/unaligned.h that uses the
le_struct.h/be_struct.h implementation unconditionally. This should lead
to essentially the same code on ARMv6+ as before, with the exception of
using regular load/store instructions instead of the trapping instructions
multi-register variants.
The crash in the LZ4 decompressor code was probably introduced by the
patch replacing the LZ4 implementation, commit 4e1a33b105dd ("lib: update
LZ4 compressor module"), so linux-4.11 and higher would be affected most.
However, we probably want to have this backported to all older stable
kernels as well, to help with the performance issues.
There are two follow-ups that I think we should also work on, but not
backport to stable kernels, first to change the asm-generic version of
the header to remove the ARM special case, and second to review all
other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
might be affected by the same problem on ARM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/Kbuild | 1 -
arch/arm/include/asm/unaligned.h | 27 +++++++++++++++++++++++++++
2 files changed, 27 insertions(+), 1 deletion(-)
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -36,4 +36,3 @@ generic-y += termbits.h
generic-y += termios.h
generic-y += timex.h
generic-y += trace_clock.h
-generic-y += unaligned.h
--- /dev/null
+++ b/arch/arm/include/asm/unaligned.h
@@ -0,0 +1,27 @@
+#ifndef __ASM_ARM_UNALIGNED_H
+#define __ASM_ARM_UNALIGNED_H
+
+/*
+ * We generally want to set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS on ARMv6+,
+ * but we don't want to use linux/unaligned/access_ok.h since that can lead
+ * to traps on unaligned stm/ldm or strd/ldrd.
+ */
+#include <asm/byteorder.h>
+
+#if defined(__LITTLE_ENDIAN)
+# include <linux/unaligned/le_struct.h>
+# include <linux/unaligned/be_byteshift.h>
+# include <linux/unaligned/generic.h>
+# define get_unaligned __get_unaligned_le
+# define put_unaligned __put_unaligned_le
+#elif defined(__BIG_ENDIAN)
+# include <linux/unaligned/be_struct.h>
+# include <linux/unaligned/le_byteshift.h>
+# include <linux/unaligned/generic.h>
+# define get_unaligned __get_unaligned_be
+# define put_unaligned __put_unaligned_be
+#else
+# error need to define endianess
+#endif
+
+#endif /* __ASM_ARM_UNALIGNED_H */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 10/40] ocfs2: fstrim: Fix start offset of first cluster group during fstrim
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 09/40] ARM: 8715/1: add a private asm/unaligned.h Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 11/40] perf tools: Fix build failure on perl script context Greg Kroah-Hartman
` (31 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ashish Samant, Junxiao Bi, Joseph Qi,
Mark Fasheh, Joel Becker, Andrew Morton, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ashish Samant <ashish.samant@oracle.com>
commit 105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream.
The first cluster group descriptor is not stored at the start of the
group but at an offset from the start. We need to take this into
account while doing fstrim on the first cluster group. Otherwise we
will wrongly start fstrim a few blocks after the desired start block and
the range can cross over into the next cluster group and zero out the
group descriptor there. This can cause filesytem corruption that cannot
be fixed by fsck.
Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com
Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.org>
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>
---
fs/ocfs2/alloc.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
--- a/fs/ocfs2/alloc.c
+++ b/fs/ocfs2/alloc.c
@@ -7270,13 +7270,24 @@ out:
static int ocfs2_trim_extent(struct super_block *sb,
struct ocfs2_group_desc *gd,
- u32 start, u32 count)
+ u64 group, u32 start, u32 count)
{
u64 discard, bcount;
+ struct ocfs2_super *osb = OCFS2_SB(sb);
bcount = ocfs2_clusters_to_blocks(sb, count);
- discard = le64_to_cpu(gd->bg_blkno) +
- ocfs2_clusters_to_blocks(sb, start);
+ discard = ocfs2_clusters_to_blocks(sb, start);
+
+ /*
+ * For the first cluster group, the gd->bg_blkno is not at the start
+ * of the group, but at an offset from the start. If we add it while
+ * calculating discard for first group, we will wrongly start fstrim a
+ * few blocks after the desried start block and the range can cross
+ * over into the next cluster group. So, add it only if this is not
+ * the first cluster group.
+ */
+ if (group != osb->first_cluster_group_blkno)
+ discard += le64_to_cpu(gd->bg_blkno);
trace_ocfs2_trim_extent(sb, (unsigned long long)discard, bcount);
@@ -7284,7 +7295,7 @@ static int ocfs2_trim_extent(struct supe
}
static int ocfs2_trim_group(struct super_block *sb,
- struct ocfs2_group_desc *gd,
+ struct ocfs2_group_desc *gd, u64 group,
u32 start, u32 max, u32 minbits)
{
int ret = 0, count = 0, next;
@@ -7303,7 +7314,7 @@ static int ocfs2_trim_group(struct super
next = ocfs2_find_next_bit(bitmap, max, start);
if ((next - start) >= minbits) {
- ret = ocfs2_trim_extent(sb, gd,
+ ret = ocfs2_trim_extent(sb, gd, group,
start, next - start);
if (ret < 0) {
mlog_errno(ret);
@@ -7401,7 +7412,8 @@ int ocfs2_trim_fs(struct super_block *sb
}
gd = (struct ocfs2_group_desc *)gd_bh->b_data;
- cnt = ocfs2_trim_group(sb, gd, first_bit, last_bit, minlen);
+ cnt = ocfs2_trim_group(sb, gd, group,
+ first_bit, last_bit, minlen);
brelse(gd_bh);
gd_bh = NULL;
if (cnt < 0) {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 11/40] perf tools: Fix build failure on perl script context
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 10/40] ocfs2: fstrim: Fix start offset of first cluster group during fstrim Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 12/40] drm/msm: Fix potential buffer overflow issue Greg Kroah-Hartman
` (30 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Peter Zijlstra,
Tuomas Tynkkynen
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namhyung Kim <namhyung@kernel.org>
commit b581c01fff646b5075d65359c8667de9c667da9e upstream.
On my Archlinux machine, perf faild to build like below:
CC scripts/perl/Perf-Trace-Util/Context.o
In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0,
from Context.xs:23:
/usr/lib/perl5/core/perl/CORE/inline.h: In function :
/usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av'
shadows a previous local [-Werror-shadow]
AV *av =3D GvAV(PL_defgv);
^
/usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of
macro 'CX_POP_SAVEARRAY'
CX_POP_SAVEARRAY(cx);
^~~~~~~~~~~~~~~~
In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0,
from Context.xs:23:
/usr/lib/perl5/core/perl/CORE/inline.h:518:9: note:
shadowed declaration is here
AV *av;
^~
What I did to fix is adding '-Wno-shadow' as the error message said it's
the cause of the failure. Since it's from the perl (not perf) code
base, we don't have the control so I just wanted to ignore the warning
when compiling perl scripting code.
Committer note:
This also fixes the build on Fedora Rawhide.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160802024317.31725-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/scripts/perl/Perf-Trace-Util/Build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
@@ -1,3 +1,5 @@
libperf-y += Context.o
-CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs -Wno-undef -Wno-switch-default
+CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls -Wno-strict-prototypes
+CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
+CFLAGS_Context.o += -Wno-switch-default -Wno-shadow
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 12/40] drm/msm: Fix potential buffer overflow issue
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 11/40] perf tools: Fix build failure on perl script context Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 13/40] drm/msm: fix an integer overflow test Greg Kroah-Hartman
` (29 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kasin Li, Jordan Crouse, Rob Clark,
Ben Hutchings
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kasin Li <donglil@codeaurora.org>
commit 4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.
In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.
Signed-off-by: Kasin Li <donglil@codeaurora.org>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/msm_gem_submit.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -34,10 +34,13 @@ static inline void __user *to_user_ptr(u
}
static struct msm_gem_submit *submit_create(struct drm_device *dev,
- struct msm_gpu *gpu, int nr)
+ struct msm_gpu *gpu, uint32_t int nr)
{
struct msm_gem_submit *submit;
- int sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+ uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+
+ if (sz > SIZE_MAX)
+ return NULL;
submit = kmalloc(sz, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
if (submit) {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 13/40] drm/msm: fix an integer overflow test
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 12/40] drm/msm: Fix potential buffer overflow issue Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 14/40] tracing/samples: Fix creation and deletion of simple_thread_fn creation Greg Kroah-Hartman
` (28 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Jordan Crouse,
Rob Clark, Ben Hutchings
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 65e93108891e571f177c202add9288eda9ac4100 upstream.
We recently added an integer overflow check but it needs an additional
tweak to work properly on 32 bit systems.
The problem is that we're doing the right hand side of the assignment as
type unsigned long so the max it will have an integer overflow instead
of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition
is never true even on 32 bit systems. We need to first cast it to u64
and then do the math.
Fixes: 4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -37,7 +37,7 @@ static struct msm_gem_submit *submit_cre
struct msm_gpu *gpu, uint32_t int nr)
{
struct msm_gem_submit *submit;
- uint64_t sz = sizeof(*submit) + (nr * sizeof(submit->bos[0]));
+ uint64_t sz = sizeof(*submit) + ((u64)nr * sizeof(submit->bos[0]));
if (sz > SIZE_MAX)
return NULL;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 14/40] tracing/samples: Fix creation and deletion of simple_thread_fn creation
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 13/40] drm/msm: fix an integer overflow test Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 15/40] Fix tracing sample code warning Greg Kroah-Hartman
` (27 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Steven Rostedt (VMware)
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt (VMware) <rostedt@goodmis.org>
commit 6575257c60e1a26a5319ccf2b5ce5b6449001017 upstream.
Commit 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and
DEFINE_EVENT()") added template examples for all the events. It created a
DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
functions.
Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
events caused the foo_bar_reg to be called twice, creating the test thread
twice. The foo_bar_unreg would remove it only once, even if it was called
multiple times, leaving a thread existing when the module is unloaded,
causing an oops.
Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
multiple trace events.
Fixes: 7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
samples/trace_events/trace-events-sample.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -78,28 +78,36 @@ static int simple_thread_fn(void *arg)
}
static DEFINE_MUTEX(thread_mutex);
+static bool simple_thread_cnt;
void foo_bar_reg(void)
{
+ mutex_lock(&thread_mutex);
+ if (simple_thread_cnt++)
+ goto out;
+
pr_info("Starting thread for foo_bar_fn\n");
/*
* We shouldn't be able to start a trace when the module is
* unloading (there's other locks to prevent that). But
* for consistency sake, we still take the thread_mutex.
*/
- mutex_lock(&thread_mutex);
simple_tsk_fn = kthread_run(simple_thread_fn, NULL, "event-sample-fn");
+ out:
mutex_unlock(&thread_mutex);
}
void foo_bar_unreg(void)
{
- pr_info("Killing thread for foo_bar_fn\n");
- /* protect against module unloading */
mutex_lock(&thread_mutex);
+ if (--simple_thread_cnt)
+ goto out;
+
+ pr_info("Killing thread for foo_bar_fn\n");
if (simple_tsk_fn)
kthread_stop(simple_tsk_fn);
simple_tsk_fn = NULL;
+ out:
mutex_unlock(&thread_mutex);
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 15/40] Fix tracing sample code warning.
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 14/40] tracing/samples: Fix creation and deletion of simple_thread_fn creation Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 16/40] PM / wakeirq: report a wakeup_event on dedicated wekup irq Greg Kroah-Hartman
` (26 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Steven Rostedt, Linus Torvalds
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <torvalds@linux-foundation.org>
commit a0cb2b5c390151837b08e5f7bca4a6ecddbcd39c upstream.
Commit 6575257c60e1 ("tracing/samples: Fix creation and deletion of
simple_thread_fn creation") introduced a new warning due to using a
boolean as a counter.
Just make it "int".
Fixes: 6575257c60e1 ("tracing/samples: Fix creation and deletion of simple_thread_fn creation")
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
samples/trace_events/trace-events-sample.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/samples/trace_events/trace-events-sample.c
+++ b/samples/trace_events/trace-events-sample.c
@@ -78,7 +78,7 @@ static int simple_thread_fn(void *arg)
}
static DEFINE_MUTEX(thread_mutex);
-static bool simple_thread_cnt;
+static int simple_thread_cnt;
void foo_bar_reg(void)
{
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 16/40] PM / wakeirq: report a wakeup_event on dedicated wekup irq
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 15/40] Fix tracing sample code warning Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 17/40] mmc: s3cmci: include linux/interrupt.h for tasklet_struct Greg Kroah-Hartman
` (25 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Grygorii Strashko, Keerthy,
Tony Lindgren, Rafael J. Wysocki, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Grygorii Strashko <grygorii.strashko@ti.com>
[ Upstream commit 09bb6e93956ae5175b96905b723ec879c3ca0765 ]
There are two reasons for reporting wakeup event when dedicated wakeup
IRQ is triggered:
- wakeup events accounting, so proper statistical data will be
displayed in sysfs and debugfs;
- there are small window when System is entering suspend during which
dedicated wakeup IRQ can be lost:
dpm_suspend_noirq()
|- device_wakeup_arm_wake_irqs()
|- dev_pm_arm_wake_irq(X)
|- IRQ is enabled and marked as wakeup source
[1]...
|- suspend_device_irqs()
|- suspend_device_irq(X)
|- irqd_set(X, IRQD_WAKEUP_ARMED);
|- wakup IRQ armed
The wakeup IRQ can be lost if it's triggered at point [1]
and not armed yet.
Hence, fix above cases by adding simple pm_wakeup_event() call in
handle_threaded_wake_irq().
Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
[ tony@atomide.com: added missing return to avoid warnings ]
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/power/wakeirq.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/base/power/wakeirq.c
+++ b/drivers/base/power/wakeirq.c
@@ -141,6 +141,13 @@ static irqreturn_t handle_threaded_wake_
struct wake_irq *wirq = _wirq;
int res;
+ /* Maybe abort suspend? */
+ if (irqd_is_wakeup_set(irq_get_irq_data(irq))) {
+ pm_wakeup_event(wirq->dev, 0);
+
+ return IRQ_HANDLED;
+ }
+
/* We don't want RPM_ASYNC or RPM_NOWAIT here */
res = pm_runtime_resume(wirq->dev);
if (res < 0)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 17/40] mmc: s3cmci: include linux/interrupt.h for tasklet_struct
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 16/40] PM / wakeirq: report a wakeup_event on dedicated wekup irq Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
` (24 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Ulf Hansson, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit e1c6ec26b853e9062f0b3daaf695c546d0702953 ]
I got this new build error on today's linux-next
drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]
While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/s3cmci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -21,6 +21,7 @@
#include <linux/debugfs.h>
#include <linux/seq_file.h>
#include <linux/gpio.h>
+#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/io.h>
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 18/40] ARM: pxa: Dont rely on public mmc header to include leds.h
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
` (40 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Mack, Haojian Zhuang,
Robert Jarzmik, linux-arm-kernel, Ulf Hansson, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <ulf.hansson@linaro.org>
[ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ]
Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-pxa/balloon3.c | 1 +
arch/arm/mach-pxa/colibri-pxa270-income.c | 1 +
arch/arm/mach-pxa/corgi.c | 1 +
arch/arm/mach-pxa/trizeps4.c | 1 +
arch/arm/mach-pxa/vpac270.c | 1 +
arch/arm/mach-pxa/zeus.c | 1 +
arch/arm/mach-pxa/zylonite.c | 1 +
7 files changed, 7 insertions(+)
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/sched.h>
#include <linux/bitops.h>
#include <linux/fb.h>
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -17,6 +17,7 @@
#include <linux/gpio.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -18,6 +18,7 @@
#include <linux/major.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/mmc/host.h>
#include <linux/mtd/physmap.h>
#include <linux/pm.h>
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/export.h>
#include <linux/sched.h>
#include <linux/bitops.h>
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -15,6 +15,7 @@
#include <linux/irq.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
+#include <linux/leds.h>
#include <linux/gpio.h>
#include <linux/usb/gpio_vbus.h>
#include <linux/mtd/mtd.h>
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -13,6 +13,7 @@
#include <linux/cpufreq.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/irq.h>
#include <linux/pm.h>
#include <linux/gpio.h>
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 18/40] ARM: pxa: Dont rely on public mmc header to include leds.h
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-arm-kernel
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ulf Hansson <ulf.hansson@linaro.org>
[ Upstream commit 40d727a2defa176b78159d445bcf7afcc2ed9021 ]
Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/mach-pxa/balloon3.c | 1 +
arch/arm/mach-pxa/colibri-pxa270-income.c | 1 +
arch/arm/mach-pxa/corgi.c | 1 +
arch/arm/mach-pxa/trizeps4.c | 1 +
arch/arm/mach-pxa/vpac270.c | 1 +
arch/arm/mach-pxa/zeus.c | 1 +
arch/arm/mach-pxa/zylonite.c | 1 +
7 files changed, 7 insertions(+)
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/sched.h>
#include <linux/bitops.h>
#include <linux/fb.h>
--- a/arch/arm/mach-pxa/colibri-pxa270-income.c
+++ b/arch/arm/mach-pxa/colibri-pxa270-income.c
@@ -17,6 +17,7 @@
#include <linux/gpio.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/platform_device.h>
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -18,6 +18,7 @@
#include <linux/major.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/mmc/host.h>
#include <linux/mtd/physmap.h>
#include <linux/pm.h>
--- a/arch/arm/mach-pxa/trizeps4.c
+++ b/arch/arm/mach-pxa/trizeps4.c
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/export.h>
#include <linux/sched.h>
#include <linux/bitops.h>
--- a/arch/arm/mach-pxa/vpac270.c
+++ b/arch/arm/mach-pxa/vpac270.c
@@ -15,6 +15,7 @@
#include <linux/irq.h>
#include <linux/gpio_keys.h>
#include <linux/input.h>
+#include <linux/leds.h>
#include <linux/gpio.h>
#include <linux/usb/gpio_vbus.h>
#include <linux/mtd/mtd.h>
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -13,6 +13,7 @@
#include <linux/cpufreq.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/irq.h>
#include <linux/pm.h>
#include <linux/gpio.h>
--- a/arch/arm/mach-pxa/zylonite.c
+++ b/arch/arm/mach-pxa/zylonite.c
@@ -16,6 +16,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/interrupt.h>
+#include <linux/leds.h>
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 19/40] mfd: ab8500-sysctrl: Handle probe deferral
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-11-06 9:44 ` Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 20/40] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped Greg Kroah-Hartman
` (22 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Linus Walleij, Lee Jones, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Walleij <linus.walleij@linaro.org>
[ Upstream commit 7e9c40c63933a643908d686bd89dfc2315e8c70a ]
In the current boot, clients making use of the AB8500 sysctrl
may be probed before the ab8500-sysctrl driver. This gives them
-EINVAL, but should rather give -EPROBE_DEFER.
Before this, the abx500 clock driver didn't probe properly,
and as a result the codec driver in turn using the clocks did
not probe properly. After this patch, everything probes
properly.
Also add OF compatible-string probing. This driver is all
device tree, so let's just make a drive-by-fix of that as
well.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mfd/ab8500-sysctrl.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -99,7 +99,7 @@ int ab8500_sysctrl_read(u16 reg, u8 *val
u8 bank;
if (sysctrl_dev == NULL)
- return -EINVAL;
+ return -EPROBE_DEFER;
bank = (reg >> 8);
if (!valid_bank(bank))
@@ -115,11 +115,13 @@ int ab8500_sysctrl_write(u16 reg, u8 mas
u8 bank;
if (sysctrl_dev == NULL)
- return -EINVAL;
+ return -EPROBE_DEFER;
bank = (reg >> 8);
- if (!valid_bank(bank))
+ if (!valid_bank(bank)) {
+ pr_err("invalid bank\n");
return -EINVAL;
+ }
return abx500_mask_and_set_register_interruptible(sysctrl_dev, bank,
(u8)(reg & 0xFF), mask, value);
@@ -180,9 +182,15 @@ static int ab8500_sysctrl_remove(struct
return 0;
}
+static const struct of_device_id ab8500_sysctrl_match[] = {
+ { .compatible = "stericsson,ab8500-sysctrl", },
+ {}
+};
+
static struct platform_driver ab8500_sysctrl_driver = {
.driver = {
.name = "ab8500-sysctrl",
+ .of_match_table = ab8500_sysctrl_match,
},
.probe = ab8500_sysctrl_probe,
.remove = ab8500_sysctrl_remove,
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 20/40] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 19/40] mfd: ab8500-sysctrl: Handle probe deferral Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 21/40] staging: rtl8712u: Fix endian settings for structs describing network packets Greg Kroah-Hartman
` (21 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hans de Goede, Chen-Yu Tsai,
Lee Jones, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ]
The R in PEK_DBR stands for rising, so it should be mapped to
AXP288_IRQ_POKP where the last P stands for positive edge.
Likewise PEK_DBF should be mapped to the falling edge, aka the
_N_egative edge, so it should be mapped to AXP288_IRQ_POKN.
This fixes the inverted powerbutton status reporting by the
axp20x-pek driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mfd/axp20x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -164,14 +164,14 @@ static struct resource axp22x_pek_resour
static struct resource axp288_power_button_resources[] = {
{
.name = "PEK_DBR",
- .start = AXP288_IRQ_POKN,
- .end = AXP288_IRQ_POKN,
+ .start = AXP288_IRQ_POKP,
+ .end = AXP288_IRQ_POKP,
.flags = IORESOURCE_IRQ,
},
{
.name = "PEK_DBF",
- .start = AXP288_IRQ_POKP,
- .end = AXP288_IRQ_POKP,
+ .start = AXP288_IRQ_POKN,
+ .end = AXP288_IRQ_POKN,
.flags = IORESOURCE_IRQ,
},
};
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 21/40] staging: rtl8712u: Fix endian settings for structs describing network packets
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 20/40] mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 22/40] ext4: fix stripe-unaligned allocations Greg Kroah-Hartman
` (20 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Larry Finger, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
[ Upstream commit 221c46d28957bd6e2158abc2179ce4a8c9ce07d3 ]
The headers describing a number of network packets do not have the
correct endian settings for several types of data.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8712/ieee80211.h | 84 ++++++++++++++++++------------------
1 file changed, 42 insertions(+), 42 deletions(-)
--- a/drivers/staging/rtl8712/ieee80211.h
+++ b/drivers/staging/rtl8712/ieee80211.h
@@ -143,52 +143,52 @@ struct ieee_ibss_seq {
};
struct ieee80211_hdr {
- u16 frame_ctl;
- u16 duration_id;
+ __le16 frame_ctl;
+ __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
- u16 seq_ctl;
+ __le16 seq_ctl;
u8 addr4[ETH_ALEN];
-} __packed;
+} __packed __aligned(2);
struct ieee80211_hdr_3addr {
- u16 frame_ctl;
- u16 duration_id;
+ __le16 frame_ctl;
+ __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
- u16 seq_ctl;
-} __packed;
+ __le16 seq_ctl;
+} __packed __aligned(2);
struct ieee80211_hdr_qos {
- u16 frame_ctl;
- u16 duration_id;
+ __le16 frame_ctl;
+ __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
- u16 seq_ctl;
+ __le16 seq_ctl;
u8 addr4[ETH_ALEN];
- u16 qc;
-} __packed;
+ __le16 qc;
+} __packed __aligned(2);
struct ieee80211_hdr_3addr_qos {
- u16 frame_ctl;
- u16 duration_id;
+ __le16 frame_ctl;
+ __le16 duration_id;
u8 addr1[ETH_ALEN];
u8 addr2[ETH_ALEN];
u8 addr3[ETH_ALEN];
- u16 seq_ctl;
- u16 qc;
+ __le16 seq_ctl;
+ __le16 qc;
} __packed;
struct eapol {
u8 snap[6];
- u16 ethertype;
+ __be16 ethertype;
u8 version;
u8 type;
- u16 length;
+ __le16 length;
} __packed;
@@ -528,13 +528,13 @@ struct ieee80211_security {
*/
struct ieee80211_header_data {
- u16 frame_ctl;
- u16 duration_id;
+ __le16 frame_ctl;
+ __le16 duration_id;
u8 addr1[6];
u8 addr2[6];
u8 addr3[6];
- u16 seq_ctrl;
-};
+ __le16 seq_ctrl;
+} __packed __aligned(2);
#define BEACON_PROBE_SSID_ID_POSITION 12
@@ -566,18 +566,18 @@ struct ieee80211_info_element {
/*
* These are the data types that can make up management packets
*
- u16 auth_algorithm;
- u16 auth_sequence;
- u16 beacon_interval;
- u16 capability;
+ __le16 auth_algorithm;
+ __le16 auth_sequence;
+ __le16 beacon_interval;
+ __le16 capability;
u8 current_ap[ETH_ALEN];
- u16 listen_interval;
+ __le16 listen_interval;
struct {
u16 association_id:14, reserved:2;
} __packed;
- u32 time_stamp[2];
- u16 reason;
- u16 status;
+ __le32 time_stamp[2];
+ __le16 reason;
+ __le16 status;
*/
#define IEEE80211_DEFAULT_TX_ESSID "Penguin"
@@ -585,16 +585,16 @@ struct ieee80211_info_element {
struct ieee80211_authentication {
struct ieee80211_header_data header;
- u16 algorithm;
- u16 transaction;
- u16 status;
+ __le16 algorithm;
+ __le16 transaction;
+ __le16 status;
} __packed;
struct ieee80211_probe_response {
struct ieee80211_header_data header;
- u32 time_stamp[2];
- u16 beacon_interval;
- u16 capability;
+ __le32 time_stamp[2];
+ __le16 beacon_interval;
+ __le16 capability;
struct ieee80211_info_element info_element;
} __packed;
@@ -604,16 +604,16 @@ struct ieee80211_probe_request {
struct ieee80211_assoc_request_frame {
struct ieee80211_hdr_3addr header;
- u16 capability;
- u16 listen_interval;
+ __le16 capability;
+ __le16 listen_interval;
struct ieee80211_info_element_hdr info_element;
} __packed;
struct ieee80211_assoc_response_frame {
struct ieee80211_hdr_3addr header;
- u16 capability;
- u16 status;
- u16 aid;
+ __le16 capability;
+ __le16 status;
+ __le16 aid;
} __packed;
struct ieee80211_txb {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 22/40] ext4: fix stripe-unaligned allocations
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 21/40] staging: rtl8712u: Fix endian settings for structs describing network packets Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 23/40] ext4: do not use stripe_width if it is not set Greg Kroah-Hartman
` (19 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ross Zwisler, Jan Kara, Theodore Tso,
Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
[ Upstream commit d9b22cf9f5466a057f2a4f1e642b469fa9d73117 ]
When a filesystem is created using:
mkfs.ext4 -b 4096 -E stride=512 <dev>
and we try to allocate 64MB extent, we will end up directly in
ext4_mb_complex_scan_group(). This is because the request is detected
as power-of-two allocation (so we start in ext4_mb_regular_allocator()
with ac_criteria == 0) however the check before
ext4_mb_simple_scan_group() refuses the direct buddy scan because the
allocation request is too large. Since cr == 0, the check whether we
should use ext4_mb_scan_aligned() fails as well and we fall back to
ext4_mb_complex_scan_group().
Fix the problem by checking for upper limit on power-of-two requests
directly when detecting them.
Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/mballoc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -2136,8 +2136,10 @@ ext4_mb_regular_allocator(struct ext4_al
* We search using buddy data only if the order of the request
* is greater than equal to the sbi_s_mb_order2_reqs
* You can tune it via /sys/fs/ext4/<partition>/mb_order2_req
+ * We also support searching for power-of-two requests only for
+ * requests upto maximum buddy size we have constructed.
*/
- if (i >= sbi->s_mb_order2_reqs) {
+ if (i >= sbi->s_mb_order2_reqs && i <= sb->s_blocksize_bits + 2) {
/*
* This should tell if fe_len is exactly power of 2
*/
@@ -2207,7 +2209,7 @@ repeat:
}
ac->ac_groups_scanned++;
- if (cr == 0 && ac->ac_2order < sb->s_blocksize_bits+2)
+ if (cr == 0)
ext4_mb_simple_scan_group(ac, &e4b);
else if (cr == 1 && sbi->s_stripe &&
!(ac->ac_g_ex.fe_len % sbi->s_stripe))
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 23/40] ext4: do not use stripe_width if it is not set
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 22/40] ext4: fix stripe-unaligned allocations Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:44 ` [PATCH 4.4 24/40] i2c: riic: correctly finish transfers Greg Kroah-Hartman
` (18 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Kara, Theodore Tso, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
[ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ]
Avoid using stripe_width for sbi->s_stripe value if it is not actually
set. It prevents using the stride for sbi->s_stripe.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/ext4/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2499,9 +2499,9 @@ static unsigned long ext4_get_stripe_siz
if (sbi->s_stripe && sbi->s_stripe <= sbi->s_blocks_per_group)
ret = sbi->s_stripe;
- else if (stripe_width <= sbi->s_blocks_per_group)
+ else if (stripe_width && stripe_width <= sbi->s_blocks_per_group)
ret = stripe_width;
- else if (stride <= sbi->s_blocks_per_group)
+ else if (stride && stride <= sbi->s_blocks_per_group)
ret = stride;
else
ret = 0;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 24/40] i2c: riic: correctly finish transfers
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 23/40] ext4: do not use stripe_width if it is not set Greg Kroah-Hartman
@ 2017-11-06 9:44 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 26/40] perf tools: Only increase index if perf_evsel__new_idx() succeeds Greg Kroah-Hartman
` (17 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Brandt, Wolfram Sang,
Wolfram Sang, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Brandt <chris.brandt@renesas.com>
[ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ]
This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.
At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.
Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.
This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.
Fixes: 310c18a41450 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/i2c/busses/i2c-riic.c | 30 +++++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
--- a/drivers/i2c/busses/i2c-riic.c
+++ b/drivers/i2c/busses/i2c-riic.c
@@ -80,6 +80,7 @@
#define ICIER_TEIE 0x40
#define ICIER_RIE 0x20
#define ICIER_NAKIE 0x10
+#define ICIER_SPIE 0x08
#define ICSR2_NACKF 0x10
@@ -216,11 +217,10 @@ static irqreturn_t riic_tend_isr(int irq
return IRQ_NONE;
}
- if (riic->is_last || riic->err)
+ if (riic->is_last || riic->err) {
+ riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
-
- writeb(0, riic->base + RIIC_ICIER);
- complete(&riic->msg_done);
+ }
return IRQ_HANDLED;
}
@@ -240,13 +240,13 @@ static irqreturn_t riic_rdrf_isr(int irq
if (riic->bytes_left == 1) {
/* STOP must come before we set ACKBT! */
- if (riic->is_last)
+ if (riic->is_last) {
+ riic_clear_set_bit(riic, 0, ICIER_SPIE, RIIC_ICIER);
writeb(ICCR2_SP, riic->base + RIIC_ICCR2);
+ }
riic_clear_set_bit(riic, 0, ICMR3_ACKBT, RIIC_ICMR3);
- writeb(0, riic->base + RIIC_ICIER);
- complete(&riic->msg_done);
} else {
riic_clear_set_bit(riic, ICMR3_ACKBT, 0, RIIC_ICMR3);
}
@@ -259,6 +259,21 @@ static irqreturn_t riic_rdrf_isr(int irq
return IRQ_HANDLED;
}
+static irqreturn_t riic_stop_isr(int irq, void *data)
+{
+ struct riic_dev *riic = data;
+
+ /* read back registers to confirm writes have fully propagated */
+ writeb(0, riic->base + RIIC_ICSR2);
+ readb(riic->base + RIIC_ICSR2);
+ writeb(0, riic->base + RIIC_ICIER);
+ readb(riic->base + RIIC_ICIER);
+
+ complete(&riic->msg_done);
+
+ return IRQ_HANDLED;
+}
+
static u32 riic_func(struct i2c_adapter *adap)
{
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
@@ -326,6 +341,7 @@ static struct riic_irq_desc riic_irqs[]
{ .res_num = 0, .isr = riic_tend_isr, .name = "riic-tend" },
{ .res_num = 1, .isr = riic_rdrf_isr, .name = "riic-rdrf" },
{ .res_num = 2, .isr = riic_tdre_isr, .name = "riic-tdre" },
+ { .res_num = 3, .isr = riic_stop_isr, .name = "riic-stop" },
{ .res_num = 5, .isr = riic_tend_isr, .name = "riic-nack" },
};
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 26/40] perf tools: Only increase index if perf_evsel__new_idx() succeeds
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-11-06 9:44 ` [PATCH 4.4 24/40] i2c: riic: correctly finish transfers Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 27/40] cx231xx: Fix I2C on Internal Master 3 Bus Greg Kroah-Hartman
` (16 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Taeung Song, Jiri Olsa, Namhyung Kim,
Peter Zijlstra, Wang Nan, Arnaldo Carvalho de Melo, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Taeung Song <treeze.taeung@gmail.com>
[ Upstream commit 75fc5ae5cc53fff71041ecadeb3354a2b4c9fe42 ]
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/parse-events.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -291,10 +291,11 @@ __add_event(struct list_head *list, int
event_attr_init(attr);
- evsel = perf_evsel__new_idx(attr, (*idx)++);
+ evsel = perf_evsel__new_idx(attr, *idx);
if (!evsel)
return NULL;
+ (*idx)++;
evsel->cpus = cpu_map__get(cpus);
evsel->own_cpus = cpu_map__get(cpus);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 27/40] cx231xx: Fix I2C on Internal Master 3 Bus
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 26/40] perf tools: Only increase index if perf_evsel__new_idx() succeeds Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge Greg Kroah-Hartman
` (15 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Oleh Kravchenko,
Mauro Carvalho Chehab, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleh Kravchenko <oleg@kaa.org.ua>
[ Upstream commit 6c5da8031a3abfad259190d35f83d89568b72ee2 ]
Internal Master 3 Bus can send and receive only 4 bytes per time.
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/usb/cx231xx/cx231xx-core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/media/usb/cx231xx/cx231xx-core.c
+++ b/drivers/media/usb/cx231xx/cx231xx-core.c
@@ -356,7 +356,12 @@ int cx231xx_send_vendor_cmd(struct cx231
*/
if ((ven_req->wLength > 4) && ((ven_req->bRequest == 0x4) ||
(ven_req->bRequest == 0x5) ||
- (ven_req->bRequest == 0x6))) {
+ (ven_req->bRequest == 0x6) ||
+
+ /* Internal Master 3 Bus can send
+ * and receive only 4 bytes per time
+ */
+ (ven_req->bRequest == 0x2))) {
unsend_size = 0;
pdata = ven_req->pBuff;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 27/40] cx231xx: Fix I2C on Internal Master 3 Bus Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-07 4:32 ` Archit Taneja
2017-11-06 9:45 ` [PATCH 4.4 29/40] xen/manage: correct return value check on xenbus_scanf() Greg Kroah-Hartman
` (14 subsequent siblings)
41 siblings, 1 reply; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Laurent Pinchart, Laurent Pinchart,
Archit Taneja, Rob Clark, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Archit Taneja <architt@codeaurora.org>
[ Upstream commit 0bb70b82c2f91e4667f3c617505235efd6d77e46 ]
The commit "drm: bridge: Link encoder and bridge in core code" updated
the drm_bridge_attach() API to also include the drm_encoder pointer
the bridge attaches to.
The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
pointer stored in msm_dsi->encoders to pass the encoder to the bridge
API.
msm_dsi->encoders is unfortunately set after this function is called,
resulting in us passing a NULL pointer to drm_brigde_attach. This
results in an error and the DSI driver probe fails.
Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
try to set the encoder's bridge. That's now managed by the bridge
API.
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/msm/dsi/dsi.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi
goto fail;
}
+ for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
+ msm_dsi->encoders[i] = encoders[i];
+
msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
if (IS_ERR(msm_dsi->bridge)) {
ret = PTR_ERR(msm_dsi->bridge);
@@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi
goto fail;
}
- for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
- encoders[i]->bridge = msm_dsi->bridge;
- msm_dsi->encoders[i] = encoders[i];
- }
-
/*
* check if the dsi encoder output is connected to a panel or an
* external bridge. We create a connector only if we're connected to a
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge
2017-11-06 9:45 ` [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge Greg Kroah-Hartman
@ 2017-11-07 4:32 ` Archit Taneja
2017-11-07 10:35 ` Greg Kroah-Hartman
0 siblings, 1 reply; 62+ messages in thread
From: Archit Taneja @ 2017-11-07 4:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Laurent Pinchart, Laurent Pinchart, Rob Clark, Sasha Levin
Hi Greg,
On 11/06/2017 03:15 PM, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
This patch isn't needed on 4.4 or the 4.9 stable branches. This was required
only after drm_bridge API was changed with the commit:
(3bb80f2495) drm: bridge: Link encoder and bridge in core code
This was merged only in 4.11.
Thanks,
Archit
>
> ------------------
>
> From: Archit Taneja <architt@codeaurora.org>
>
>
> [ Upstream commit 0bb70b82c2f91e4667f3c617505235efd6d77e46 ]
>
> The commit "drm: bridge: Link encoder and bridge in core code" updated
> the drm_bridge_attach() API to also include the drm_encoder pointer
> the bridge attaches to.
>
> The func msm_dsi_manager_bridge_init() now relies on the drm_encoder
> pointer stored in msm_dsi->encoders to pass the encoder to the bridge
> API.
>
> msm_dsi->encoders is unfortunately set after this function is called,
> resulting in us passing a NULL pointer to drm_brigde_attach. This
> results in an error and the DSI driver probe fails.
>
> Move the initialization of msm_dsi->encoders[] a bit up. Also, don't
> try to set the encoder's bridge. That's now managed by the bridge
> API.
>
> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/gpu/drm/msm/dsi/dsi.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> --- a/drivers/gpu/drm/msm/dsi/dsi.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi.c
> @@ -205,6 +205,9 @@ int msm_dsi_modeset_init(struct msm_dsi
> goto fail;
> }
>
> + for (i = 0; i < MSM_DSI_ENCODER_NUM; i++)
> + msm_dsi->encoders[i] = encoders[i];
> +
> msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
> if (IS_ERR(msm_dsi->bridge)) {
> ret = PTR_ERR(msm_dsi->bridge);
> @@ -213,11 +216,6 @@ int msm_dsi_modeset_init(struct msm_dsi
> goto fail;
> }
>
> - for (i = 0; i < MSM_DSI_ENCODER_NUM; i++) {
> - encoders[i]->bridge = msm_dsi->bridge;
> - msm_dsi->encoders[i] = encoders[i];
> - }
> -
> /*
> * check if the dsi encoder output is connected to a panel or an
> * external bridge. We create a connector only if we're connected to a
>
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge
2017-11-07 4:32 ` Archit Taneja
@ 2017-11-07 10:35 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-07 10:35 UTC (permalink / raw)
To: Archit Taneja
Cc: linux-kernel, stable, Laurent Pinchart, Laurent Pinchart,
Rob Clark, Sasha Levin
On Tue, Nov 07, 2017 at 10:02:23AM +0530, Archit Taneja wrote:
> Hi Greg,
>
> On 11/06/2017 03:15 PM, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
>
> This patch isn't needed on 4.4 or the 4.9 stable branches. This was required
> only after drm_bridge API was changed with the commit:
>
> (3bb80f2495) drm: bridge: Link encoder and bridge in core code
>
> This was merged only in 4.11.
Great, thanks for the review, they are now dropped from 4.4 and 4.9.
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 29/40] xen/manage: correct return value check on xenbus_scanf()
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 28/40] drm/msm/dsi: Set msm_dsi->encoders before initializing bridge Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` Greg Kroah-Hartman
` (13 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Beulich, Juergen Gross,
Boris Ostrovsky, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Beulich <JBeulich@suse.com>
[ Upstream commit 4fed1b125eb6252bde478665fc05d4819f774fa8 ]
A negative return value indicates an error; in fact the function at
present won't ever return zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/xen/manage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -275,7 +275,7 @@ static void sysrq_handler(struct xenbus_
err = xenbus_transaction_start(&xbt);
if (err)
return;
- if (!xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key)) {
+ if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
pr_err("Unable to read sysrq code in control/sysrq\n");
xenbus_transaction_end(xbt, 1);
return;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 30/40] scsi: aacraid: Process Error for response I/O
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:44 ` Greg Kroah-Hartman
` (40 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Raghava Aditya Renukunta,
Dave Carroll, Johannes Thumshirn, Martin K. Petersen,
Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
[ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ]
Make sure that the driver processes error conditions even in the fast
response path for response from the adapter.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Dave Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 291 +++++++++++++++++++++---------------------
1 file changed, 152 insertions(+), 139 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2977,16 +2977,11 @@ static void aac_srb_callback(void *conte
return;
BUG_ON(fibptr == NULL);
- dev = fibptr->dev;
-
- scsi_dma_unmap(scsicmd);
- /* expose physical device if expose_physicald flag is on */
- if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
- && expose_physicals > 0)
- aac_expose_phy_device(scsicmd);
+ dev = fibptr->dev;
srbreply = (struct aac_srb_reply *) fib_data(fibptr);
+
scsicmd->sense_buffer[0] = '\0'; /* Initialize sense valid flag to false */
if (fibptr->flags & FIB_CONTEXT_FLAG_FASTRESP) {
@@ -2999,158 +2994,176 @@ static void aac_srb_callback(void *conte
*/
scsi_set_resid(scsicmd, scsi_bufflen(scsicmd)
- le32_to_cpu(srbreply->data_xfer_length));
- /*
- * First check the fib status
- */
+ }
- if (le32_to_cpu(srbreply->status) != ST_OK) {
- int len;
- printk(KERN_WARNING "aac_srb_callback: srb failed, status = %d\n", le32_to_cpu(srbreply->status));
- len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
- SCSI_SENSE_BUFFERSIZE);
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8
- | SAM_STAT_CHECK_CONDITION;
- memcpy(scsicmd->sense_buffer,
- srbreply->sense_data, len);
- }
+ scsi_dma_unmap(scsicmd);
- /*
- * Next check the srb status
- */
- switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
- case SRB_STATUS_ERROR_RECOVERY:
- case SRB_STATUS_PENDING:
- case SRB_STATUS_SUCCESS:
- scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
- break;
- case SRB_STATUS_DATA_OVERRUN:
- switch (scsicmd->cmnd[0]) {
- case READ_6:
- case WRITE_6:
- case READ_10:
- case WRITE_10:
- case READ_12:
- case WRITE_12:
- case READ_16:
- case WRITE_16:
- if (le32_to_cpu(srbreply->data_xfer_length)
- < scsicmd->underflow)
- printk(KERN_WARNING"aacraid: SCSI CMD underflow\n");
- else
- printk(KERN_WARNING"aacraid: SCSI CMD Data Overrun\n");
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8;
- break;
- case INQUIRY: {
- scsicmd->result = DID_OK << 16
- | COMMAND_COMPLETE << 8;
- break;
- }
- default:
- scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
- break;
- }
- break;
- case SRB_STATUS_ABORTED:
- scsicmd->result = DID_ABORT << 16 | ABORT << 8;
- break;
- case SRB_STATUS_ABORT_FAILED:
- /*
- * Not sure about this one - but assuming the
- * hba was trying to abort for some reason
- */
- scsicmd->result = DID_ERROR << 16 | ABORT << 8;
- break;
- case SRB_STATUS_PARITY_ERROR:
- scsicmd->result = DID_PARITY << 16
- | MSG_PARITY_ERROR << 8;
- break;
- case SRB_STATUS_NO_DEVICE:
- case SRB_STATUS_INVALID_PATH_ID:
- case SRB_STATUS_INVALID_TARGET_ID:
- case SRB_STATUS_INVALID_LUN:
- case SRB_STATUS_SELECTION_TIMEOUT:
- scsicmd->result = DID_NO_CONNECT << 16
- | COMMAND_COMPLETE << 8;
- break;
+ /* expose physical device if expose_physicald flag is on */
+ if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
+ && expose_physicals > 0)
+ aac_expose_phy_device(scsicmd);
- case SRB_STATUS_COMMAND_TIMEOUT:
- case SRB_STATUS_TIMEOUT:
- scsicmd->result = DID_TIME_OUT << 16
- | COMMAND_COMPLETE << 8;
- break;
+ /*
+ * First check the fib status
+ */
- case SRB_STATUS_BUSY:
- scsicmd->result = DID_BUS_BUSY << 16
- | COMMAND_COMPLETE << 8;
- break;
+ if (le32_to_cpu(srbreply->status) != ST_OK) {
+ int len;
- case SRB_STATUS_BUS_RESET:
- scsicmd->result = DID_RESET << 16
- | COMMAND_COMPLETE << 8;
- break;
+ pr_warn("aac_srb_callback: srb failed, status = %d\n",
+ le32_to_cpu(srbreply->status));
+ len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+ SCSI_SENSE_BUFFERSIZE);
+ scsicmd->result = DID_ERROR << 16
+ | COMMAND_COMPLETE << 8
+ | SAM_STAT_CHECK_CONDITION;
+ memcpy(scsicmd->sense_buffer,
+ srbreply->sense_data, len);
+ }
- case SRB_STATUS_MESSAGE_REJECTED:
+ /*
+ * Next check the srb status
+ */
+ switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
+ case SRB_STATUS_ERROR_RECOVERY:
+ case SRB_STATUS_PENDING:
+ case SRB_STATUS_SUCCESS:
+ scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+ break;
+ case SRB_STATUS_DATA_OVERRUN:
+ switch (scsicmd->cmnd[0]) {
+ case READ_6:
+ case WRITE_6:
+ case READ_10:
+ case WRITE_10:
+ case READ_12:
+ case WRITE_12:
+ case READ_16:
+ case WRITE_16:
+ if (le32_to_cpu(srbreply->data_xfer_length)
+ < scsicmd->underflow)
+ pr_warn("aacraid: SCSI CMD underflow\n");
+ else
+ pr_warn("aacraid: SCSI CMD Data Overrun\n");
scsicmd->result = DID_ERROR << 16
- | MESSAGE_REJECT << 8;
+ | COMMAND_COMPLETE << 8;
+ break;
+ case INQUIRY:
+ scsicmd->result = DID_OK << 16
+ | COMMAND_COMPLETE << 8;
break;
- case SRB_STATUS_REQUEST_FLUSHED:
- case SRB_STATUS_ERROR:
- case SRB_STATUS_INVALID_REQUEST:
- case SRB_STATUS_REQUEST_SENSE_FAILED:
- case SRB_STATUS_NO_HBA:
- case SRB_STATUS_UNEXPECTED_BUS_FREE:
- case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
- case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
- case SRB_STATUS_DELAYED_RETRY:
- case SRB_STATUS_BAD_FUNCTION:
- case SRB_STATUS_NOT_STARTED:
- case SRB_STATUS_NOT_IN_USE:
- case SRB_STATUS_FORCE_ABORT:
- case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
default:
+ scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+ break;
+ }
+ break;
+ case SRB_STATUS_ABORTED:
+ scsicmd->result = DID_ABORT << 16 | ABORT << 8;
+ break;
+ case SRB_STATUS_ABORT_FAILED:
+ /*
+ * Not sure about this one - but assuming the
+ * hba was trying to abort for some reason
+ */
+ scsicmd->result = DID_ERROR << 16 | ABORT << 8;
+ break;
+ case SRB_STATUS_PARITY_ERROR:
+ scsicmd->result = DID_PARITY << 16
+ | MSG_PARITY_ERROR << 8;
+ break;
+ case SRB_STATUS_NO_DEVICE:
+ case SRB_STATUS_INVALID_PATH_ID:
+ case SRB_STATUS_INVALID_TARGET_ID:
+ case SRB_STATUS_INVALID_LUN:
+ case SRB_STATUS_SELECTION_TIMEOUT:
+ scsicmd->result = DID_NO_CONNECT << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_COMMAND_TIMEOUT:
+ case SRB_STATUS_TIMEOUT:
+ scsicmd->result = DID_TIME_OUT << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_BUSY:
+ scsicmd->result = DID_BUS_BUSY << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_BUS_RESET:
+ scsicmd->result = DID_RESET << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_MESSAGE_REJECTED:
+ scsicmd->result = DID_ERROR << 16
+ | MESSAGE_REJECT << 8;
+ break;
+ case SRB_STATUS_REQUEST_FLUSHED:
+ case SRB_STATUS_ERROR:
+ case SRB_STATUS_INVALID_REQUEST:
+ case SRB_STATUS_REQUEST_SENSE_FAILED:
+ case SRB_STATUS_NO_HBA:
+ case SRB_STATUS_UNEXPECTED_BUS_FREE:
+ case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
+ case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
+ case SRB_STATUS_DELAYED_RETRY:
+ case SRB_STATUS_BAD_FUNCTION:
+ case SRB_STATUS_NOT_STARTED:
+ case SRB_STATUS_NOT_IN_USE:
+ case SRB_STATUS_FORCE_ABORT:
+ case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
+ default:
#ifdef AAC_DETAILED_STATUS_INFO
- printk(KERN_INFO "aacraid: SRB ERROR(%u) %s scsi cmd 0x%x - scsi status 0x%x\n",
- le32_to_cpu(srbreply->srb_status) & 0x3F,
- aac_get_status_string(
- le32_to_cpu(srbreply->srb_status) & 0x3F),
- scsicmd->cmnd[0],
- le32_to_cpu(srbreply->scsi_status));
+ pr_info("aacraid: SRB ERROR(%u) %s scsi cmd 0x%x -scsi status 0x%x\n",
+ le32_to_cpu(srbreply->srb_status) & 0x3F,
+ aac_get_status_string(
+ le32_to_cpu(srbreply->srb_status) & 0x3F),
+ scsicmd->cmnd[0],
+ le32_to_cpu(srbreply->scsi_status));
#endif
- if ((scsicmd->cmnd[0] == ATA_12)
- || (scsicmd->cmnd[0] == ATA_16)) {
- if (scsicmd->cmnd[2] & (0x01 << 5)) {
- scsicmd->result = DID_OK << 16
- | COMMAND_COMPLETE << 8;
- break;
- } else {
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8;
- break;
- }
+ /*
+ * When the CC bit is SET by the host in ATA pass thru CDB,
+ * driver is supposed to return DID_OK
+ *
+ * When the CC bit is RESET by the host, driver should
+ * return DID_ERROR
+ */
+ if ((scsicmd->cmnd[0] == ATA_12)
+ || (scsicmd->cmnd[0] == ATA_16)) {
+
+ if (scsicmd->cmnd[2] & (0x01 << 5)) {
+ scsicmd->result = DID_OK << 16
+ | COMMAND_COMPLETE << 8;
+ break;
} else {
scsicmd->result = DID_ERROR << 16
| COMMAND_COMPLETE << 8;
- break;
+ break;
}
+ } else {
+ scsicmd->result = DID_ERROR << 16
+ | COMMAND_COMPLETE << 8;
+ break;
}
- if (le32_to_cpu(srbreply->scsi_status)
- == SAM_STAT_CHECK_CONDITION) {
- int len;
-
- scsicmd->result |= SAM_STAT_CHECK_CONDITION;
- len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
- SCSI_SENSE_BUFFERSIZE);
+ }
+ if (le32_to_cpu(srbreply->scsi_status)
+ == SAM_STAT_CHECK_CONDITION) {
+ int len;
+
+ scsicmd->result |= SAM_STAT_CHECK_CONDITION;
+ len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+ SCSI_SENSE_BUFFERSIZE);
#ifdef AAC_DETAILED_STATUS_INFO
- printk(KERN_WARNING "aac_srb_callback: check condition, status = %d len=%d\n",
- le32_to_cpu(srbreply->status), len);
+ pr_warn("aac_srb_callback: check condition, status = %d len=%d\n",
+ le32_to_cpu(srbreply->status), len);
#endif
- memcpy(scsicmd->sense_buffer,
- srbreply->sense_data, len);
- }
+ memcpy(scsicmd->sense_buffer,
+ srbreply->sense_data, len);
}
+
/*
* OR in the scsi status (already shifted up a bit)
*/
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 30/40] scsi: aacraid: Process Error for response I/O
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Raghava Aditya Renukunta,
Dave Carroll, Johannes Thumshirn, Martin K. Petersen,
Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
[ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ]
Make sure that the driver processes error conditions even in the fast
response path for response from the adapter.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Dave Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/aacraid/aachba.c | 291 +++++++++++++++++++++---------------------
1 file changed, 152 insertions(+), 139 deletions(-)
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2977,16 +2977,11 @@ static void aac_srb_callback(void *conte
return;
BUG_ON(fibptr == NULL);
- dev = fibptr->dev;
-
- scsi_dma_unmap(scsicmd);
- /* expose physical device if expose_physicald flag is on */
- if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
- && expose_physicals > 0)
- aac_expose_phy_device(scsicmd);
+ dev = fibptr->dev;
srbreply = (struct aac_srb_reply *) fib_data(fibptr);
+
scsicmd->sense_buffer[0] = '\0'; /* Initialize sense valid flag to false */
if (fibptr->flags & FIB_CONTEXT_FLAG_FASTRESP) {
@@ -2999,158 +2994,176 @@ static void aac_srb_callback(void *conte
*/
scsi_set_resid(scsicmd, scsi_bufflen(scsicmd)
- le32_to_cpu(srbreply->data_xfer_length));
- /*
- * First check the fib status
- */
+ }
- if (le32_to_cpu(srbreply->status) != ST_OK) {
- int len;
- printk(KERN_WARNING "aac_srb_callback: srb failed, status = %d\n", le32_to_cpu(srbreply->status));
- len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
- SCSI_SENSE_BUFFERSIZE);
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8
- | SAM_STAT_CHECK_CONDITION;
- memcpy(scsicmd->sense_buffer,
- srbreply->sense_data, len);
- }
+ scsi_dma_unmap(scsicmd);
- /*
- * Next check the srb status
- */
- switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
- case SRB_STATUS_ERROR_RECOVERY:
- case SRB_STATUS_PENDING:
- case SRB_STATUS_SUCCESS:
- scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
- break;
- case SRB_STATUS_DATA_OVERRUN:
- switch (scsicmd->cmnd[0]) {
- case READ_6:
- case WRITE_6:
- case READ_10:
- case WRITE_10:
- case READ_12:
- case WRITE_12:
- case READ_16:
- case WRITE_16:
- if (le32_to_cpu(srbreply->data_xfer_length)
- < scsicmd->underflow)
- printk(KERN_WARNING"aacraid: SCSI CMD underflow\n");
- else
- printk(KERN_WARNING"aacraid: SCSI CMD Data Overrun\n");
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8;
- break;
- case INQUIRY: {
- scsicmd->result = DID_OK << 16
- | COMMAND_COMPLETE << 8;
- break;
- }
- default:
- scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
- break;
- }
- break;
- case SRB_STATUS_ABORTED:
- scsicmd->result = DID_ABORT << 16 | ABORT << 8;
- break;
- case SRB_STATUS_ABORT_FAILED:
- /*
- * Not sure about this one - but assuming the
- * hba was trying to abort for some reason
- */
- scsicmd->result = DID_ERROR << 16 | ABORT << 8;
- break;
- case SRB_STATUS_PARITY_ERROR:
- scsicmd->result = DID_PARITY << 16
- | MSG_PARITY_ERROR << 8;
- break;
- case SRB_STATUS_NO_DEVICE:
- case SRB_STATUS_INVALID_PATH_ID:
- case SRB_STATUS_INVALID_TARGET_ID:
- case SRB_STATUS_INVALID_LUN:
- case SRB_STATUS_SELECTION_TIMEOUT:
- scsicmd->result = DID_NO_CONNECT << 16
- | COMMAND_COMPLETE << 8;
- break;
+ /* expose physical device if expose_physicald flag is on */
+ if (scsicmd->cmnd[0] == INQUIRY && !(scsicmd->cmnd[1] & 0x01)
+ && expose_physicals > 0)
+ aac_expose_phy_device(scsicmd);
- case SRB_STATUS_COMMAND_TIMEOUT:
- case SRB_STATUS_TIMEOUT:
- scsicmd->result = DID_TIME_OUT << 16
- | COMMAND_COMPLETE << 8;
- break;
+ /*
+ * First check the fib status
+ */
- case SRB_STATUS_BUSY:
- scsicmd->result = DID_BUS_BUSY << 16
- | COMMAND_COMPLETE << 8;
- break;
+ if (le32_to_cpu(srbreply->status) != ST_OK) {
+ int len;
- case SRB_STATUS_BUS_RESET:
- scsicmd->result = DID_RESET << 16
- | COMMAND_COMPLETE << 8;
- break;
+ pr_warn("aac_srb_callback: srb failed, status = %d\n",
+ le32_to_cpu(srbreply->status));
+ len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+ SCSI_SENSE_BUFFERSIZE);
+ scsicmd->result = DID_ERROR << 16
+ | COMMAND_COMPLETE << 8
+ | SAM_STAT_CHECK_CONDITION;
+ memcpy(scsicmd->sense_buffer,
+ srbreply->sense_data, len);
+ }
- case SRB_STATUS_MESSAGE_REJECTED:
+ /*
+ * Next check the srb status
+ */
+ switch ((le32_to_cpu(srbreply->srb_status))&0x3f) {
+ case SRB_STATUS_ERROR_RECOVERY:
+ case SRB_STATUS_PENDING:
+ case SRB_STATUS_SUCCESS:
+ scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+ break;
+ case SRB_STATUS_DATA_OVERRUN:
+ switch (scsicmd->cmnd[0]) {
+ case READ_6:
+ case WRITE_6:
+ case READ_10:
+ case WRITE_10:
+ case READ_12:
+ case WRITE_12:
+ case READ_16:
+ case WRITE_16:
+ if (le32_to_cpu(srbreply->data_xfer_length)
+ < scsicmd->underflow)
+ pr_warn("aacraid: SCSI CMD underflow\n");
+ else
+ pr_warn("aacraid: SCSI CMD Data Overrun\n");
scsicmd->result = DID_ERROR << 16
- | MESSAGE_REJECT << 8;
+ | COMMAND_COMPLETE << 8;
+ break;
+ case INQUIRY:
+ scsicmd->result = DID_OK << 16
+ | COMMAND_COMPLETE << 8;
break;
- case SRB_STATUS_REQUEST_FLUSHED:
- case SRB_STATUS_ERROR:
- case SRB_STATUS_INVALID_REQUEST:
- case SRB_STATUS_REQUEST_SENSE_FAILED:
- case SRB_STATUS_NO_HBA:
- case SRB_STATUS_UNEXPECTED_BUS_FREE:
- case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
- case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
- case SRB_STATUS_DELAYED_RETRY:
- case SRB_STATUS_BAD_FUNCTION:
- case SRB_STATUS_NOT_STARTED:
- case SRB_STATUS_NOT_IN_USE:
- case SRB_STATUS_FORCE_ABORT:
- case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
default:
+ scsicmd->result = DID_OK << 16 | COMMAND_COMPLETE << 8;
+ break;
+ }
+ break;
+ case SRB_STATUS_ABORTED:
+ scsicmd->result = DID_ABORT << 16 | ABORT << 8;
+ break;
+ case SRB_STATUS_ABORT_FAILED:
+ /*
+ * Not sure about this one - but assuming the
+ * hba was trying to abort for some reason
+ */
+ scsicmd->result = DID_ERROR << 16 | ABORT << 8;
+ break;
+ case SRB_STATUS_PARITY_ERROR:
+ scsicmd->result = DID_PARITY << 16
+ | MSG_PARITY_ERROR << 8;
+ break;
+ case SRB_STATUS_NO_DEVICE:
+ case SRB_STATUS_INVALID_PATH_ID:
+ case SRB_STATUS_INVALID_TARGET_ID:
+ case SRB_STATUS_INVALID_LUN:
+ case SRB_STATUS_SELECTION_TIMEOUT:
+ scsicmd->result = DID_NO_CONNECT << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_COMMAND_TIMEOUT:
+ case SRB_STATUS_TIMEOUT:
+ scsicmd->result = DID_TIME_OUT << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_BUSY:
+ scsicmd->result = DID_BUS_BUSY << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_BUS_RESET:
+ scsicmd->result = DID_RESET << 16
+ | COMMAND_COMPLETE << 8;
+ break;
+
+ case SRB_STATUS_MESSAGE_REJECTED:
+ scsicmd->result = DID_ERROR << 16
+ | MESSAGE_REJECT << 8;
+ break;
+ case SRB_STATUS_REQUEST_FLUSHED:
+ case SRB_STATUS_ERROR:
+ case SRB_STATUS_INVALID_REQUEST:
+ case SRB_STATUS_REQUEST_SENSE_FAILED:
+ case SRB_STATUS_NO_HBA:
+ case SRB_STATUS_UNEXPECTED_BUS_FREE:
+ case SRB_STATUS_PHASE_SEQUENCE_FAILURE:
+ case SRB_STATUS_BAD_SRB_BLOCK_LENGTH:
+ case SRB_STATUS_DELAYED_RETRY:
+ case SRB_STATUS_BAD_FUNCTION:
+ case SRB_STATUS_NOT_STARTED:
+ case SRB_STATUS_NOT_IN_USE:
+ case SRB_STATUS_FORCE_ABORT:
+ case SRB_STATUS_DOMAIN_VALIDATION_FAIL:
+ default:
#ifdef AAC_DETAILED_STATUS_INFO
- printk(KERN_INFO "aacraid: SRB ERROR(%u) %s scsi cmd 0x%x - scsi status 0x%x\n",
- le32_to_cpu(srbreply->srb_status) & 0x3F,
- aac_get_status_string(
- le32_to_cpu(srbreply->srb_status) & 0x3F),
- scsicmd->cmnd[0],
- le32_to_cpu(srbreply->scsi_status));
+ pr_info("aacraid: SRB ERROR(%u) %s scsi cmd 0x%x -scsi status 0x%x\n",
+ le32_to_cpu(srbreply->srb_status) & 0x3F,
+ aac_get_status_string(
+ le32_to_cpu(srbreply->srb_status) & 0x3F),
+ scsicmd->cmnd[0],
+ le32_to_cpu(srbreply->scsi_status));
#endif
- if ((scsicmd->cmnd[0] == ATA_12)
- || (scsicmd->cmnd[0] == ATA_16)) {
- if (scsicmd->cmnd[2] & (0x01 << 5)) {
- scsicmd->result = DID_OK << 16
- | COMMAND_COMPLETE << 8;
- break;
- } else {
- scsicmd->result = DID_ERROR << 16
- | COMMAND_COMPLETE << 8;
- break;
- }
+ /*
+ * When the CC bit is SET by the host in ATA pass thru CDB,
+ * driver is supposed to return DID_OK
+ *
+ * When the CC bit is RESET by the host, driver should
+ * return DID_ERROR
+ */
+ if ((scsicmd->cmnd[0] == ATA_12)
+ || (scsicmd->cmnd[0] == ATA_16)) {
+
+ if (scsicmd->cmnd[2] & (0x01 << 5)) {
+ scsicmd->result = DID_OK << 16
+ | COMMAND_COMPLETE << 8;
+ break;
} else {
scsicmd->result = DID_ERROR << 16
| COMMAND_COMPLETE << 8;
- break;
+ break;
}
+ } else {
+ scsicmd->result = DID_ERROR << 16
+ | COMMAND_COMPLETE << 8;
+ break;
}
- if (le32_to_cpu(srbreply->scsi_status)
- == SAM_STAT_CHECK_CONDITION) {
- int len;
-
- scsicmd->result |= SAM_STAT_CHECK_CONDITION;
- len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
- SCSI_SENSE_BUFFERSIZE);
+ }
+ if (le32_to_cpu(srbreply->scsi_status)
+ == SAM_STAT_CHECK_CONDITION) {
+ int len;
+
+ scsicmd->result |= SAM_STAT_CHECK_CONDITION;
+ len = min_t(u32, le32_to_cpu(srbreply->sense_data_size),
+ SCSI_SENSE_BUFFERSIZE);
#ifdef AAC_DETAILED_STATUS_INFO
- printk(KERN_WARNING "aac_srb_callback: check condition, status = %d len=%d\n",
- le32_to_cpu(srbreply->status), len);
+ pr_warn("aac_srb_callback: check condition, status = %d len=%d\n",
+ le32_to_cpu(srbreply->status), len);
#endif
- memcpy(scsicmd->sense_buffer,
- srbreply->sense_data, len);
- }
+ memcpy(scsicmd->sense_buffer,
+ srbreply->sense_data, len);
}
+
/*
* OR in the scsi status (already shifted up a bit)
*/
^ permalink raw reply [flat|nested] 62+ messages in thread
* [PATCH 4.4 31/40] platform/x86: intel_mid_thermal: Fix module autoload
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2017-11-06 9:45 ` Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 32/40] staging: lustre: llite: dont invoke direct_IO for the EOF case Greg Kroah-Hartman
` (11 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Javier Martinez Canillas,
Andy Shevchenko, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Martinez Canillas <javier@osg.samsung.com>
[ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
$
After this patch:
$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
alias: platform:msic_thermal
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/platform/x86/intel_mid_thermal.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/platform/x86/intel_mid_thermal.c
+++ b/drivers/platform/x86/intel_mid_thermal.c
@@ -550,6 +550,7 @@ static const struct platform_device_id t
{ "msic_thermal", 1 },
{ }
};
+MODULE_DEVICE_TABLE(platform, therm_id_table);
static struct platform_driver mid_thermal_driver = {
.driver = {
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 32/40] staging: lustre: llite: dont invoke direct_IO for the EOF case
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 31/40] platform/x86: intel_mid_thermal: Fix module autoload Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 33/40] staging: lustre: hsm: stack overrun in hai_dump_data_field Greg Kroah-Hartman
` (10 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yang Sheng, Bob Glossman, Bobi Jam,
Oleg Drokin, James Simmons, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Sheng <yang.sheng@intel.com>
[ Upstream commit 77759771fb95420d23876cb104ab65c022613325 ]
The function generic_file_read_iter() does not check EOF
before invoke direct_IO callback. So we have to check it
ourselves.
Signed-off-by: Yang Sheng <yang.sheng@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969
Reviewed-on: https://review.whamcloud.com/24552
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/lustre/lustre/llite/rw26.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -376,6 +376,10 @@ static ssize_t ll_direct_IO_26(struct ki
if (!lli->lli_has_smd)
return -EBADF;
+ /* Check EOF by ourselves */
+ if (iov_iter_rw(iter) == READ && file_offset >= i_size_read(inode))
+ return 0;
+
/* FIXME: io smaller than PAGE_SIZE is broken on ia64 ??? */
if ((file_offset & ~CFS_PAGE_MASK) || (count & ~CFS_PAGE_MASK))
return -EINVAL;
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 33/40] staging: lustre: hsm: stack overrun in hai_dump_data_field
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 32/40] staging: lustre: llite: dont invoke direct_IO for the EOF case Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 34/40] staging: lustre: ptlrpc: skip lock if export failed Greg Kroah-Hartman
` (9 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, frank zago, John L. Hammond,
Jean-Baptiste Riaux, Oleg Drokin, James Simmons, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: frank zago <fzago@cray.com>
[ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ]
The function hai_dump_data_field will do a stack buffer
overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has
some data in it.
hai_dump_data_field uses snprintf. But there is no check for
truncation, and the value returned by snprintf is used as-is. The
coordinator code calls hai_dump_data_field with 12 bytes in the
buffer. The 6th byte of data is printed incompletely to make room for
the terminating NUL. However snprintf still returns 2, so when
hai_dump_data_field writes the final NUL, it does it outside the
reserved buffer, in the 13th byte of the buffer. This stack buffer
overrun hangs my VM.
Fix by checking that there is enough room for the next 2 characters
plus the NUL terminator. Don't print half bytes. Change the format to
02X instead of .2X, which makes more sense.
Signed-off-by: frank zago <fzago@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171
Reviewed-on: http://review.whamcloud.com/20338
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Jean-Baptiste Riaux <riaux.jb@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/lustre/lustre/include/lustre/lustre_user.h | 18 +++++--------
1 file changed, 8 insertions(+), 10 deletions(-)
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -1063,23 +1063,21 @@ struct hsm_action_item {
* \retval buffer
*/
static inline char *hai_dump_data_field(struct hsm_action_item *hai,
- char *buffer, int len)
+ char *buffer, size_t len)
{
- int i, sz, data_len;
+ int i, data_len;
char *ptr;
ptr = buffer;
- sz = len;
data_len = hai->hai_len - sizeof(*hai);
- for (i = 0 ; (i < data_len) && (sz > 0) ; i++) {
- int cnt;
-
- cnt = snprintf(ptr, sz, "%.2X",
- (unsigned char)hai->hai_data[i]);
- ptr += cnt;
- sz -= cnt;
+ for (i = 0; (i < data_len) && (len > 2); i++) {
+ snprintf(ptr, 3, "%02X", (unsigned char)hai->hai_data[i]);
+ ptr += 2;
+ len -= 2;
}
+
*ptr = '\0';
+
return buffer;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 34/40] staging: lustre: ptlrpc: skip lock if export failed
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 33/40] staging: lustre: hsm: stack overrun in hai_dump_data_field Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 35/40] exynos4-is: fimc-is: Unmap region obtained by of_iomap() Greg Kroah-Hartman
` (8 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Boyko, Fan Yong,
Vitaly Fertman, Oleg Drokin, James Simmons, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Boyko <alexander.boyko@seagate.com>
[ Upstream commit 4c43c27ddc461d8473cedd70f2549614641dfbc7 ]
This patch resolves IO vs eviction race.
After eviction failed export stayed at stale list,
a client had IO processing and reconnected during it.
A client sent brw rpc with last lock cookie and new connection.
The lock with failed export was found and assert was happened.
(ost_handler.c:1812:ost_prolong_lock_one())
ASSERTION( lock->l_export == opd->opd_exp ) failed:
1. Skip the lock at ldlm_handle2lock if lock export failed.
2. Validation of lock for IO was added at hpreq_check(). The lock
searching is based on granted interval tree. If server doesn`t
have a valid lock, it reply to client with ESTALE.
Signed-off-by: Alexander Boyko <alexander.boyko@seagate.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702
Seagate-bug-id: MRP-2787
Reviewed-on: http://review.whamcloud.com/18120
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 7 +++++++
drivers/staging/lustre/lustre/ptlrpc/service.c | 21 ++++++++-------------
2 files changed, 15 insertions(+), 13 deletions(-)
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_lock.c
@@ -550,6 +550,13 @@ struct ldlm_lock *__ldlm_handle2lock(con
if (lock == NULL)
return NULL;
+ if (lock->l_export && lock->l_export->exp_failed) {
+ CDEBUG(D_INFO, "lock export failed: lock %p, exp %p\n",
+ lock, lock->l_export);
+ LDLM_LOCK_PUT(lock);
+ return NULL;
+ }
+
/* It's unlikely but possible that someone marked the lock as
* destroyed after we did handle2object on it */
if (flags == 0 && ((lock->l_flags & LDLM_FL_DESTROYED) == 0)) {
--- a/drivers/staging/lustre/lustre/ptlrpc/service.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/service.c
@@ -1240,20 +1240,15 @@ static int ptlrpc_server_hpreq_init(stru
* it may hit swab race at LU-1044. */
if (req->rq_ops->hpreq_check) {
rc = req->rq_ops->hpreq_check(req);
- /**
- * XXX: Out of all current
- * ptlrpc_hpreq_ops::hpreq_check(), only
- * ldlm_cancel_hpreq_check() can return an error code;
- * other functions assert in similar places, which seems
- * odd. What also does not seem right is that handlers
- * for those RPCs do not assert on the same checks, but
- * rather handle the error cases. e.g. see
- * ost_rw_hpreq_check(), and ost_brw_read(),
- * ost_brw_write().
+ if (rc == -ESTALE) {
+ req->rq_status = rc;
+ ptlrpc_error(req);
+ }
+ /** can only return error,
+ * 0 for normal request,
+ * or 1 for high priority request
*/
- if (rc < 0)
- return rc;
- LASSERT(rc == 0 || rc == 1);
+ LASSERT(rc <= 1);
}
spin_lock_bh(&req->rq_export->exp_rpc_lock);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 35/40] exynos4-is: fimc-is: Unmap region obtained by of_iomap()
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 34/40] staging: lustre: ptlrpc: skip lock if export failed Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 36/40] mei: return error on notification request to a disconnected client Greg Kroah-Hartman
` (7 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Yadav, Sylwester Nawrocki,
Mauro Carvalho Chehab, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
[ Upstream commit 4742575cde1f3cee0ea6b41af42781672315b04b ]
Free memory mapping, if fimc_is_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/platform/exynos4-is/fimc-is.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -815,12 +815,13 @@ static int fimc_is_probe(struct platform
is->irq = irq_of_parse_and_map(dev->of_node, 0);
if (!is->irq) {
dev_err(dev, "no irq found\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_iounmap;
}
ret = fimc_is_get_clocks(is);
if (ret < 0)
- return ret;
+ goto err_iounmap;
platform_set_drvdata(pdev, is);
@@ -880,6 +881,8 @@ err_irq:
free_irq(is->irq, is);
err_clk:
fimc_is_put_clocks(is);
+err_iounmap:
+ iounmap(is->pmu_regs);
return ret;
}
@@ -935,6 +938,7 @@ static int fimc_is_remove(struct platfor
fimc_is_unregister_subdevs(is);
vb2_dma_contig_cleanup_ctx(is->alloc_ctx);
fimc_is_put_clocks(is);
+ iounmap(is->pmu_regs);
fimc_is_debugfs_remove(is);
release_firmware(is->fw.f_w);
fimc_is_free_cpu_memory(is);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 36/40] mei: return error on notification request to a disconnected client
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 35/40] exynos4-is: fimc-is: Unmap region obtained by of_iomap() Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 37/40] s390/dasd: check for device error pointer within state change interrupts Greg Kroah-Hartman
` (6 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alexander Usyskin, Tomas Winkler,
Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Usyskin <alexander.usyskin@intel.com>
[ Upstream commit 7c47d2ca0feca767479329da23523ed798acb854 ]
Request for a notification from a disconnected client will be ignored
silently by the FW but the caller should know that the operation hasn't
succeeded.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/mei/client.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1300,6 +1300,9 @@ int mei_cl_notify_request(struct mei_cl
return -EOPNOTSUPP;
}
+ if (!mei_cl_is_connected(cl))
+ return -ENODEV;
+
rets = pm_runtime_get(dev->dev);
if (rets < 0 && rets != -EINPROGRESS) {
pm_runtime_put_noidle(dev->dev);
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 37/40] s390/dasd: check for device error pointer within state change interrupts
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 36/40] mei: return error on notification request to a disconnected client Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 38/40] bt8xx: fix memory leak Greg Kroah-Hartman
` (5 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Stefan Haberland, Martin Schwidefsky,
Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Haberland <sth@linux.vnet.ibm.com>
[ Upstream commit 2202134e48a3b50320aeb9e3dd1186833e9d7e66 ]
Check if the device pointer is valid. Just a sanity check since we already
are in the int handler of the device.
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/s390/block/dasd.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -1635,8 +1635,11 @@ void dasd_int_handler(struct ccw_device
/* check for for attention message */
if (scsw_dstat(&irb->scsw) & DEV_STAT_ATTENTION) {
device = dasd_device_from_cdev_locked(cdev);
- device->discipline->check_attention(device, irb->esw.esw1.lpum);
- dasd_put_device(device);
+ if (!IS_ERR(device)) {
+ device->discipline->check_attention(device,
+ irb->esw.esw1.lpum);
+ dasd_put_device(device);
+ }
}
if (!cqr)
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 38/40] bt8xx: fix memory leak
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 37/40] s390/dasd: check for device error pointer within state change interrupts Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 39/40] xen: dont print error message in case of missing Xenstore entry Greg Kroah-Hartman
` (4 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sudip Mukherjee, Hans Verkuil,
Mauro Carvalho Chehab, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
[ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ]
If dvb_attach() fails then we were just printing an error message and
exiting but the memory allocated to state was not released.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/pci/bt8xx/dvb-bt8xx.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/pci/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/pci/bt8xx/dvb-bt8xx.c
@@ -680,6 +680,7 @@ static void frontend_init(struct dvb_bt8
/* DST is not a frontend, attaching the ASIC */
if (dvb_attach(dst_attach, state, &card->dvb_adapter) == NULL) {
pr_err("%s: Could not find a Twinhan DST\n", __func__);
+ kfree(state);
break;
}
/* Attach other DST peripherals if any */
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 39/40] xen: dont print error message in case of missing Xenstore entry
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 38/40] bt8xx: fix memory leak Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 9:45 ` [PATCH 4.4 40/40] staging: r8712u: Fix Sparse warning in rtl871x_xmit.c Greg Kroah-Hartman
` (3 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Juergen Gross, Boris Ostrovsky, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Juergen Gross <jgross@suse.com>
[ Upstream commit 4e93b6481c87ea5afde944a32b4908357ec58992 ]
When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/xen/manage.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -275,8 +275,16 @@ static void sysrq_handler(struct xenbus_
err = xenbus_transaction_start(&xbt);
if (err)
return;
- if (xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key) < 0) {
- pr_err("Unable to read sysrq code in control/sysrq\n");
+ err = xenbus_scanf(xbt, "control", "sysrq", "%c", &sysrq_key);
+ if (err < 0) {
+ /*
+ * The Xenstore watch fires directly after registering it and
+ * after a suspend/resume cycle. So ENOENT is no error but
+ * might happen in those cases.
+ */
+ if (err != -ENOENT)
+ pr_err("Error %d reading sysrq code in control/sysrq\n",
+ err);
xenbus_transaction_end(xbt, 1);
return;
}
^ permalink raw reply [flat|nested] 62+ messages in thread* [PATCH 4.4 40/40] staging: r8712u: Fix Sparse warning in rtl871x_xmit.c
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 39/40] xen: dont print error message in case of missing Xenstore entry Greg Kroah-Hartman
@ 2017-11-06 9:45 ` Greg Kroah-Hartman
2017-11-06 21:17 ` [PATCH 4.4 00/40] 4.4.97-stable review Guenter Roeck
` (2 subsequent siblings)
41 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-06 9:45 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Larry Finger, Sasha Levin
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Larry Finger <Larry.Finger@lwfinger.net>
[ Upstream commit 07222e535831b916221dd2a48a3047ec7e45dc72 ]
Sparse reports the following:
CHECK drivers/staging/rtl8712/rtl871x_xmit.c
drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8712/rtl871x_xmit.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -339,7 +339,8 @@ sint r8712_update_attrib(struct _adapter
/* if in MP_STATE, update pkt_attrib from mp_txcmd, and overwrite
* some settings above.*/
if (check_fwstate(pmlmepriv, WIFI_MP_STATE))
- pattrib->priority = (txdesc.txdw1 >> QSEL_SHT) & 0x1f;
+ pattrib->priority =
+ (le32_to_cpu(txdesc.txdw1) >> QSEL_SHT) & 0x1f;
return _SUCCESS;
}
@@ -479,7 +480,7 @@ static sint make_wlanhdr(struct _adapter
struct ieee80211_hdr *pwlanhdr = (struct ieee80211_hdr *)hdr;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct qos_priv *pqospriv = &pmlmepriv->qospriv;
- u16 *fctrl = &pwlanhdr->frame_ctl;
+ __le16 *fctrl = &pwlanhdr->frame_ctl;
memset(hdr, 0, WLANHDR_OFFSET);
SetFrameSubType(fctrl, pattrib->subtype);
@@ -568,7 +569,7 @@ static sint r8712_put_snap(u8 *data, u16
snap->oui[0] = oui[0];
snap->oui[1] = oui[1];
snap->oui[2] = oui[2];
- *(u16 *)(data + SNAP_SIZE) = htons(h_proto);
+ *(__be16 *)(data + SNAP_SIZE) = htons(h_proto);
return SNAP_SIZE + sizeof(u16);
}
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 00/40] 4.4.97-stable review
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2017-11-06 9:45 ` [PATCH 4.4 40/40] staging: r8712u: Fix Sparse warning in rtl871x_xmit.c Greg Kroah-Hartman
@ 2017-11-06 21:17 ` Guenter Roeck
2017-11-06 23:26 ` Shuah Khan
2017-11-07 22:55 ` Tom Gall
41 siblings, 0 replies; 62+ messages in thread
From: Guenter Roeck @ 2017-11-06 21:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Mon, Nov 06, 2017 at 10:44:35AM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov 8 09:44:42 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 116 pass: 116 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 00/40] 4.4.97-stable review
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2017-11-06 21:17 ` [PATCH 4.4 00/40] 4.4.97-stable review Guenter Roeck
@ 2017-11-06 23:26 ` Shuah Khan
2017-11-07 22:55 ` Tom Gall
41 siblings, 0 replies; 62+ messages in thread
From: Shuah Khan @ 2017-11-06 23:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
On 11/06/2017 02:44 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov 8 09:44:42 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.97-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 and kselftest regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 00/40] 4.4.97-stable review
2017-11-06 9:44 [PATCH 4.4 00/40] 4.4.97-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2017-11-06 23:26 ` Shuah Khan
@ 2017-11-07 22:55 ` Tom Gall
2017-11-08 9:22 ` Greg Kroah-Hartman
41 siblings, 1 reply; 62+ messages in thread
From: Tom Gall @ 2017-11-07 22:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, linux- stable
> On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov 8 09:44:42 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.97-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
>
Results from Linaro’s test farm. As per usual HiKey results held separate because it’s platform support is out of tree.
Summary
------------------------------------------------------------------------
kernel: 4.4.97-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 3a8149abdccbecc21c68451ee8ffd86b56ff3061
git describe: v4.4.96-41-g3a8149abdccb
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.96-41-g3a8149abdccb
Boards, architectures and test suites:
-------------------------------------
juno-r2 - arm64
x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, fail: 11, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, fail: 4, skip: 67 (known failures)
* ltp-timers-tests - pass: 12,
dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 15, skip: 9 (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 959, fail: 3, skip: 164 (known failures)
* ltp-timers-tests - pass: 13,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
Summary
------------------------------------------------------------------------
kernel: 4.4.97-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.97-rc1-hikey-20171107
git commit: f9ac28c428c0ddaf64cca891932a283fcca26516
git describe: 4.4.97-rc1-hikey-20171107
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.97-rc1-hikey-20171107
No regressions (compared to build 4.4.96-rc1-hikey-20171031)
Boards, architectures and test suites:
-------------------------------------
hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, fail: 13, skip: 9 (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, fail: 13, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, fail: 3, skip: 125 (known failures)
* ltp-timers-tests - pass: 13,
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
^ permalink raw reply [flat|nested] 62+ messages in thread* Re: [PATCH 4.4 00/40] 4.4.97-stable review
2017-11-07 22:55 ` Tom Gall
@ 2017-11-08 9:22 ` Greg Kroah-Hartman
0 siblings, 0 replies; 62+ messages in thread
From: Greg Kroah-Hartman @ 2017-11-08 9:22 UTC (permalink / raw)
To: Tom Gall
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, linux- stable
On Tue, Nov 07, 2017 at 04:55:36PM -0600, Tom Gall wrote:
>
> > On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 4.4.97 release.
> > There are 40 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 Wed Nov 8 09:44:42 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.97-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
> >
>
> Results from Linaro’s test farm. As per usual HiKey results held separate because it’s platform support is out of tree.
Thanks for letting me know, but howcome you all are not testing 4.13
releases?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 62+ messages in thread