* [PATCH 4.9 01/62] ALSA: line6: use dynamic buffers
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 02/62] ipv4: ip_do_fragment: Preserve skb_iif during fragmentation Greg Kroah-Hartman
` (64 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christo Gouws, Alan Stern, Takashi Iwai
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5c812e84f0dece3400d5caf42522287e6ef139f upstream.
The line6 driver uses a lot of USB buffers off of the stack, which is
not allowed on many systems, causing the driver to crash on some of
them. Fix this up by dynamically allocating the buffers with kmalloc()
which allows for proper DMA-able memory.
Reported-by: Christo Gouws <gouws.christo@gmail.com>
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Christo Gouws <gouws.christo@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/usb/line6/driver.c | 60 ++++++++++++++++++++++++++-------------------
sound/usb/line6/podhd.c | 21 +++++++++------
sound/usb/line6/toneport.c | 24 +++++++++++++-----
3 files changed, 65 insertions(+), 40 deletions(-)
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -337,12 +337,16 @@ int line6_read_data(struct usb_line6 *li
{
struct usb_device *usbdev = line6->usbdev;
int ret;
- unsigned char len;
+ unsigned char *len;
unsigned count;
if (address > 0xffff || datalen > 0xff)
return -EINVAL;
+ len = kmalloc(sizeof(*len), GFP_KERNEL);
+ if (!len)
+ return -ENOMEM;
+
/* query the serial number: */
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
@@ -351,7 +355,7 @@ int line6_read_data(struct usb_line6 *li
if (ret < 0) {
dev_err(line6->ifcdev, "read request failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
/* Wait for data length. We'll get 0xff until length arrives. */
@@ -361,28 +365,29 @@ int line6_read_data(struct usb_line6 *li
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
- 0x0012, 0x0000, &len, 1,
+ 0x0012, 0x0000, len, 1,
LINE6_TIMEOUT * HZ);
if (ret < 0) {
dev_err(line6->ifcdev,
"receive length failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
- if (len != 0xff)
+ if (*len != 0xff)
break;
}
- if (len == 0xff) {
+ ret = -EIO;
+ if (*len == 0xff) {
dev_err(line6->ifcdev, "read failed after %d retries\n",
count);
- return -EIO;
- } else if (len != datalen) {
+ goto exit;
+ } else if (*len != datalen) {
/* should be equal or something went wrong */
dev_err(line6->ifcdev,
"length mismatch (expected %d, got %d)\n",
- (int)datalen, (int)len);
- return -EIO;
+ (int)datalen, (int)*len);
+ goto exit;
}
/* receive the result: */
@@ -391,12 +396,12 @@ int line6_read_data(struct usb_line6 *li
0x0013, 0x0000, data, datalen,
LINE6_TIMEOUT * HZ);
- if (ret < 0) {
+ if (ret < 0)
dev_err(line6->ifcdev, "read failed (error %d)\n", ret);
- return ret;
- }
- return 0;
+exit:
+ kfree(len);
+ return ret;
}
EXPORT_SYMBOL_GPL(line6_read_data);
@@ -408,12 +413,16 @@ int line6_write_data(struct usb_line6 *l
{
struct usb_device *usbdev = line6->usbdev;
int ret;
- unsigned char status;
+ unsigned char *status;
int count;
if (address > 0xffff || datalen > 0xffff)
return -EINVAL;
+ status = kmalloc(sizeof(*status), GFP_KERNEL);
+ if (!status)
+ return -ENOMEM;
+
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
0x0022, address, data, datalen,
@@ -422,7 +431,7 @@ int line6_write_data(struct usb_line6 *l
if (ret < 0) {
dev_err(line6->ifcdev,
"write request failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
for (count = 0; count < LINE6_READ_WRITE_MAX_RETRIES; count++) {
@@ -433,28 +442,29 @@ int line6_write_data(struct usb_line6 *l
USB_TYPE_VENDOR | USB_RECIP_DEVICE |
USB_DIR_IN,
0x0012, 0x0000,
- &status, 1, LINE6_TIMEOUT * HZ);
+ status, 1, LINE6_TIMEOUT * HZ);
if (ret < 0) {
dev_err(line6->ifcdev,
"receiving status failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
- if (status != 0xff)
+ if (*status != 0xff)
break;
}
- if (status == 0xff) {
+ if (*status == 0xff) {
dev_err(line6->ifcdev, "write failed after %d retries\n",
count);
- return -EIO;
- } else if (status != 0) {
+ ret = -EIO;
+ } else if (*status != 0) {
dev_err(line6->ifcdev, "write failed (error %d)\n", ret);
- return -EIO;
+ ret = -EIO;
}
-
- return 0;
+exit:
+ kfree(status);
+ return ret;
}
EXPORT_SYMBOL_GPL(line6_write_data);
--- a/sound/usb/line6/podhd.c
+++ b/sound/usb/line6/podhd.c
@@ -221,28 +221,32 @@ static void podhd_startup_start_workqueu
static int podhd_dev_start(struct usb_line6_podhd *pod)
{
int ret;
- u8 init_bytes[8];
+ u8 *init_bytes;
int i;
struct usb_device *usbdev = pod->line6.usbdev;
+ init_bytes = kmalloc(8, GFP_KERNEL);
+ if (!init_bytes)
+ return -ENOMEM;
+
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0),
0x67, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
0x11, 0,
NULL, 0, LINE6_TIMEOUT * HZ);
if (ret < 0) {
dev_err(pod->line6.ifcdev, "read request failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
/* NOTE: looks like some kind of ping message */
ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67,
USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
0x11, 0x0,
- &init_bytes, 3, LINE6_TIMEOUT * HZ);
+ init_bytes, 3, LINE6_TIMEOUT * HZ);
if (ret < 0) {
dev_err(pod->line6.ifcdev,
"receive length failed (error %d)\n", ret);
- return ret;
+ goto exit;
}
pod->firmware_version =
@@ -251,7 +255,7 @@ static int podhd_dev_start(struct usb_li
for (i = 0; i <= 16; i++) {
ret = line6_read_data(&pod->line6, 0xf000 + 0x08 * i, init_bytes, 8);
if (ret < 0)
- return ret;
+ goto exit;
}
ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0),
@@ -259,10 +263,9 @@ static int podhd_dev_start(struct usb_li
USB_TYPE_STANDARD | USB_RECIP_DEVICE | USB_DIR_OUT,
1, 0,
NULL, 0, LINE6_TIMEOUT * HZ);
- if (ret < 0)
- return ret;
-
- return 0;
+exit:
+ kfree(init_bytes);
+ return ret;
}
static void podhd_startup_workqueue(struct work_struct *work)
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -365,15 +365,20 @@ static bool toneport_has_source_select(s
/*
Setup Toneport device.
*/
-static void toneport_setup(struct usb_line6_toneport *toneport)
+static int toneport_setup(struct usb_line6_toneport *toneport)
{
- int ticks;
+ int *ticks;
struct usb_line6 *line6 = &toneport->line6;
struct usb_device *usbdev = line6->usbdev;
+ ticks = kmalloc(sizeof(*ticks), GFP_KERNEL);
+ if (!ticks)
+ return -ENOMEM;
+
/* sync time on device with host: */
- ticks = (int)get_seconds();
- line6_write_data(line6, 0x80c6, &ticks, 4);
+ *ticks = (int)get_seconds();
+ line6_write_data(line6, 0x80c6, ticks, 4);
+ kfree(ticks);
/* enable device: */
toneport_send_cmd(usbdev, 0x0301, 0x0000);
@@ -388,6 +393,7 @@ static void toneport_setup(struct usb_li
toneport_update_led(toneport);
mod_timer(&toneport->timer, jiffies + TONEPORT_PCM_DELAY * HZ);
+ return 0;
}
/*
@@ -451,7 +457,9 @@ static int toneport_init(struct usb_line
return err;
}
- toneport_setup(toneport);
+ err = toneport_setup(toneport);
+ if (err)
+ return err;
/* register audio system: */
return snd_card_register(line6->card);
@@ -463,7 +471,11 @@ static int toneport_init(struct usb_line
*/
static int toneport_reset_resume(struct usb_interface *interface)
{
- toneport_setup(usb_get_intfdata(interface));
+ int err;
+
+ err = toneport_setup(usb_get_intfdata(interface));
+ if (err)
+ return err;
return line6_resume(interface);
}
#endif
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 02/62] ipv4: ip_do_fragment: Preserve skb_iif during fragmentation
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 01/62] ALSA: line6: use dynamic buffers Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 03/62] ipv6/flowlabel: wait rcu grace period before put_pid() Greg Kroah-Hartman
` (63 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Shmulik Ladkani, David S. Miller
From: Shmulik Ladkani <shmulik@metanetworks.com>
[ Upstream commit d2f0c961148f65bc73eda72b9fa3a4e80973cb49 ]
Previously, during fragmentation after forwarding, skb->skb_iif isn't
preserved, i.e. 'ip_copy_metadata' does not copy skb_iif from given
'from' skb.
As a result, ip_do_fragment's creates fragments with zero skb_iif,
leading to inconsistent behavior.
Assume for example an eBPF program attached at tc egress (post
forwarding) that examines __sk_buff->ingress_ifindex:
- the correct iif is observed if forwarding path does not involve
fragmentation/refragmentation
- a bogus iif is observed if forwarding path involves
fragmentation/refragmentatiom
Fix, by preserving skb_iif during 'ip_copy_metadata'.
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv4/ip_output.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -492,6 +492,7 @@ static void ip_copy_metadata(struct sk_b
to->pkt_type = from->pkt_type;
to->priority = from->priority;
to->protocol = from->protocol;
+ to->skb_iif = from->skb_iif;
skb_dst_drop(to);
skb_dst_copy(to, from);
to->dev = from->dev;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 03/62] ipv6/flowlabel: wait rcu grace period before put_pid()
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 01/62] ALSA: line6: use dynamic buffers Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 02/62] ipv4: ip_do_fragment: Preserve skb_iif during fragmentation Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 04/62] ipv6: invert flowlabel sharing check in process and user mode Greg Kroah-Hartman
` (62 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Dumazet, Eric W. Biederman,
syzbot, David S. Miller
From: Eric Dumazet <edumazet@google.com>
[ Upstream commit 6c0afef5fb0c27758f4d52b2210c61b6bd8b4470 ]
syzbot was able to catch a use-after-free read in pid_nr_ns() [1]
ip6fl_seq_show() seems to use RCU protection, dereferencing fl->owner.pid
but fl_free() releases fl->owner.pid before rcu grace period is started.
[1]
BUG: KASAN: use-after-free in pid_nr_ns+0x128/0x140 kernel/pid.c:407
Read of size 4 at addr ffff888094012a04 by task syz-executor.0/18087
CPU: 0 PID: 18087 Comm: syz-executor.0 Not tainted 5.1.0-rc6+ #89
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
pid_nr_ns+0x128/0x140 kernel/pid.c:407
ip6fl_seq_show+0x2f8/0x4f0 net/ipv6/ip6_flowlabel.c:794
seq_read+0xad3/0x1130 fs/seq_file.c:268
proc_reg_read+0x1fe/0x2c0 fs/proc/inode.c:227
do_loop_readv_writev fs/read_write.c:701 [inline]
do_loop_readv_writev fs/read_write.c:688 [inline]
do_iter_read+0x4a9/0x660 fs/read_write.c:922
vfs_readv+0xf0/0x160 fs/read_write.c:984
kernel_readv fs/splice.c:358 [inline]
default_file_splice_read+0x475/0x890 fs/splice.c:413
do_splice_to+0x12a/0x190 fs/splice.c:876
splice_direct_to_actor+0x2d2/0x970 fs/splice.c:953
do_splice_direct+0x1da/0x2a0 fs/splice.c:1062
do_sendfile+0x597/0xd00 fs/read_write.c:1443
__do_sys_sendfile64 fs/read_write.c:1498 [inline]
__se_sys_sendfile64 fs/read_write.c:1490 [inline]
__x64_sys_sendfile64+0x15a/0x220 fs/read_write.c:1490
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x458da9
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f300d24bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 0000000000458da9
RDX: 00000000200000c0 RSI: 0000000000000008 RDI: 0000000000000007
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 000000000000005a R11: 0000000000000246 R12: 00007f300d24c6d4
R13: 00000000004c5fa3 R14: 00000000004da748 R15: 00000000ffffffff
Allocated by task 17543:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:497 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470
kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505
slab_post_alloc_hook mm/slab.h:437 [inline]
slab_alloc mm/slab.c:3393 [inline]
kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555
alloc_pid+0x55/0x8f0 kernel/pid.c:168
copy_process.part.0+0x3b08/0x7980 kernel/fork.c:1932
copy_process kernel/fork.c:1709 [inline]
_do_fork+0x257/0xfd0 kernel/fork.c:2226
__do_sys_clone kernel/fork.c:2333 [inline]
__se_sys_clone kernel/fork.c:2327 [inline]
__x64_sys_clone+0xbf/0x150 kernel/fork.c:2327
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 7789:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:459
kasan_slab_free+0xe/0x10 mm/kasan/common.c:467
__cache_free mm/slab.c:3499 [inline]
kmem_cache_free+0x86/0x260 mm/slab.c:3765
put_pid.part.0+0x111/0x150 kernel/pid.c:111
put_pid+0x20/0x30 kernel/pid.c:105
fl_free+0xbe/0xe0 net/ipv6/ip6_flowlabel.c:102
ip6_fl_gc+0x295/0x3e0 net/ipv6/ip6_flowlabel.c:152
call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers kernel/time/timer.c:1681 [inline]
__run_timers kernel/time/timer.c:1649 [inline]
run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
__do_softirq+0x266/0x95a kernel/softirq.c:293
The buggy address belongs to the object at ffff888094012a00
which belongs to the cache pid_2 of size 88
The buggy address is located 4 bytes inside of
88-byte region [ffff888094012a00, ffff888094012a58)
The buggy address belongs to the page:
page:ffffea0002500480 count:1 mapcount:0 mapping:ffff88809a483080 index:0xffff888094012980
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea00018a3508 ffffea0002524a88 ffff88809a483080
raw: ffff888094012980 ffff888094012000 000000010000001b 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888094012900: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
ffff888094012980: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
>ffff888094012a00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
^
ffff888094012a80: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
ffff888094012b00: fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
Fixes: 4f82f45730c6 ("net ip6 flowlabel: Make owner a union of struct pid * and kuid_t")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -94,15 +94,21 @@ static struct ip6_flowlabel *fl_lookup(s
return fl;
}
+static void fl_free_rcu(struct rcu_head *head)
+{
+ struct ip6_flowlabel *fl = container_of(head, struct ip6_flowlabel, rcu);
+
+ if (fl->share == IPV6_FL_S_PROCESS)
+ put_pid(fl->owner.pid);
+ kfree(fl->opt);
+ kfree(fl);
+}
+
static void fl_free(struct ip6_flowlabel *fl)
{
- if (fl) {
- if (fl->share == IPV6_FL_S_PROCESS)
- put_pid(fl->owner.pid);
- kfree(fl->opt);
- kfree_rcu(fl, rcu);
- }
+ if (fl)
+ call_rcu(&fl->rcu, fl_free_rcu);
}
static void fl_release(struct ip6_flowlabel *fl)
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 04/62] ipv6: invert flowlabel sharing check in process and user mode
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 03/62] ipv6/flowlabel: wait rcu grace period before put_pid() Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 05/62] packet: validate msg_namelen in send directly Greg Kroah-Hartman
` (61 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Willem de Bruijn, David S. Miller
From: Willem de Bruijn <willemb@google.com>
[ Upstream commit 95c169251bf734aa555a1e8043e4d88ec97a04ec ]
A request for a flowlabel fails in process or user exclusive mode must
fail if the caller pid or uid does not match. Invert the test.
Previously, the test was unsafe wrt PID recycling, but indeed tested
for inequality: fl1->owner != fl->owner
Fixes: 4f82f45730c68 ("net ip6 flowlabel: Make owner a union of struct pid* and kuid_t")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/ip6_flowlabel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -640,9 +640,9 @@ recheck:
if (fl1->share == IPV6_FL_S_EXCL ||
fl1->share != fl->share ||
((fl1->share == IPV6_FL_S_PROCESS) &&
- (fl1->owner.pid == fl->owner.pid)) ||
+ (fl1->owner.pid != fl->owner.pid)) ||
((fl1->share == IPV6_FL_S_USER) &&
- uid_eq(fl1->owner.uid, fl->owner.uid)))
+ !uid_eq(fl1->owner.uid, fl->owner.uid)))
goto release;
err = -ENOMEM;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 05/62] packet: validate msg_namelen in send directly
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 04/62] ipv6: invert flowlabel sharing check in process and user mode Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 06/62] bnxt_en: Improve multicast address setup logic Greg Kroah-Hartman
` (60 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Laight, Willem de Bruijn,
David S. Miller
From: Willem de Bruijn <willemb@google.com>
[ Upstream commit 486efdc8f6ce802b27e15921d2353cc740c55451 ]
Packet sockets in datagram mode take a destination address. Verify its
length before passing to dev_hard_header.
Prior to 2.6.14-rc3, the send code ignored sll_halen. This is
established behavior. Directly compare msg_namelen to dev->addr_len.
Change v1->v2: initialize addr in all paths
Fixes: 6b8d95f1795c4 ("packet: validate address length if non-zero")
Suggested-by: David Laight <David.Laight@aculab.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/packet/af_packet.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2638,8 +2638,8 @@ static int tpacket_snd(struct packet_soc
void *ph;
DECLARE_SOCKADDR(struct sockaddr_ll *, saddr, msg->msg_name);
bool need_wait = !(msg->msg_flags & MSG_DONTWAIT);
+ unsigned char *addr = NULL;
int tp_len, size_max;
- unsigned char *addr;
void *data;
int len_sum = 0;
int status = TP_STATUS_AVAILABLE;
@@ -2650,7 +2650,6 @@ static int tpacket_snd(struct packet_soc
if (likely(saddr == NULL)) {
dev = packet_cached_dev_get(po);
proto = po->num;
- addr = NULL;
} else {
err = -EINVAL;
if (msg->msg_namelen < sizeof(struct sockaddr_ll))
@@ -2660,10 +2659,13 @@ static int tpacket_snd(struct packet_soc
sll_addr)))
goto out;
proto = saddr->sll_protocol;
- addr = saddr->sll_halen ? saddr->sll_addr : NULL;
dev = dev_get_by_index(sock_net(&po->sk), saddr->sll_ifindex);
- if (addr && dev && saddr->sll_halen < dev->addr_len)
- goto out_put;
+ if (po->sk.sk_socket->type == SOCK_DGRAM) {
+ if (dev && msg->msg_namelen < dev->addr_len +
+ offsetof(struct sockaddr_ll, sll_addr))
+ goto out_put;
+ addr = saddr->sll_addr;
+ }
}
err = -ENXIO;
@@ -2834,7 +2836,7 @@ static int packet_snd(struct socket *soc
struct sk_buff *skb;
struct net_device *dev;
__be16 proto;
- unsigned char *addr;
+ unsigned char *addr = NULL;
int err, reserve = 0;
struct sockcm_cookie sockc;
struct virtio_net_hdr vnet_hdr = { 0 };
@@ -2851,7 +2853,6 @@ static int packet_snd(struct socket *soc
if (likely(saddr == NULL)) {
dev = packet_cached_dev_get(po);
proto = po->num;
- addr = NULL;
} else {
err = -EINVAL;
if (msg->msg_namelen < sizeof(struct sockaddr_ll))
@@ -2859,10 +2860,13 @@ static int packet_snd(struct socket *soc
if (msg->msg_namelen < (saddr->sll_halen + offsetof(struct sockaddr_ll, sll_addr)))
goto out;
proto = saddr->sll_protocol;
- addr = saddr->sll_halen ? saddr->sll_addr : NULL;
dev = dev_get_by_index(sock_net(sk), saddr->sll_ifindex);
- if (addr && dev && saddr->sll_halen < dev->addr_len)
- goto out_unlock;
+ if (sock->type == SOCK_DGRAM) {
+ if (dev && msg->msg_namelen < dev->addr_len +
+ offsetof(struct sockaddr_ll, sll_addr))
+ goto out_unlock;
+ addr = saddr->sll_addr;
+ }
}
err = -ENXIO;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 06/62] bnxt_en: Improve multicast address setup logic.
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 05/62] packet: validate msg_namelen in send directly Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 07/62] net: phy: marvell: Fix buffer overrun with stats counters Greg Kroah-Hartman
` (59 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Chan, David S. Miller
From: Michael Chan <michael.chan@broadcom.com>
[ Upstream commit b4e30e8e7ea1d1e35ffd64ca46f7d9a7f227b4bf ]
The driver builds a list of multicast addresses and sends it to the
firmware when the driver's ndo_set_rx_mode() is called. In rare
cases, the firmware can fail this call if internal resources to
add multicast addresses are exhausted. In that case, we should
try the call again by setting the ALL_MCAST flag which is more
guaranteed to succeed.
Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5954,8 +5954,15 @@ static int bnxt_cfg_rx_mode(struct bnxt
skip_uc:
rc = bnxt_hwrm_cfa_l2_set_rx_mask(bp, 0);
+ if (rc && vnic->mc_list_count) {
+ netdev_info(bp->dev, "Failed setting MC filters rc: %d, turning on ALL_MCAST mode\n",
+ rc);
+ vnic->rx_mask |= CFA_L2_SET_RX_MASK_REQ_MASK_ALL_MCAST;
+ vnic->mc_list_count = 0;
+ rc = bnxt_hwrm_cfa_l2_set_rx_mask(bp, 0);
+ }
if (rc)
- netdev_err(bp->dev, "HWRM cfa l2 rx mask failure rc: %x\n",
+ netdev_err(bp->dev, "HWRM cfa l2 rx mask failure rc: %d\n",
rc);
return rc;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 07/62] net: phy: marvell: Fix buffer overrun with stats counters
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 06/62] bnxt_en: Improve multicast address setup logic Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 08/62] x86/suspend: fix false positive KASAN warning on suspend/resume Greg Kroah-Hartman
` (58 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrew Lunn, Florian Fainelli,
David S. Miller
From: Andrew Lunn <andrew@lunn.ch>
[ Upstream commit fdfdf86720a34527f777cbe0d8599bf0528fa146 ]
marvell_get_sset_count() returns how many statistics counters there
are. If the PHY supports fibre, there are 3, otherwise two.
marvell_get_strings() does not make this distinction, and always
returns 3 strings. This then often results in writing past the end
of the buffer for the strings.
Fixes: 2170fef78a40 ("Marvell phy: add field to get errors from fiber link.")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/phy/marvell.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -1429,9 +1429,10 @@ static int marvell_get_sset_count(struct
static void marvell_get_strings(struct phy_device *phydev, u8 *data)
{
+ int count = marvell_get_sset_count(phydev);
int i;
- for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++) {
+ for (i = 0; i < count; i++) {
memcpy(data + i * ETH_GSTRING_LEN,
marvell_hw_stats[i].string, ETH_GSTRING_LEN);
}
@@ -1470,9 +1471,10 @@ static u64 marvell_get_stat(struct phy_d
static void marvell_get_stats(struct phy_device *phydev,
struct ethtool_stats *stats, u64 *data)
{
+ int count = marvell_get_sset_count(phydev);
int i;
- for (i = 0; i < ARRAY_SIZE(marvell_hw_stats); i++)
+ for (i = 0; i < count; i++)
data[i] = marvell_get_stat(phydev, i);
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 08/62] x86/suspend: fix false positive KASAN warning on suspend/resume
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 07/62] net: phy: marvell: Fix buffer overrun with stats counters Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope Greg Kroah-Hartman
` (57 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Scott Bauer, Josh Poimboeuf,
Andrey Ryabinin, Pavel Machek, Rafael J. Wysocki,
Andrey Konovalov
From: Josh Poimboeuf <jpoimboe@redhat.com>
commit b53f40db59b27b62bc294c30506b02a0cae47e0b upstream.
Resuming from a suspend operation is showing a KASAN false positive
warning:
BUG: KASAN: stack-out-of-bounds in unwind_get_return_address+0x11d/0x130 at addr ffff8803867d7878
Read of size 8 by task pm-suspend/7774
page:ffffea000e19f5c0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x2ffff0000000000()
page dumped because: kasan: bad access detected
CPU: 0 PID: 7774 Comm: pm-suspend Tainted: G B 4.9.0-rc7+ #8
Hardware name: Gigabyte Technology Co., Ltd. Z170X-UD5/Z170X-UD5-CF, BIOS F5 03/07/2016
Call Trace:
dump_stack+0x63/0x82
kasan_report_error+0x4b4/0x4e0
? acpi_hw_read_port+0xd0/0x1ea
? kfree_const+0x22/0x30
? acpi_hw_validate_io_request+0x1a6/0x1a6
__asan_report_load8_noabort+0x61/0x70
? unwind_get_return_address+0x11d/0x130
unwind_get_return_address+0x11d/0x130
? unwind_next_frame+0x97/0xf0
__save_stack_trace+0x92/0x100
save_stack_trace+0x1b/0x20
save_stack+0x46/0xd0
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
? kasan_kmalloc+0xad/0xe0
? kasan_slab_alloc+0x12/0x20
? acpi_hw_read+0x2b6/0x3aa
? acpi_hw_validate_register+0x20b/0x20b
? acpi_hw_write_port+0x72/0xc7
? acpi_hw_write+0x11f/0x15f
? acpi_hw_read_multiple+0x19f/0x19f
? memcpy+0x45/0x50
? acpi_hw_write_port+0x72/0xc7
? acpi_hw_write+0x11f/0x15f
? acpi_hw_read_multiple+0x19f/0x19f
? kasan_unpoison_shadow+0x36/0x50
kasan_kmalloc+0xad/0xe0
kasan_slab_alloc+0x12/0x20
kmem_cache_alloc_trace+0xbc/0x1e0
? acpi_get_sleep_type_data+0x9a/0x578
acpi_get_sleep_type_data+0x9a/0x578
acpi_hw_legacy_wake_prep+0x88/0x22c
? acpi_hw_legacy_sleep+0x3c7/0x3c7
? acpi_write_bit_register+0x28d/0x2d3
? acpi_read_bit_register+0x19b/0x19b
acpi_hw_sleep_dispatch+0xb5/0xba
acpi_leave_sleep_state_prep+0x17/0x19
acpi_suspend_enter+0x154/0x1e0
? trace_suspend_resume+0xe8/0xe8
suspend_devices_and_enter+0xb09/0xdb0
? printk+0xa8/0xd8
? arch_suspend_enable_irqs+0x20/0x20
? try_to_freeze_tasks+0x295/0x600
pm_suspend+0x6c9/0x780
? finish_wait+0x1f0/0x1f0
? suspend_devices_and_enter+0xdb0/0xdb0
state_store+0xa2/0x120
? kobj_attr_show+0x60/0x60
kobj_attr_store+0x36/0x70
sysfs_kf_write+0x131/0x200
kernfs_fop_write+0x295/0x3f0
__vfs_write+0xef/0x760
? handle_mm_fault+0x1346/0x35e0
? do_iter_readv_writev+0x660/0x660
? __pmd_alloc+0x310/0x310
? do_lock_file_wait+0x1e0/0x1e0
? apparmor_file_permission+0x18/0x20
? security_file_permission+0x73/0x1c0
? rw_verify_area+0xbd/0x2b0
vfs_write+0x149/0x4a0
SyS_write+0xd9/0x1c0
? SyS_read+0x1c0/0x1c0
entry_SYSCALL_64_fastpath+0x1e/0xad
Memory state around the buggy address:
ffff8803867d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8803867d7780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8803867d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4
^
ffff8803867d7880: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
ffff8803867d7900: 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3 00
KASAN instrumentation poisons the stack when entering a function and
unpoisons it when exiting the function. However, in the suspend path,
some functions never return, so their stack never gets unpoisoned,
resulting in stale KASAN shadow data which can cause later false
positive warnings like the one above.
Reported-by: Scott Bauer <scott.bauer@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/acpi/wakeup_64.S | 9 +++++++++
mm/kasan/kasan.c | 9 ++++++++-
2 files changed, 17 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -109,6 +109,15 @@ ENTRY(do_suspend_lowlevel)
movq pt_regs_r14(%rax), %r14
movq pt_regs_r15(%rax), %r15
+#ifdef CONFIG_KASAN
+ /*
+ * The suspend path may have poisoned some areas deeper in the stack,
+ * which we now need to unpoison.
+ */
+ movq %rsp, %rdi
+ call kasan_unpoison_task_stack_below
+#endif
+
xorl %eax, %eax
addq $8, %rsp
FRAME_END
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -80,7 +80,14 @@ void kasan_unpoison_task_stack(struct ta
/* Unpoison the stack for the current task beyond a watermark sp value. */
asmlinkage void kasan_unpoison_task_stack_below(const void *watermark)
{
- __kasan_unpoison_stack(current, watermark);
+ /*
+ * Calculate the task stack base address. Avoid using 'current'
+ * because this function is called by early resume code which hasn't
+ * yet set up the percpu register (%gs).
+ */
+ void *base = (void *)((unsigned long)watermark & ~(THREAD_SIZE - 1));
+
+ kasan_unpoison_shadow(base, watermark - base);
}
/*
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 08/62] x86/suspend: fix false positive KASAN warning on suspend/resume Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:55 ` Andrey Ryabinin
2019-05-06 14:32 ` [PATCH 4.9 10/62] kasan: rework Kconfig settings Greg Kroah-Hartman
` (56 subsequent siblings)
65 siblings, 1 reply; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrey Ryabinin, Dmitry Vyukov,
Alexander Potapenko, Andrey Konovalov, Andrew Morton,
Linus Torvalds
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
In the upcoming gcc7 release, the -fsanitize=kernel-address option at
first implied new -fsanitize-address-use-after-scope option. This would
cause link errors on older kernels because they don't have two new
functions required for use-after-scope support. Therefore, gcc7 changed
default to -fno-sanitize-address-use-after-scope.
Now the kernel has everything required for that feature since commit
828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it
work, we just have to enable use-after-scope in CFLAGS.
Link: http://lkml.kernel.org/r/1481207977-28654-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/Makefile.kasan | 2 ++
1 file changed, 2 insertions(+)
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -29,6 +29,8 @@ else
endif
endif
+CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
endif
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope
2019-05-06 14:32 ` [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope Greg Kroah-Hartman
@ 2019-05-06 14:55 ` Andrey Ryabinin
2019-05-06 15:10 ` Greg Kroah-Hartman
0 siblings, 1 reply; 73+ messages in thread
From: Andrey Ryabinin @ 2019-05-06 14:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Dmitry Vyukov, Alexander Potapenko, Andrey Konovalov,
Andrew Morton, Linus Torvalds
On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> From: Andrey Ryabinin <aryabinin@virtuozzo.com>
>
> commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
>
> In the upcoming gcc7 release, the -fsanitize=kernel-address option at
> first implied new -fsanitize-address-use-after-scope option. This would
> cause link errors on older kernels because they don't have two new
> functions required for use-after-scope support. Therefore, gcc7 changed
> default to -fno-sanitize-address-use-after-scope.
>
> Now the kernel has everything required for that feature since commit
> 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it
> work, we just have to enable use-after-scope in CFLAGS.
>
> Link: http://lkml.kernel.org/r/1481207977-28654-1-git-send-email-aryabinin@virtuozzo.com
> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> scripts/Makefile.kasan | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -29,6 +29,8 @@ else
> endif
> endif
>
> +CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
> +
> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
>
> endif
>
>
This shouldn't be in the -stable.
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope
2019-05-06 14:55 ` Andrey Ryabinin
@ 2019-05-06 15:10 ` Greg Kroah-Hartman
2019-05-06 15:36 ` Andrey Ryabinin
0 siblings, 1 reply; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 15:10 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: linux-kernel, stable, Dmitry Vyukov, Alexander Potapenko,
Andrey Konovalov, Andrew Morton, Linus Torvalds
On Mon, May 06, 2019 at 05:55:54PM +0300, Andrey Ryabinin wrote:
>
>
> On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> > From: Andrey Ryabinin <aryabinin@virtuozzo.com>
> >
> > commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
> >
> > In the upcoming gcc7 release, the -fsanitize=kernel-address option at
> > first implied new -fsanitize-address-use-after-scope option. This would
> > cause link errors on older kernels because they don't have two new
> > functions required for use-after-scope support. Therefore, gcc7 changed
> > default to -fno-sanitize-address-use-after-scope.
> >
> > Now the kernel has everything required for that feature since commit
> > 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it
> > work, we just have to enable use-after-scope in CFLAGS.
> >
> > Link: http://lkml.kernel.org/r/1481207977-28654-1-git-send-email-aryabinin@virtuozzo.com
> > Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> > Acked-by: Dmitry Vyukov <dvyukov@google.com>
> > Cc: Alexander Potapenko <glider@google.com>
> > Cc: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > ---
> > scripts/Makefile.kasan | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > --- a/scripts/Makefile.kasan
> > +++ b/scripts/Makefile.kasan
> > @@ -29,6 +29,8 @@ else
> > endif
> > endif
> >
> > +CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
> > +
> > CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> >
> > endif
> >
> >
>
> This shouldn't be in the -stable.
Why not? Does no one use gcc7 with this kernel and kasan?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope
2019-05-06 15:10 ` Greg Kroah-Hartman
@ 2019-05-06 15:36 ` Andrey Ryabinin
2019-05-06 15:42 ` Greg Kroah-Hartman
0 siblings, 1 reply; 73+ messages in thread
From: Andrey Ryabinin @ 2019-05-06 15:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Dmitry Vyukov, Alexander Potapenko,
Andrey Konovalov, Andrew Morton, Linus Torvalds
On 5/6/19 6:10 PM, Greg Kroah-Hartman wrote:
> On Mon, May 06, 2019 at 05:55:54PM +0300, Andrey Ryabinin wrote:
>>
>>
>> On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
>>> From: Andrey Ryabinin <aryabinin@virtuozzo.com>
>>>
>>> commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
>>>
>>> In the upcoming gcc7 release, the -fsanitize=kernel-address option at
>>> first implied new -fsanitize-address-use-after-scope option. This would
>>> cause link errors on older kernels because they don't have two new
>>> functions required for use-after-scope support. Therefore, gcc7 changed
>>> default to -fno-sanitize-address-use-after-scope.
>>>
>>> Now the kernel has everything required for that feature since commit
>>> 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it
>>> work, we just have to enable use-after-scope in CFLAGS.
>>>
>>> Link: http://lkml.kernel.org/r/1481207977-28654-1-git-send-email-aryabinin@virtuozzo.com
>>> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
>>> Acked-by: Dmitry Vyukov <dvyukov@google.com>
>>> Cc: Alexander Potapenko <glider@google.com>
>>> Cc: Andrey Konovalov <andreyknvl@google.com>
>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>
>>> ---
>>> scripts/Makefile.kasan | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> --- a/scripts/Makefile.kasan
>>> +++ b/scripts/Makefile.kasan
>>> @@ -29,6 +29,8 @@ else
>>> endif
>>> endif
>>>
>>> +CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
>>> +
>>> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
>>>
>>> endif
>>>
>>>
>>
>> This shouldn't be in the -stable.
>
> Why not? Does no one use gcc7 with this kernel and kasan?
>
You don't need this patch to use kasan on this kernel with gcc7.
This patch only enables detection of use-after-scope bugs. This feature appeared to be useless,
hence it disabled recently by commit 7771bdbbfd3d ("kasan: remove use after scope bugs detection.")
The link errors mentioned in changelog was the problem only for some period of time in the development branch of GCC 7.
The released GCC7 version doesn't have this problem.
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope
2019-05-06 15:36 ` Andrey Ryabinin
@ 2019-05-06 15:42 ` Greg Kroah-Hartman
0 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 15:42 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: linux-kernel, stable, Dmitry Vyukov, Alexander Potapenko,
Andrey Konovalov, Andrew Morton, Linus Torvalds
On Mon, May 06, 2019 at 06:36:45PM +0300, Andrey Ryabinin wrote:
>
>
> On 5/6/19 6:10 PM, Greg Kroah-Hartman wrote:
> > On Mon, May 06, 2019 at 05:55:54PM +0300, Andrey Ryabinin wrote:
> >>
> >>
> >> On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> >>> From: Andrey Ryabinin <aryabinin@virtuozzo.com>
> >>>
> >>> commit c5caf21ab0cf884ef15b25af234f620e4a233139 upstream.
> >>>
> >>> In the upcoming gcc7 release, the -fsanitize=kernel-address option at
> >>> first implied new -fsanitize-address-use-after-scope option. This would
> >>> cause link errors on older kernels because they don't have two new
> >>> functions required for use-after-scope support. Therefore, gcc7 changed
> >>> default to -fno-sanitize-address-use-after-scope.
> >>>
> >>> Now the kernel has everything required for that feature since commit
> >>> 828347f8f9a5 ("kasan: support use-after-scope detection"). So, to make it
> >>> work, we just have to enable use-after-scope in CFLAGS.
> >>>
> >>> Link: http://lkml.kernel.org/r/1481207977-28654-1-git-send-email-aryabinin@virtuozzo.com
> >>> Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> >>> Acked-by: Dmitry Vyukov <dvyukov@google.com>
> >>> Cc: Alexander Potapenko <glider@google.com>
> >>> Cc: Andrey Konovalov <andreyknvl@google.com>
> >>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >>> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>>
> >>> ---
> >>> scripts/Makefile.kasan | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> --- a/scripts/Makefile.kasan
> >>> +++ b/scripts/Makefile.kasan
> >>> @@ -29,6 +29,8 @@ else
> >>> endif
> >>> endif
> >>>
> >>> +CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
> >>> +
> >>> CFLAGS_KASAN_NOSANITIZE := -fno-builtin
> >>>
> >>> endif
> >>>
> >>>
> >>
> >> This shouldn't be in the -stable.
> >
> > Why not? Does no one use gcc7 with this kernel and kasan?
> >
>
> You don't need this patch to use kasan on this kernel with gcc7.
> This patch only enables detection of use-after-scope bugs. This feature appeared to be useless,
> hence it disabled recently by commit 7771bdbbfd3d ("kasan: remove use after scope bugs detection.")
Ah, didn't notice that, nice!
Ok, I'll go drop this, thanks for letting me know.
> The link errors mentioned in changelog was the problem only for some period of time in the development branch of GCC 7.
> The released GCC7 version doesn't have this problem.
Also good to know, thanks!
greg k-h
^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 4.9 10/62] kasan: rework Kconfig settings
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 09/62] kasan: turn on -fsanitize-address-use-after-scope Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:58 ` Andrey Ryabinin
2019-05-06 14:32 ` [PATCH 4.9 11/62] mm/kasan: Switch to using __pa_symbol and lm_alias Greg Kroah-Hartman
` (55 subsequent siblings)
65 siblings, 1 reply; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Andrey Ryabinin,
Mauro Carvalho Chehab, Alexander Potapenko, Dmitry Vyukov,
Andrey Konovalov, Andrew Morton, Linus Torvalds
From: Arnd Bergmann <arnd@arndb.de>
commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
We get a lot of very large stack frames using gcc-7.0.1 with the default
-fsanitize-address-use-after-scope --param asan-stack=1 options, which can
easily cause an overflow of the kernel stack, e.g.
drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
To reduce this risk, -fsanitize-address-use-after-scope is now split out
into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
frames that are smaller than 2 kilobytes most of the time on x86_64. An
earlier version of this patch also prevented combining KASAN_EXTRA with
KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
bring back that default now. KASAN_EXTRA=y still causes lots of
warnings but now defaults to !COMPILE_TEST to disable it in
allmodconfig, and it remains disabled in all other defconfigs since it
is a new option. I arbitrarily raise the warning limit for KASAN_EXTRA
to 3072 to reduce the noise, but an allmodconfig kernel still has around
50 warnings on gcc-7.
I experimented a bit more with smaller stack frames and have another
follow-up series that reduces the warning limit for 64-bit architectures
to 1280 bytes (without CONFIG_KASAN).
With earlier versions of this patch series, I also had patches to address
the warnings we get with KASAN and/or KASAN_EXTRA, using a
"noinline_if_stackbloat" annotation.
That annotation now got replaced with a gcc-8 bugfix (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
older compilers, which means that KASAN_EXTRA is now just as bad as
before and will lead to an instant stack overflow in a few extreme
cases.
This reverts parts of commit 3f181b4d8652 ("lib/Kconfig.debug: disable
-Wframe-larger-than warnings with KASAN=y"). Two patches in linux-next
should be merged first to avoid introducing warnings in an allmodconfig
build:
3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
16c3ada89cff ("media: r820t: fix r820t_write_reg for KASAN")
Do we really need to backport this?
I think we do: without this patch, enabling KASAN will lead to
unavoidable kernel stack overflow in certain device drivers when built
with gcc-7 or higher on linux-4.10+ or any version that contains a
backport of commit c5caf21ab0cf8. Most people are probably still on
older compilers, but it will get worse over time as they upgrade their
distros.
The warnings we get on kernels older than this should all be for code
that uses dangerously large stack frames, though most of them do not
cause an actual stack overflow by themselves.The asan-stack option was
added in linux-4.0, and commit 3f181b4d8652 ("lib/Kconfig.debug:
disable -Wframe-larger-than warnings with KASAN=y") effectively turned
off the warning for allmodconfig kernels, so I would like to see this
fix backported to any kernels later than 4.0.
I have done dozens of fixes for individual functions with stack frames
larger than 2048 bytes with asan-stack, and I plan to make sure that
all those fixes make it into the stable kernels as well (most are
already there).
Part of the complication here is that asan-stack (from 4.0) was
originally assumed to always require much larger stacks, but that
turned out to be a combination of multiple gcc bugs that we have now
worked around and fixed, but sanitize-address-use-after-scope (from
v4.10) has a much higher inherent stack usage and also suffers from at
least three other problems that we have analyzed but not yet fixed
upstream, each of them makes the stack usage more severe than it should
be.
Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.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>
---
lib/Kconfig.debug | 1 +
lib/Kconfig.kasan | 11 +++++++++++
scripts/Makefile.kasan | 2 ++
3 files changed, 14 insertions(+)
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -197,6 +197,7 @@ config ENABLE_MUST_CHECK
config FRAME_WARN
int "Warn for stack frames larger than (needs gcc 4.4)"
range 0 8192
+ default 3072 if KASAN_EXTRA
default 2048 if GCC_PLUGIN_LATENT_ENTROPY
default 1024 if !64BIT
default 2048 if 64BIT
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -20,6 +20,17 @@ config KASAN
Currently CONFIG_KASAN doesn't work with CONFIG_DEBUG_SLAB
(the resulting kernel does not boot).
+config KASAN_EXTRA
+ bool "KAsan: extra checks"
+ depends on KASAN && DEBUG_KERNEL && !COMPILE_TEST
+ help
+ This enables further checks in the kernel address sanitizer, for now
+ it only includes the address-use-after-scope check that can lead
+ to excessive kernel stack usage, frame size warnings and longer
+ compile time.
+ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 has more
+
+
choice
prompt "Instrumentation type"
depends on KASAN
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -29,7 +29,9 @@ else
endif
endif
+ifdef CONFIG_KASAN_EXTRA
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+endif
CFLAGS_KASAN_NOSANITIZE := -fno-builtin
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 10/62] kasan: rework Kconfig settings
2019-05-06 14:32 ` [PATCH 4.9 10/62] kasan: rework Kconfig settings Greg Kroah-Hartman
@ 2019-05-06 14:58 ` Andrey Ryabinin
2019-05-06 15:42 ` Greg Kroah-Hartman
0 siblings, 1 reply; 73+ messages in thread
From: Andrey Ryabinin @ 2019-05-06 14:58 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Arnd Bergmann, Mauro Carvalho Chehab,
Alexander Potapenko, Dmitry Vyukov, Andrey Konovalov,
Andrew Morton, Linus Torvalds
On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
>
This is a fix/workaround for the previous patch c5caf21ab0cf "kasan: turn on -fsanitize-address-use-after-scope"
which shouldn't be in the -stable. So without c5caf21ab0cf we don't need this one.
^ permalink raw reply [flat|nested] 73+ messages in thread
* Re: [PATCH 4.9 10/62] kasan: rework Kconfig settings
2019-05-06 14:58 ` Andrey Ryabinin
@ 2019-05-06 15:42 ` Greg Kroah-Hartman
0 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 15:42 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: linux-kernel, stable, Arnd Bergmann, Mauro Carvalho Chehab,
Alexander Potapenko, Dmitry Vyukov, Andrey Konovalov,
Andrew Morton, Linus Torvalds
On Mon, May 06, 2019 at 05:58:59PM +0300, Andrey Ryabinin wrote:
>
>
> On 5/6/19 5:32 PM, Greg Kroah-Hartman wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 upstream.
> >
>
> This is a fix/workaround for the previous patch c5caf21ab0cf "kasan: turn on -fsanitize-address-use-after-scope"
> which shouldn't be in the -stable. So without c5caf21ab0cf we don't need this one.
Great, will go drop this now as well!
greg k-h
^ permalink raw reply [flat|nested] 73+ messages in thread
* [PATCH 4.9 11/62] mm/kasan: Switch to using __pa_symbol and lm_alias
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 10/62] kasan: rework Kconfig settings Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 12/62] x86/unwind: Disable KASAN checks for non-current tasks Greg Kroah-Hartman
` (54 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Laura Abbott,
Will Deacon, Andrey Konovalov
From: Laura Abbott <labbott@redhat.com>
commit 5c6a84a3f4558a6115fef1b59343c7ae56b3abc3 upstream.
__pa_symbol is the correct API to find the physical address of symbols.
Switch to it to allow for debugging APIs to work correctly. Other
functions such as p*d_populate may call __pa internally. Ensure that the
address passed is in the linear region by calling lm_alias.
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/kasan/kasan_init.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- a/mm/kasan/kasan_init.c
+++ b/mm/kasan/kasan_init.c
@@ -15,6 +15,7 @@
#include <linux/kasan.h>
#include <linux/kernel.h>
#include <linux/memblock.h>
+#include <linux/mm.h>
#include <linux/pfn.h>
#include <asm/page.h>
@@ -49,7 +50,7 @@ static void __init zero_pte_populate(pmd
pte_t *pte = pte_offset_kernel(pmd, addr);
pte_t zero_pte;
- zero_pte = pfn_pte(PFN_DOWN(__pa(kasan_zero_page)), PAGE_KERNEL);
+ zero_pte = pfn_pte(PFN_DOWN(__pa_symbol(kasan_zero_page)), PAGE_KERNEL);
zero_pte = pte_wrprotect(zero_pte);
while (addr + PAGE_SIZE <= end) {
@@ -69,7 +70,7 @@ static void __init zero_pmd_populate(pud
next = pmd_addr_end(addr, end);
if (IS_ALIGNED(addr, PMD_SIZE) && end - addr >= PMD_SIZE) {
- pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
+ pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
continue;
}
@@ -92,9 +93,9 @@ static void __init zero_pud_populate(pgd
if (IS_ALIGNED(addr, PUD_SIZE) && end - addr >= PUD_SIZE) {
pmd_t *pmd;
- pud_populate(&init_mm, pud, kasan_zero_pmd);
+ pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd));
pmd = pmd_offset(pud, addr);
- pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
+ pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
continue;
}
@@ -135,11 +136,11 @@ void __init kasan_populate_zero_shadow(c
* puds,pmds, so pgd_populate(), pud_populate()
* is noops.
*/
- pgd_populate(&init_mm, pgd, kasan_zero_pud);
+ pgd_populate(&init_mm, pgd, lm_alias(kasan_zero_pud));
pud = pud_offset(pgd, addr);
- pud_populate(&init_mm, pud, kasan_zero_pmd);
+ pud_populate(&init_mm, pud, lm_alias(kasan_zero_pmd));
pmd = pmd_offset(pud, addr);
- pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
+ pmd_populate_kernel(&init_mm, pmd, lm_alias(kasan_zero_pte));
continue;
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 12/62] x86/unwind: Disable KASAN checks for non-current tasks
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 11/62] mm/kasan: Switch to using __pa_symbol and lm_alias Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 13/62] arm64: kasan: avoid bad virt_to_pfn() Greg Kroah-Hartman
` (53 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry Vyukov, Josh Poimboeuf,
Andy Lutomirski, Andy Lutomirski, Borislav Petkov, Brian Gerst,
Dave Jones, Denys Vlasenko, H. Peter Anvin, Linus Torvalds,
Miroslav Benes, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Andrey Konovalov
From: Josh Poimboeuf <jpoimboe@redhat.com>
commit 84936118bdf37bda513d4a361c38181a216427e0 upstream.
There are a handful of callers to save_stack_trace_tsk() and
show_stack() which try to unwind the stack of a task other than current.
In such cases, it's remotely possible that the task is running on one
CPU while the unwinder is reading its stack from another CPU, causing
the unwinder to see stack corruption.
These cases seem to be mostly harmless. The unwinder has checks which
prevent it from following bad pointers beyond the bounds of the stack.
So it's not really a bug as long as the caller understands that
unwinding another task will not always succeed.
In such cases, it's possible that the unwinder may read a KASAN-poisoned
region of the stack. Account for that by using READ_ONCE_NOCHECK() when
reading the stack of another task.
Use READ_ONCE() when reading the stack of the current task, since KASAN
warnings can still be useful for finding bugs in that case.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/4c575eb288ba9f73d498dfe0acde2f58674598f1.1483978430.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/stacktrace.h | 5 ++++-
arch/x86/kernel/unwind_frame.c | 20 ++++++++++++++++++--
2 files changed, 22 insertions(+), 3 deletions(-)
--- a/arch/x86/include/asm/stacktrace.h
+++ b/arch/x86/include/asm/stacktrace.h
@@ -55,13 +55,16 @@ extern int kstack_depth_to_print;
static inline unsigned long *
get_frame_pointer(struct task_struct *task, struct pt_regs *regs)
{
+ struct inactive_task_frame *frame;
+
if (regs)
return (unsigned long *)regs->bp;
if (task == current)
return __builtin_frame_address(0);
- return (unsigned long *)((struct inactive_task_frame *)task->thread.sp)->bp;
+ frame = (struct inactive_task_frame *)task->thread.sp;
+ return (unsigned long *)READ_ONCE_NOCHECK(frame->bp);
}
#else
static inline unsigned long *
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -6,6 +6,21 @@
#define FRAME_HEADER_SIZE (sizeof(long) * 2)
+/*
+ * This disables KASAN checking when reading a value from another task's stack,
+ * since the other task could be running on another CPU and could have poisoned
+ * the stack in the meantime.
+ */
+#define READ_ONCE_TASK_STACK(task, x) \
+({ \
+ unsigned long val; \
+ if (task == current) \
+ val = READ_ONCE(x); \
+ else \
+ val = READ_ONCE_NOCHECK(x); \
+ val; \
+})
+
unsigned long unwind_get_return_address(struct unwind_state *state)
{
unsigned long addr;
@@ -14,7 +29,8 @@ unsigned long unwind_get_return_address(
if (unwind_done(state))
return 0;
- addr = ftrace_graph_ret_addr(state->task, &state->graph_idx, *addr_p,
+ addr = READ_ONCE_TASK_STACK(state->task, *addr_p);
+ addr = ftrace_graph_ret_addr(state->task, &state->graph_idx, addr,
addr_p);
return __kernel_text_address(addr) ? addr : 0;
@@ -48,7 +64,7 @@ bool unwind_next_frame(struct unwind_sta
if (unwind_done(state))
return false;
- next_bp = (unsigned long *)*state->bp;
+ next_bp = (unsigned long *)READ_ONCE_TASK_STACK(state->task,*state->bp);
/* make sure the next frame's data is accessible */
if (!update_stack_state(state, next_bp, FRAME_HEADER_SIZE))
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 13/62] arm64: kasan: avoid bad virt_to_pfn()
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 12/62] x86/unwind: Disable KASAN checks for non-current tasks Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 14/62] kasan: add a prototype of task_struct to avoid warning Greg Kroah-Hartman
` (52 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Catalin Marinas, Will Deacon,
Laura Abbott, Mark Rutland, Andrey Konovalov
From: Mark Rutland <mark.rutland@arm.com>
commit b0de0ccc8b9edd8846828e0ecdc35deacdf186b0 upstream.
Booting a v4.11-rc1 kernel with DEBUG_VIRTUAL and KASAN enabled produces
the following splat (trimmed for brevity):
[ 0.000000] virt_to_phys used for non-linear address: ffff200008080000 (0xffff200008080000)
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:14 __virt_to_phys+0x48/0x70
[ 0.000000] PC is at __virt_to_phys+0x48/0x70
[ 0.000000] LR is at __virt_to_phys+0x48/0x70
[ 0.000000] Call trace:
[ 0.000000] [<ffff2000080b1ac0>] __virt_to_phys+0x48/0x70
[ 0.000000] [<ffff20000a03b86c>] kasan_init+0x1c0/0x498
[ 0.000000] [<ffff20000a034018>] setup_arch+0x2fc/0x948
[ 0.000000] [<ffff20000a030c68>] start_kernel+0xb8/0x570
[ 0.000000] [<ffff20000a0301e8>] __primary_switched+0x6c/0x74
This is because we use virt_to_pfn() on a kernel image address when
trying to figure out its nid, so that we can allocate its shadow from
the same node.
As with other recent changes, this patch uses lm_alias() to solve this.
We could instead use NUMA_NO_NODE, as x86 does for all shadow
allocations, though we'll likely want the "real" memory shadow to be
backed from its corresponding nid anyway, so we may as well be
consistent and find the nid for the image shadow.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/kasan_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -153,7 +153,7 @@ void __init kasan_init(void)
clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END);
vmemmap_populate(kimg_shadow_start, kimg_shadow_end,
- pfn_to_nid(virt_to_pfn(_text)));
+ pfn_to_nid(virt_to_pfn(lm_alias(_text))));
/*
* vmemmap_populate() has populated the shadow region that covers the
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 14/62] kasan: add a prototype of task_struct to avoid warning
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 13/62] arm64: kasan: avoid bad virt_to_pfn() Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 15/62] kasan: avoid -Wmaybe-uninitialized warning Greg Kroah-Hartman
` (51 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Masami Hiramatsu,
Alexander Potapenko, Andrey Ryabinin, Dmitry Vyukov,
Andrew Morton, Linus Torvalds, Andrey Konovalov
From: Masami Hiramatsu <mhiramat@kernel.org>
commit 5be9b730b09c45c358bbfe7f51d254e306cccc07 upstream.
Add a prototype of task_struct to fix below warning on arm64.
In file included from arch/arm64/kernel/probes/kprobes.c:19:0:
include/linux/kasan.h:81:132: error: 'struct task_struct' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
static inline void kasan_unpoison_task_stack(struct task_struct *task) {}
As same as other types (kmem_cache, page, and vm_struct) this adds a
prototype of task_struct data structure on top of kasan.h.
[arnd] A related warning was fixed before, but now appears in a
different line in the same file in v4.11-rc2. The patch from Masami
Hiramatsu still seems appropriate, so let's take his version.
Fixes: 71af2ed5eeea ("kasan, sched/headers: Remove <linux/sched.h> from <linux/kasan.h>")
Link: https://patchwork.kernel.org/patch/9569839/
Link: http://lkml.kernel.org/r/20170313141517.3397802-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Alexander Potapenko <glider@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/kasan.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -7,6 +7,7 @@
struct kmem_cache;
struct page;
struct vm_struct;
+struct task_struct;
#ifdef CONFIG_KASAN
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 15/62] kasan: avoid -Wmaybe-uninitialized warning
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 14/62] kasan: add a prototype of task_struct to avoid warning Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 16/62] kasan: remove redundant initialization of variable real_size Greg Kroah-Hartman
` (50 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Alexander Potapenko,
Andrey Ryabinin, Dmitry Vyukov, Andrew Morton, Linus Torvalds,
Andrey Konovalov
From: Arnd Bergmann <arnd@arndb.de>
commit e7701557bfdd81ff44cab13a80439319a735d8e2 upstream.
gcc-7 produces this warning:
mm/kasan/report.c: In function 'kasan_report':
mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
print_shadow_for_address(info->first_bad_addr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mm/kasan/report.c:360:27: note: 'info.first_bad_addr' was declared here
The code seems fine as we only print info.first_bad_addr when there is a
shadow, and we always initialize it in that case, but this is relatively
hard for gcc to figure out after the latest rework.
Adding an intialization to the most likely value together with the other
struct members shuts up that warning.
Fixes: b235b9808664 ("kasan: unify report headers")
Link: https://patchwork.kernel.org/patch/9641417/
Link: http://lkml.kernel.org/r/20170725152739.4176967-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Alexander Potapenko <glider@google.com>
Suggested-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/kasan/report.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -302,6 +302,7 @@ void kasan_report(unsigned long addr, si
disable_trace_on_warning();
info.access_addr = (void *)addr;
+ info.first_bad_addr = (void *)addr;
info.access_size = size;
info.is_write = is_write;
info.ip = ip;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 16/62] kasan: remove redundant initialization of variable real_size
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 15/62] kasan: avoid -Wmaybe-uninitialized warning Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 17/62] arm64: proc: Set PTE_NG for table entries to avoid traversing them twice Greg Kroah-Hartman
` (49 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Colin Ian King, Andrey Ryabinin,
Andrew Morton, Alexander Potapenko, Dmitry Vyukov,
Linus Torvalds, Andrey Konovalov
From: Colin Ian King <colin.king@canonical.com>
commit 48c232395431c23d35cf3b4c5a090bd793316578 upstream.
Variable real_size is initialized with a value that is never read, it is
re-assigned a new value later on, hence the initialization is redundant
and can be removed.
Cleans up clang warning:
lib/test_kasan.c:422:21: warning: Value stored to 'real_size' during its initialization is never read
Link: http://lkml.kernel.org/r/20180206144950.32457-1-colin.king@canonical.com
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/test_kasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -355,7 +355,7 @@ static noinline void __init kasan_stack_
static noinline void __init ksize_unpoisons_memory(void)
{
char *ptr;
- size_t size = 123, real_size = size;
+ size_t size = 123, real_size;
pr_info("ksize() unpoisons the whole allocated chunk\n");
ptr = kmalloc(size, GFP_KERNEL);
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 17/62] arm64: proc: Set PTE_NG for table entries to avoid traversing them twice
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 16/62] kasan: remove redundant initialization of variable real_size Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 18/62] kasan: prevent compiler from optimizing away memset in tests Greg Kroah-Hartman
` (48 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Will Deacon,
Catalin Marinas, Andrey Konovalov
From: Will Deacon <will.deacon@arm.com>
commit 2ce77f6d8a9ae9ce6d80397d88bdceb84a2004cd upstream.
When KASAN is enabled, the swapper page table contains many identical
mappings of the zero page, which can lead to a stall during boot whilst
the G -> nG code continually walks the same page table entries looking
for global mappings.
This patch sets the nG bit (bit 11, which is IGNORED) in table entries
after processing the subtree so we can easily skip them if we see them
a second time.
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/proc.S | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -181,7 +181,8 @@ ENDPROC(idmap_cpu_replace_ttbr1)
dc cvac, cur_\()\type\()p // Ensure any existing dirty
dmb sy // lines are written back before
ldr \type, [cur_\()\type\()p] // loading the entry
- tbz \type, #0, next_\()\type // Skip invalid entries
+ tbz \type, #0, skip_\()\type // Skip invalid and
+ tbnz \type, #11, skip_\()\type // non-global entries
.endm
.macro __idmap_kpti_put_pgtable_ent_ng, type
@@ -241,8 +242,9 @@ ENTRY(idmap_kpti_install_ng_mappings)
add end_pgdp, cur_pgdp, #(PTRS_PER_PGD * 8)
do_pgd: __idmap_kpti_get_pgtable_ent pgd
tbnz pgd, #1, walk_puds
- __idmap_kpti_put_pgtable_ent_ng pgd
next_pgd:
+ __idmap_kpti_put_pgtable_ent_ng pgd
+skip_pgd:
add cur_pgdp, cur_pgdp, #8
cmp cur_pgdp, end_pgdp
b.ne do_pgd
@@ -270,8 +272,9 @@ walk_puds:
add end_pudp, cur_pudp, #(PTRS_PER_PUD * 8)
do_pud: __idmap_kpti_get_pgtable_ent pud
tbnz pud, #1, walk_pmds
- __idmap_kpti_put_pgtable_ent_ng pud
next_pud:
+ __idmap_kpti_put_pgtable_ent_ng pud
+skip_pud:
add cur_pudp, cur_pudp, 8
cmp cur_pudp, end_pudp
b.ne do_pud
@@ -290,8 +293,9 @@ walk_pmds:
add end_pmdp, cur_pmdp, #(PTRS_PER_PMD * 8)
do_pmd: __idmap_kpti_get_pgtable_ent pmd
tbnz pmd, #1, walk_ptes
- __idmap_kpti_put_pgtable_ent_ng pmd
next_pmd:
+ __idmap_kpti_put_pgtable_ent_ng pmd
+skip_pmd:
add cur_pmdp, cur_pmdp, #8
cmp cur_pmdp, end_pmdp
b.ne do_pmd
@@ -309,7 +313,7 @@ walk_ptes:
add end_ptep, cur_ptep, #(PTRS_PER_PTE * 8)
do_pte: __idmap_kpti_get_pgtable_ent pte
__idmap_kpti_put_pgtable_ent_ng pte
-next_pte:
+skip_pte:
add cur_ptep, cur_ptep, #8
cmp cur_ptep, end_ptep
b.ne do_pte
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 18/62] kasan: prevent compiler from optimizing away memset in tests
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 17/62] arm64: proc: Set PTE_NG for table entries to avoid traversing them twice Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 19/62] arm64: mm: print out correct page table entries Greg Kroah-Hartman
` (47 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrey Konovalov, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Geert Uytterhoeven,
Nick Terrell, Chris Mason, Yury Norov, Al Viro,
Luis R . Rodriguez, Palmer Dabbelt, Paul E . McKenney,
Jeff Layton, Jason A . Donenfeld, Kostya Serebryany,
Andrew Morton, Linus Torvalds
From: Andrey Konovalov <andreyknvl@google.com>
commit 69ca372c100fba99c78ef826a1795aa86e4f01a8 upstream.
A compiler can optimize away memset calls by replacing them with mov
instructions. There are KASAN tests that specifically test that KASAN
correctly handles memset calls so we don't want this optimization to
happen.
The solution is to add -fno-builtin flag to test_kasan.ko
Link: http://lkml.kernel.org/r/105ec9a308b2abedb1a0d1fdced0c22d765e4732.1519924383.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Nick Terrell <terrelln@fb.com>
Cc: Chris Mason <clm@fb.com>
Cc: Yury Norov <ynorov@caviumnetworks.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Luis R . Rodriguez" <mcgrof@kernel.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Jeff Layton <jlayton@redhat.com>
Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
Cc: Kostya Serebryany <kcc@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
lib/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_TEST_BPF) += test_bpf.o
obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o
obj-$(CONFIG_TEST_HASH) += test_hash.o
obj-$(CONFIG_TEST_KASAN) += test_kasan.o
+CFLAGS_test_kasan.o += -fno-builtin
obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
obj-$(CONFIG_TEST_LKM) += test_module.o
obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 19/62] arm64: mm: print out correct page table entries
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 18/62] kasan: prevent compiler from optimizing away memset in tests Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 20/62] arm64: mm: dont print out page table entries on EL0 faults Greg Kroah-Hartman
` (46 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Kristina Martsenko,
Will Deacon, Andrey Konovalov
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit 67ce16ec15ce9d97d3d85e72beabbc5d7017193e upstream.
When we take a fault that can't be handled, we print out the page table
entries associated with the faulting address. In some cases we currently
print out the wrong entries. For a faulting TTBR1 address, we sometimes
print out TTBR0 table entries instead, and for a faulting TTBR0 address
we sometimes print out TTBR1 table entries. Fix this by choosing the
tables based on the faulting address.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
[will: zero-extend addrs to 64-bit, don't walk swapper w/ TTBR0 addr]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/system_misc.h | 2 -
arch/arm64/mm/fault.c | 36 ++++++++++++++++++++++++-----------
2 files changed, 26 insertions(+), 12 deletions(-)
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -40,7 +40,7 @@ void hook_debug_fault_code(int nr, int (
int sig, int code, const char *name);
struct mm_struct;
-extern void show_pte(struct mm_struct *mm, unsigned long addr);
+extern void show_pte(unsigned long addr);
extern void __show_regs(struct pt_regs *);
extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -79,18 +79,33 @@ static inline int notify_page_fault(stru
#endif
/*
- * Dump out the page tables associated with 'addr' in mm 'mm'.
+ * Dump out the page tables associated with 'addr' in the currently active mm.
*/
-void show_pte(struct mm_struct *mm, unsigned long addr)
+void show_pte(unsigned long addr)
{
+ struct mm_struct *mm;
pgd_t *pgd;
- if (!mm)
+ if (addr < TASK_SIZE) {
+ /* TTBR0 */
+ mm = current->active_mm;
+ if (mm == &init_mm) {
+ pr_alert("[%016lx] user address but active_mm is swapper\n",
+ addr);
+ return;
+ }
+ } else if (addr >= VA_START) {
+ /* TTBR1 */
mm = &init_mm;
+ } else {
+ pr_alert("[%016lx] address between user and kernel address ranges\n",
+ addr);
+ return;
+ }
pr_alert("pgd = %p\n", mm->pgd);
pgd = pgd_offset(mm, addr);
- pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
+ pr_alert("[%016lx] *pgd=%016llx", addr, pgd_val(*pgd));
do {
pud_t *pud;
@@ -176,8 +191,8 @@ static bool is_el1_instruction_abort(uns
/*
* The kernel tried to access some page that wasn't present.
*/
-static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
- unsigned int esr, struct pt_regs *regs)
+static void __do_kernel_fault(unsigned long addr, unsigned int esr,
+ struct pt_regs *regs)
{
/*
* Are we prepared to handle this kernel fault?
@@ -194,7 +209,7 @@ static void __do_kernel_fault(struct mm_
(addr < PAGE_SIZE) ? "NULL pointer dereference" :
"paging request", addr);
- show_pte(mm, addr);
+ show_pte(addr);
die("Oops", regs, esr);
bust_spinlocks(0);
do_exit(SIGKILL);
@@ -216,7 +231,7 @@ static void __do_user_fault(struct task_
pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
tsk->comm, task_pid_nr(tsk), inf->name, sig,
addr, esr);
- show_pte(tsk->mm, addr);
+ show_pte(addr);
show_regs(regs);
}
@@ -232,7 +247,6 @@ static void __do_user_fault(struct task_
static void do_bad_area(unsigned long addr, unsigned int esr, struct pt_regs *regs)
{
struct task_struct *tsk = current;
- struct mm_struct *mm = tsk->active_mm;
const struct fault_info *inf;
/*
@@ -243,7 +257,7 @@ static void do_bad_area(unsigned long ad
inf = esr_to_fault_info(esr);
__do_user_fault(tsk, addr, esr, inf->sig, inf->code, regs);
} else
- __do_kernel_fault(mm, addr, esr, regs);
+ __do_kernel_fault(addr, esr, regs);
}
#define VM_FAULT_BADMAP 0x010000
@@ -454,7 +468,7 @@ retry:
return 0;
no_context:
- __do_kernel_fault(mm, addr, esr, regs);
+ __do_kernel_fault(addr, esr, regs);
return 0;
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 20/62] arm64: mm: dont print out page table entries on EL0 faults
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 19/62] arm64: mm: print out correct page table entries Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 21/62] caif: reduce stack size with KASAN Greg Kroah-Hartman
` (45 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mark Rutland, Kristina Martsenko,
Will Deacon, Andrey Konovalov
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit bf396c09c2447a787d02af34cf167e953f85fa42 upstream.
When we take a fault from EL0 that can't be handled, we print out the
page table entries associated with the faulting address. This allows
userspace to print out any current page table entries, including kernel
(TTBR1) entries. Exposing kernel mappings like this could pose a
security risk, so don't print out page table information on EL0 faults.
(But still print it out for EL1 faults.) This also follows the same
behaviour as x86, printing out page table entries on kernel mode faults
but not user mode faults.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/mm/fault.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -231,7 +231,6 @@ static void __do_user_fault(struct task_
pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
tsk->comm, task_pid_nr(tsk), inf->name, sig,
addr, esr);
- show_pte(addr);
show_regs(regs);
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 21/62] caif: reduce stack size with KASAN
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 20/62] arm64: mm: dont print out page table entries on EL0 faults Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 22/62] USB: yurex: Fix protection fault after device removal Greg Kroah-Hartman
` (44 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, David S. Miller,
Andrey Konovalov
From: Arnd Bergmann <arnd@arndb.de>
commit ce6289661b14a8b391d90db918c91b6d6da6540a upstream.
When CONFIG_KASAN is set, we can use relatively large amounts of kernel
stack space:
net/caif/cfctrl.c:555:1: warning: the frame size of 1600 bytes is larger than 1280 bytes [-Wframe-larger-than=]
This adds convenience wrappers around cfpkt_extr_head(), which is responsible
for most of the stack growth. With those wrapper functions, gcc apparently
starts reusing the stack slots for each instance, thus avoiding the
problem.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/net/caif/cfpkt.h | 27 +++++++++++++++++++++++++
net/caif/cfctrl.c | 50 ++++++++++++++++++++---------------------------
2 files changed, 49 insertions(+), 28 deletions(-)
--- a/include/net/caif/cfpkt.h
+++ b/include/net/caif/cfpkt.h
@@ -32,6 +32,33 @@ void cfpkt_destroy(struct cfpkt *pkt);
*/
int cfpkt_extr_head(struct cfpkt *pkt, void *data, u16 len);
+static inline u8 cfpkt_extr_head_u8(struct cfpkt *pkt)
+{
+ u8 tmp;
+
+ cfpkt_extr_head(pkt, &tmp, 1);
+
+ return tmp;
+}
+
+static inline u16 cfpkt_extr_head_u16(struct cfpkt *pkt)
+{
+ __le16 tmp;
+
+ cfpkt_extr_head(pkt, &tmp, 2);
+
+ return le16_to_cpu(tmp);
+}
+
+static inline u32 cfpkt_extr_head_u32(struct cfpkt *pkt)
+{
+ __le32 tmp;
+
+ cfpkt_extr_head(pkt, &tmp, 4);
+
+ return le32_to_cpu(tmp);
+}
+
/*
* Peek header from packet.
* Reads data from packet without changing packet.
--- a/net/caif/cfctrl.c
+++ b/net/caif/cfctrl.c
@@ -352,15 +352,14 @@ static int cfctrl_recv(struct cflayer *l
u8 cmdrsp;
u8 cmd;
int ret = -1;
- u16 tmp16;
u8 len;
u8 param[255];
- u8 linkid;
+ u8 linkid = 0;
struct cfctrl *cfctrl = container_obj(layer);
struct cfctrl_request_info rsp, *req;
- cfpkt_extr_head(pkt, &cmdrsp, 1);
+ cmdrsp = cfpkt_extr_head_u8(pkt);
cmd = cmdrsp & CFCTRL_CMD_MASK;
if (cmd != CFCTRL_CMD_LINK_ERR
&& CFCTRL_RSP_BIT != (CFCTRL_RSP_BIT & cmdrsp)
@@ -378,13 +377,12 @@ static int cfctrl_recv(struct cflayer *l
u8 physlinkid;
u8 prio;
u8 tmp;
- u32 tmp32;
u8 *cp;
int i;
struct cfctrl_link_param linkparam;
memset(&linkparam, 0, sizeof(linkparam));
- cfpkt_extr_head(pkt, &tmp, 1);
+ tmp = cfpkt_extr_head_u8(pkt);
serv = tmp & CFCTRL_SRV_MASK;
linkparam.linktype = serv;
@@ -392,13 +390,13 @@ static int cfctrl_recv(struct cflayer *l
servtype = tmp >> 4;
linkparam.chtype = servtype;
- cfpkt_extr_head(pkt, &tmp, 1);
+ tmp = cfpkt_extr_head_u8(pkt);
physlinkid = tmp & 0x07;
prio = tmp >> 3;
linkparam.priority = prio;
linkparam.phyid = physlinkid;
- cfpkt_extr_head(pkt, &endpoint, 1);
+ endpoint = cfpkt_extr_head_u8(pkt);
linkparam.endpoint = endpoint & 0x03;
switch (serv) {
@@ -407,45 +405,43 @@ static int cfctrl_recv(struct cflayer *l
if (CFCTRL_ERR_BIT & cmdrsp)
break;
/* Link ID */
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
break;
case CFCTRL_SRV_VIDEO:
- cfpkt_extr_head(pkt, &tmp, 1);
+ tmp = cfpkt_extr_head_u8(pkt);
linkparam.u.video.connid = tmp;
if (CFCTRL_ERR_BIT & cmdrsp)
break;
/* Link ID */
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
break;
case CFCTRL_SRV_DATAGRAM:
- cfpkt_extr_head(pkt, &tmp32, 4);
linkparam.u.datagram.connid =
- le32_to_cpu(tmp32);
+ cfpkt_extr_head_u32(pkt);
if (CFCTRL_ERR_BIT & cmdrsp)
break;
/* Link ID */
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
break;
case CFCTRL_SRV_RFM:
/* Construct a frame, convert
* DatagramConnectionID
* to network format long and copy it out...
*/
- cfpkt_extr_head(pkt, &tmp32, 4);
linkparam.u.rfm.connid =
- le32_to_cpu(tmp32);
+ cfpkt_extr_head_u32(pkt);
cp = (u8 *) linkparam.u.rfm.volume;
- for (cfpkt_extr_head(pkt, &tmp, 1);
+ for (tmp = cfpkt_extr_head_u8(pkt);
cfpkt_more(pkt) && tmp != '\0';
- cfpkt_extr_head(pkt, &tmp, 1))
+ tmp = cfpkt_extr_head_u8(pkt))
*cp++ = tmp;
*cp = '\0';
if (CFCTRL_ERR_BIT & cmdrsp)
break;
/* Link ID */
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
break;
case CFCTRL_SRV_UTIL:
@@ -454,13 +450,11 @@ static int cfctrl_recv(struct cflayer *l
* to network format long and copy it out...
*/
/* Fifosize KB */
- cfpkt_extr_head(pkt, &tmp16, 2);
linkparam.u.utility.fifosize_kb =
- le16_to_cpu(tmp16);
+ cfpkt_extr_head_u16(pkt);
/* Fifosize bufs */
- cfpkt_extr_head(pkt, &tmp16, 2);
linkparam.u.utility.fifosize_bufs =
- le16_to_cpu(tmp16);
+ cfpkt_extr_head_u16(pkt);
/* name */
cp = (u8 *) linkparam.u.utility.name;
caif_assert(sizeof(linkparam.u.utility.name)
@@ -468,24 +462,24 @@ static int cfctrl_recv(struct cflayer *l
for (i = 0;
i < UTILITY_NAME_LENGTH
&& cfpkt_more(pkt); i++) {
- cfpkt_extr_head(pkt, &tmp, 1);
+ tmp = cfpkt_extr_head_u8(pkt);
*cp++ = tmp;
}
/* Length */
- cfpkt_extr_head(pkt, &len, 1);
+ len = cfpkt_extr_head_u8(pkt);
linkparam.u.utility.paramlen = len;
/* Param Data */
cp = linkparam.u.utility.params;
while (cfpkt_more(pkt) && len--) {
- cfpkt_extr_head(pkt, &tmp, 1);
+ tmp = cfpkt_extr_head_u8(pkt);
*cp++ = tmp;
}
if (CFCTRL_ERR_BIT & cmdrsp)
break;
/* Link ID */
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
/* Length */
- cfpkt_extr_head(pkt, &len, 1);
+ len = cfpkt_extr_head_u8(pkt);
/* Param Data */
cfpkt_extr_head(pkt, ¶m, len);
break;
@@ -522,7 +516,7 @@ static int cfctrl_recv(struct cflayer *l
}
break;
case CFCTRL_CMD_LINK_DESTROY:
- cfpkt_extr_head(pkt, &linkid, 1);
+ linkid = cfpkt_extr_head_u8(pkt);
cfctrl->res.linkdestroy_rsp(cfctrl->serv.layer.up, linkid);
break;
case CFCTRL_CMD_LINK_ERR:
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 22/62] USB: yurex: Fix protection fault after device removal
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 21/62] caif: reduce stack size with KASAN Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 23/62] USB: w1 ds2490: Fix bug caused by improper use of altsetting array Greg Kroah-Hartman
` (43 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, syzbot+2eb9121678bdb36e6d57
From: Alan Stern <stern@rowland.harvard.edu>
commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream.
The syzkaller USB fuzzer found a general-protection-fault bug in the
yurex driver. The fault occurs when a device has been unplugged; the
driver's interrupt-URB handler logs an error message referring to the
device by name, after the device has been unregistered and its name
deallocated.
This problem is caused by the fact that the interrupt URB isn't
cancelled until the driver's private data structure is released, which
can happen long after the device is gone. The cure is to make sure
that the interrupt URB is killed before yurex_disconnect() returns;
this is exactly the sort of thing that usb_poison_urb() was meant for.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/misc/yurex.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -324,6 +324,7 @@ static void yurex_disconnect(struct usb_
usb_deregister_dev(interface, &yurex_class);
/* prevent more I/O from starting */
+ usb_poison_urb(dev->urb);
mutex_lock(&dev->io_mutex);
dev->interface = NULL;
mutex_unlock(&dev->io_mutex);
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 23/62] USB: w1 ds2490: Fix bug caused by improper use of altsetting array
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (21 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 22/62] USB: yurex: Fix protection fault after device removal Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 24/62] usb: usbip: fix isoc packet num validation in get_pipe Greg Kroah-Hartman
` (42 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, syzbot+d65f673b847a1a96cdba
From: Alan Stern <stern@rowland.harvard.edu>
commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream.
The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the
ds2490 driver. This bug is caused by improper use of the altsetting
array in the usb_interface structure (the array's entries are not
always stored in numerical order), combined with a naive assumption
that all interfaces probed by the driver will have the expected number
of altsettings.
The bug can be fixed by replacing references to the possibly
non-existent intf->altsetting[alt] entry with the guaranteed-to-exist
intf->cur_altsetting entry.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/w1/masters/ds2490.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/w1/masters/ds2490.c
+++ b/drivers/w1/masters/ds2490.c
@@ -1039,15 +1039,15 @@ static int ds_probe(struct usb_interface
/* alternative 3, 1ms interrupt (greatly speeds search), 64 byte bulk */
alt = 3;
err = usb_set_interface(dev->udev,
- intf->altsetting[alt].desc.bInterfaceNumber, alt);
+ intf->cur_altsetting->desc.bInterfaceNumber, alt);
if (err) {
dev_err(&dev->udev->dev, "Failed to set alternative setting %d "
"for %d interface: err=%d.\n", alt,
- intf->altsetting[alt].desc.bInterfaceNumber, err);
+ intf->cur_altsetting->desc.bInterfaceNumber, err);
goto err_out_clear;
}
- iface_desc = &intf->altsetting[alt];
+ iface_desc = intf->cur_altsetting;
if (iface_desc->desc.bNumEndpoints != NUM_EP-1) {
pr_info("Num endpoints=%d. It is not DS9490R.\n",
iface_desc->desc.bNumEndpoints);
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 24/62] usb: usbip: fix isoc packet num validation in get_pipe
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 23/62] USB: w1 ds2490: Fix bug caused by improper use of altsetting array Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 25/62] USB: core: Fix unterminated string returned by usb_string() Greg Kroah-Hartman
` (41 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Malte Leip, Shuah Khan
From: Malte Leip <malte@leip.net>
commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream.
Change the validation of number_of_packets in get_pipe to compare the
number of packets to a fixed maximum number of packets allowed, set to
be 1024. This number was chosen due to it being used by other drivers as
well, for example drivers/usb/host/uhci-q.c
Background/reason:
The get_pipe function in stub_rx.c validates the number of packets in
isochronous mode and aborts with an error if that number is too large,
in order to prevent malicious input from possibly triggering large
memory allocations. This was previously done by checking whether
pdu->u.cmd_submit.number_of_packets is bigger than the number of packets
that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes
if all except possibly the last packet had maximum length, given by
usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an
error if URBs with packets shorter than the maximum possible length are
submitted, which is allowed according to
Documentation/driver-api/usb/URB.rst and occurs for example with the
snd-usb-audio driver.
Fixes: c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input")
Signed-off-by: Malte Leip <malte@leip.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/usbip/stub_rx.c | 12 +++---------
drivers/usb/usbip/usbip_common.h | 7 +++++++
2 files changed, 10 insertions(+), 9 deletions(-)
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -383,16 +383,10 @@ static int get_pipe(struct stub_device *
}
if (usb_endpoint_xfer_isoc(epd)) {
- /* validate packet size and number of packets */
- unsigned int maxp, packets, bytes;
-
- maxp = usb_endpoint_maxp(epd);
- maxp *= usb_endpoint_maxp_mult(epd);
- bytes = pdu->u.cmd_submit.transfer_buffer_length;
- packets = DIV_ROUND_UP(bytes, maxp);
-
+ /* validate number of packets */
if (pdu->u.cmd_submit.number_of_packets < 0 ||
- pdu->u.cmd_submit.number_of_packets > packets) {
+ pdu->u.cmd_submit.number_of_packets >
+ USBIP_MAX_ISO_PACKETS) {
dev_err(&sdev->udev->dev,
"CMD_SUBMIT: isoc invalid num packets %d\n",
pdu->u.cmd_submit.number_of_packets);
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -136,6 +136,13 @@ extern struct device_attribute dev_attr_
#define USBIP_DIR_OUT 0x00
#define USBIP_DIR_IN 0x01
+/*
+ * Arbitrary limit for the maximum number of isochronous packets in an URB,
+ * compare for example the uhci_submit_isochronous function in
+ * drivers/usb/host/uhci-q.c
+ */
+#define USBIP_MAX_ISO_PACKETS 1024
+
/**
* struct usbip_header_basic - data pertinent to every request
* @command: the usbip request type
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 25/62] USB: core: Fix unterminated string returned by usb_string()
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 24/62] usb: usbip: fix isoc packet num validation in get_pipe Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 26/62] USB: core: Fix bug caused by duplicate interface PM usage counter Greg Kroah-Hartman
` (40 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, syzbot+b75b85111c10b8d680f1
From: Alan Stern <stern@rowland.harvard.edu>
commit c01c348ecdc66085e44912c97368809612231520 upstream.
Some drivers (such as the vub300 MMC driver) expect usb_string() to
return a properly NUL-terminated string, even when an error occurs.
(In fact, vub300's probe routine doesn't bother to check the return
code from usb_string().) When the driver goes on to use an
unterminated string, it leads to kernel errors such as
stack-out-of-bounds, as found by the syzkaller USB fuzzer.
An out-of-range string index argument is not at all unlikely, given
that some devices don't provide string descriptors and therefore list
0 as the value for their string indexes. This patch makes
usb_string() return a properly terminated empty string along with the
-EINVAL error code when an out-of-range index is encountered.
And since a USB string index is a single-byte value, indexes >= 256
are just as invalid as values of 0 or below.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/message.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -817,9 +817,11 @@ int usb_string(struct usb_device *dev, i
if (dev->state == USB_STATE_SUSPENDED)
return -EHOSTUNREACH;
- if (size <= 0 || !buf || !index)
+ if (size <= 0 || !buf)
return -EINVAL;
buf[0] = 0;
+ if (index <= 0 || index >= 256)
+ return -EINVAL;
tbuf = kmalloc(256, GFP_NOIO);
if (!tbuf)
return -ENOMEM;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 26/62] USB: core: Fix bug caused by duplicate interface PM usage counter
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 25/62] USB: core: Fix unterminated string returned by usb_string() Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 27/62] nvme-loop: init nvmet_ctrl fatal_err_work when allocate Greg Kroah-Hartman
` (39 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alan Stern, syzbot+7634edaea4d0b341c625
From: Alan Stern <stern@rowland.harvard.edu>
commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream.
The syzkaller fuzzer reported a bug in the USB hub driver which turned
out to be caused by a negative runtime-PM usage counter. This allowed
a hub to be runtime suspended at a time when the driver did not expect
it. The symptom is a WARNING issued because the hub's status URB is
submitted while it is already active:
URB 0000000031fb463e submitted while active
WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363
The negative runtime-PM usage count was caused by an unfortunate
design decision made when runtime PM was first implemented for USB.
At that time, USB class drivers were allowed to unbind from their
interfaces without balancing the usage counter (i.e., leaving it with
a positive count). The core code would take care of setting the
counter back to 0 before allowing another driver to bind to the
interface.
Later on when runtime PM was implemented for the entire kernel, the
opposite decision was made: Drivers were required to balance their
runtime-PM get and put calls. In order to maintain backward
compatibility, however, the USB subsystem adapted to the new
implementation by keeping an independent usage counter for each
interface and using it to automatically adjust the normal usage
counter back to 0 whenever a driver was unbound.
This approach involves duplicating information, but what is worse, it
doesn't work properly in cases where a USB class driver delays
decrementing the usage counter until after the driver's disconnect()
routine has returned and the counter has been adjusted back to 0.
Doing so would cause the usage counter to become negative. There's
even a warning about this in the USB power management documentation!
As it happens, this is exactly what the hub driver does. The
kick_hub_wq() routine increments the runtime-PM usage counter, and the
corresponding decrement is carried out by hub_event() in the context
of the hub_wq work-queue thread. This work routine may sometimes run
after the driver has been unbound from its interface, and when it does
it causes the usage counter to go negative.
It is not possible for hub_disconnect() to wait for a pending
hub_event() call to finish, because hub_disconnect() is called with
the device lock held and hub_event() acquires that lock. The only
feasible fix is to reverse the original design decision: remove the
duplicate interface-specific usage counter and require USB drivers to
balance their runtime PM gets and puts. As far as I know, all
existing drivers currently do this.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/usb/power-management.txt | 14 +++++++++-----
drivers/usb/core/driver.c | 13 -------------
drivers/usb/storage/realtek_cr.c | 13 +++++--------
include/linux/usb.h | 2 --
4 files changed, 14 insertions(+), 28 deletions(-)
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -365,11 +365,15 @@ autosuspend the interface's device. Whe
then the interface is considered to be idle, and the kernel may
autosuspend the device.
-Drivers need not be concerned about balancing changes to the usage
-counter; the USB core will undo any remaining "get"s when a driver
-is unbound from its interface. As a corollary, drivers must not call
-any of the usb_autopm_* functions after their disconnect() routine has
-returned.
+Drivers must be careful to balance their overall changes to the usage
+counter. Unbalanced "get"s will remain in effect when a driver is
+unbound from its interface, preventing the device from going into
+runtime suspend should the interface be bound to a driver again. On
+the other hand, drivers are allowed to achieve this balance by calling
+the ``usb_autopm_*`` functions even after their ``disconnect`` routine
+has returned -- say from within a work-queue routine -- provided they
+retain an active reference to the interface (via ``usb_get_intf`` and
+``usb_put_intf``).
Drivers using the async routines are responsible for their own
synchronization and mutual exclusion.
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -470,11 +470,6 @@ static int usb_unbind_interface(struct d
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
- /* Undo any residual pm_autopm_get_interface_* calls */
- for (r = atomic_read(&intf->pm_usage_cnt); r > 0; --r)
- usb_autopm_put_interface_no_suspend(intf);
- atomic_set(&intf->pm_usage_cnt, 0);
-
if (!error)
usb_autosuspend_device(udev);
@@ -1625,7 +1620,6 @@ void usb_autopm_put_interface(struct usb
int status;
usb_mark_last_busy(udev);
- atomic_dec(&intf->pm_usage_cnt);
status = pm_runtime_put_sync(&intf->dev);
dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
__func__, atomic_read(&intf->dev.power.usage_count),
@@ -1654,7 +1648,6 @@ void usb_autopm_put_interface_async(stru
int status;
usb_mark_last_busy(udev);
- atomic_dec(&intf->pm_usage_cnt);
status = pm_runtime_put(&intf->dev);
dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
__func__, atomic_read(&intf->dev.power.usage_count),
@@ -1676,7 +1669,6 @@ void usb_autopm_put_interface_no_suspend
struct usb_device *udev = interface_to_usbdev(intf);
usb_mark_last_busy(udev);
- atomic_dec(&intf->pm_usage_cnt);
pm_runtime_put_noidle(&intf->dev);
}
EXPORT_SYMBOL_GPL(usb_autopm_put_interface_no_suspend);
@@ -1707,8 +1699,6 @@ int usb_autopm_get_interface(struct usb_
status = pm_runtime_get_sync(&intf->dev);
if (status < 0)
pm_runtime_put_sync(&intf->dev);
- else
- atomic_inc(&intf->pm_usage_cnt);
dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
__func__, atomic_read(&intf->dev.power.usage_count),
status);
@@ -1742,8 +1732,6 @@ int usb_autopm_get_interface_async(struc
status = pm_runtime_get(&intf->dev);
if (status < 0 && status != -EINPROGRESS)
pm_runtime_put_noidle(&intf->dev);
- else
- atomic_inc(&intf->pm_usage_cnt);
dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
__func__, atomic_read(&intf->dev.power.usage_count),
status);
@@ -1767,7 +1755,6 @@ void usb_autopm_get_interface_no_resume(
struct usb_device *udev = interface_to_usbdev(intf);
usb_mark_last_busy(udev);
- atomic_inc(&intf->pm_usage_cnt);
pm_runtime_get_noresume(&intf->dev);
}
EXPORT_SYMBOL_GPL(usb_autopm_get_interface_no_resume);
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -776,18 +776,16 @@ static void rts51x_suspend_timer_fn(unsi
break;
case RTS51X_STAT_IDLE:
case RTS51X_STAT_SS:
- usb_stor_dbg(us, "RTS51X_STAT_SS, intf->pm_usage_cnt:%d, power.usage:%d\n",
- atomic_read(&us->pusb_intf->pm_usage_cnt),
+ usb_stor_dbg(us, "RTS51X_STAT_SS, power.usage:%d\n",
atomic_read(&us->pusb_intf->dev.power.usage_count));
- if (atomic_read(&us->pusb_intf->pm_usage_cnt) > 0) {
+ if (atomic_read(&us->pusb_intf->dev.power.usage_count) > 0) {
usb_stor_dbg(us, "Ready to enter SS state\n");
rts51x_set_stat(chip, RTS51X_STAT_SS);
/* ignore mass storage interface's children */
pm_suspend_ignore_children(&us->pusb_intf->dev, true);
usb_autopm_put_interface_async(us->pusb_intf);
- usb_stor_dbg(us, "RTS51X_STAT_SS 01, intf->pm_usage_cnt:%d, power.usage:%d\n",
- atomic_read(&us->pusb_intf->pm_usage_cnt),
+ usb_stor_dbg(us, "RTS51X_STAT_SS 01, power.usage:%d\n",
atomic_read(&us->pusb_intf->dev.power.usage_count));
}
break;
@@ -820,11 +818,10 @@ static void rts51x_invoke_transport(stru
int ret;
if (working_scsi(srb)) {
- usb_stor_dbg(us, "working scsi, intf->pm_usage_cnt:%d, power.usage:%d\n",
- atomic_read(&us->pusb_intf->pm_usage_cnt),
+ usb_stor_dbg(us, "working scsi, power.usage:%d\n",
atomic_read(&us->pusb_intf->dev.power.usage_count));
- if (atomic_read(&us->pusb_intf->pm_usage_cnt) <= 0) {
+ if (atomic_read(&us->pusb_intf->dev.power.usage_count) <= 0) {
ret = usb_autopm_get_interface(us->pusb_intf);
usb_stor_dbg(us, "working scsi, ret=%d\n", ret);
}
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -129,7 +129,6 @@ enum usb_interface_condition {
* @dev: driver model's view of this device
* @usb_dev: if an interface is bound to the USB major, this will point
* to the sysfs representation for that device.
- * @pm_usage_cnt: PM usage counter for this interface
* @reset_ws: Used for scheduling resets from atomic context.
* @resetting_device: USB core reset the device, so use alt setting 0 as
* current; needs bandwidth alloc after reset.
@@ -186,7 +185,6 @@ struct usb_interface {
struct device dev; /* interface specific device info */
struct device *usb_dev;
- atomic_t pm_usage_cnt; /* usage counter for autosuspend */
struct work_struct reset_ws; /* for resets in atomic context */
};
#define to_usb_interface(d) container_of(d, struct usb_interface, dev)
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 27/62] nvme-loop: init nvmet_ctrl fatal_err_work when allocate
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 26/62] USB: core: Fix bug caused by duplicate interface PM usage counter Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:32 ` [PATCH 4.9 28/62] HID: logitech: check the return value of create_singlethread_workqueue Greg Kroah-Hartman
` (38 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yufen Yu, Sagi Grimberg,
Bart Van Assche, Christoph Hellwig, Jens Axboe, Sasha Levin
[ Upstream commit d11de63f2b519f0a162b834013b6d3a46dbf3886 ]
After commit 4d43d395fe (workqueue: Try to catch flush_work() without
INIT_WORK()), it can cause warning when delete nvme-loop device, trace
like:
[ 76.601272] Call Trace:
[ 76.601646] ? del_timer+0x72/0xa0
[ 76.602156] __cancel_work_timer+0x1ae/0x270
[ 76.602791] cancel_work_sync+0x14/0x20
[ 76.603407] nvmet_ctrl_free+0x1b7/0x2f0 [nvmet]
[ 76.604091] ? free_percpu+0x168/0x300
[ 76.604652] nvmet_sq_destroy+0x106/0x240 [nvmet]
[ 76.605346] nvme_loop_destroy_admin_queue+0x30/0x60 [nvme_loop]
[ 76.606220] nvme_loop_shutdown_ctrl+0xc3/0xf0 [nvme_loop]
[ 76.607026] nvme_loop_delete_ctrl_host+0x19/0x30 [nvme_loop]
[ 76.607871] nvme_do_delete_ctrl+0x75/0xb0
[ 76.608477] nvme_sysfs_delete+0x7d/0xc0
[ 76.609057] dev_attr_store+0x24/0x40
[ 76.609603] sysfs_kf_write+0x4c/0x60
[ 76.610144] kernfs_fop_write+0x19a/0x260
[ 76.610742] __vfs_write+0x1c/0x60
[ 76.611246] vfs_write+0xfa/0x280
[ 76.611739] ksys_write+0x6e/0x120
[ 76.612238] __x64_sys_write+0x1e/0x30
[ 76.612787] do_syscall_64+0xbf/0x3a0
[ 76.613329] entry_SYSCALL_64_after_hwframe+0x44/0xa9
We fix it by moving fatal_err_work init to nvmet_alloc_ctrl(), which may
more reasonable.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/nvme/target/core.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c
index f12753eb3216..96ea6c76be6e 100644
--- a/drivers/nvme/target/core.c
+++ b/drivers/nvme/target/core.c
@@ -709,6 +709,15 @@ bool nvmet_host_allowed(struct nvmet_req *req, struct nvmet_subsys *subsys,
return __nvmet_host_allowed(subsys, hostnqn);
}
+static void nvmet_fatal_error_handler(struct work_struct *work)
+{
+ struct nvmet_ctrl *ctrl =
+ container_of(work, struct nvmet_ctrl, fatal_err_work);
+
+ pr_err("ctrl %d fatal error occurred!\n", ctrl->cntlid);
+ ctrl->ops->delete_ctrl(ctrl);
+}
+
u16 nvmet_alloc_ctrl(const char *subsysnqn, const char *hostnqn,
struct nvmet_req *req, u32 kato, struct nvmet_ctrl **ctrlp)
{
@@ -747,6 +756,7 @@ u16 nvmet_alloc_ctrl(const char *subsysnqn, const char *hostnqn,
INIT_WORK(&ctrl->async_event_work, nvmet_async_event_work);
INIT_LIST_HEAD(&ctrl->async_events);
+ INIT_WORK(&ctrl->fatal_err_work, nvmet_fatal_error_handler);
memcpy(ctrl->subsysnqn, subsysnqn, NVMF_NQN_SIZE);
memcpy(ctrl->hostnqn, hostnqn, NVMF_NQN_SIZE);
@@ -849,21 +859,11 @@ void nvmet_ctrl_put(struct nvmet_ctrl *ctrl)
kref_put(&ctrl->ref, nvmet_ctrl_free);
}
-static void nvmet_fatal_error_handler(struct work_struct *work)
-{
- struct nvmet_ctrl *ctrl =
- container_of(work, struct nvmet_ctrl, fatal_err_work);
-
- pr_err("ctrl %d fatal error occurred!\n", ctrl->cntlid);
- ctrl->ops->delete_ctrl(ctrl);
-}
-
void nvmet_ctrl_fatal_error(struct nvmet_ctrl *ctrl)
{
mutex_lock(&ctrl->lock);
if (!(ctrl->csts & NVME_CSTS_CFS)) {
ctrl->csts |= NVME_CSTS_CFS;
- INIT_WORK(&ctrl->fatal_err_work, nvmet_fatal_error_handler);
schedule_work(&ctrl->fatal_err_work);
}
mutex_unlock(&ctrl->lock);
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 28/62] HID: logitech: check the return value of create_singlethread_workqueue
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 27/62] nvme-loop: init nvmet_ctrl fatal_err_work when allocate Greg Kroah-Hartman
@ 2019-05-06 14:32 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 29/62] HID: debug: fix race condition with between rdesc_show() and device removal Greg Kroah-Hartman
` (37 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:32 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kangjie Lu, Jiri Kosina, Sasha Levin
[ Upstream commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2 ]
create_singlethread_workqueue may fail and return NULL. The fix checks if it is
NULL to avoid NULL pointer dereference. Also, the fix moves the call of
create_singlethread_workqueue earlier to avoid resource-release issues.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-logitech-hidpp.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2e2515a4c070..3198faf5cff4 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1282,6 +1282,13 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index)
kfree(data);
return -ENOMEM;
}
+ data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
+ if (!data->wq) {
+ kfree(data->effect_ids);
+ kfree(data);
+ return -ENOMEM;
+ }
+
data->hidpp = hidpp;
data->feature_index = feature_index;
data->version = version;
@@ -1326,7 +1333,6 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index)
/* ignore boost value at response.fap.params[2] */
/* init the hardware command queue */
- data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
atomic_set(&data->workqueue_size, 0);
/* initialize with zero autocenter to get wheel in usable state */
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 29/62] HID: debug: fix race condition with between rdesc_show() and device removal
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2019-05-06 14:32 ` [PATCH 4.9 28/62] HID: logitech: check the return value of create_singlethread_workqueue Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 30/62] rtc: sh: Fix invalid alarm warning for non-enabled alarm Greg Kroah-Hartman
` (36 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, he, bo, Zhang, Jun, Jiri Kosina, Sasha Levin
[ Upstream commit cef0d4948cb0a02db37ebfdc320e127c77ab1637 ]
There is a race condition that could happen if hid_debug_rdesc_show()
is running while hdev is in the process of going away (device removal,
system suspend, etc) which could result in NULL pointer dereference:
BUG: unable to handle kernel paging request at 0000000783316040
CPU: 1 PID: 1512 Comm: getevent Tainted: G U O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1
RIP: 0010:hid_dump_device+0x9b/0x160
Call Trace:
hid_debug_rdesc_show+0x72/0x1d0
seq_read+0xe0/0x410
full_proxy_read+0x5f/0x90
__vfs_read+0x3a/0x170
vfs_read+0xa0/0x150
ksys_read+0x58/0xc0
__x64_sys_read+0x1a/0x20
do_syscall_64+0x55/0x110
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Grab driver_input_lock to make sure the input device exists throughout the
whole process of dumping the rdesc.
[jkosina@suse.cz: update changelog a bit]
Signed-off-by: he, bo <bo.he@intel.com>
Signed-off-by: "Zhang, Jun" <jun.zhang@intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-debug.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index d7179dd3c9ef..3cafa1d28fed 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -1058,10 +1058,15 @@ static int hid_debug_rdesc_show(struct seq_file *f, void *p)
seq_printf(f, "\n\n");
/* dump parsed data and input mappings */
+ if (down_interruptible(&hdev->driver_input_lock))
+ return 0;
+
hid_dump_device(hdev, f);
seq_printf(f, "\n");
hid_dump_input_mapping(hdev, f);
+ up(&hdev->driver_input_lock);
+
return 0;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 30/62] rtc: sh: Fix invalid alarm warning for non-enabled alarm
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 29/62] HID: debug: fix race condition with between rdesc_show() and device removal Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 31/62] batman-adv: Reduce claim hash refcnt only for removed entry Greg Kroah-Hartman
` (35 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Geert Uytterhoeven,
Alexandre Belloni, Sasha Levin
[ Upstream commit 15d82d22498784966df8e4696174a16b02cc1052 ]
When no alarm has been programmed on RSK-RZA1, an error message is
printed during boot:
rtc rtc0: invalid alarm value: 2019-03-14T255:255:255
sh_rtc_read_alarm_value() returns 0xff when querying a hardware alarm
field that is not enabled. __rtc_read_alarm() validates the received
alarm values, and fills in missing fields when needed.
While 0xff is handled fine for the year, month, and day fields, and
corrected as considered being out-of-range, this is not the case for the
hour, minute, and second fields, where -1 is expected for missing
fields.
Fix this by returning -1 instead, as this value is handled fine for all
fields.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/rtc-sh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-sh.c b/drivers/rtc/rtc-sh.c
index 17b6235d67a5..600fb7f93939 100644
--- a/drivers/rtc/rtc-sh.c
+++ b/drivers/rtc/rtc-sh.c
@@ -454,7 +454,7 @@ static int sh_rtc_set_time(struct device *dev, struct rtc_time *tm)
static inline int sh_rtc_read_alarm_value(struct sh_rtc *rtc, int reg_off)
{
unsigned int byte;
- int value = 0xff; /* return 0xff for ignored values */
+ int value = -1; /* return -1 for ignored values */
byte = readb(rtc->regbase + reg_off);
if (byte & AR_ENB) {
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 31/62] batman-adv: Reduce claim hash refcnt only for removed entry
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 30/62] rtc: sh: Fix invalid alarm warning for non-enabled alarm Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 32/62] batman-adv: Reduce tt_local " Greg Kroah-Hartman
` (34 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sven Eckelmann, Simon Wunderlich,
Sasha Levin
[ Upstream commit 4ba104f468bbfc27362c393815d03aa18fb7a20f ]
The batadv_hash_remove is a function which searches the hashtable for an
entry using a needle, a hashtable bucket selection function and a compare
function. It will lock the bucket list and delete an entry when the compare
function matches it with the needle. It returns the pointer to the
hlist_node which matches or NULL when no entry matches the needle.
The batadv_bla_del_claim is not itself protected in anyway to avoid that
any other function is modifying the hashtable between the search for the
entry and the call to batadv_hash_remove. It can therefore happen that the
entry either doesn't exist anymore or an entry was deleted which is not the
same object as the needle. In such an situation, the reference counter (for
the reference stored in the hashtable) must not be reduced for the needle.
Instead the reference counter of the actually removed entry has to be
reduced.
Otherwise the reference counter will underflow and the object might be
freed before all its references were dropped. The kref helpers reported
this problem as:
refcount_t: underflow; use-after-free.
Fixes: 23721387c409 ("batman-adv: add basic bridge loop avoidance code")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/batman-adv/bridge_loop_avoidance.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 8b6f654bc85d..00123064eb26 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -802,6 +802,8 @@ static void batadv_bla_del_claim(struct batadv_priv *bat_priv,
const u8 *mac, const unsigned short vid)
{
struct batadv_bla_claim search_claim, *claim;
+ struct batadv_bla_claim *claim_removed_entry;
+ struct hlist_node *claim_removed_node;
ether_addr_copy(search_claim.addr, mac);
search_claim.vid = vid;
@@ -812,10 +814,18 @@ static void batadv_bla_del_claim(struct batadv_priv *bat_priv,
batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_del_claim(): %pM, vid %d\n",
mac, BATADV_PRINT_VID(vid));
- batadv_hash_remove(bat_priv->bla.claim_hash, batadv_compare_claim,
- batadv_choose_claim, claim);
- batadv_claim_put(claim); /* reference from the hash is gone */
+ claim_removed_node = batadv_hash_remove(bat_priv->bla.claim_hash,
+ batadv_compare_claim,
+ batadv_choose_claim, claim);
+ if (!claim_removed_node)
+ goto free_claim;
+ /* reference from the hash is gone */
+ claim_removed_entry = hlist_entry(claim_removed_node,
+ struct batadv_bla_claim, hash_entry);
+ batadv_claim_put(claim_removed_entry);
+
+free_claim:
/* don't need the reference from hash_find() anymore */
batadv_claim_put(claim);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 32/62] batman-adv: Reduce tt_local hash refcnt only for removed entry
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 31/62] batman-adv: Reduce claim hash refcnt only for removed entry Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 33/62] batman-adv: Reduce tt_global " Greg Kroah-Hartman
` (33 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sven Eckelmann, Simon Wunderlich,
Sasha Levin
[ Upstream commit 3d65b9accab4a7ed5038f6df403fbd5e298398c7 ]
The batadv_hash_remove is a function which searches the hashtable for an
entry using a needle, a hashtable bucket selection function and a compare
function. It will lock the bucket list and delete an entry when the compare
function matches it with the needle. It returns the pointer to the
hlist_node which matches or NULL when no entry matches the needle.
The batadv_tt_local_remove is not itself protected in anyway to avoid that
any other function is modifying the hashtable between the search for the
entry and the call to batadv_hash_remove. It can therefore happen that the
entry either doesn't exist anymore or an entry was deleted which is not the
same object as the needle. In such an situation, the reference counter (for
the reference stored in the hashtable) must not be reduced for the needle.
Instead the reference counter of the actually removed entry has to be
reduced.
Otherwise the reference counter will underflow and the object might be
freed before all its references were dropped. The kref helpers reported
this problem as:
refcount_t: underflow; use-after-free.
Fixes: ef72706a0543 ("batman-adv: protect tt_local_entry from concurrent delete events")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/batman-adv/translation-table.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index b9f9a310eb78..4f18fcd2d3c0 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -1308,9 +1308,10 @@ u16 batadv_tt_local_remove(struct batadv_priv *bat_priv, const u8 *addr,
unsigned short vid, const char *message,
bool roaming)
{
+ struct batadv_tt_local_entry *tt_removed_entry;
struct batadv_tt_local_entry *tt_local_entry;
u16 flags, curr_flags = BATADV_NO_FLAGS;
- void *tt_entry_exists;
+ struct hlist_node *tt_removed_node;
tt_local_entry = batadv_tt_local_hash_find(bat_priv, addr, vid);
if (!tt_local_entry)
@@ -1339,15 +1340,18 @@ u16 batadv_tt_local_remove(struct batadv_priv *bat_priv, const u8 *addr,
*/
batadv_tt_local_event(bat_priv, tt_local_entry, BATADV_TT_CLIENT_DEL);
- tt_entry_exists = batadv_hash_remove(bat_priv->tt.local_hash,
+ tt_removed_node = batadv_hash_remove(bat_priv->tt.local_hash,
batadv_compare_tt,
batadv_choose_tt,
&tt_local_entry->common);
- if (!tt_entry_exists)
+ if (!tt_removed_node)
goto out;
- /* extra call to free the local tt entry */
- batadv_tt_local_entry_put(tt_local_entry);
+ /* drop reference of remove hash entry */
+ tt_removed_entry = hlist_entry(tt_removed_node,
+ struct batadv_tt_local_entry,
+ common.hash_entry);
+ batadv_tt_local_entry_put(tt_removed_entry);
out:
if (tt_local_entry)
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 33/62] batman-adv: Reduce tt_global hash refcnt only for removed entry
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 32/62] batman-adv: Reduce tt_local " Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 34/62] igb: Fix WARN_ONCE on runtime suspend Greg Kroah-Hartman
` (32 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Martin Weinelt, Sven Eckelmann,
Antonio Quartulli, Simon Wunderlich, Sasha Levin
[ Upstream commit f131a56880d10932931e74773fb8702894a94a75 ]
The batadv_hash_remove is a function which searches the hashtable for an
entry using a needle, a hashtable bucket selection function and a compare
function. It will lock the bucket list and delete an entry when the compare
function matches it with the needle. It returns the pointer to the
hlist_node which matches or NULL when no entry matches the needle.
The batadv_tt_global_free is not itself protected in anyway to avoid that
any other function is modifying the hashtable between the search for the
entry and the call to batadv_hash_remove. It can therefore happen that the
entry either doesn't exist anymore or an entry was deleted which is not the
same object as the needle. In such an situation, the reference counter (for
the reference stored in the hashtable) must not be reduced for the needle.
Instead the reference counter of the actually removed entry has to be
reduced.
Otherwise the reference counter will underflow and the object might be
freed before all its references were dropped. The kref helpers reported
this problem as:
refcount_t: underflow; use-after-free.
Fixes: 7683fdc1e886 ("batman-adv: protect the local and the global trans-tables with rcu")
Reported-by: Martin Weinelt <martin@linuxlounge.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: Antonio Quartulli <a@unstable.cc>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/batman-adv/translation-table.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/net/batman-adv/translation-table.c b/net/batman-adv/translation-table.c
index 4f18fcd2d3c0..af4a02ad8503 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -615,14 +615,26 @@ static void batadv_tt_global_free(struct batadv_priv *bat_priv,
struct batadv_tt_global_entry *tt_global,
const char *message)
{
+ struct batadv_tt_global_entry *tt_removed_entry;
+ struct hlist_node *tt_removed_node;
+
batadv_dbg(BATADV_DBG_TT, bat_priv,
"Deleting global tt entry %pM (vid: %d): %s\n",
tt_global->common.addr,
BATADV_PRINT_VID(tt_global->common.vid), message);
- batadv_hash_remove(bat_priv->tt.global_hash, batadv_compare_tt,
- batadv_choose_tt, &tt_global->common);
- batadv_tt_global_entry_put(tt_global);
+ tt_removed_node = batadv_hash_remove(bat_priv->tt.global_hash,
+ batadv_compare_tt,
+ batadv_choose_tt,
+ &tt_global->common);
+ if (!tt_removed_node)
+ return;
+
+ /* drop reference of remove hash entry */
+ tt_removed_entry = hlist_entry(tt_removed_node,
+ struct batadv_tt_global_entry,
+ common.hash_entry);
+ batadv_tt_global_entry_put(tt_removed_entry);
}
/**
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 34/62] igb: Fix WARN_ONCE on runtime suspend
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 33/62] batman-adv: Reduce tt_global " Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 35/62] net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands Greg Kroah-Hartman
` (31 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arvind Sankar, Kai-Heng Feng,
Aaron Brown, Jeff Kirsher, Sasha Levin
[ Upstream commit dabb8338be533c18f50255cf39ff4f66d4dabdbe ]
The runtime_suspend device callbacks are not supposed to save
configuration state or change the power state. Commit fb29f76cc566
("igb: Fix an issue that PME is not enabled during runtime suspend")
changed the driver to not save configuration state during runtime
suspend, however the driver callback still put the device into a
low-power state. This causes a warning in the pci pm core and results in
pci_pm_runtime_suspend not calling pci_save_state or pci_finish_runtime_suspend.
Fix this by not changing the power state either, leaving that to pci pm
core, and make the same change for suspend callback as well.
Also move a couple of defines into the appropriate header file instead
of inline in the .c file.
Fixes: fb29f76cc566 ("igb: Fix an issue that PME is not enabled during runtime suspend")
Signed-off-by: Arvind Sankar <niveditas98@gmail.com>
Reviewed-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/intel/igb/e1000_defines.h | 2 +
drivers/net/ethernet/intel/igb/igb_main.c | 57 +++----------------
2 files changed, 10 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index 2688180a7acd..f948eec7b35f 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -193,6 +193,8 @@
/* enable link status from external LINK_0 and LINK_1 pins */
#define E1000_CTRL_SWDPIN0 0x00040000 /* SWDPIN 0 value */
#define E1000_CTRL_SWDPIN1 0x00080000 /* SWDPIN 1 value */
+#define E1000_CTRL_ADVD3WUC 0x00100000 /* D3 WUC */
+#define E1000_CTRL_EN_PHY_PWR_MGMT 0x00200000 /* PHY PM enable */
#define E1000_CTRL_SDP0_DIR 0x00400000 /* SDP0 Data direction */
#define E1000_CTRL_SDP1_DIR 0x00800000 /* SDP1 Data direction */
#define E1000_CTRL_RST 0x04000000 /* Global reset */
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 82e48e355fb9..7956176c2c73 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -7548,9 +7548,7 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
struct e1000_hw *hw = &adapter->hw;
u32 ctrl, rctl, status;
u32 wufc = runtime ? E1000_WUFC_LNKC : adapter->wol;
-#ifdef CONFIG_PM
- int retval = 0;
-#endif
+ bool wake;
rtnl_lock();
netif_device_detach(netdev);
@@ -7563,14 +7561,6 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
igb_clear_interrupt_scheme(adapter);
rtnl_unlock();
-#ifdef CONFIG_PM
- if (!runtime) {
- retval = pci_save_state(pdev);
- if (retval)
- return retval;
- }
-#endif
-
status = rd32(E1000_STATUS);
if (status & E1000_STATUS_LU)
wufc &= ~E1000_WUFC_LNKC;
@@ -7587,10 +7577,6 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
}
ctrl = rd32(E1000_CTRL);
- /* advertise wake from D3Cold */
- #define E1000_CTRL_ADVD3WUC 0x00100000
- /* phy power management enable */
- #define E1000_CTRL_EN_PHY_PWR_MGMT 0x00200000
ctrl |= E1000_CTRL_ADVD3WUC;
wr32(E1000_CTRL, ctrl);
@@ -7604,12 +7590,15 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
wr32(E1000_WUFC, 0);
}
- *enable_wake = wufc || adapter->en_mng_pt;
- if (!*enable_wake)
+ wake = wufc || adapter->en_mng_pt;
+ if (!wake)
igb_power_down_link(adapter);
else
igb_power_up_link(adapter);
+ if (enable_wake)
+ *enable_wake = wake;
+
/* Release control of h/w to f/w. If f/w is AMT enabled, this
* would have already happened in close and is redundant.
*/
@@ -7624,22 +7613,7 @@ static int __igb_shutdown(struct pci_dev *pdev, bool *enable_wake,
#ifdef CONFIG_PM_SLEEP
static int igb_suspend(struct device *dev)
{
- int retval;
- bool wake;
- struct pci_dev *pdev = to_pci_dev(dev);
-
- retval = __igb_shutdown(pdev, &wake, 0);
- if (retval)
- return retval;
-
- if (wake) {
- pci_prepare_to_sleep(pdev);
- } else {
- pci_wake_from_d3(pdev, false);
- pci_set_power_state(pdev, PCI_D3hot);
- }
-
- return 0;
+ return __igb_shutdown(to_pci_dev(dev), NULL, 0);
}
#endif /* CONFIG_PM_SLEEP */
@@ -7707,22 +7681,7 @@ static int igb_runtime_idle(struct device *dev)
static int igb_runtime_suspend(struct device *dev)
{
- struct pci_dev *pdev = to_pci_dev(dev);
- int retval;
- bool wake;
-
- retval = __igb_shutdown(pdev, &wake, 1);
- if (retval)
- return retval;
-
- if (wake) {
- pci_prepare_to_sleep(pdev);
- } else {
- pci_wake_from_d3(pdev, false);
- pci_set_power_state(pdev, PCI_D3hot);
- }
-
- return 0;
+ return __igb_shutdown(to_pci_dev(dev), NULL, 1);
}
static int igb_runtime_resume(struct device *dev)
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 35/62] net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 34/62] igb: Fix WARN_ONCE on runtime suspend Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 36/62] bonding: show full hw address in sysfs for slave entries Greg Kroah-Hartman
` (30 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Omri Kahalon, Max Gurtovoy,
Saeed Mahameed, Sasha Levin
[ Upstream commit eca4a928585ac08147e5cc8e2111ecbc6279ee31 ]
Traditionally, the PF (Physical Function) which resides on vport 0 was
the E-switch manager. Since the ECPF (Embedded CPU Physical Function),
which resides on vport 0xfffe, was introduced as the E-Switch manager,
the assumption that the E-switch manager is on vport 0 is incorrect.
Since the eswitch code already uses the actual vport value, all we
need is to always set other_vport=1.
Signed-off-by: Omri Kahalon <omrik@mellanox.com>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
index da9246f6c31e..d1a3a35ba87b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
@@ -92,8 +92,7 @@ static int arm_vport_context_events_cmd(struct mlx5_core_dev *dev, u16 vport,
opcode, MLX5_CMD_OP_MODIFY_NIC_VPORT_CONTEXT);
MLX5_SET(modify_nic_vport_context_in, in, field_select.change_event, 1);
MLX5_SET(modify_nic_vport_context_in, in, vport_number, vport);
- if (vport)
- MLX5_SET(modify_nic_vport_context_in, in, other_vport, 1);
+ MLX5_SET(modify_nic_vport_context_in, in, other_vport, 1);
nic_vport_ctx = MLX5_ADDR_OF(modify_nic_vport_context_in,
in, nic_vport_context);
@@ -121,8 +120,7 @@ static int modify_esw_vport_context_cmd(struct mlx5_core_dev *dev, u16 vport,
MLX5_SET(modify_esw_vport_context_in, in, opcode,
MLX5_CMD_OP_MODIFY_ESW_VPORT_CONTEXT);
MLX5_SET(modify_esw_vport_context_in, in, vport_number, vport);
- if (vport)
- MLX5_SET(modify_esw_vport_context_in, in, other_vport, 1);
+ MLX5_SET(modify_esw_vport_context_in, in, other_vport, 1);
return mlx5_cmd_exec(dev, in, inlen, out, sizeof(out));
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 36/62] bonding: show full hw address in sysfs for slave entries
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 35/62] net/mlx5: E-Switch, Fix esw manager vport indication for more vport commands Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 37/62] net: stmmac: dont overwrite discard_frame status Greg Kroah-Hartman
` (29 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Konstantin Khorenko, David S. Miller,
Sasha Levin
[ Upstream commit 18bebc6dd3281955240062655a4df35eef2c46b3 ]
Bond expects ethernet hwaddr for its slave, but it can be longer than 6
bytes - infiniband interface for example.
# cat /sys/devices/<skipped>/net/ib0/address
80:00:02:08:fe:80:00:00:00:00:00:00:7c:fe:90:03:00:be:5d:e1
# cat /sys/devices/<skipped>/net/ib0/bonding_slave/perm_hwaddr
80:00:02:08:fe:80
So print full hwaddr in sysfs "bonding_slave/perm_hwaddr" as well.
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/bonding/bond_sysfs_slave.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_sysfs_slave.c b/drivers/net/bonding/bond_sysfs_slave.c
index 7d16c51e6913..641a532b67cb 100644
--- a/drivers/net/bonding/bond_sysfs_slave.c
+++ b/drivers/net/bonding/bond_sysfs_slave.c
@@ -55,7 +55,9 @@ static SLAVE_ATTR_RO(link_failure_count);
static ssize_t perm_hwaddr_show(struct slave *slave, char *buf)
{
- return sprintf(buf, "%pM\n", slave->perm_hwaddr);
+ return sprintf(buf, "%*phC\n",
+ slave->dev->addr_len,
+ slave->perm_hwaddr);
}
static SLAVE_ATTR_RO(perm_hwaddr);
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 37/62] net: stmmac: dont overwrite discard_frame status
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 36/62] bonding: show full hw address in sysfs for slave entries Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 38/62] net: stmmac: fix dropping of multi-descriptor RX frames Greg Kroah-Hartman
` (28 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaro Koskinen, David S. Miller, Sasha Levin
[ Upstream commit 1b746ce8b397e58f9e40ce5c63b7198de6930482 ]
If we have error bits set, the discard_frame status will get overwritten
by checksum bit checks, which might set the status back to good one.
Fix by checking the COE status only if the frame is good.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index ce97e522566a..2c40cafa2619 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -235,9 +235,10 @@ static int enh_desc_get_rx_status(void *data, struct stmmac_extra_stats *x,
* It doesn't match with the information reported into the databook.
* At any rate, we need to understand if the CSUM hw computation is ok
* and report this info to the upper layers. */
- ret = enh_desc_coe_rdes0(!!(rdes0 & RDES0_IPC_CSUM_ERROR),
- !!(rdes0 & RDES0_FRAME_TYPE),
- !!(rdes0 & ERDES0_RX_MAC_ADDR));
+ if (likely(ret == good_frame))
+ ret = enh_desc_coe_rdes0(!!(rdes0 & RDES0_IPC_CSUM_ERROR),
+ !!(rdes0 & RDES0_FRAME_TYPE),
+ !!(rdes0 & ERDES0_RX_MAC_ADDR));
if (unlikely(rdes0 & RDES0_DRIBBLING))
x->dribbling_bit++;
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 38/62] net: stmmac: fix dropping of multi-descriptor RX frames
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 37/62] net: stmmac: dont overwrite discard_frame status Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 39/62] net: stmmac: dont log oversized frames Greg Kroah-Hartman
` (27 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaro Koskinen, David S. Miller, Sasha Levin
[ Upstream commit 8ac0c24fe1c256af6644caf3d311029440ec2fbd ]
Packets without the last descriptor set should be dropped early. If we
receive a frame larger than the DMA buffer, the HW will continue using the
next descriptor. Driver mistakes these as individual frames, and sometimes
a truncated frame (without the LD set) may look like a valid packet.
This fixes a strange issue where the system replies to 4098-byte ping
although the MTU/DMA buffer size is set to 4096, and yet at the same
time it's logging an oversized packet.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
index 2c40cafa2619..77dc5842bd0b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -205,6 +205,11 @@ static int enh_desc_get_rx_status(void *data, struct stmmac_extra_stats *x,
if (unlikely(rdes0 & RDES0_OWN))
return dma_own;
+ if (unlikely(!(rdes0 & RDES0_LAST_DESCRIPTOR))) {
+ stats->rx_length_errors++;
+ return discard_frame;
+ }
+
if (unlikely(rdes0 & RDES0_ERROR_SUMMARY)) {
if (unlikely(rdes0 & RDES0_DESCRIPTOR_ERROR)) {
x->rx_desc++;
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 39/62] net: stmmac: dont log oversized frames
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 38/62] net: stmmac: fix dropping of multi-descriptor RX frames Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 40/62] jffs2: fix use-after-free on symlink traversal Greg Kroah-Hartman
` (26 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Aaro Koskinen, David S. Miller, Sasha Levin
[ Upstream commit 057a0c5642a2ff2db7c421cdcde34294a23bf37b ]
This is log is harmful as it can trigger multiple times per packet. Delete
it.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
index fd78406e2e9a..01f8f2e94c0f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -95,8 +95,6 @@ static int ndesc_get_rx_status(void *data, struct stmmac_extra_stats *x,
return dma_own;
if (unlikely(!(rdes0 & RDES0_LAST_DESCRIPTOR))) {
- pr_warn("%s: Oversized frame spanned multiple buffers\n",
- __func__);
stats->rx_length_errors++;
return discard_frame;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 40/62] jffs2: fix use-after-free on symlink traversal
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 39/62] net: stmmac: dont log oversized frames Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 41/62] debugfs: " Greg Kroah-Hartman
` (25 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro, Sasha Levin
[ Upstream commit 4fdcfab5b5537c21891e22e65996d4d0dd8ab4ca ]
free the symlink body after the same RCU delay we have for freeing the
struct inode itself, so that traversal during RCU pathwalk wouldn't step
into freed memory.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/jffs2/readinode.c | 5 -----
fs/jffs2/super.c | 5 ++++-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/jffs2/readinode.c b/fs/jffs2/readinode.c
index 06a71dbd4833..2f236cca6095 100644
--- a/fs/jffs2/readinode.c
+++ b/fs/jffs2/readinode.c
@@ -1414,11 +1414,6 @@ void jffs2_do_clear_inode(struct jffs2_sb_info *c, struct jffs2_inode_info *f)
jffs2_kill_fragtree(&f->fragtree, deleted?c:NULL);
- if (f->target) {
- kfree(f->target);
- f->target = NULL;
- }
-
fds = f->dents;
while(fds) {
fd = fds;
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 226640563df3..76aedbc97773 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -47,7 +47,10 @@ static struct inode *jffs2_alloc_inode(struct super_block *sb)
static void jffs2_i_callback(struct rcu_head *head)
{
struct inode *inode = container_of(head, struct inode, i_rcu);
- kmem_cache_free(jffs2_inode_cachep, JFFS2_INODE_INFO(inode));
+ struct jffs2_inode_info *f = JFFS2_INODE_INFO(inode);
+
+ kfree(f->target);
+ kmem_cache_free(jffs2_inode_cachep, f);
}
static void jffs2_destroy_inode(struct inode *inode)
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 41/62] debugfs: fix use-after-free on symlink traversal
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 40/62] jffs2: fix use-after-free on symlink traversal Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 42/62] rtc: da9063: set uie_unsupported when relevant Greg Kroah-Hartman
` (24 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Al Viro, Sasha Levin
[ Upstream commit 93b919da64c15b90953f96a536e5e61df896ca57 ]
symlink body shouldn't be freed without an RCU delay. Switch debugfs to
->destroy_inode() and use of call_rcu(); free both the inode and symlink
body in the callback. Similar to solution for bpf, only here it's even
more obvious that ->evict_inode() can be dropped.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/debugfs/inode.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 77e9cd7a0137..20ee612017bf 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -170,19 +170,24 @@ static int debugfs_show_options(struct seq_file *m, struct dentry *root)
return 0;
}
-static void debugfs_evict_inode(struct inode *inode)
+static void debugfs_i_callback(struct rcu_head *head)
{
- truncate_inode_pages_final(&inode->i_data);
- clear_inode(inode);
+ struct inode *inode = container_of(head, struct inode, i_rcu);
if (S_ISLNK(inode->i_mode))
kfree(inode->i_link);
+ free_inode_nonrcu(inode);
+}
+
+static void debugfs_destroy_inode(struct inode *inode)
+{
+ call_rcu(&inode->i_rcu, debugfs_i_callback);
}
static const struct super_operations debugfs_super_operations = {
.statfs = simple_statfs,
.remount_fs = debugfs_remount,
.show_options = debugfs_show_options,
- .evict_inode = debugfs_evict_inode,
+ .destroy_inode = debugfs_destroy_inode,
};
static struct vfsmount *debugfs_automount(struct path *path)
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 42/62] rtc: da9063: set uie_unsupported when relevant
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 41/62] debugfs: " Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 43/62] vfio/pci: use correct format characters Greg Kroah-Hartman
` (23 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Wolfram Sang, Geert Uytterhoeven,
Steve Twiss, Alexandre Belloni, Sasha Levin
[ Upstream commit 882c5e552ffd06856de42261460f46e18319d259 ]
The DA9063AD doesn't support alarms on any seconds and its granularity is
the minute. Set uie_unsupported in that case.
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/rtc/rtc-da9063.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/rtc/rtc-da9063.c b/drivers/rtc/rtc-da9063.c
index f85cae240f12..7e92e491c2e7 100644
--- a/drivers/rtc/rtc-da9063.c
+++ b/drivers/rtc/rtc-da9063.c
@@ -480,6 +480,13 @@ static int da9063_rtc_probe(struct platform_device *pdev)
da9063_data_to_tm(data, &rtc->alarm_time, rtc);
rtc->rtc_sync = false;
+ /*
+ * TODO: some models have alarms on a minute boundary but still support
+ * real hardware interrupts. Add this once the core supports it.
+ */
+ if (config->rtc_data_start != RTC_SEC)
+ rtc->rtc_dev->uie_unsupported = 1;
+
irq_alarm = platform_get_irq_byname(pdev, "ALARM");
ret = devm_request_threaded_irq(&pdev->dev, irq_alarm, NULL,
da9063_alarm_event,
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 43/62] vfio/pci: use correct format characters
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 42/62] rtc: da9063: set uie_unsupported when relevant Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 44/62] scsi: core: add new RDAC LENOVO/DE_Series device Greg Kroah-Hartman
` (22 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Louis Taylor, Nick Desaulniers,
Alex Williamson, Sasha Levin
[ Upstream commit 426b046b748d1f47e096e05bdcc6fb4172791307 ]
When compiling with -Wformat, clang emits the following warnings:
drivers/vfio/pci/vfio_pci.c:1601:5: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~
drivers/vfio/pci/vfio_pci.c:1601:13: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~
drivers/vfio/pci/vfio_pci.c:1601:21: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~~~~
drivers/vfio/pci/vfio_pci.c:1601:32: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~~~~
drivers/vfio/pci/vfio_pci.c:1605:5: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~
drivers/vfio/pci/vfio_pci.c:1605:13: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~
drivers/vfio/pci/vfio_pci.c:1605:21: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~~~~
drivers/vfio/pci/vfio_pci.c:1605:32: warning: format specifies type
'unsigned short' but the argument has type 'unsigned int' [-Wformat]
vendor, device, subvendor, subdevice,
^~~~~~~~~
The types of these arguments are unconditionally defined, so this patch
updates the format character to the correct ones for unsigned ints.
Link: https://github.com/ClangBuiltLinux/linux/issues/378
Signed-off-by: Louis Taylor <louis@kragniz.eu>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/vfio/pci/vfio_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 7338e43faa17..f9a75df2d22d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -1467,11 +1467,11 @@ static void __init vfio_pci_fill_ids(void)
rc = pci_add_dynid(&vfio_pci_driver, vendor, device,
subvendor, subdevice, class, class_mask, 0);
if (rc)
- pr_warn("failed to add dynamic id [%04hx:%04hx[%04hx:%04hx]] class %#08x/%08x (%d)\n",
+ pr_warn("failed to add dynamic id [%04x:%04x[%04x:%04x]] class %#08x/%08x (%d)\n",
vendor, device, subvendor, subdevice,
class, class_mask, rc);
else
- pr_info("add [%04hx:%04hx[%04hx:%04hx]] class %#08x/%08x\n",
+ pr_info("add [%04x:%04x[%04x:%04x]] class %#08x/%08x\n",
vendor, device, subvendor, subdevice,
class, class_mask);
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 44/62] scsi: core: add new RDAC LENOVO/DE_Series device
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 43/62] vfio/pci: use correct format characters Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 45/62] scsi: storvsc: Fix calculation of sub-channel count Greg Kroah-Hartman
` (21 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Martin Wilck, Hannes Reinecke,
NetApp RDAC team, Christophe Varoqui, James E.J. Bottomley,
Martin K. Petersen, SCSI ML, DM ML, Xose Vazquez Perez,
Sasha Levin
[ Upstream commit 1cb1d2c64e812928fe0a40b8f7e74523d0283dbe ]
Blacklist "Universal Xport" LUN. It's used for in-band storage array
management. Also add model to the rdac dh family.
Cc: Martin Wilck <mwilck@suse.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: DM ML <dm-devel@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Reviewed-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/scsi_devinfo.c | 1 +
drivers/scsi/scsi_dh.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 282ea00d0f87..9d555b63d2e2 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -249,6 +249,7 @@ static struct {
{"NETAPP", "Universal Xport", "*", BLIST_NO_ULD_ATTACH},
{"LSI", "Universal Xport", "*", BLIST_NO_ULD_ATTACH},
{"ENGENIO", "Universal Xport", "*", BLIST_NO_ULD_ATTACH},
+ {"LENOVO", "Universal Xport", "*", BLIST_NO_ULD_ATTACH},
{"SMSC", "USB 2 HS-CF", NULL, BLIST_SPARSELUN | BLIST_INQUIRY_36},
{"SONY", "CD-ROM CDU-8001", NULL, BLIST_BORKEN},
{"SONY", "TSL", NULL, BLIST_FORCELUN}, /* DDS3 & DDS4 autoloaders */
diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
index 375cede0c534..c9bc6f058424 100644
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -75,6 +75,7 @@ static const struct scsi_dh_blist scsi_dh_blist[] = {
{"NETAPP", "INF-01-00", "rdac", },
{"LSI", "INF-01-00", "rdac", },
{"ENGENIO", "INF-01-00", "rdac", },
+ {"LENOVO", "DE_Series", "rdac", },
{NULL, NULL, NULL },
};
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 45/62] scsi: storvsc: Fix calculation of sub-channel count
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 44/62] scsi: core: add new RDAC LENOVO/DE_Series device Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 46/62] net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() Greg Kroah-Hartman
` (20 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michael Kelley, Vitaly Kuznetsov,
Long Li, Martin K. Petersen, Sasha Levin
[ Upstream commit 382e06d11e075a40b4094b6ef809f8d4bcc7ab2a ]
When the number of sub-channels offered by Hyper-V is >= the number of CPUs
in the VM, calculate the correct number of sub-channels. The current code
produces one too many.
This scenario arises only when the number of CPUs is artificially
restricted (for example, with maxcpus=<n> on the kernel boot line), because
Hyper-V normally offers a sub-channel count < number of CPUs. While the
current code doesn't break, the extra sub-channel is unbalanced across the
CPUs (for example, a total of 5 channels on a VM with 4 CPUs).
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/storvsc_drv.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index d92b2808d191..6df34d68737f 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -641,13 +641,22 @@ static void handle_sc_creation(struct vmbus_channel *new_sc)
static void handle_multichannel_storage(struct hv_device *device, int max_chns)
{
struct storvsc_device *stor_device;
- int num_cpus = num_online_cpus();
int num_sc;
struct storvsc_cmd_request *request;
struct vstor_packet *vstor_packet;
int ret, t;
- num_sc = ((max_chns > num_cpus) ? num_cpus : max_chns);
+ /*
+ * If the number of CPUs is artificially restricted, such as
+ * with maxcpus=1 on the kernel boot line, Hyper-V could offer
+ * sub-channels >= the number of CPUs. These sub-channels
+ * should not be created. The primary channel is already created
+ * and assigned to one CPU, so check against # CPUs - 1.
+ */
+ num_sc = min((int)(num_online_cpus() - 1), max_chns);
+ if (!num_sc)
+ return;
+
stor_device = get_out_stor_device(device);
if (!stor_device)
return;
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 46/62] net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw()
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 45/62] scsi: storvsc: Fix calculation of sub-channel count Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 47/62] net: hns: Use NAPI_POLL_WEIGHT for hns driver Greg Kroah-Hartman
` (19 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Liubin Shu, Zhen Lei, Yonglong Liu,
Peng Li, David S. Miller, Sasha Levin
[ Upstream commit 3a39a12ad364a9acd1038ba8da67cd8430f30de4 ]
This patch is trying to fix the issue due to:
[27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]
After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be
interrupted by interruptions, and than call hns_nic_tx_poll_one()
to handle the new packets, and free the skb. So, when turn back to
hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free.
This patch update tx ring statistics in hns_nic_tx_poll_one() to
fix the bug.
Signed-off-by: Liubin Shu <shuliubin@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index ad8681cf5ef0..f77578a5ea9d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -375,8 +375,6 @@ netdev_tx_t hns_nic_net_xmit_hw(struct net_device *ndev,
wmb(); /* commit all data before submit */
assert(skb->queue_mapping < priv->ae_handle->q_num);
hnae_queue_xmit(priv->ae_handle->qs[skb->queue_mapping], buf_num);
- ring->stats.tx_pkts++;
- ring->stats.tx_bytes += skb->len;
return NETDEV_TX_OK;
@@ -916,6 +914,9 @@ static int hns_nic_tx_poll_one(struct hns_nic_ring_data *ring_data,
/* issue prefetch for next Tx descriptor */
prefetch(&ring->desc_cb[ring->next_to_clean]);
}
+ /* update tx ring statistics. */
+ ring->stats.tx_pkts += pkts;
+ ring->stats.tx_bytes += bytes;
NETIF_TX_UNLOCK(ndev);
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 47/62] net: hns: Use NAPI_POLL_WEIGHT for hns driver
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 46/62] net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 48/62] net: hns: Fix WARNING when remove HNS driver with SMMU enabled Greg Kroah-Hartman
` (18 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yonglong Liu, Peng Li,
David S. Miller, Sasha Levin
[ Upstream commit acb1ce15a61154aa501891d67ebf79bc9ea26818 ]
When the HNS driver loaded, always have an error print:
"netif_napi_add() called with weight 256"
This is because the kernel checks the NAPI polling weights
requested by drivers and it prints an error message if a driver
requests a weight bigger than 64.
So use NAPI_POLL_WEIGHT to fix it.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index f77578a5ea9d..24a815997ec5 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -28,9 +28,6 @@
#define SERVICE_TIMER_HZ (1 * HZ)
-#define NIC_TX_CLEAN_MAX_NUM 256
-#define NIC_RX_CLEAN_MAX_NUM 64
-
#define RCB_IRQ_NOT_INITED 0
#define RCB_IRQ_INITED 1
#define HNS_BUFFER_SIZE_2048 2048
@@ -1822,7 +1819,7 @@ static int hns_nic_init_ring_data(struct hns_nic_priv *priv)
hns_nic_tx_fini_pro_v2;
netif_napi_add(priv->netdev, &rd->napi,
- hns_nic_common_poll, NIC_TX_CLEAN_MAX_NUM);
+ hns_nic_common_poll, NAPI_POLL_WEIGHT);
rd->ring->irq_init_flag = RCB_IRQ_NOT_INITED;
}
for (i = h->q_num; i < h->q_num * 2; i++) {
@@ -1835,7 +1832,7 @@ static int hns_nic_init_ring_data(struct hns_nic_priv *priv)
hns_nic_rx_fini_pro_v2;
netif_napi_add(priv->netdev, &rd->napi,
- hns_nic_common_poll, NIC_RX_CLEAN_MAX_NUM);
+ hns_nic_common_poll, NAPI_POLL_WEIGHT);
rd->ring->irq_init_flag = RCB_IRQ_NOT_INITED;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 48/62] net: hns: Fix WARNING when remove HNS driver with SMMU enabled
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 47/62] net: hns: Use NAPI_POLL_WEIGHT for hns driver Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 49/62] hugetlbfs: fix memory leak for resv_map Greg Kroah-Hartman
` (17 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Yonglong Liu, Peng Li,
David S. Miller, Sasha Levin
[ Upstream commit 8601a99d7c0256b7a7fdd1ab14cf6c1f1dfcadc6 ]
When enable SMMU, remove HNS driver will cause a WARNING:
[ 141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
[ 141.954673] Modules linked in: hns_enet_drv(-)
[ 141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G W 5.0.0-rc1-28723-gb729c57de95c-dirty #32
[ 141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017
[ 142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
[ 142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
[ 142.027066] sp : ffff000013533b90
[ 142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
[ 142.044420] x27: 0000000000000000 x26: 0000000000000000
[ 142.055113] x25: 0000000056000000 x24: 0000000000000015
[ 142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
[ 142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
[ 142.087192] x19: 0000000000001000 x18: 0000000000000007
[ 142.097885] x17: 000000000000000e x16: 0000000000000001
[ 142.108578] x15: 0000000000000019 x14: 363139343a70616d
[ 142.119270] x13: 6e75656761705f67 x12: 0000000000000000
[ 142.129963] x11: 00000000ffffffff x10: 0000000000000006
[ 142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
[ 142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
[ 142.162042] x5 : 0000000000000000 x4 : 0000000000000000
[ 142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
[ 142.183427] x1 : 0000000000000000 x0 : 0000000000000035
[ 142.194120] Call trace:
[ 142.199030] __iommu_dma_unmap+0xc0/0xc8
[ 142.206920] iommu_dma_unmap_page+0x20/0x28
[ 142.215335] __iommu_unmap_page+0x40/0x60
[ 142.223399] hnae_unmap_buffer+0x110/0x134
[ 142.231639] hnae_free_desc+0x6c/0x10c
[ 142.239177] hnae_fini_ring+0x14/0x34
[ 142.246540] hnae_fini_queue+0x2c/0x40
[ 142.254080] hnae_put_handle+0x38/0xcc
[ 142.261619] hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
[ 142.272312] platform_drv_remove+0x24/0x64
[ 142.280552] device_release_driver_internal+0x17c/0x20c
[ 142.291070] driver_detach+0x4c/0x90
[ 142.298259] bus_remove_driver+0x5c/0xd8
[ 142.306148] driver_unregister+0x2c/0x54
[ 142.314037] platform_driver_unregister+0x10/0x18
[ 142.323505] hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
[ 142.335248] __arm64_sys_delete_module+0x214/0x25c
[ 142.344891] el0_svc_common+0xb0/0x10c
[ 142.352430] el0_svc_handler+0x24/0x80
[ 142.359968] el0_svc+0x8/0x7c0
[ 142.366104] ---[ end trace 60ad1cd58e63c407 ]---
The tx ring buffer map when xmit and unmap when xmit done. So in
hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring()
have a unmap operation for tx ring buffer, which is already unmapped
when xmit done, than cause this WARNING.
The hnae_alloc_buffers() is called in hnae_init_ring(),
so the hnae_free_buffers() should be in hnae_fini_ring(), not in
hnae_free_desc().
In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring().
When the ring buffer is tx ring, adds a piece of code to ensure that
the tx ring is unmap.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c b/drivers/net/ethernet/hisilicon/hns/hnae.c
index 06bc8638501e..66e7a5fd4249 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -146,7 +146,6 @@ static int hnae_alloc_buffers(struct hnae_ring *ring)
/* free desc along with its attached buffer */
static void hnae_free_desc(struct hnae_ring *ring)
{
- hnae_free_buffers(ring);
dma_unmap_single(ring_to_dev(ring), ring->desc_dma_addr,
ring->desc_num * sizeof(ring->desc[0]),
ring_to_dma_dir(ring));
@@ -179,6 +178,9 @@ static int hnae_alloc_desc(struct hnae_ring *ring)
/* fini ring, also free the buffer for the ring */
static void hnae_fini_ring(struct hnae_ring *ring)
{
+ if (is_rx_ring(ring))
+ hnae_free_buffers(ring);
+
hnae_free_desc(ring);
kfree(ring->desc_cb);
ring->desc_cb = NULL;
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 49/62] hugetlbfs: fix memory leak for resv_map
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 48/62] net: hns: Fix WARNING when remove HNS driver with SMMU enabled Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 50/62] sh: fix multiple function definition build errors Greg Kroah-Hartman
` (16 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mike Kravetz, Andrew Morton,
Yufen Yu, Linus Torvalds, Sasha Levin
[ Upstream commit 58b6e5e8f1addd44583d61b0a03c0f5519527e35 ]
When mknod is used to create a block special file in hugetlbfs, it will
allocate an inode and kmalloc a 'struct resv_map' via resv_map_alloc().
inode->i_mapping->private_data will point the newly allocated resv_map.
However, when the device special file is opened bd_acquire() will set
inode->i_mapping to bd_inode->i_mapping. Thus the pointer to the
allocated resv_map is lost and the structure is leaked.
Programs to reproduce:
mount -t hugetlbfs nodev hugetlbfs
mknod hugetlbfs/dev b 0 0
exec 30<> hugetlbfs/dev
umount hugetlbfs/
resv_map structures are only needed for inodes which can have associated
page allocations. To fix the leak, only allocate resv_map for those
inodes which could possibly be associated with page allocations.
Link: http://lkml.kernel.org/r/20190401213101.16476-1-mike.kravetz@oracle.com
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Yufen Yu <yuyufen@huawei.com>
Suggested-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/hugetlbfs/inode.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 001487b230b5..4acc677ac8fb 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -746,11 +746,17 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
umode_t mode, dev_t dev)
{
struct inode *inode;
- struct resv_map *resv_map;
+ struct resv_map *resv_map = NULL;
- resv_map = resv_map_alloc();
- if (!resv_map)
- return NULL;
+ /*
+ * Reserve maps are only needed for inodes that can have associated
+ * page allocations.
+ */
+ if (S_ISREG(mode) || S_ISLNK(mode)) {
+ resv_map = resv_map_alloc();
+ if (!resv_map)
+ return NULL;
+ }
inode = new_inode(sb);
if (inode) {
@@ -782,8 +788,10 @@ static struct inode *hugetlbfs_get_inode(struct super_block *sb,
break;
}
lockdep_annotate_inode_mutex_key(inode);
- } else
- kref_put(&resv_map->refs, resv_map_release);
+ } else {
+ if (resv_map)
+ kref_put(&resv_map->refs, resv_map_release);
+ }
return inode;
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 50/62] sh: fix multiple function definition build errors
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 49/62] hugetlbfs: fix memory leak for resv_map Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 51/62] xsysace: Fix error handling in ace_setup Greg Kroah-Hartman
` (15 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Randy Dunlap, kbuild test robot,
Takashi Iwai, Yoshinori Sato, Rich Felker, Andrew Morton,
Linus Torvalds, Sasha Levin
[ Upstream commit acaf892ecbf5be7710ae05a61fd43c668f68ad95 ]
Many of the sh CPU-types have their own plat_irq_setup() and
arch_init_clk_ops() functions, so these same (empty) functions in
arch/sh/boards/of-generic.c are not needed and cause build errors.
If there is some case where these empty functions are needed, they can
be retained by marking them as "__weak" while at the same time making
builds that do not need them succeed.
Fixes these build errors:
arch/sh/boards/of-generic.o: In function `plat_irq_setup':
(.init.text+0x134): multiple definition of `plat_irq_setup'
arch/sh/kernel/cpu/sh2/setup-sh7619.o:(.init.text+0x30): first defined here
arch/sh/boards/of-generic.o: In function `arch_init_clk_ops':
(.init.text+0x118): multiple definition of `arch_init_clk_ops'
arch/sh/kernel/cpu/sh2/clock-sh7619.o:(.init.text+0x0): first defined here
Link: http://lkml.kernel.org/r/9ee4e0c5-f100-86a2-bd4d-1d3287ceab31@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Rich Felker <dalias@libc.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/sh/boards/of-generic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sh/boards/of-generic.c b/arch/sh/boards/of-generic.c
index 1fb6d5714bae..fd00566677c9 100644
--- a/arch/sh/boards/of-generic.c
+++ b/arch/sh/boards/of-generic.c
@@ -180,10 +180,10 @@ static struct sh_machine_vector __initmv sh_of_generic_mv = {
struct sh_clk_ops;
-void __init arch_init_clk_ops(struct sh_clk_ops **ops, int idx)
+void __init __weak arch_init_clk_ops(struct sh_clk_ops **ops, int idx)
{
}
-void __init plat_irq_setup(void)
+void __init __weak plat_irq_setup(void)
{
}
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 51/62] xsysace: Fix error handling in ace_setup
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 50/62] sh: fix multiple function definition build errors Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 52/62] ARM: orion: dont use using 64-bit DMA masks Greg Kroah-Hartman
` (14 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Michal Simek, Guenter Roeck,
Jens Axboe, Sasha Levin
[ Upstream commit 47b16820c490149c2923e8474048f2c6e7557cab ]
If xace hardware reports a bad version number, the error handling code
in ace_setup() calls put_disk(), followed by queue cleanup. However, since
the disk data structure has the queue pointer set, put_disk() also
cleans and releases the queue. This results in blk_cleanup_queue()
accessing an already released data structure, which in turn may result
in a crash such as the following.
[ 10.681671] BUG: Kernel NULL pointer dereference at 0x00000040
[ 10.681826] Faulting instruction address: 0xc0431480
[ 10.682072] Oops: Kernel access of bad area, sig: 11 [#1]
[ 10.682251] BE PAGE_SIZE=4K PREEMPT Xilinx Virtex440
[ 10.682387] Modules linked in:
[ 10.682528] CPU: 0 PID: 1 Comm: swapper Tainted: G W 5.0.0-rc6-next-20190218+ #2
[ 10.682733] NIP: c0431480 LR: c043147c CTR: c0422ad8
[ 10.682863] REGS: cf82fbe0 TRAP: 0300 Tainted: G W (5.0.0-rc6-next-20190218+)
[ 10.683065] MSR: 00029000 <CE,EE,ME> CR: 22000222 XER: 00000000
[ 10.683236] DEAR: 00000040 ESR: 00000000
[ 10.683236] GPR00: c043147c cf82fc90 cf82ccc0 00000000 00000000 00000000 00000002 00000000
[ 10.683236] GPR08: 00000000 00000000 c04310bc 00000000 22000222 00000000 c0002c54 00000000
[ 10.683236] GPR16: 00000000 00000001 c09aa39c c09021b0 c09021dc 00000007 c0a68c08 00000000
[ 10.683236] GPR24: 00000001 ced6d400 ced6dcf0 c0815d9c 00000000 00000000 00000000 cedf0800
[ 10.684331] NIP [c0431480] blk_mq_run_hw_queue+0x28/0x114
[ 10.684473] LR [c043147c] blk_mq_run_hw_queue+0x24/0x114
[ 10.684602] Call Trace:
[ 10.684671] [cf82fc90] [c043147c] blk_mq_run_hw_queue+0x24/0x114 (unreliable)
[ 10.684854] [cf82fcc0] [c04315bc] blk_mq_run_hw_queues+0x50/0x7c
[ 10.685002] [cf82fce0] [c0422b24] blk_set_queue_dying+0x30/0x68
[ 10.685154] [cf82fcf0] [c0423ec0] blk_cleanup_queue+0x34/0x14c
[ 10.685306] [cf82fd10] [c054d73c] ace_probe+0x3dc/0x508
[ 10.685445] [cf82fd50] [c052d740] platform_drv_probe+0x4c/0xb8
[ 10.685592] [cf82fd70] [c052abb0] really_probe+0x20c/0x32c
[ 10.685728] [cf82fda0] [c052ae58] driver_probe_device+0x68/0x464
[ 10.685877] [cf82fdc0] [c052b500] device_driver_attach+0xb4/0xe4
[ 10.686024] [cf82fde0] [c052b5dc] __driver_attach+0xac/0xfc
[ 10.686161] [cf82fe00] [c0528428] bus_for_each_dev+0x80/0xc0
[ 10.686314] [cf82fe30] [c0529b3c] bus_add_driver+0x144/0x234
[ 10.686457] [cf82fe50] [c052c46c] driver_register+0x88/0x15c
[ 10.686610] [cf82fe60] [c09de288] ace_init+0x4c/0xac
[ 10.686742] [cf82fe80] [c0002730] do_one_initcall+0xac/0x330
[ 10.686888] [cf82fee0] [c09aafd0] kernel_init_freeable+0x34c/0x478
[ 10.687043] [cf82ff30] [c0002c6c] kernel_init+0x18/0x114
[ 10.687188] [cf82ff40] [c000f2f0] ret_from_kernel_thread+0x14/0x1c
[ 10.687349] Instruction dump:
[ 10.687435] 3863ffd4 4bfffd70 9421ffd0 7c0802a6 93c10028 7c9e2378 93e1002c 38810008
[ 10.687637] 7c7f1b78 90010034 4bfffc25 813f008c <81290040> 75290100 4182002c 80810008
[ 10.688056] ---[ end trace 13c9ff51d41b9d40 ]---
Fix the problem by setting the disk queue pointer to NULL before calling
put_disk(). A more comprehensive fix might be to rearrange the code
to check the hardware version before initializing data structures,
but I don't know if this would have undesirable side effects, and
it would increase the complexity of backporting the fix to older kernels.
Fixes: 74489a91dd43a ("Add support for Xilinx SystemACE CompactFlash interface")
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/xsysace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
index c4328d9d9981..f838119d12b2 100644
--- a/drivers/block/xsysace.c
+++ b/drivers/block/xsysace.c
@@ -1062,6 +1062,8 @@ static int ace_setup(struct ace_device *ace)
return 0;
err_read:
+ /* prevent double queue cleanup */
+ ace->gd->queue = NULL;
put_disk(ace->gd);
err_alloc_disk:
blk_cleanup_queue(ace->queue);
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 52/62] ARM: orion: dont use using 64-bit DMA masks
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 51/62] xsysace: Fix error handling in ace_setup Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 53/62] ARM: iop: " Greg Kroah-Hartman
` (13 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Olof Johansson, Sasha Levin
[ Upstream commit cd92d74d67c811dc22544430b9ac3029f5bd64c5 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/plat-orion/common.c:625:29: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
.coherent_dma_mask = DMA_BIT_MASK(64),
^~~~~~~~~~~~~~~~
include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
The ones in orion shouldn't really be 64 bit masks, so changing them
to what the driver can support avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/plat-orion/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 272f49b2c68f..bb29e6ebdc0d 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -605,7 +605,7 @@ static struct platform_device orion_xor0_shared = {
.resource = orion_xor0_shared_resources,
.dev = {
.dma_mask = &orion_xor_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &orion_xor0_pdata,
},
};
@@ -666,7 +666,7 @@ static struct platform_device orion_xor1_shared = {
.resource = orion_xor1_shared_resources,
.dev = {
.dma_mask = &orion_xor_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &orion_xor1_pdata,
},
};
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 53/62] ARM: iop: dont use using 64-bit DMA masks
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 52/62] ARM: orion: dont use using 64-bit DMA masks Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 54/62] perf/x86/amd: Update generic hardware cache events for Family 17h Greg Kroah-Hartman
` (12 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Arnd Bergmann, Olof Johansson, Sasha Levin
[ Upstream commit 2125801ccce19249708ca3245d48998e70569ab8 ]
clang warns about statically defined DMA masks from the DMA_BIT_MASK
macro with length 64:
arch/arm/mach-iop13xx/setup.c:303:35: error: shift count >= width of type [-Werror,-Wshift-count-overflow]
static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64);
^~~~~~~~~~~~~~~~
include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK'
#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
^ ~~~
The ones in iop shouldn't really be 64 bit masks, so changing them
to what the driver can support avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/mach-iop13xx/setup.c | 8 ++++----
arch/arm/mach-iop13xx/tpmi.c | 10 +++++-----
arch/arm/plat-iop/adma.c | 6 +++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-iop13xx/setup.c b/arch/arm/mach-iop13xx/setup.c
index 53c316f7301e..fe4932fda01d 100644
--- a/arch/arm/mach-iop13xx/setup.c
+++ b/arch/arm/mach-iop13xx/setup.c
@@ -300,7 +300,7 @@ static struct resource iop13xx_adma_2_resources[] = {
}
};
-static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(64);
+static u64 iop13xx_adma_dmamask = DMA_BIT_MASK(32);
static struct iop_adma_platform_data iop13xx_adma_0_data = {
.hw_id = 0,
.pool_size = PAGE_SIZE,
@@ -324,7 +324,7 @@ static struct platform_device iop13xx_adma_0_channel = {
.resource = iop13xx_adma_0_resources,
.dev = {
.dma_mask = &iop13xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop13xx_adma_0_data,
},
};
@@ -336,7 +336,7 @@ static struct platform_device iop13xx_adma_1_channel = {
.resource = iop13xx_adma_1_resources,
.dev = {
.dma_mask = &iop13xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop13xx_adma_1_data,
},
};
@@ -348,7 +348,7 @@ static struct platform_device iop13xx_adma_2_channel = {
.resource = iop13xx_adma_2_resources,
.dev = {
.dma_mask = &iop13xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop13xx_adma_2_data,
},
};
diff --git a/arch/arm/mach-iop13xx/tpmi.c b/arch/arm/mach-iop13xx/tpmi.c
index db511ec2b1df..116feb6b261e 100644
--- a/arch/arm/mach-iop13xx/tpmi.c
+++ b/arch/arm/mach-iop13xx/tpmi.c
@@ -152,7 +152,7 @@ static struct resource iop13xx_tpmi_3_resources[] = {
}
};
-u64 iop13xx_tpmi_mask = DMA_BIT_MASK(64);
+u64 iop13xx_tpmi_mask = DMA_BIT_MASK(32);
static struct platform_device iop13xx_tpmi_0_device = {
.name = "iop-tpmi",
.id = 0,
@@ -160,7 +160,7 @@ static struct platform_device iop13xx_tpmi_0_device = {
.resource = iop13xx_tpmi_0_resources,
.dev = {
.dma_mask = &iop13xx_tpmi_mask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
},
};
@@ -171,7 +171,7 @@ static struct platform_device iop13xx_tpmi_1_device = {
.resource = iop13xx_tpmi_1_resources,
.dev = {
.dma_mask = &iop13xx_tpmi_mask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
},
};
@@ -182,7 +182,7 @@ static struct platform_device iop13xx_tpmi_2_device = {
.resource = iop13xx_tpmi_2_resources,
.dev = {
.dma_mask = &iop13xx_tpmi_mask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
},
};
@@ -193,7 +193,7 @@ static struct platform_device iop13xx_tpmi_3_device = {
.resource = iop13xx_tpmi_3_resources,
.dev = {
.dma_mask = &iop13xx_tpmi_mask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
},
};
diff --git a/arch/arm/plat-iop/adma.c b/arch/arm/plat-iop/adma.c
index a4d1f8de3b5b..d9612221e484 100644
--- a/arch/arm/plat-iop/adma.c
+++ b/arch/arm/plat-iop/adma.c
@@ -143,7 +143,7 @@ struct platform_device iop3xx_dma_0_channel = {
.resource = iop3xx_dma_0_resources,
.dev = {
.dma_mask = &iop3xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop3xx_dma_0_data,
},
};
@@ -155,7 +155,7 @@ struct platform_device iop3xx_dma_1_channel = {
.resource = iop3xx_dma_1_resources,
.dev = {
.dma_mask = &iop3xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop3xx_dma_1_data,
},
};
@@ -167,7 +167,7 @@ struct platform_device iop3xx_aau_channel = {
.resource = iop3xx_aau_resources,
.dev = {
.dma_mask = &iop3xx_adma_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(64),
+ .coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = (void *) &iop3xx_aau_data,
},
};
--
2.20.1
^ permalink raw reply related [flat|nested] 73+ messages in thread* [PATCH 4.9 54/62] perf/x86/amd: Update generic hardware cache events for Family 17h
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 53/62] ARM: iop: " Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 55/62] staging: iio: adt7316: allow adt751x to use internal vref for all dacs Greg Kroah-Hartman
` (11 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kim Phillips, Alexander Shishkin,
Arnaldo Carvalho de Melo, Borislav Petkov, H. Peter Anvin,
Janakarajan Natarajan, Jiri Olsa, Linus Torvalds,
Martin Liška, Namhyung Kim, Peter Zijlstra, Pu Wen,
Stephane Eranian, Suravee Suthikulpanit, Thomas Gleixner,
Thomas Lendacky, Vince Weaver, linux-perf-users, Ingo Molnar
From: Kim Phillips <kim.phillips@amd.com>
commit 0e3b74e26280f2cf8753717a950b97d424da6046 upstream.
Add a new amd_hw_cache_event_ids_f17h assignment structure set
for AMD families 17h and above, since a lot has changed. Specifically:
L1 Data Cache
The data cache access counter remains the same on Family 17h.
For DC misses, PMCx041's definition changes with Family 17h,
so instead we use the L2 cache accesses from L1 data cache
misses counter (PMCx060,umask=0xc8).
For DC hardware prefetch events, Family 17h breaks compatibility
for PMCx067 "Data Prefetcher", so instead, we use PMCx05a "Hardware
Prefetch DC Fills."
L1 Instruction Cache
PMCs 0x80 and 0x81 (32-byte IC fetches and misses) are backward
compatible on Family 17h.
For prefetches, we remove the erroneous PMCx04B assignment which
counts how many software data cache prefetch load instructions were
dispatched.
LL - Last Level Cache
Removing PMCs 7D, 7E, and 7F assignments, as they do not exist
on Family 17h, where the last level cache is L3. L3 counters
can be accessed using the existing AMD Uncore driver.
Data TLB
On Intel machines, data TLB accesses ("dTLB-loads") are assigned
to counters that count load/store instructions retired. This
is inconsistent with instruction TLB accesses, where Intel
implementations report iTLB misses that hit in the STLB.
Ideally, dTLB-loads would count higher level dTLB misses that hit
in lower level TLBs, and dTLB-load-misses would report those
that also missed in those lower-level TLBs, therefore causing
a page table walk. That would be consistent with instruction
TLB operation, remove the redundancy between dTLB-loads and
L1-dcache-loads, and prevent perf from producing artificially
low percentage ratios, i.e. the "0.01%" below:
42,550,869 L1-dcache-loads
41,591,860 dTLB-loads
4,802 dTLB-load-misses # 0.01% of all dTLB cache hits
7,283,682 L1-dcache-stores
7,912,392 dTLB-stores
310 dTLB-store-misses
On AMD Families prior to 17h, the "Data Cache Accesses" counter is
used, which is slightly better than load/store instructions retired,
but still counts in terms of individual load/store operations
instead of TLB operations.
So, for AMD Families 17h and higher, this patch assigns "dTLB-loads"
to a counter for L1 dTLB misses that hit in the L2 dTLB, and
"dTLB-load-misses" to a counter for L1 DTLB misses that caused
L2 DTLB misses and therefore also caused page table walks. This
results in a much more accurate view of data TLB performance:
60,961,781 L1-dcache-loads
4,601 dTLB-loads
963 dTLB-load-misses # 20.93% of all dTLB cache hits
Note that for all AMD families, data loads and stores are combined
in a single accesses counter, so no 'L1-dcache-stores' are reported
separately, and stores are counted with loads in 'L1-dcache-loads'.
Also note that the "% of all dTLB cache hits" string is misleading
because (a) "dTLB cache": although TLBs can be considered caches for
page tables, in this context, it can be misinterpreted as data cache
hits because the figures are similar (at least on Intel), and (b) not
all those loads (technically accesses) technically "hit" at that
hardware level. "% of all dTLB accesses" would be more clear/accurate.
Instruction TLB
On Intel machines, 'iTLB-loads' measure iTLB misses that hit in the
STLB, and 'iTLB-load-misses' measure iTLB misses that also missed in
the STLB and completed a page table walk.
For AMD Family 17h and above, for 'iTLB-loads' we replace the
erroneous instruction cache fetches counter with PMCx084
"L1 ITLB Miss, L2 ITLB Hit".
For 'iTLB-load-misses' we still use PMCx085 "L1 ITLB Miss,
L2 ITLB Miss", but set a 0xff umask because without it the event
does not get counted.
Branch Predictor (BPU)
PMCs 0xc2 and 0xc3 continue to be valid across all AMD Families.
Node Level Events
Family 17h does not have a PMCx0e9 counter, and corresponding counters
have not been made available publicly, so for now, we mark them as
unsupported for Families 17h and above.
Reference:
"Open-Source Register Reference For AMD Family 17h Processors Models 00h-2Fh"
Released 7/17/2018, Publication #56255, Revision 3.03:
https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf
[ mingo: tidied up the line breaks. ]
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Liška <mliska@suse.cz>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Pu Wen <puwen@hygon.cn>
Cc: Stephane Eranian <eranian@google.com>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-kernel@vger.kernel.org
Cc: linux-perf-users@vger.kernel.org
Fixes: e40ed1542dd7 ("perf/x86: Add perf support for AMD family-17h processors")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/events/amd/core.c | 111 +++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 108 insertions(+), 3 deletions(-)
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -112,6 +112,110 @@ static __initconst const u64 amd_hw_cach
},
};
+static __initconst const u64 amd_hw_cache_event_ids_f17h
+ [PERF_COUNT_HW_CACHE_MAX]
+ [PERF_COUNT_HW_CACHE_OP_MAX]
+ [PERF_COUNT_HW_CACHE_RESULT_MAX] = {
+[C(L1D)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0x0040, /* Data Cache Accesses */
+ [C(RESULT_MISS)] = 0xc860, /* L2$ access from DC Miss */
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0xff5a, /* h/w prefetch DC Fills */
+ [C(RESULT_MISS)] = 0,
+ },
+},
+[C(L1I)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0x0080, /* Instruction cache fetches */
+ [C(RESULT_MISS)] = 0x0081, /* Instruction cache misses */
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+},
+[C(LL)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+},
+[C(DTLB)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0xff45, /* All L2 DTLB accesses */
+ [C(RESULT_MISS)] = 0xf045, /* L2 DTLB misses (PT walks) */
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+},
+[C(ITLB)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0x0084, /* L1 ITLB misses, L2 ITLB hits */
+ [C(RESULT_MISS)] = 0xff85, /* L1 ITLB misses, L2 misses */
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+},
+[C(BPU)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0x00c2, /* Retired Branch Instr. */
+ [C(RESULT_MISS)] = 0x00c3, /* Retired Mispredicted BI */
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+},
+[C(NODE)] = {
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0,
+ [C(RESULT_MISS)] = 0,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = -1,
+ [C(RESULT_MISS)] = -1,
+ },
+},
+};
+
/*
* AMD Performance Monitor K7 and later, up to and including Family 16h:
*/
@@ -731,9 +835,10 @@ __init int amd_pmu_init(void)
x86_pmu.amd_nb_constraints = 0;
}
- /* Events are common for all AMDs */
- memcpy(hw_cache_event_ids, amd_hw_cache_event_ids,
- sizeof(hw_cache_event_ids));
+ if (boot_cpu_data.x86 >= 0x17)
+ memcpy(hw_cache_event_ids, amd_hw_cache_event_ids_f17h, sizeof(hw_cache_event_ids));
+ else
+ memcpy(hw_cache_event_ids, amd_hw_cache_event_ids, sizeof(hw_cache_event_ids));
return 0;
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 55/62] staging: iio: adt7316: allow adt751x to use internal vref for all dacs
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 54/62] perf/x86/amd: Update generic hardware cache events for Family 17h Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 56/62] staging: iio: adt7316: fix the dac read calculation Greg Kroah-Hartman
` (10 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jeremy Fertic, Jonathan Cameron
From: Jeremy Fertic <jeremyfertic@gmail.com>
commit 10bfe7cc1739c22f0aa296b39e53f61e9e3f4d99 upstream.
With adt7516/7/9, internal vref is available for dacs a and b, dacs c and
d, or all dacs. The driver doesn't currently support internal vref for all
dacs. Change the else if to an if so both bits are checked rather than
just one or the other.
Signed-off-by: Jeremy Fertic <jeremyfertic@gmail.com>
Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/iio/addac/adt7316.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -1089,7 +1089,7 @@ static ssize_t adt7316_store_DAC_interna
ldac_config = chip->ldac_config & (~ADT7516_DAC_IN_VREF_MASK);
if (data & 0x1)
ldac_config |= ADT7516_DAC_AB_IN_VREF;
- else if (data & 0x2)
+ if (data & 0x2)
ldac_config |= ADT7516_DAC_CD_IN_VREF;
} else {
ret = kstrtou8(buf, 16, &data);
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 56/62] staging: iio: adt7316: fix the dac read calculation
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 55/62] staging: iio: adt7316: allow adt751x to use internal vref for all dacs Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 57/62] staging: iio: adt7316: fix the dac write calculation Greg Kroah-Hartman
` (9 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jeremy Fertic, Jonathan Cameron
From: Jeremy Fertic <jeremyfertic@gmail.com>
commit 45130fb030aec26ac28b4bb23344901df3ec3b7f upstream.
The calculation of the current dac value is using the wrong bits of the
dac lsb register. Create two macros to shift the lsb register value into
lsb position, depending on whether the dac is 10 or 12 bit. Initialize
data to 0 so, with an 8 bit dac, the msb register value can be bitwise
ORed with data.
Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
Signed-off-by: Jeremy Fertic <jeremyfertic@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/iio/addac/adt7316.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -47,6 +47,8 @@
#define ADT7516_MSB_AIN3 0xA
#define ADT7516_MSB_AIN4 0xB
#define ADT7316_DA_DATA_BASE 0x10
+#define ADT7316_DA_10_BIT_LSB_SHIFT 6
+#define ADT7316_DA_12_BIT_LSB_SHIFT 4
#define ADT7316_DA_MSB_DATA_REGS 4
#define ADT7316_LSB_DAC_A 0x10
#define ADT7316_MSB_DAC_A 0x11
@@ -1411,7 +1413,7 @@ static IIO_DEVICE_ATTR(ex_analog_temp_of
static ssize_t adt7316_show_DAC(struct adt7316_chip_info *chip,
int channel, char *buf)
{
- u16 data;
+ u16 data = 0;
u8 msb, lsb, offset;
int ret;
@@ -1436,7 +1438,11 @@ static ssize_t adt7316_show_DAC(struct a
if (ret)
return -EIO;
- data = (msb << offset) + (lsb & ((1 << offset) - 1));
+ if (chip->dac_bits == 12)
+ data = lsb >> ADT7316_DA_12_BIT_LSB_SHIFT;
+ else if (chip->dac_bits == 10)
+ data = lsb >> ADT7316_DA_10_BIT_LSB_SHIFT;
+ data |= msb << offset;
return sprintf(buf, "%d\n", data);
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 57/62] staging: iio: adt7316: fix the dac write calculation
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 56/62] staging: iio: adt7316: fix the dac read calculation Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 58/62] scsi: RDMA/srpt: Fix a credit leak for aborted commands Greg Kroah-Hartman
` (8 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jeremy Fertic, Jonathan Cameron
From: Jeremy Fertic <jeremyfertic@gmail.com>
commit 78accaea117c1ae878774974fab91ac4a0b0e2b0 upstream.
The lsb calculation is not masking the correct bits from the user input.
Subtract 1 from (1 << offset) to correctly set up the mask to be applied
to user input.
The lsb register stores its value starting at the bit 7 position.
adt7316_store_DAC() currently assumes the value is at the other end of the
register. Shift the lsb value before storing it in a new variable lsb_reg,
and write this variable to the lsb register.
Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
Signed-off-by: Jeremy Fertic <jeremyfertic@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/iio/addac/adt7316.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -1450,7 +1450,7 @@ static ssize_t adt7316_show_DAC(struct a
static ssize_t adt7316_store_DAC(struct adt7316_chip_info *chip,
int channel, const char *buf, size_t len)
{
- u8 msb, lsb, offset;
+ u8 msb, lsb, lsb_reg, offset;
u16 data;
int ret;
@@ -1468,9 +1468,13 @@ static ssize_t adt7316_store_DAC(struct
return -EINVAL;
if (chip->dac_bits > 8) {
- lsb = data & (1 << offset);
+ lsb = data & ((1 << offset) - 1);
+ if (chip->dac_bits == 12)
+ lsb_reg = lsb << ADT7316_DA_12_BIT_LSB_SHIFT;
+ else
+ lsb_reg = lsb << ADT7316_DA_10_BIT_LSB_SHIFT;
ret = chip->bus.write(chip->bus.client,
- ADT7316_DA_DATA_BASE + channel * 2, lsb);
+ ADT7316_DA_DATA_BASE + channel * 2, lsb_reg);
if (ret)
return -EIO;
}
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 58/62] scsi: RDMA/srpt: Fix a credit leak for aborted commands
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 57/62] staging: iio: adt7316: fix the dac write calculation Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 59/62] Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ Greg Kroah-Hartman
` (7 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Doug Ledford, Jason Gunthorpe,
Nicholas Bellinger, Mike Christie, Hannes Reinecke,
Christoph Hellwig, Bart Van Assche, Martin K. Petersen
From: Bart Van Assche <bvanassche@acm.org>
commit 40ca8757291ca7a8775498112d320205b2a2e571 upstream.
Make sure that the next time a response is sent to the initiator that the
credit it had allocated for the aborted request gets freed.
Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Fixes: 131e6abc674e ("target: Add TFO->abort_task for aborted task resources release") # v3.15
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2368,8 +2368,19 @@ static void srpt_queue_tm_rsp(struct se_
srpt_queue_response(cmd);
}
+/*
+ * This function is called for aborted commands if no response is sent to the
+ * initiator. Make sure that the credits freed by aborting a command are
+ * returned to the initiator the next time a response is sent by incrementing
+ * ch->req_lim_delta.
+ */
static void srpt_aborted_task(struct se_cmd *cmd)
{
+ struct srpt_send_ioctx *ioctx = container_of(cmd,
+ struct srpt_send_ioctx, cmd);
+ struct srpt_rdma_ch *ch = ioctx->ch;
+
+ atomic_inc(&ch->req_lim_delta);
}
static int srpt_queue_status(struct se_cmd *cmd)
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 59/62] Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 58/62] scsi: RDMA/srpt: Fix a credit leak for aborted commands Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 60/62] selinux: never allow relabeling on context mounts Greg Kroah-Hartman
` (6 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Anson Huang, Dmitry Torokhov
From: Anson Huang <anson.huang@nxp.com>
commit bf2a7ca39fd3ab47ef71c621a7ee69d1813b1f97 upstream.
SNVS IRQ is requested before necessary driver data initialized,
if there is a pending IRQ during driver probe phase, kernel
NULL pointer panic will occur in IRQ handler. To avoid such
scenario, just initialize necessary driver data before enabling
IRQ. This patch is inspired by NXP's internal kernel tree.
Fixes: d3dc6e232215 ("input: keyboard: imx: add snvs power key driver")
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/input/keyboard/snvs_pwrkey.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/input/keyboard/snvs_pwrkey.c
+++ b/drivers/input/keyboard/snvs_pwrkey.c
@@ -156,6 +156,9 @@ static int imx_snvs_pwrkey_probe(struct
return error;
}
+ pdata->input = input;
+ platform_set_drvdata(pdev, pdata);
+
error = devm_request_irq(&pdev->dev, pdata->irq,
imx_snvs_pwrkey_interrupt,
0, pdev->name, pdev);
@@ -171,9 +174,6 @@ static int imx_snvs_pwrkey_probe(struct
return error;
}
- pdata->input = input;
- platform_set_drvdata(pdev, pdata);
-
device_init_wakeup(&pdev->dev, pdata->wakeup);
return 0;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 60/62] selinux: never allow relabeling on context mounts
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 59/62] Input: snvs_pwrkey - initialize necessary driver data before enabling IRQ Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 61/62] x86/mce: Improve error message when kernel cannot recover, p2 Greg Kroah-Hartman
` (5 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ondrej Mosnacek, Stephen Smalley, Paul Moore
From: Ondrej Mosnacek <omosnace@redhat.com>
commit a83d6ddaebe541570291205cb538e35ad4ff94f9 upstream.
In the SECURITY_FS_USE_MNTPOINT case we never want to allow relabeling
files/directories, so we should never set the SBLABEL_MNT flag. The
'special handling' in selinux_is_sblabel_mnt() is only intended for when
the behavior is set to SECURITY_FS_USE_GENFS.
While there, make the logic in selinux_is_sblabel_mnt() more explicit
and add a BUILD_BUG_ON() to make sure that introducing a new
SECURITY_FS_USE_* forces a review of the logic.
Fixes: d5f3a5f6e7e7 ("selinux: add security in-core xattr support for pstore and debugfs")
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Reviewed-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/selinux/hooks.c | 40 +++++++++++++++++++++++++++++++---------
1 file changed, 31 insertions(+), 9 deletions(-)
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -467,21 +467,43 @@ static int may_context_mount_inode_relab
return rc;
}
-static int selinux_is_sblabel_mnt(struct super_block *sb)
+static int selinux_is_genfs_special_handling(struct super_block *sb)
{
- struct superblock_security_struct *sbsec = sb->s_security;
-
- return sbsec->behavior == SECURITY_FS_USE_XATTR ||
- sbsec->behavior == SECURITY_FS_USE_TRANS ||
- sbsec->behavior == SECURITY_FS_USE_TASK ||
- sbsec->behavior == SECURITY_FS_USE_NATIVE ||
- /* Special handling. Genfs but also in-core setxattr handler */
- !strcmp(sb->s_type->name, "sysfs") ||
+ /* Special handling. Genfs but also in-core setxattr handler */
+ return !strcmp(sb->s_type->name, "sysfs") ||
!strcmp(sb->s_type->name, "pstore") ||
!strcmp(sb->s_type->name, "debugfs") ||
!strcmp(sb->s_type->name, "rootfs");
}
+static int selinux_is_sblabel_mnt(struct super_block *sb)
+{
+ struct superblock_security_struct *sbsec = sb->s_security;
+
+ /*
+ * IMPORTANT: Double-check logic in this function when adding a new
+ * SECURITY_FS_USE_* definition!
+ */
+ BUILD_BUG_ON(SECURITY_FS_USE_MAX != 7);
+
+ switch (sbsec->behavior) {
+ case SECURITY_FS_USE_XATTR:
+ case SECURITY_FS_USE_TRANS:
+ case SECURITY_FS_USE_TASK:
+ case SECURITY_FS_USE_NATIVE:
+ return 1;
+
+ case SECURITY_FS_USE_GENFS:
+ return selinux_is_genfs_special_handling(sb);
+
+ /* Never allow relabeling on context mounts */
+ case SECURITY_FS_USE_MNTPOINT:
+ case SECURITY_FS_USE_NONE:
+ default:
+ return 0;
+ }
+}
+
static int sb_finish_set_opts(struct super_block *sb)
{
struct superblock_security_struct *sbsec = sb->s_security;
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 61/62] x86/mce: Improve error message when kernel cannot recover, p2
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 60/62] selinux: never allow relabeling on context mounts Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-06 14:33 ` [PATCH 4.9 62/62] media: v4l2: i2c: ov7670: Fix PLL bypass register values Greg Kroah-Hartman
` (4 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tony Luck, Borislav Petkov,
H. Peter Anvin, Ingo Molnar, Pu Wen, Thomas Gleixner, x86-ml
From: Tony Luck <tony.luck@intel.com>
commit 41f035a86b5b72a4f947c38e94239d20d595352a upstream.
In
c7d606f560e4 ("x86/mce: Improve error message when kernel cannot recover")
a case was added for a machine check caused by a DATA access to poison
memory from the kernel. A case should have been added also for an
uncorrectable error during an instruction fetch in the kernel.
Add that extra case so the error message now reads:
mce: [Hardware Error]: Machine check: Instruction fetch error in kernel
Fixes: c7d606f560e4 ("x86/mce: Improve error message when kernel cannot recover")
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Pu Wen <puwen@hygon.cn>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20190225205940.15226-1-tony.luck@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce-severity.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -148,6 +148,11 @@ static struct severity {
SER, MASK(MCI_STATUS_OVER|MCI_UC_SAR|MCI_ADDR|MCACOD, MCI_UC_SAR|MCI_ADDR|MCACOD_DATA),
KERNEL
),
+ MCESEV(
+ PANIC, "Instruction fetch error in kernel",
+ SER, MASK(MCI_STATUS_OVER|MCI_UC_SAR|MCI_ADDR|MCACOD, MCI_UC_SAR|MCI_ADDR|MCACOD_INSTR),
+ KERNEL
+ ),
#endif
MCESEV(
PANIC, "Action required: unknown MCACOD",
^ permalink raw reply [flat|nested] 73+ messages in thread* [PATCH 4.9 62/62] media: v4l2: i2c: ov7670: Fix PLL bypass register values
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 61/62] x86/mce: Improve error message when kernel cannot recover, p2 Greg Kroah-Hartman
@ 2019-05-06 14:33 ` Greg Kroah-Hartman
2019-05-07 8:12 ` [PATCH 4.9 00/62] 4.9.174-stable review Naresh Kamboju
` (3 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Greg Kroah-Hartman @ 2019-05-06 14:33 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jacopo Mondi, Sakari Ailus,
Mauro Carvalho Chehab
From: Jacopo Mondi <jacopo+renesas@jmondi.org>
commit 61da76beef1e4f0b6ba7be4f8d0cf0dac7ce1f55 upstream.
The following commits:
commit f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675")
commit 04ee6d92047e ("[media] media: ov7670: add possibility to bypass pll for ov7675")
introduced the ability to bypass PLL multiplier and use input clock (xvclk)
as pixel clock output frequency for ov7675 sensor.
PLL is bypassed using register DBLV[7:6], according to ov7670 and ov7675
sensor manuals. Macros used to set DBLV register seem wrong in the
driver, as their values do not match what reported in the datasheet.
Fix by changing DBLV_* macros to use bits [7:6] and set bits [3:0] to
default 0x0a reserved value (according to datasheets).
While at there, remove a write to DBLV register in
"ov7675_set_framerate()" that over-writes the previous one to the same
register that takes "info->pll_bypass" flag into account instead of setting PLL
multiplier to 4x unconditionally.
And, while at there, since "info->pll_bypass" is only used in
set/get_framerate() functions used by ov7675 only, it is not necessary
to check for the device id at probe time to make sure that when using
ov7670 "info->pll_bypass" is set to false.
Fixes: f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675")
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/media/i2c/ov7670.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -155,10 +155,10 @@ MODULE_PARM_DESC(debug, "Debug level (0-
#define REG_GFIX 0x69 /* Fix gain control */
#define REG_DBLV 0x6b /* PLL control an debugging */
-#define DBLV_BYPASS 0x00 /* Bypass PLL */
-#define DBLV_X4 0x01 /* clock x4 */
-#define DBLV_X6 0x10 /* clock x6 */
-#define DBLV_X8 0x11 /* clock x8 */
+#define DBLV_BYPASS 0x0a /* Bypass PLL */
+#define DBLV_X4 0x4a /* clock x4 */
+#define DBLV_X6 0x8a /* clock x6 */
+#define DBLV_X8 0xca /* clock x8 */
#define REG_REG76 0x76 /* OV's name */
#define R76_BLKPCOR 0x80 /* Black pixel correction enable */
@@ -833,7 +833,7 @@ static int ov7675_set_framerate(struct v
if (ret < 0)
return ret;
- return ov7670_write(sd, REG_DBLV, DBLV_X4);
+ return 0;
}
static void ov7670_get_framerate_legacy(struct v4l2_subdev *sd,
@@ -1578,11 +1578,7 @@ static int ov7670_probe(struct i2c_clien
if (config->clock_speed)
info->clock_speed = config->clock_speed;
- /*
- * It should be allowed for ov7670 too when it is migrated to
- * the new frame rate formula.
- */
- if (config->pll_bypass && id->driver_data != MODEL_OV7670)
+ if (config->pll_bypass)
info->pll_bypass = true;
if (config->pclk_hb_disable)
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 00/62] 4.9.174-stable review
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2019-05-06 14:33 ` [PATCH 4.9 62/62] media: v4l2: i2c: ov7670: Fix PLL bypass register values Greg Kroah-Hartman
@ 2019-05-07 8:12 ` Naresh Kamboju
2019-05-07 12:44 ` Jon Hunter
` (2 subsequent siblings)
65 siblings, 0 replies; 73+ messages in thread
From: Naresh Kamboju @ 2019-05-07 8:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
On Mon, 6 May 2019 at 20:18, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.9.174 release.
> There are 62 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 08 May 2019 02:29:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.174-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
The results from 4.9.174-rc2,
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Summary
------------------------------------------------------------------------
kernel: 4.9.174-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 43d95ffd279c80b33fcc2c0b327c1195e3331185
git describe: v4.9.173-61-g43d95ffd279c
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.173-61-g43d95ffd279c
No regressions (compared to build v4.9.173)
No fixes (compared to build v4.9.173)
Ran 23406 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 00/62] 4.9.174-stable review
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2019-05-07 8:12 ` [PATCH 4.9 00/62] 4.9.174-stable review Naresh Kamboju
@ 2019-05-07 12:44 ` Jon Hunter
2019-05-07 18:38 ` Guenter Roeck
2019-05-07 20:34 ` shuah
65 siblings, 0 replies; 73+ messages in thread
From: Jon Hunter @ 2019-05-07 12:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, ben.hutchings,
lkft-triage, stable, linux-tegra
On 06/05/2019 15:32, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.174 release.
> There are 62 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 08 May 2019 02:29:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.174-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests are passing for Tegra ...
Test results for stable-v4.9:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
24 tests: 24 pass, 0 fail
Linux version: 4.9.174-rc2-g43d95ff
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Cheers
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 00/62] 4.9.174-stable review
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2019-05-07 12:44 ` Jon Hunter
@ 2019-05-07 18:38 ` Guenter Roeck
2019-05-07 20:34 ` shuah
65 siblings, 0 replies; 73+ messages in thread
From: Guenter Roeck @ 2019-05-07 18:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, ben.hutchings,
lkft-triage, stable
On Mon, May 06, 2019 at 04:32:31PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.174 release.
> There are 62 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 08 May 2019 02:29:15 PM UTC.
> Anything received after that time might be too late.
>
Build results:
total: 172 pass: 172 fail: 0
Qemu test results:
total: 320 pass: 320 fail: 0
Guenter
^ permalink raw reply [flat|nested] 73+ messages in thread* Re: [PATCH 4.9 00/62] 4.9.174-stable review
2019-05-06 14:32 [PATCH 4.9 00/62] 4.9.174-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2019-05-07 18:38 ` Guenter Roeck
@ 2019-05-07 20:34 ` shuah
65 siblings, 0 replies; 73+ messages in thread
From: shuah @ 2019-05-07 20:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, lkft-triage,
stable, shuah
On 5/6/19 8:32 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.174 release.
> There are 62 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 08 May 2019 02:29:15 PM UTC.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.174-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 73+ messages in thread