From: Greg Kroah-Hartman Date: Wed, 15 Apr 2020 10:15:54 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v4.19.116~54 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f00d7b9937ecc75023651298d12fd543eed5d18d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: alsa-hda-initialize-power_state-field-properly.patch btrfs-incremental-send-fix-invalid-memory-access.patch futex-futex_wake_op-do-not-fail-on-invalid-op.patch ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.patch revert-videobuf2-v4l2-verify-planes-array-in-buffer-dequeueing.patch xen-netfront-rework-the-fix-for-rx-stall-during-oom-and-network-stress.patch --- diff --git a/queue-4.4/alsa-hda-initialize-power_state-field-properly.patch b/queue-4.4/alsa-hda-initialize-power_state-field-properly.patch new file mode 100644 index 00000000000..5406bc3bc1c --- /dev/null +++ b/queue-4.4/alsa-hda-initialize-power_state-field-properly.patch @@ -0,0 +1,35 @@ +From 183ab39eb0ea9879bb68422a83e65f750f3192f0 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Sat, 13 Apr 2019 10:04:49 +0200 +Subject: ALSA: hda: Initialize power_state field properly + +From: Takashi Iwai + +commit 183ab39eb0ea9879bb68422a83e65f750f3192f0 upstream. + +The recent commit 98081ca62cba ("ALSA: hda - Record the current power +state before suspend/resume calls") made the HD-audio driver to store +the PM state in power_state field. This forgot, however, the +initialization at power up. Although the codec drivers usually don't +need to refer to this field in the normal operation, let's initialize +it properly for consistency. + +Fixes: 98081ca62cba ("ALSA: hda - Record the current power state before suspend/resume calls") +Signed-off-by: Takashi Iwai +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_codec.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/hda_codec.c ++++ b/sound/pci/hda/hda_codec.c +@@ -876,6 +876,7 @@ int snd_hda_codec_new(struct hda_bus *bu + + /* power-up all before initialization */ + hda_set_power_state(codec, AC_PWRST_D0); ++ codec->core.dev.power.power_state = PMSG_ON; + + snd_hda_codec_proc_new(codec); + diff --git a/queue-4.4/btrfs-incremental-send-fix-invalid-memory-access.patch b/queue-4.4/btrfs-incremental-send-fix-invalid-memory-access.patch new file mode 100644 index 00000000000..6d3400d5f5e --- /dev/null +++ b/queue-4.4/btrfs-incremental-send-fix-invalid-memory-access.patch @@ -0,0 +1,156 @@ +From 24e52b11e0ca788513b945a87b57cc0522a92933 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 6 Jul 2017 15:31:46 +0100 +Subject: Btrfs: incremental send, fix invalid memory access + +From: Filipe Manana + +commit 24e52b11e0ca788513b945a87b57cc0522a92933 upstream. + +When doing an incremental send, while processing an extent that changed +between the parent and send snapshots and that extent was an inline extent +in the parent snapshot, it's possible to access a memory region beyond +the end of leaf if the inline extent is very small and it is the first +item in a leaf. + +An example scenario is described below. + +The send snapshot has the following leaf: + + leaf 33865728 items 33 free space 773 generation 46 owner 5 + fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7 + chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f + (...) + item 14 key (335 EXTENT_DATA 0) itemoff 3052 itemsize 53 + generation 36 type 1 (regular) + extent data disk byte 12791808 nr 4096 + extent data offset 0 nr 4096 ram 4096 + extent compression 0 (none) + item 15 key (335 EXTENT_DATA 8192) itemoff 2999 itemsize 53 + generation 36 type 1 (regular) + extent data disk byte 138170368 nr 225280 + extent data offset 0 nr 225280 ram 225280 + extent compression 0 (none) + (...) + +And the parent snapshot has the following leaf: + + leaf 31272960 items 17 free space 17 generation 31 owner 5 + fs uuid ab7090d8-dafd-4fb9-9246-723b6d2e2fb7 + chunk uuid 2d16478c-c704-4ab9-b574-68bff2281b1f + item 0 key (335 EXTENT_DATA 0) itemoff 3951 itemsize 44 + generation 31 type 0 (inline) + inline extent data size 23 ram_bytes 613 compression 1 (zlib) + (...) + +When computing the send stream, it is detected that the extent of inode +335, at file offset 0, and at fs/btrfs/send.c:is_extent_unchanged() we +grab the leaf from the parent snapshot and access the inline extent item. +However, before jumping to the 'out' label, we access the 'offset' and +'disk_bytenr' fields of the extent item, which should not be done for +inline extents since the inlined data starts at the offset of the +'disk_bytenr' field and can be very small. For example accessing the +'offset' field of the file extent item results in the following trace: + +[ 599.705368] general protection fault: 0000 [#1] PREEMPT SMP +[ 599.706296] Modules linked in: btrfs psmouse i2c_piix4 ppdev acpi_cpufreq serio_raw parport_pc i2c_core evdev tpm_tis tpm_tis_core sg pcspkr parport tpm button su$ +[ 599.709340] CPU: 7 PID: 5283 Comm: btrfs Not tainted 4.10.0-rc8-btrfs-next-46+ #1 +[ 599.709340] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 +[ 599.709340] task: ffff88023eedd040 task.stack: ffffc90006658000 +[ 599.709340] RIP: 0010:read_extent_buffer+0xdb/0xf4 [btrfs] +[ 599.709340] RSP: 0018:ffffc9000665ba00 EFLAGS: 00010286 +[ 599.709340] RAX: db73880000000000 RBX: 0000000000000000 RCX: 0000000000000001 +[ 599.709340] RDX: ffffc9000665ba60 RSI: db73880000000000 RDI: ffffc9000665ba5f +[ 599.709340] RBP: ffffc9000665ba30 R08: 0000000000000001 R09: ffff88020dc5e098 +[ 599.709340] R10: 0000000000001000 R11: 0000160000000000 R12: 6db6db6db6db6db7 +[ 599.709340] R13: ffff880000000000 R14: 0000000000000000 R15: ffff88020dc5e088 +[ 599.709340] FS: 00007f519555a8c0(0000) GS:ffff88023f3c0000(0000) knlGS:0000000000000000 +[ 599.709340] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 599.709340] CR2: 00007f1411afd000 CR3: 0000000235f8e000 CR4: 00000000000006e0 +[ 599.709340] Call Trace: +[ 599.709340] btrfs_get_token_64+0x93/0xce [btrfs] +[ 599.709340] ? printk+0x48/0x50 +[ 599.709340] btrfs_get_64+0xb/0xd [btrfs] +[ 599.709340] process_extent+0x3a1/0x1106 [btrfs] +[ 599.709340] ? btree_read_extent_buffer_pages+0x5/0xef [btrfs] +[ 599.709340] changed_cb+0xb03/0xb3d [btrfs] +[ 599.709340] ? btrfs_get_token_32+0x7a/0xcc [btrfs] +[ 599.709340] btrfs_compare_trees+0x432/0x53d [btrfs] +[ 599.709340] ? process_extent+0x1106/0x1106 [btrfs] +[ 599.709340] btrfs_ioctl_send+0x960/0xe26 [btrfs] +[ 599.709340] btrfs_ioctl+0x181b/0x1fed [btrfs] +[ 599.709340] ? trace_hardirqs_on_caller+0x150/0x1ac +[ 599.709340] vfs_ioctl+0x21/0x38 +[ 599.709340] ? vfs_ioctl+0x21/0x38 +[ 599.709340] do_vfs_ioctl+0x611/0x645 +[ 599.709340] ? rcu_read_unlock+0x5b/0x5d +[ 599.709340] ? __fget+0x6d/0x79 +[ 599.709340] SyS_ioctl+0x57/0x7b +[ 599.709340] entry_SYSCALL_64_fastpath+0x18/0xad +[ 599.709340] RIP: 0033:0x7f51945eec47 +[ 599.709340] RSP: 002b:00007ffc21c13e98 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 +[ 599.709340] RAX: ffffffffffffffda RBX: ffffffff81096459 RCX: 00007f51945eec47 +[ 599.709340] RDX: 00007ffc21c13f20 RSI: 0000000040489426 RDI: 0000000000000004 +[ 599.709340] RBP: ffffc9000665bf98 R08: 00007f519450d700 R09: 00007f519450d700 +[ 599.709340] R10: 00007f519450d9d0 R11: 0000000000000202 R12: 0000000000000046 +[ 599.709340] R13: ffffc9000665bf78 R14: 0000000000000000 R15: 00007f5195574040 +[ 599.709340] ? trace_hardirqs_off_caller+0x43/0xb1 +[ 599.709340] Code: 29 f0 49 39 d8 4c 0f 47 c3 49 03 81 58 01 00 00 44 89 c1 4c 01 c2 4c 29 c3 48 c1 f8 03 49 0f af c4 48 c1 e0 0c 4c 01 e8 48 01 c6 a4 31 f6 4$ +[ 599.709340] RIP: read_extent_buffer+0xdb/0xf4 [btrfs] RSP: ffffc9000665ba00 +[ 599.762057] ---[ end trace fe00d7af61b9f49e ]--- + +This is because the 'offset' field starts at an offset of 37 bytes +(offsetof(struct btrfs_file_extent_item, offset)), has a length of 8 +bytes and therefore attemping to read it causes a 1 byte access beyond +the end of the leaf, as the first item's content in a leaf is located +at the tail of the leaf, the item size is 44 bytes and the offset of +that field plus its length (37 + 8 = 45) goes beyond the item's size +by 1 byte. + +So fix this by accessing the 'offset' and 'disk_bytenr' fields after +jumping to the 'out' label if we are processing an inline extent. We +move the reading operation of the 'disk_bytenr' field too because we +have the same problem as for the 'offset' field explained above when +the inline data is less then 8 bytes. The access to the 'generation' +field is also moved but just for the sake of grouping access to all +the fields. + +Fixes: e1cbfd7bf6da ("Btrfs: send, fix file hole not being preserved due to inline extent") +Cc: # v4.12+ +Signed-off-by: Filipe Manana +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/send.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -5022,15 +5022,12 @@ static int is_extent_unchanged(struct se + goto out; + } + +- right_disknr = btrfs_file_extent_disk_bytenr(eb, ei); + if (right_type == BTRFS_FILE_EXTENT_INLINE) { + right_len = btrfs_file_extent_inline_len(eb, slot, ei); + right_len = PAGE_ALIGN(right_len); + } else { + right_len = btrfs_file_extent_num_bytes(eb, ei); + } +- right_offset = btrfs_file_extent_offset(eb, ei); +- right_gen = btrfs_file_extent_generation(eb, ei); + + /* + * Are we at extent 8? If yes, we know the extent is changed. +@@ -5055,6 +5052,10 @@ static int is_extent_unchanged(struct se + goto out; + } + ++ right_disknr = btrfs_file_extent_disk_bytenr(eb, ei); ++ right_offset = btrfs_file_extent_offset(eb, ei); ++ right_gen = btrfs_file_extent_generation(eb, ei); ++ + left_offset_fixed = left_offset; + if (key.offset < ekey->offset) { + /* Fix the right offset for 2a and 7. */ diff --git a/queue-4.4/futex-futex_wake_op-do-not-fail-on-invalid-op.patch b/queue-4.4/futex-futex_wake_op-do-not-fail-on-invalid-op.patch new file mode 100644 index 00000000000..e1ace9631db --- /dev/null +++ b/queue-4.4/futex-futex_wake_op-do-not-fail-on-invalid-op.patch @@ -0,0 +1,87 @@ +From e78c38f6bdd900b2ad9ac9df8eff58b745dc5b3c Mon Sep 17 00:00:00 2001 +From: Jiri Slaby +Date: Mon, 23 Oct 2017 13:41:51 +0200 +Subject: futex: futex_wake_op, do not fail on invalid op + +From: Jiri Slaby + +commit e78c38f6bdd900b2ad9ac9df8eff58b745dc5b3c upstream. + +In commit 30d6e0a4190d ("futex: Remove duplicated code and fix undefined +behaviour"), I let FUTEX_WAKE_OP to fail on invalid op. Namely when op +should be considered as shift and the shift is out of range (< 0 or > 31). + +But strace's test suite does this madness: + + futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xa0caffee); + futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xbadfaced); + futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xffffffff); + +When I pick the first 0xa0caffee, it decodes as: + + 0x80000000 & 0xa0caffee: oparg is shift + 0x70000000 & 0xa0caffee: op is FUTEX_OP_OR + 0x0f000000 & 0xa0caffee: cmp is FUTEX_OP_CMP_EQ + 0x00fff000 & 0xa0caffee: oparg is sign-extended 0xcaf = -849 + 0x00000fff & 0xa0caffee: cmparg is sign-extended 0xfee = -18 + +That means the op tries to do this: + + (futex |= (1 << (-849))) == -18 + +which is completely bogus. The new check of op in the code is: + + if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) { + if (oparg < 0 || oparg > 31) + return -EINVAL; + oparg = 1 << oparg; + } + +which results obviously in the "Invalid argument" errno: + + FAIL: futex + =========== + + futex(0x7fabd78bcffc, 0x5, 0xfacefeed, 0xb, 0x7fabd78bcffc, 0xa0caffee) = -1: Invalid argument + futex.test: failed test: ../futex failed with code 1 + +So let us soften the failure to print only a (ratelimited) message, crop +the value and continue as if it were right. When userspace keeps up, we +can switch this to return -EINVAL again. + +[v2] Do not return 0 immediatelly, proceed with the cropped value. + +Fixes: 30d6e0a4190d ("futex: Remove duplicated code and fix undefined behaviour") +Signed-off-by: Jiri Slaby +Cc: Ingo Molnar +Cc: Peter Zijlstra +Cc: Darren Hart +Signed-off-by: Linus Torvalds +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -1479,8 +1479,16 @@ static int futex_atomic_op_inuser(unsign + int oldval, ret; + + if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) { +- if (oparg < 0 || oparg > 31) +- return -EINVAL; ++ if (oparg < 0 || oparg > 31) { ++ char comm[sizeof(current->comm)]; ++ /* ++ * kill this print and return -EINVAL when userspace ++ * is sane again ++ */ ++ pr_info_ratelimited("futex_wake_op: %s tries to shift op by %d; fix this program\n", ++ get_task_comm(comm, current), oparg); ++ oparg &= 31; ++ } + oparg = 1 << oparg; + } + diff --git a/queue-4.4/ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.patch b/queue-4.4/ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.patch new file mode 100644 index 00000000000..4f35c7c2451 --- /dev/null +++ b/queue-4.4/ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.patch @@ -0,0 +1,102 @@ +From 1f80bd6a6cc8358b81194e1f5fc16449947396ec Mon Sep 17 00:00:00 2001 +From: Alex Vesker +Date: Thu, 21 Dec 2017 17:38:27 +0200 +Subject: IB/ipoib: Fix lockdep issue found on ipoib_ib_dev_heavy_flush + +From: Alex Vesker + +commit 1f80bd6a6cc8358b81194e1f5fc16449947396ec upstream. + +The locking order of vlan_rwsem (LOCK A) and then rtnl (LOCK B), +contradicts other flows such as ipoib_open possibly causing a deadlock. +To prevent this deadlock heavy flush is called with RTNL locked and +only then tries to acquire vlan_rwsem. +This deadlock is possible only when there are child interfaces. + +[ 140.941758] ====================================================== +[ 140.946276] WARNING: possible circular locking dependency detected +[ 140.950950] 4.15.0-rc1+ #9 Tainted: G O +[ 140.954797] ------------------------------------------------------ +[ 140.959424] kworker/u32:1/146 is trying to acquire lock: +[ 140.963450] (rtnl_mutex){+.+.}, at: [] __ipoib_ib_dev_flush+0x2da/0x4e0 [ib_ipoib] +[ 140.970006] +but task is already holding lock: +[ 140.975141] (&priv->vlan_rwsem){++++}, at: [] __ipoib_ib_dev_flush+0x51/0x4e0 [ib_ipoib] +[ 140.982105] +which lock already depends on the new lock. +[ 140.990023] +the existing dependency chain (in reverse order) is: +[ 140.998650] +-> #1 (&priv->vlan_rwsem){++++}: +[ 141.005276] down_read+0x4d/0xb0 +[ 141.009560] ipoib_open+0xad/0x120 [ib_ipoib] +[ 141.014400] __dev_open+0xcb/0x140 +[ 141.017919] __dev_change_flags+0x1a4/0x1e0 +[ 141.022133] dev_change_flags+0x23/0x60 +[ 141.025695] devinet_ioctl+0x704/0x7d0 +[ 141.029156] sock_do_ioctl+0x20/0x50 +[ 141.032526] sock_ioctl+0x221/0x300 +[ 141.036079] do_vfs_ioctl+0xa6/0x6d0 +[ 141.039656] SyS_ioctl+0x74/0x80 +[ 141.042811] entry_SYSCALL_64_fastpath+0x1f/0x96 +[ 141.046891] +-> #0 (rtnl_mutex){+.+.}: +[ 141.051701] lock_acquire+0xd4/0x220 +[ 141.055212] __mutex_lock+0x88/0x970 +[ 141.058631] __ipoib_ib_dev_flush+0x2da/0x4e0 [ib_ipoib] +[ 141.063160] __ipoib_ib_dev_flush+0x71/0x4e0 [ib_ipoib] +[ 141.067648] process_one_work+0x1f5/0x610 +[ 141.071429] worker_thread+0x4a/0x3f0 +[ 141.074890] kthread+0x141/0x180 +[ 141.078085] ret_from_fork+0x24/0x30 +[ 141.081559] + +other info that might help us debug this: +[ 141.088967] Possible unsafe locking scenario: +[ 141.094280] CPU0 CPU1 +[ 141.097953] ---- ---- +[ 141.101640] lock(&priv->vlan_rwsem); +[ 141.104771] lock(rtnl_mutex); +[ 141.109207] lock(&priv->vlan_rwsem); +[ 141.114032] lock(rtnl_mutex); +[ 141.116800] + *** DEADLOCK *** + +Fixes: b4b678b06f6e ("IB/ipoib: Grab rtnl lock on heavy flush when calling ndo_open/stop") +Signed-off-by: Alex Vesker +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/ulp/ipoib/ipoib_ib.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c ++++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c +@@ -1057,13 +1057,10 @@ static void __ipoib_ib_dev_flush(struct + ipoib_ib_dev_down(dev); + + if (level == IPOIB_FLUSH_HEAVY) { +- rtnl_lock(); + if (test_bit(IPOIB_FLAG_INITIALIZED, &priv->flags)) + ipoib_ib_dev_stop(dev); + +- result = ipoib_ib_dev_open(dev); +- rtnl_unlock(); +- if (result) ++ if (ipoib_ib_dev_open(dev)) + return; + + if (netif_queue_stopped(dev)) +@@ -1102,7 +1099,9 @@ void ipoib_ib_dev_flush_heavy(struct wor + struct ipoib_dev_priv *priv = + container_of(work, struct ipoib_dev_priv, flush_heavy); + ++ rtnl_lock(); + __ipoib_ib_dev_flush(priv, IPOIB_FLUSH_HEAVY, 0); ++ rtnl_unlock(); + } + + void ipoib_ib_dev_cleanup(struct net_device *dev) diff --git a/queue-4.4/revert-videobuf2-v4l2-verify-planes-array-in-buffer-dequeueing.patch b/queue-4.4/revert-videobuf2-v4l2-verify-planes-array-in-buffer-dequeueing.patch new file mode 100644 index 00000000000..9c18cadd3ff --- /dev/null +++ b/queue-4.4/revert-videobuf2-v4l2-verify-planes-array-in-buffer-dequeueing.patch @@ -0,0 +1,88 @@ +From 93f0750dcdaed083d6209b01e952e98ca730db66 Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Wed, 11 May 2016 13:09:34 -0300 +Subject: Revert "[media] videobuf2-v4l2: Verify planes array in buffer dequeueing" + +From: Mauro Carvalho Chehab + +commit 93f0750dcdaed083d6209b01e952e98ca730db66 upstream. + +This patch causes a Kernel panic when called on a DVB driver. + +This was also reported by David R : + +May 7 14:47:35 server kernel: [ 501.247123] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 +May 7 14:47:35 server kernel: [ 501.247239] IP: [] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2] +May 7 14:47:35 server kernel: [ 501.247354] PGD cae6f067 PUD ca99c067 PMD 0 +May 7 14:47:35 server kernel: [ 501.247426] Oops: 0000 [#1] SMP +May 7 14:47:35 server kernel: [ 501.247482] Modules linked in: xfs tun xt_connmark xt_TCPMSS xt_tcpmss xt_owner xt_REDIRECT nf_nat_redirect xt_nat ipt_MASQUERADE nf_nat_masquerade_ipv4 ts_kmp ts_bm xt_string ipt_REJECT nf_reject_ipv4 xt_recent xt_conntrack xt_multiport xt_pkttype xt_tcpudp xt_mark nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables ip6table_filter ip6_tables x_tables pppoe pppox dm_crypt ts2020 regmap_i2c ds3000 cx88_dvb dvb_pll cx88_vp3054_i2c mt352 videobuf2_dvb cx8800 cx8802 cx88xx pl2303 tveeprom videobuf2_dma_sg ppdev videobuf2_memops videobuf2_v4l2 videobuf2_core dvb_usb_digitv snd_hda_codec_via snd_hda_codec_hdmi snd_hda_codec_generic radeon dvb_usb snd_hda_intel amd64_edac_mod serio_raw snd_hda_codec edac_core fbcon k10temp bitblit softcursor snd_hda_core font snd_pcm_oss i2c_piix4 snd_mixer_oss tileblit drm_kms_helper syscopyarea snd_pcm snd_seq_dummy sysfillrect snd_seq_oss sysimgblt fb_sys_fops ttm snd_seq_midi r8169 snd_rawmidi drm snd_seq_midi_event e1000e snd_seq snd_seq_device snd_timer snd ptp pps_core i2c_algo_bit soundcore parport_pc ohci_pci shpchp tpm_tis tpm nfsd auth_rpcgss oid_registry hwmon_vid exportfs nfs_acl mii nfs bonding lockd grace lp sunrpc parport +May 7 14:47:35 server kernel: [ 501.249564] CPU: 1 PID: 6889 Comm: vb2-cx88[0] Not tainted 4.5.3 #3 +May 7 14:47:35 server kernel: [ 501.249644] Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 0211 07/08/2009 +May 7 14:47:35 server kernel: [ 501.249767] task: ffff8800aebf3600 ti: ffff8801e07a0000 task.ti: ffff8801e07a0000 +May 7 14:47:35 server kernel: [ 501.249861] RIP: 0010:[] [] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2] +May 7 14:47:35 server kernel: [ 501.250002] RSP: 0018:ffff8801e07a3de8 EFLAGS: 00010086 +May 7 14:47:35 server kernel: [ 501.250071] RAX: 0000000000000283 RBX: ffff880210dc5000 RCX: 0000000000000283 +May 7 14:47:35 server kernel: [ 501.250161] RDX: ffffffffa0222cf0 RSI: 0000000000000000 RDI: ffff880210dc5014 +May 7 14:47:35 server kernel: [ 501.250251] RBP: ffff8801e07a3df8 R08: ffff8801e07a0000 R09: 0000000000000000 +May 7 14:47:35 server kernel: [ 501.250348] R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800cda2a9d8 +May 7 14:47:35 server kernel: [ 501.250438] R13: ffff880210dc51b8 R14: 0000000000000000 R15: ffff8800cda2a828 +May 7 14:47:35 server kernel: [ 501.250528] FS: 00007f5b77fff700(0000) GS:ffff88021fc40000(0000) knlGS:00000000adaffb40 +May 7 14:47:35 server kernel: [ 501.250631] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b +May 7 14:47:35 server kernel: [ 501.250704] CR2: 0000000000000004 CR3: 00000000ca19d000 CR4: 00000000000006e0 +May 7 14:47:35 server kernel: [ 501.250794] Stack: +May 7 14:47:35 server kernel: [ 501.250822] ffff8801e07a3df8 ffffffffa0222cfd ffff8801e07a3e70 ffffffffa0236beb +May 7 14:47:35 server kernel: [ 501.250937] 0000000000000283 ffff8801e07a3e94 0000000000000000 0000000000000000 +May 7 14:47:35 server kernel: [ 501.251051] ffff8800aebf3600 ffffffff8108d8e0 ffff8801e07a3e38 ffff8801e07a3e38 +May 7 14:47:35 server kernel: [ 501.251165] Call Trace: +May 7 14:47:35 server kernel: [ 501.251200] [] ? __verify_planes_array_core+0xd/0x10 [videobuf2_v4l2] +May 7 14:47:35 server kernel: [ 501.251306] [] vb2_core_dqbuf+0x2eb/0x4c0 [videobuf2_core] +May 7 14:47:35 server kernel: [ 501.251398] [] ? prepare_to_wait_event+0x100/0x100 +May 7 14:47:35 server kernel: [ 501.251482] [] vb2_thread+0x1cb/0x220 [videobuf2_core] +May 7 14:47:35 server kernel: [ 501.251569] [] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core] +May 7 14:47:35 server kernel: [ 501.251662] [] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core] +May 7 14:47:35 server kernel: [ 501.255982] [] kthread+0xc4/0xe0 +May 7 14:47:35 server kernel: [ 501.260292] [] ? kthread_park+0x50/0x50 +May 7 14:47:35 server kernel: [ 501.264615] [] ret_from_fork+0x3f/0x70 +May 7 14:47:35 server kernel: [ 501.268962] [] ? kthread_park+0x50/0x50 +May 7 14:47:35 server kernel: [ 501.273216] Code: 0d 01 74 16 48 8b 46 28 48 8b 56 30 48 89 87 d0 01 00 00 48 89 97 d8 01 00 00 5d c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 <8b> 46 04 48 89 e5 8d 50 f7 31 c0 83 fa 01 76 02 5d c3 48 83 7e +May 7 14:47:35 server kernel: [ 501.282146] RIP [] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2] +May 7 14:47:35 server kernel: [ 501.286391] RSP +May 7 14:47:35 server kernel: [ 501.290619] CR2: 0000000000000004 +May 7 14:47:35 server kernel: [ 501.294786] ---[ end trace b2b354153ccad110 ]--- + +This reverts commit 2c1f6951a8a82e6de0d82b1158b5e493fc6c54ab. + +Cc: Sakari Ailus +Cc: Hans Verkuil +Cc: stable@vger.kernel.org +Fixes: 2c1f6951a8a8 ("[media] videobuf2-v4l2: Verify planes array in buffer dequeueing") +Signed-off-by: Mauro Carvalho Chehab +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/v4l2-core/videobuf2-v4l2.c | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/drivers/media/v4l2-core/videobuf2-v4l2.c ++++ b/drivers/media/v4l2-core/videobuf2-v4l2.c +@@ -67,11 +67,6 @@ static int __verify_planes_array(struct + return 0; + } + +-static int __verify_planes_array_core(struct vb2_buffer *vb, const void *pb) +-{ +- return __verify_planes_array(vb, pb); +-} +- + /** + * __verify_length() - Verify that the bytesused value for each plane fits in + * the plane length and that the data offset doesn't exceed the bytesused value. +@@ -436,7 +431,6 @@ static int __fill_vb2_buffer(struct vb2_ + } + + static const struct vb2_buf_ops v4l2_buf_ops = { +- .verify_planes_array = __verify_planes_array_core, + .fill_user_buffer = __fill_v4l2_buffer, + .fill_vb2_buffer = __fill_vb2_buffer, + .set_timestamp = __set_timestamp, diff --git a/queue-4.4/series b/queue-4.4/series index 11904d36b0b..7d760085591 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -32,3 +32,9 @@ signal-extend-exec_id-to-64bits.patch x86-entry-32-add-missing-asm_clac-to-general_protection-entry.patch kvm-x86-allocate-new-rmap-and-large-page-tracking-when-moving-memslot.patch crypto-mxs-dcp-fix-scatterlist-linearization-for-hash.patch +futex-futex_wake_op-do-not-fail-on-invalid-op.patch +revert-videobuf2-v4l2-verify-planes-array-in-buffer-dequeueing.patch +xen-netfront-rework-the-fix-for-rx-stall-during-oom-and-network-stress.patch +alsa-hda-initialize-power_state-field-properly.patch +btrfs-incremental-send-fix-invalid-memory-access.patch +ib-ipoib-fix-lockdep-issue-found-on-ipoib_ib_dev_heavy_flush.patch diff --git a/queue-4.4/xen-netfront-rework-the-fix-for-rx-stall-during-oom-and-network-stress.patch b/queue-4.4/xen-netfront-rework-the-fix-for-rx-stall-during-oom-and-network-stress.patch new file mode 100644 index 00000000000..046acd891e8 --- /dev/null +++ b/queue-4.4/xen-netfront-rework-the-fix-for-rx-stall-during-oom-and-network-stress.patch @@ -0,0 +1,66 @@ +From 538d92912d3190a1dd809233a0d57277459f37b2 Mon Sep 17 00:00:00 2001 +From: Vineeth Remanan Pillai +Date: Tue, 7 Feb 2017 18:59:01 +0000 +Subject: xen-netfront: Rework the fix for Rx stall during OOM and network stress + +From: Vineeth Remanan Pillai + +commit 538d92912d3190a1dd809233a0d57277459f37b2 upstream. + +The commit 90c311b0eeea ("xen-netfront: Fix Rx stall during network +stress and OOM") caused the refill timer to be triggerred almost on +all invocations of xennet_alloc_rx_buffers for certain workloads. +This reworks the fix by reverting to the old behaviour and taking into +consideration the skb allocation failure. Refill timer is now triggered +on insufficient requests or skb allocation failure. + +Signed-off-by: Vineeth Remanan Pillai +Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM) +Reported-by: Boris Ostrovsky +Reviewed-by: Boris Ostrovsky +Signed-off-by: David S. Miller +Cc: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/xen-netfront.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -283,6 +283,7 @@ static void xennet_alloc_rx_buffers(stru + { + RING_IDX req_prod = queue->rx.req_prod_pvt; + int notify; ++ int err = 0; + + if (unlikely(!netif_carrier_ok(queue->info->netdev))) + return; +@@ -297,8 +298,10 @@ static void xennet_alloc_rx_buffers(stru + struct xen_netif_rx_request *req; + + skb = xennet_alloc_one_rx_buffer(queue); +- if (!skb) ++ if (!skb) { ++ err = -ENOMEM; + break; ++ } + + id = xennet_rxidx(req_prod); + +@@ -322,8 +325,13 @@ static void xennet_alloc_rx_buffers(stru + + queue->rx.req_prod_pvt = req_prod; + +- /* Not enough requests? Try again later. */ +- if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) { ++ /* Try again later if there are not enough requests or skb allocation ++ * failed. ++ * Enough requests is quantified as the sum of newly created slots and ++ * the unconsumed slots at the backend. ++ */ ++ if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN || ++ unlikely(err)) { + mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10)); + return; + }