commit 1e20e732ffa107e21f2089ce56e32d99b9229944
Author: Sasha Levin <alexander.levin@verizon.com>
Date: Sat Dec 24 11:10:18 2016 -0500
Linux 3.18.46
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 5c120b79dd6601a987eb33214f2686e5b75f3c3e
Author: Philip Pettersson <philip.pettersson@gmail.com>
Date: Wed Dec 14 13:24:56 2016 +0100
packet: fix race condition in packet_set_ring
[ Upstream commit 84ac7260236a49c79eede91617700174c2c19b0c ]
When packet_set_ring creates a ring buffer it will initialize a
struct timer_list if the packet version is TPACKET_V3. This value
can then be raced by a different thread calling setsockopt to
set the version to TPACKET_V1 before packet_set_ring has finished.
This leads to a use-after-free on a function pointer in the
struct timer_list when the socket is closed as the previously
initialized timer will not be deleted.
The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
changing the packet version while also taking the lock at the start
of packet_set_ring.
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.")
Signed-off-by: Philip Pettersson <philip.pettersson@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit ee79b622f43bab46bd6ff778b3cd2e4af4784bc2
Author: Jaganath Kanakkassery <jaganath.k@samsung.com>
Date: Wed Dec 14 13:24:54 2016 +0100
Bluetooth: Fix potential NULL dereference in RFCOMM bind callback
[ Upstream commit 951b6a0717db97ce420547222647bcc40bf1eacd ]
addr can be NULL and it should not be dereferenced before NULL checking.
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 6371e0cdc5be8671461f136dc1df9a36bdb5292a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed Dec 14 13:24:52 2016 +0100
scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()
[ Upstream commit 7bc2b55a5c030685b399bb65b6baa9ccc3d1f167 ]
We need to put an upper bound on "user_len" so the memcpy() doesn't
overflow.
Cc: <stable@vger.kernel.org>
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 1cb57d81cf20fe24b9e2e1daf57bfbdc24b77cd8
Author: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
Date: Wed Dec 14 13:24:47 2016 +0100
nfsd: Disable NFSv2 timestamp workaround for NFSv3+
[ Upstream commit cc265089ce1b176dde963c74b53593446ee7f99a ]
NFSv2 can set the atime and/or mtime of a file to specific timestamps but not
to the server's current time. To implement the equivalent of utimes("file",
NULL), it uses a heuristic.
NFSv3 and later do support setting the atime and/or mtime to the server's
current time directly. The NFSv2 heuristic is still enabled, and causes
timestamps to be set wrong sometimes.
Fix this by moving the heuristic into the NFSv2 specific code. We can leave it
out of the create code path: the owner can always set timestamps arbitrarily,
and the workaround would never trigger.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 33b52836b538a87686c80fa504ae538b6dd15e65
Author: Jan Kara <jack@suse.cz>
Date: Wed Dec 14 13:24:46 2016 +0100
fuse: Propagate dentry down to inode_change_ok()
[ Upstream commit 62490330769c1ce5dcba3f1f3e8f4005e9b797e6 ]
To avoid clearing of capabilities or security related extended
attributes too early, inode_change_ok() will need to take dentry instead
of inode. Propagate it down to fuse_do_setattr().
Acked-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit fa9b0c17c956a6d2bb3e99ad274c32e86adfddcf
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Dec 14 13:24:43 2016 +0100
tcp: fix use after free in tcp_xmit_retransmit_queue()
[ Upstream commit bb1fceca22492109be12640d49f5ea5a544c6bb4 ]
When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the
tail of the write queue using tcp_add_write_queue_tail()
Then it attempts to copy user data into this fresh skb.
If the copy fails, we undo the work and remove the fresh skb.
Unfortunately, this undo lacks the change done to tp->highest_sack and
we can leave a dangling pointer (to a freed skb)
Later, tcp_xmit_retransmit_queue() can dereference this pointer and
access freed memory. For regular kernels where memory is not unmapped,
this might cause SACK bugs because tcp_highest_sack_seq() is buggy,
returning garbage instead of tp->snd_nxt, but with various debug
features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel.
This bug was found by Marco Grassi thanks to syzkaller.
Fixes: 6859d49475d4 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb")
Reported-by: Marco Grassi <marco.gra@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 5341057bf2727736bfaecd75009145972b5c4d2e
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Nov 4 19:39:40 2016 +0100
x86/kexec: add -fno-PIE
[ Upstream commit 90944e40ba1838de4b2a9290cf273f9d76bd3bdd ]
If the gcc is configured to do -fPIE by default then the build aborts
later with:
| Unsupported relocation type: unknown type rel type name (29)
Tagging it stable so it is possible to compile recent stable kernels as
well.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit c873ec3a0dcb59c26a83c3bbe9d262fcd2cbccd2
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Fri Nov 4 19:39:39 2016 +0100
scripts/has-stack-protector: add -fno-PIE
[ Upstream commit 82031ea29e454b574bc6f49a33683a693ca5d907 ]
Adding -no-PIE to the fstack protector check. -no-PIE was introduced
before -fstack-protector so there is no need for a runtime check.
Without it the build stops:
|Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken
due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default.
Tagging it stable so it is possible to compile recent stable kernels as
well.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 0e3f4b0fd5f8031d56251a452630a3448133895c
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed Sep 28 12:34:14 2016 -0700
x86/init: Fix cr4_init_shadow() on CR4-less machines
[ Upstream commit e1bfc11c5a6f40222a698a818dc269113245820e ]
cr4_init_shadow() will panic on 486-like machines without CR4. Fix
it using __read_cr4_safe().
Reported-by: david@saggiorato.net
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit d884eb7cb82c974de5c8282c06b08edd1d0f2712
Author: Roger Quadros <rogerq@ti.com>
Date: Thu Sep 29 08:32:55 2016 +0100
ARM: 8617/1: dma: fix dma_max_pfn()
[ Upstream commit d248220f0465b818887baa9829e691fe662b2c5e ]
Since commit 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation"),
dma_to_pfn() already returns the PFN with the physical memory start offset
so we don't need to add it again.
This fixes USB mass storage lock-up problem on systems that can't do DMA
over the entire physical memory range (e.g.) Keystone 2 systems with 4GB RAM
can only do DMA over the first 2GB. [K2E-EVM].
What happens there is that without this patch SCSI layer sets a wrong
bounce buffer limit in scsi_calculate_bounce_limit() for the USB mass
storage device. dma_max_pfn() evaluates to 0x8fffff and bounce_limit
is set to 0x8fffff000 whereas maximum DMA'ble physical memory on Keystone 2
is 0x87fffffff. This results in non DMA'ble pages being given to the
USB controller and hence the lock-up.
NOTE: in the above case, USB-SCSI-device's dma_pfn_offset was showing as 0.
This should have really been 0x780000 as on K2e, LOWMEM_START is 0x80000000
and HIGHMEM_START is 0x800000000. DMA zone is 2GB so dma_max_pfn should be
0x87ffff. The incorrect dma_pfn_offset for the USB storage device is because
USB devices are not correctly inheriting the dma_pfn_offset from the
USB host controller. This will be fixed by a separate patch.
Fixes: 6ce0d2001692 ("ARM: dma: Use dma_pfn_offset for dma address translation")
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 956e1e405c8f586a4194125beb45d749c98e3dcd
Author: zhong jiang <zhongjiang@huawei.com>
Date: Wed Sep 28 15:22:30 2016 -0700
mm,ksm: fix endless looping in allocating memory when ksm enable
[ Upstream commit 5b398e416e880159fe55eefd93c6588fa072cd66 ]
I hit the following hung task when runing a OOM LTP test case with 4.1
kernel.
Call trace:
[<ffffffc000086a88>] __switch_to+0x74/0x8c
[<ffffffc000a1bae0>] __schedule+0x23c/0x7bc
[<ffffffc000a1c09c>] schedule+0x3c/0x94
[<ffffffc000a1eb84>] rwsem_down_write_failed+0x214/0x350
[<ffffffc000a1e32c>] down_write+0x64/0x80
[<ffffffc00021f794>] __ksm_exit+0x90/0x19c
[<ffffffc0000be650>] mmput+0x118/0x11c
[<ffffffc0000c3ec4>] do_exit+0x2dc/0xa74
[<ffffffc0000c46f8>] do_group_exit+0x4c/0xe4
[<ffffffc0000d0f34>] get_signal+0x444/0x5e0
[<ffffffc000089fcc>] do_signal+0x1d8/0x450
[<ffffffc00008a35c>] do_notify_resume+0x70/0x78
The oom victim cannot terminate because it needs to take mmap_sem for
write while the lock is held by ksmd for read which loops in the page
allocator
ksm_do_scan
scan_get_next_rmap_item
down_read
get_next_rmap_item
alloc_rmap_item #ksmd will loop permanently.
There is no way forward because the oom victim cannot release any memory
in 4.1 based kernel. Since 4.6 we have the oom reaper which would solve
this problem because it would release the memory asynchronously.
Nevertheless we can relax alloc_rmap_item requirements and use
__GFP_NORETRY because the allocation failure is acceptable as ksm_do_scan
would just retry later after the lock got dropped.
Such a patch would be also easy to backport to older stable kernels which
do not have oom_reaper.
While we are at it add GFP_NOWARN so the admin doesn't have to be alarmed
by the allocation failure.
Link: http://lkml.kernel.org/r/1474165570-44398-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Suggested-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Hugh Dickins <hughd@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: Sasha Levin <alexander.levin@verizon.com>
commit 5e5920acffa330fabb1a7df2c340d747d2a13e37
Author: Sergei Miroshnichenko <sergeimir@emcraft.com>
Date: Wed Sep 7 16:51:12 2016 +0300
can: dev: fix deadlock reported after bus-off
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]
A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].
To resolve this issue, the restart_timer is replaced by a delayed
work.
[1] https://github.com/victronenergy/venus/issues/24
Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit e1df4c5d40ceb63924167c87421b81fd3818a201
Author: Joonwoo Park <joonwoop@codeaurora.org>
Date: Sun Sep 11 21:14:58 2016 -0700
cpuset: handle race between CPU hotplug and cpuset_hotplug_work
[ Upstream commit 28b89b9e6f7b6c8fef7b3af39828722bca20cfee ]
A discrepancy between cpu_online_mask and cpuset's effective_cpus
mask is inevitable during hotplug since cpuset defers updating of
effective_cpus mask using a workqueue, during which time nothing
prevents the system from more hotplug operations. For that reason
guarantee_online_cpus() walks up the cpuset hierarchy until it finds
an intersection under the assumption that top cpuset's effective_cpus
mask intersects with cpu_online_mask even with such a race occurring.
However a sequence of CPU hotplugs can open a time window, during which
none of the effective CPUs in the top cpuset intersect with
cpu_online_mask.
For example when there are 4 possible CPUs 0-3 and only CPU0 is online:
======================== ===========================
cpu_online_mask top_cpuset.effective_cpus
======================== ===========================
echo 1 > cpu2/online.
CPU hotplug notifier woke up hotplug work but not yet scheduled.
[0,2] [0]
echo 0 > cpu0/online.
The workqueue is still runnable.
[2] [0]
======================== ===========================
Now there is no intersection between cpu_online_mask and
top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at
this moment can cause following:
Unable to handle kernel NULL pointer dereference at virtual address 000000d0
------------[ cut here ]------------
Kernel BUG at ffffffc0001389b0 [verbose debug info unavailable]
Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 1420 Comm: taskset Tainted: G W 4.4.8+ #98
task: ffffffc06a5c4880 ti: ffffffc06e124000 task.ti: ffffffc06e124000
PC is at guarantee_online_cpus+0x2c/0x58
LR is at cpuset_cpus_allowed+0x4c/0x6c
<snip>
Process taskset (pid: 1420, stack limit = 0xffffffc06e124020)
Call trace:
[<ffffffc0001389b0>] guarantee_online_cpus+0x2c/0x58
[<ffffffc00013b208>] cpuset_cpus_allowed+0x4c/0x6c
[<ffffffc0000d61f0>] sched_setaffinity+0xc0/0x1ac
[<ffffffc0000d6374>] SyS_sched_setaffinity+0x98/0xac
[<ffffffc000085cb0>] el0_svc_naked+0x24/0x28
The top cpuset's effective_cpus are guaranteed to be identical to
cpu_online_mask eventually. Hence fall back to cpu_online_mask when
there is no intersection between top cpuset's effective_cpus and
cpu_online_mask.
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: cgroups@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.17+
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 57d83cda45c6fb515c2cba19e2c14980b627ed03
Author: Karl Beldan <kbeldan@baylibre.com>
Date: Mon Aug 29 07:45:49 2016 +0000
mtd: nand: davinci: Reinitialize the HW ECC engine in 4bit hwctl
[ Upstream commit f6d7c1b5598b6407c3f1da795dd54acf99c1990c ]
This fixes subpage writes when using 4-bit HW ECC.
There has been numerous reports about ECC errors with devices using this
driver for a while. Also the 4-bit ECC has been reported as broken with
subpages in [1] and with 16 bits NANDs in the driver and in mach* board
files both in mainline and in the vendor BSPs.
What I saw with 4-bit ECC on a 16bits NAND (on an LCDK) which got me to
try reinitializing the ECC engine:
- R/W on whole pages properly generates/checks RS code
- try writing the 1st subpage only of a blank page, the subpage is well
written and the RS code properly generated, re-reading the same page
the HW detects some ECC error, reading the same page again no ECC
error is detected
Note that the ECC engine is already reinitialized in the 1-bit case.
Tested on my LCDK with UBI+UBIFS using subpages.
This could potentially get rid of the issue workarounded in [1].
[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")
Fixes: 6a4123e581b3 ("mtd: nand: davinci_nand, 4-bit ECC for smallpage")
Cc: <stable@vger.kernel.org>
Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 86a53e36f16d0318caa73de296b20d80df6b27f1
Author: Rob Clark <robdclark@gmail.com>
Date: Mon Aug 22 15:15:23 2016 -0400
drm/msm: fix use of copy_from_user() while holding spinlock
[ Upstream commit 89f82cbb0d5c0ab768c8d02914188aa2211cd2e3 ]
Use instead __copy_from_user_inatomic() and fallback to slow-path where
we drop and re-aquire the lock in case of fault.
Cc: stable@vger.kernel.org
Reported-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 077ae72acc9bc0906a4e173591c3a32673ea7736
Author: Pawel Moll <pawel.moll@arm.com>
Date: Tue Aug 2 16:45:37 2016 +0100
bus: arm-ccn: Fix PMU handling of MN
[ Upstream commit 4e486cba285ff06a1f28f0fc2991dde1482d1dcf ]
The "Miscellaneous Node" fell through cracks of node initialisation,
as its ID is shared with HN-I.
This patch treats MN as a special case (which it is), adding separate
validation check for it and pre-defining the node ID in relevant events
descriptions. That way one can simply run:
# perf stat -a -e ccn/mn_ecbarrier/ <workload>
Additionally, direction in the MN pseudo-events XP watchpoint
definitions is corrected to be "TX" (1) as they are defined from the
crosspoint point of view (thus barriers are transmitted from XP to MN).
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 69ecf071d851281a0bc2feaf1f30e643927109c1
Author: Pawel Moll <pawel.moll@arm.com>
Date: Thu Apr 2 14:01:06 2015 +0100
bus: arm-ccn: Provide required event arguments
[ Upstream commit 8f06c51fac1ca4104b8b64872f310e28186aea42 ]
Since 688d4dfcdd624192cbf03c08402e444d1d11f294 "perf tools: Support
parsing parameterized events" the perf userspace tools understands
"argument=?" syntax in the events file, making sure that required
arguments are provided by the user and not defaulting to 0, causing
confusion.
This patch adds the required arguments lists for CCN events.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
commit 41a83f7482d6281db0c47430235343c2cf024d59
Author: Sumit Saxena <sumit.saxena@broadcom.com>
Date: Wed Nov 9 02:59:42 2016 -0800
scsi: megaraid_sas: fix macro MEGASAS_IS_LOGICAL to avoid regression
[ Upstream commit 5e5ec1759dd663a1d5a2f10930224dd009e500e8 ]
This patch will fix regression caused by commit 1e793f6fc0db ("scsi:
megaraid_sas: Fix data integrity failure for JBOD (passthrough)
devices").
The problem was that the MEGASAS_IS_LOGICAL macro did not have braces
and as a result the driver ended up exposing a lot of non-existing SCSI
devices (all SCSI commands to channels 1,2,3 were returned as
SUCCESS-DID_OK by driver).
[mkp: clarified patch description]
Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe <axboe@kernel.dk>
CC: stable@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Tested-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Tested-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>