--- /dev/null
+From 183ab39eb0ea9879bb68422a83e65f750f3192f0 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sat, 13 Apr 2019 10:04:49 +0200
+Subject: ALSA: hda: Initialize power_state field properly
+
+From: Takashi Iwai <tiwai@suse.de>
+
+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 <tiwai@suse.de>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 24e52b11e0ca788513b945a87b57cc0522a92933 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 6 Jul 2017 15:31:46 +0100
+Subject: Btrfs: incremental send, fix invalid memory access
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <f3> 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: <stable@vger.kernel.org> # v4.12+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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. */
--- /dev/null
+From e78c38f6bdd900b2ad9ac9df8eff58b745dc5b3c Mon Sep 17 00:00:00 2001
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Mon, 23 Oct 2017 13:41:51 +0200
+Subject: futex: futex_wake_op, do not fail on invalid op
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+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 <jslaby@suse.cz>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Darren Hart <dvhart@infradead.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From 1f80bd6a6cc8358b81194e1f5fc16449947396ec Mon Sep 17 00:00:00 2001
+From: Alex Vesker <valex@mellanox.com>
+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 <valex@mellanox.com>
+
+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: [<ffffffffc083516a>] __ipoib_ib_dev_flush+0x2da/0x4e0 [ib_ipoib]
+[ 140.970006]
+but task is already holding lock:
+[ 140.975141] (&priv->vlan_rwsem){++++}, at: [<ffffffffc0834ee1>] __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 <valex@mellanox.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 93f0750dcdaed083d6209b01e952e98ca730db66 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Date: Wed, 11 May 2016 13:09:34 -0300
+Subject: Revert "[media] videobuf2-v4l2: Verify planes array in buffer dequeueing"
+
+From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+
+commit 93f0750dcdaed083d6209b01e952e98ca730db66 upstream.
+
+This patch causes a Kernel panic when called on a DVB driver.
+
+This was also reported by David R <david@unsolicited.net>:
+
+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: [<ffffffffa0222c71>] __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:[<ffffffffa0222c71>] [<ffffffffa0222c71>] __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] [<ffffffffa0222cfd>] ? __verify_planes_array_core+0xd/0x10 [videobuf2_v4l2]
+May 7 14:47:35 server kernel: [ 501.251306] [<ffffffffa0236beb>] vb2_core_dqbuf+0x2eb/0x4c0 [videobuf2_core]
+May 7 14:47:35 server kernel: [ 501.251398] [<ffffffff8108d8e0>] ? prepare_to_wait_event+0x100/0x100
+May 7 14:47:35 server kernel: [ 501.251482] [<ffffffffa023855b>] vb2_thread+0x1cb/0x220 [videobuf2_core]
+May 7 14:47:35 server kernel: [ 501.251569] [<ffffffffa0238390>] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core]
+May 7 14:47:35 server kernel: [ 501.251662] [<ffffffffa0238390>] ? vb2_core_qbuf+0x230/0x230 [videobuf2_core]
+May 7 14:47:35 server kernel: [ 501.255982] [<ffffffff8106f984>] kthread+0xc4/0xe0
+May 7 14:47:35 server kernel: [ 501.260292] [<ffffffff8106f8c0>] ? kthread_park+0x50/0x50
+May 7 14:47:35 server kernel: [ 501.264615] [<ffffffff81697a5f>] ret_from_fork+0x3f/0x70
+May 7 14:47:35 server kernel: [ 501.268962] [<ffffffff8106f8c0>] ? 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 [<ffffffffa0222c71>] __verify_planes_array.isra.3+0x1/0x80 [videobuf2_v4l2]
+May 7 14:47:35 server kernel: [ 501.286391] RSP <ffff8801e07a3de8>
+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 <sakari.ailus@linux.intel.com>
+Cc: Hans Verkuil <hans.verkuil@cisco.com>
+Cc: stable@vger.kernel.org
+Fixes: 2c1f6951a8a8 ("[media] videobuf2-v4l2: Verify planes array in buffer dequeueing")
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
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
--- /dev/null
+From 538d92912d3190a1dd809233a0d57277459f37b2 Mon Sep 17 00:00:00 2001
+From: Vineeth Remanan Pillai <vineethp@amazon.com>
+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 <vineethp@amazon.com>
+
+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 <vineethp@amazon.com>
+Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM)
+Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Cc: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
