--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Liu Bo <bo.liu@linux.alibaba.com>
+Date: Fri, 29 Jun 2018 09:56:08 +0800
+Subject: Blktrace: bail out early if block debugfs is not configured
+
+From: Liu Bo <bo.liu@linux.alibaba.com>
+
+commit e1a413245a564683697a3d02ec197b72cf009b89 upstream.
+
+Since @blk_debugfs_root couldn't be configured dynamically, we can
+save a few memory allocation if it's not there.
+
+Signed-off-by: Liu Bo <bo.liu@linux.alibaba.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+[bwh: Cherry-picked for 4.14 to ease backporting a later fix]
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/blktrace.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/blktrace.c
++++ b/kernel/trace/blktrace.c
+@@ -498,6 +498,9 @@ static int do_blk_trace_setup(struct req
+ if (!buts->buf_size || !buts->buf_nr)
+ return -EINVAL;
+
++ if (!blk_debugfs_root)
++ return -ENOENT;
++
+ strncpy(buts->name, name, BLKTRACE_BDEV_SIZE);
+ buts->name[BLKTRACE_BDEV_SIZE - 1] = '\0';
+
+@@ -532,9 +535,6 @@ static int do_blk_trace_setup(struct req
+
+ ret = -ENOENT;
+
+- if (!blk_debugfs_root)
+- goto err;
+-
+ dir = debugfs_lookup(buts->name, blk_debugfs_root);
+ if (!dir)
+ bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root);
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Luis Chamberlain <mcgrof@kernel.org>
+Date: Fri, 19 Jun 2020 20:47:28 +0000
+Subject: blktrace: fix debugfs use after free
+
+From: Luis Chamberlain <mcgrof@kernel.org>
+
+commit bad8e64fb19d3a0de5e564d9a7271c31bd684369 upstream.
+
+On commit 6ac93117ab00 ("blktrace: use existing disk debugfs directory")
+merged on v4.12 Omar fixed the original blktrace code for request-based
+drivers (multiqueue). This however left in place a possible crash, if you
+happen to abuse blktrace while racing to remove / add a device.
+
+We used to use asynchronous removal of the request_queue, and with that
+the issue was easier to reproduce. Now that we have reverted to
+synchronous removal of the request_queue, the issue is still possible to
+reproduce, its however just a bit more difficult.
+
+We essentially run two instances of break-blktrace which add/remove
+a loop device, and setup a blktrace and just never tear the blktrace
+down. We do this twice in parallel. This is easily reproduced with the
+script run_0004.sh from break-blktrace [0].
+
+We can end up with two types of panics each reflecting where we
+race, one a failed blktrace setup:
+
+[ 252.426751] debugfs: Directory 'loop0' with parent 'block' already present!
+[ 252.432265] BUG: kernel NULL pointer dereference, address: 00000000000000a0
+[ 252.436592] #PF: supervisor write access in kernel mode
+[ 252.439822] #PF: error_code(0x0002) - not-present page
+[ 252.442967] PGD 0 P4D 0
+[ 252.444656] Oops: 0002 [#1] SMP NOPTI
+[ 252.446972] CPU: 10 PID: 1153 Comm: break-blktrace Tainted: G E 5.7.0-rc2-next-20200420+ #164
+[ 252.452673] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
+[ 252.456343] RIP: 0010:down_write+0x15/0x40
+[ 252.458146] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
+ cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
+ 00 00 <f0> 48 0f b1 55 00 75 0f 48 8b 04 25 c0 8b 01 00 48 89
+ 45 08 5d
+[ 252.463638] RSP: 0018:ffffa626415abcc8 EFLAGS: 00010246
+[ 252.464950] RAX: 0000000000000000 RBX: ffff958c25f0f5c0 RCX: ffffff8100000000
+[ 252.466727] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0
+[ 252.468482] RBP: 00000000000000a0 R08: 0000000000000000 R09: 0000000000000001
+[ 252.470014] R10: 0000000000000000 R11: ffff958d1f9227ff R12: 0000000000000000
+[ 252.471473] R13: ffff958c25ea5380 R14: ffffffff8cce15f1 R15: 00000000000000a0
+[ 252.473346] FS: 00007f2e69dee540(0000) GS:ffff958c2fc80000(0000) knlGS:0000000000000000
+[ 252.475225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 252.476267] CR2: 00000000000000a0 CR3: 0000000427d10004 CR4: 0000000000360ee0
+[ 252.477526] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 252.478776] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 252.479866] Call Trace:
+[ 252.480322] simple_recursive_removal+0x4e/0x2e0
+[ 252.481078] ? debugfs_remove+0x60/0x60
+[ 252.481725] ? relay_destroy_buf+0x77/0xb0
+[ 252.482662] debugfs_remove+0x40/0x60
+[ 252.483518] blk_remove_buf_file_callback+0x5/0x10
+[ 252.484328] relay_close_buf+0x2e/0x60
+[ 252.484930] relay_open+0x1ce/0x2c0
+[ 252.485520] do_blk_trace_setup+0x14f/0x2b0
+[ 252.486187] __blk_trace_setup+0x54/0xb0
+[ 252.486803] blk_trace_ioctl+0x90/0x140
+[ 252.487423] ? do_sys_openat2+0x1ab/0x2d0
+[ 252.488053] blkdev_ioctl+0x4d/0x260
+[ 252.488636] block_ioctl+0x39/0x40
+[ 252.489139] ksys_ioctl+0x87/0xc0
+[ 252.489675] __x64_sys_ioctl+0x16/0x20
+[ 252.490380] do_syscall_64+0x52/0x180
+[ 252.491032] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+And the other on the device removal:
+
+[ 128.528940] debugfs: Directory 'loop0' with parent 'block' already present!
+[ 128.615325] BUG: kernel NULL pointer dereference, address: 00000000000000a0
+[ 128.619537] #PF: supervisor write access in kernel mode
+[ 128.622700] #PF: error_code(0x0002) - not-present page
+[ 128.625842] PGD 0 P4D 0
+[ 128.627585] Oops: 0002 [#1] SMP NOPTI
+[ 128.629871] CPU: 12 PID: 544 Comm: break-blktrace Tainted: G E 5.7.0-rc2-next-20200420+ #164
+[ 128.635595] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
+[ 128.640471] RIP: 0010:down_write+0x15/0x40
+[ 128.643041] Code: eb ca e8 ae 22 8d ff cc cc cc cc cc cc cc cc cc cc cc cc
+ cc cc 0f 1f 44 00 00 55 48 89 fd e8 52 db ff ff 31 c0 ba 01 00
+ 00 00 <f0> 48 0f b1 55 00 75 0f 65 48 8b 04 25 c0 8b 01 00 48 89
+ 45 08 5d
+[ 128.650180] RSP: 0018:ffffa9c3c05ebd78 EFLAGS: 00010246
+[ 128.651820] RAX: 0000000000000000 RBX: ffff8ae9a6370240 RCX: ffffff8100000000
+[ 128.653942] RDX: 0000000000000001 RSI: ffffff8100000000 RDI: 00000000000000a0
+[ 128.655720] RBP: 00000000000000a0 R08: 0000000000000002 R09: ffff8ae9afd2d3d0
+[ 128.657400] R10: 0000000000000056 R11: 0000000000000000 R12: 0000000000000000
+[ 128.659099] R13: 0000000000000000 R14: 0000000000000003 R15: 00000000000000a0
+[ 128.660500] FS: 00007febfd995540(0000) GS:ffff8ae9afd00000(0000) knlGS:0000000000000000
+[ 128.662204] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 128.663426] CR2: 00000000000000a0 CR3: 0000000420042003 CR4: 0000000000360ee0
+[ 128.664776] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 128.666022] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 128.667282] Call Trace:
+[ 128.667801] simple_recursive_removal+0x4e/0x2e0
+[ 128.668663] ? debugfs_remove+0x60/0x60
+[ 128.669368] debugfs_remove+0x40/0x60
+[ 128.669985] blk_trace_free+0xd/0x50
+[ 128.670593] __blk_trace_remove+0x27/0x40
+[ 128.671274] blk_trace_shutdown+0x30/0x40
+[ 128.671935] blk_release_queue+0x95/0xf0
+[ 128.672589] kobject_put+0xa5/0x1b0
+[ 128.673188] disk_release+0xa2/0xc0
+[ 128.673786] device_release+0x28/0x80
+[ 128.674376] kobject_put+0xa5/0x1b0
+[ 128.674915] loop_remove+0x39/0x50 [loop]
+[ 128.675511] loop_control_ioctl+0x113/0x130 [loop]
+[ 128.676199] ksys_ioctl+0x87/0xc0
+[ 128.676708] __x64_sys_ioctl+0x16/0x20
+[ 128.677274] do_syscall_64+0x52/0x180
+[ 128.677823] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The common theme here is:
+
+debugfs: Directory 'loop0' with parent 'block' already present
+
+This crash happens because of how blktrace uses the debugfs directory
+where it places its files. Upon init we always create the same directory
+which would be needed by blktrace but we only do this for make_request
+drivers (multiqueue) block drivers. When you race a removal of these
+devices with a blktrace setup you end up in a situation where the
+make_request recursive debugfs removal will sweep away the blktrace
+files and then later blktrace will also try to remove individual
+dentries which are already NULL. The inverse is also possible and hence
+the two types of use after frees.
+
+We don't create the block debugfs directory on init for these types of
+block devices:
+
+ * request-based block driver block devices
+ * every possible partition
+ * scsi-generic
+
+And so, this race should in theory only be possible with make_request
+drivers.
+
+We can fix the UAF by simply re-using the debugfs directory for
+make_request drivers (multiqueue) and only creating the ephemeral
+directory for the other type of block devices. The new clarifications
+on relying on the q->blk_trace_mutex *and* also checking for q->blk_trace
+*prior* to processing a blktrace ensures the debugfs directories are
+only created if no possible directory name clashes are possible.
+
+This goes tested with:
+
+ o nvme partitions
+ o ISCSI with tgt, and blktracing against scsi-generic with:
+ o block
+ o tape
+ o cdrom
+ o media changer
+ o blktests
+
+This patch is part of the work which disputes the severity of
+CVE-2019-19770 which shows this issue is not a core debugfs issue, but
+a misuse of debugfs within blktace.
+
+Fixes: 6ac93117ab00 ("blktrace: use existing disk debugfs directory")
+Reported-by: syzbot+603294af2d01acfdd6da@syzkaller.appspotmail.com
+Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Cc: Bart Van Assche <bvanassche@acm.org>
+Cc: Omar Sandoval <osandov@fb.com>
+Cc: Hannes Reinecke <hare@suse.com>
+Cc: Nicolai Stange <nstange@suse.de>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
+Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
+Cc: yu kuai <yukuai3@huawei.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+[bwh: Backported to 4.14: open-code queue_is_mq()]
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/blktrace.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+--- a/kernel/trace/blktrace.c
++++ b/kernel/trace/blktrace.c
+@@ -533,10 +533,18 @@ static int do_blk_trace_setup(struct req
+ if (!bt->msg_data)
+ goto err;
+
+- ret = -ENOENT;
+-
+- dir = debugfs_lookup(buts->name, blk_debugfs_root);
+- if (!dir)
++#ifdef CONFIG_BLK_DEBUG_FS
++ /*
++ * When tracing whole make_request drivers (multiqueue) block devices,
++ * reuse the existing debugfs directory created by the block layer on
++ * init. For request-based block devices, all partitions block devices,
++ * and scsi-generic block devices we create a temporary new debugfs
++ * directory that will be removed once the trace ends.
++ */
++ if (q->mq_ops && bdev && bdev == bdev->bd_contains)
++ dir = q->debugfs_dir;
++ else
++#endif
+ bt->dir = dir = debugfs_create_dir(buts->name, blk_debugfs_root);
+ if (!dir)
+ goto err;
+@@ -595,8 +603,6 @@ static int do_blk_trace_setup(struct req
+
+ ret = 0;
+ err:
+- if (dir && !bt->dir)
+- dput(dir);
+ if (ret)
+ blk_trace_free(bt);
+ return ret;
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Sergey Nemov <sergey.nemov@intel.com>
+Date: Fri, 29 Mar 2019 15:08:36 -0700
+Subject: i40e: add num_vectors checker in iwarp handler
+
+From: Sergey Nemov <sergey.nemov@intel.com>
+
+commit 7015ca3df965378bcef072cca9cd63ed098665b5 upstream.
+
+Field num_vectors from struct virtchnl_iwarp_qvlist_info should not be
+larger than num_msix_vectors_vf in the hw struct. The iwarp uses the
+same set of vectors as the LAN VF driver.
+
+Signed-off-by: Sergey Nemov <sergey.nemov@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -419,6 +419,16 @@ static int i40e_config_iwarp_qvlist(stru
+ u32 next_q_idx, next_q_type;
+ u32 msix_vf, size;
+
++ msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
++
++ if (qvlist_info->num_vectors > msix_vf) {
++ dev_warn(&pf->pdev->dev,
++ "Incorrect number of iwarp vectors %u. Maximum %u allowed.\n",
++ qvlist_info->num_vectors,
++ msix_vf);
++ goto err;
++ }
++
+ size = sizeof(struct virtchnl_iwarp_qvlist_info) +
+ (sizeof(struct virtchnl_iwarp_qv_info) *
+ (qvlist_info->num_vectors - 1));
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sun, 6 Aug 2017 23:37:01 +0200
+Subject: i40e: Fix a potential NULL pointer dereference
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 54902349ee95045b67e2f0c39b75f5418540064b upstream.
+
+If 'kzalloc()' fails, a NULL pointer will be dereferenced.
+Return an error code (-ENOMEM) instead.
+
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -423,6 +423,9 @@ static int i40e_config_iwarp_qvlist(stru
+ (sizeof(struct virtchnl_iwarp_qv_info) *
+ (qvlist_info->num_vectors - 1));
+ vf->qvlist_info = kzalloc(size, GFP_KERNEL);
++ if (!vf->qvlist_info)
++ return -ENOMEM;
++
+ vf->qvlist_info->num_vectors = qvlist_info->num_vectors;
+
+ msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Martyna Szapar <martyna.szapar@intel.com>
+Date: Mon, 15 Apr 2019 14:43:07 -0700
+Subject: i40e: Fix of memory leak and integer truncation in i40e_virtchnl.c
+
+From: Martyna Szapar <martyna.szapar@intel.com>
+
+commit 24474f2709af6729b9b1da1c5e160ab62e25e3a4 upstream.
+
+Fixed possible memory leak in i40e_vc_add_cloud_filter function:
+cfilter is being allocated and in some error conditions
+the function returns without freeing the memory.
+
+Fix of integer truncation from u16 (type of queue_id value) to u8
+when calling i40e_vc_isvalid_queue_id function.
+
+Signed-off-by: Martyna Szapar <martyna.szapar@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+[bwh: Backported to 4.14: i40e_vc_add_cloud_filter() does not exist
+ but the integer truncation is still possible]
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -189,7 +189,7 @@ static inline bool i40e_vc_isvalid_vsi_i
+ * check for the valid queue id
+ **/
+ static inline bool i40e_vc_isvalid_queue_id(struct i40e_vf *vf, u16 vsi_id,
+- u8 qid)
++ u16 qid)
+ {
+ struct i40e_pf *pf = vf->pf;
+ struct i40e_vsi *vsi = i40e_find_vsi_from_id(pf, vsi_id);
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Martyna Szapar <martyna.szapar@intel.com>
+Date: Thu, 18 Apr 2019 13:31:53 -0700
+Subject: i40e: Memory leak in i40e_config_iwarp_qvlist
+
+From: Martyna Szapar <martyna.szapar@intel.com>
+
+commit 0b63644602cfcbac849f7ea49272a39e90fa95eb upstream.
+
+Added freeing the old allocation of vf->qvlist_info in function
+i40e_config_iwarp_qvlist before overwriting it with
+the new allocation.
+
+Signed-off-by: Martyna Szapar <martyna.szapar@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 23 +++++++++++++--------
+ 1 file changed, 15 insertions(+), 8 deletions(-)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -418,6 +418,7 @@ static int i40e_config_iwarp_qvlist(stru
+ u32 v_idx, i, reg_idx, reg;
+ u32 next_q_idx, next_q_type;
+ u32 msix_vf, size;
++ int ret = 0;
+
+ msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
+
+@@ -426,16 +427,19 @@ static int i40e_config_iwarp_qvlist(stru
+ "Incorrect number of iwarp vectors %u. Maximum %u allowed.\n",
+ qvlist_info->num_vectors,
+ msix_vf);
+- goto err;
++ ret = -EINVAL;
++ goto err_out;
+ }
+
+ size = sizeof(struct virtchnl_iwarp_qvlist_info) +
+ (sizeof(struct virtchnl_iwarp_qv_info) *
+ (qvlist_info->num_vectors - 1));
++ kfree(vf->qvlist_info);
+ vf->qvlist_info = kzalloc(size, GFP_KERNEL);
+- if (!vf->qvlist_info)
+- return -ENOMEM;
+-
++ if (!vf->qvlist_info) {
++ ret = -ENOMEM;
++ goto err_out;
++ }
+ vf->qvlist_info->num_vectors = qvlist_info->num_vectors;
+
+ msix_vf = pf->hw.func_caps.num_msix_vectors_vf;
+@@ -446,8 +450,10 @@ static int i40e_config_iwarp_qvlist(stru
+ v_idx = qv_info->v_idx;
+
+ /* Validate vector id belongs to this vf */
+- if (!i40e_vc_isvalid_vector_id(vf, v_idx))
+- goto err;
++ if (!i40e_vc_isvalid_vector_id(vf, v_idx)) {
++ ret = -EINVAL;
++ goto err_free;
++ }
+
+ vf->qvlist_info->qv_info[i] = *qv_info;
+
+@@ -489,10 +495,11 @@ static int i40e_config_iwarp_qvlist(stru
+ }
+
+ return 0;
+-err:
++err_free:
+ kfree(vf->qvlist_info);
+ vf->qvlist_info = NULL;
+- return -EINVAL;
++err_out:
++ return ret;
+ }
+
+ /**
--- /dev/null
+From foo@baz Sat Nov 7 04:27:36 PM CET 2020
+From: Grzegorz Siwik <grzegorz.siwik@intel.com>
+Date: Fri, 29 Mar 2019 15:08:37 -0700
+Subject: i40e: Wrong truncation from u16 to u8
+
+From: Grzegorz Siwik <grzegorz.siwik@intel.com>
+
+commit c004804dceee9ca384d97d9857ea2e2795c2651d upstream.
+
+In this patch fixed wrong truncation method from u16 to u8 during
+validation.
+
+It was changed by changing u8 to u32 parameter in method declaration
+and arguments were changed to u32.
+
+Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
+Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
++++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+@@ -204,7 +204,7 @@ static inline bool i40e_vc_isvalid_queue
+ *
+ * check for the valid vector id
+ **/
+-static inline bool i40e_vc_isvalid_vector_id(struct i40e_vf *vf, u8 vector_id)
++static inline bool i40e_vc_isvalid_vector_id(struct i40e_vf *vf, u32 vector_id)
+ {
+ struct i40e_pf *pf = vf->pf;
+
net-usb-qmi_wwan-add-telit-le910cx-0x1230-composition.patch
sctp-fix-comm_lost-cant_str_assoc-err-reporting-on-big-endian-platforms.patch
sfp-fix-error-handing-in-sfp_probe.patch
+blktrace-bail-out-early-if-block-debugfs-is-not-configured.patch
+blktrace-fix-debugfs-use-after-free.patch
+i40e-fix-a-potential-null-pointer-dereference.patch
+i40e-add-num_vectors-checker-in-iwarp-handler.patch
+i40e-wrong-truncation-from-u16-to-u8.patch
+i40e-fix-of-memory-leak-and-integer-truncation-in-i40e_virtchnl.c.patch
+i40e-memory-leak-in-i40e_config_iwarp_qvlist.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
