linux-stable.git, branch v3.18.89 Linux kernel stable tree Linux 3.18.89 2017-12-20T09:01:34+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2017-12-20T09:01:34+00:00 1e6e21c74c7c866db0abdfc452937724c3d80bdc 






usb: musb: da8xx: fix babble condition handling
2017-12-20T09:01:34+00:00

Bin Liu
b-liu@ti.com

2017-12-05T14:45:30+00:00

29d2c6506bc347732e509940c243a56891c12c1c

commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.

When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.

In this case, we should handle the babble interrupt first and recover
from the babble condition.

This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>






commit bd3486ded7a0c313a6575343e6c2b21d14476645 upstream.

When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.

In this case, we should handle the babble interrupt first and recover
from the babble condition.

This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>








ath9k: fix tx99 potential info leak
2017-12-20T09:01:34+00:00

Miaoqing Pan
miaoqing@codeaurora.org

2017-09-27T01:13:34+00:00

07aa0bc0072e49c71caad90a3ab74aa34ccd64e4

[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]

When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Reviewed-by: Christoph Böhmwalder <christoph@boehmwalder.at>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit ee0a47186e2fa9aa1c56cadcea470ca0ba8c8692 ]

When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Reviewed-by: Christoph Böhmwalder <christoph@boehmwalder.at>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







macvlan: Only deliver one copy of the frame to the macvlan interface
2017-12-20T09:01:34+00:00

Alexander Duyck
alexander.h.duyck@intel.com

2017-10-13T20:40:24+00:00

2d7c1288825f5c6fc85502d3a32bb1a9806354ff

[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]

This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.

The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.

Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]

This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.

The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.

Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







udf: Avoid overflow when session starts at large offset
2017-12-20T09:01:34+00:00

Jan Kara
jack@suse.cz

2017-10-16T09:38:11+00:00

58617c76ed62f0b9a9b6b5a9b791ee5314937d1e

[ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ]

When session starts beyond offset 2^31 the arithmetics in
udf_check_vsd() would overflow. Make sure the computation is done in
large enough type.

Reported-by: Cezary Sliwa <sliwa@ifpan.edu.pl>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit abdc0eb06964fe1d2fea6dd1391b734d0590365d ]

When session starts beyond offset 2^31 the arithmetics in
udf_check_vsd() would overflow. Make sure the computation is done in
large enough type.

Reported-by: Cezary Sliwa <sliwa@ifpan.edu.pl>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







scsi: bfa: integer overflow in debugfs
2017-12-20T09:01:34+00:00

Dan Carpenter
dan.carpenter@oracle.com

2017-10-04T07:50:37+00:00

cae8f2343a45475d0ba606fdd457ffce8cb5db01

[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]

We could allocate less memory than intended because we do:

	bfad->regdata = kzalloc(len << 2, GFP_KERNEL);

The shift can overflow leading to a crash.  This is debugfs code so the
impact is very small.  I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").

Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]

We could allocate less memory than intended because we do:

	bfad->regdata = kzalloc(len << 2, GFP_KERNEL);

The shift can overflow leading to a crash.  This is debugfs code so the
impact is very small.  I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").

Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
2017-12-20T09:01:34+00:00

Kurt Garloff
garloff@suse.de

2017-10-17T07:10:45+00:00

47e43e619077ec024130020aa34deb3d9deb9561

[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]

All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.

Signed-off-by: Kurt Garloff <garloff@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]

All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.

Signed-off-by: Kurt Garloff <garloff@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







raid5: Set R5_Expanded on parity devices as well as data.
2017-12-20T09:01:34+00:00

NeilBrown
neilb@suse.com

2017-10-17T05:18:36+00:00

57886e81b8bbb5d9d15c6aaab70d5ce63674de36

[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]

When reshaping a fully degraded raid5/raid6 to a larger
nubmer of devices, the new device(s) are not in-sync
and so that can make the newly grown stripe appear to be
"failed".
To avoid this, we set the R5_Expanded flag to say "Even though
this device is not fully in-sync, this block is safe so
don't treat the device as failed for this stripe".
This flag is set for data devices, not not for parity devices.

Consequently, if you have a RAID6 with two devices that are partly
recovered and a spare, and start a reshape to include the spare,
then when the reshape gets past the point where the recovery was
up to, it will think the stripes are failed and will get into
an infinite loop, failing to make progress.

So when contructing parity on an EXPAND_READY stripe,
set R5_Expanded.

Reported-by: Curt <lightspd@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]

When reshaping a fully degraded raid5/raid6 to a larger
nubmer of devices, the new device(s) are not in-sync
and so that can make the newly grown stripe appear to be
"failed".
To avoid this, we set the R5_Expanded flag to say "Even though
this device is not fully in-sync, this block is safe so
don't treat the device as failed for this stripe".
This flag is set for data devices, not not for parity devices.

Consequently, if you have a RAID6 with two devices that are partly
recovered and a spare, and start a reshape to include the spare,
then when the reshape gets past the point where the recovery was
up to, it will think the stripes are failed and will get into
an infinite loop, failing to make progress.

So when contructing parity on an EXPAND_READY stripe,
set R5_Expanded.

Reported-by: Curt <lightspd@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







pinctrl: adi2: Fix Kconfig build problem
2017-12-20T09:01:33+00:00

Linus Walleij
linus.walleij@linaro.org

2017-10-11T09:57:15+00:00

9df8ffc3035abc95311464775037d9690e8316a0

[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]

The build robot is complaining on Blackfin:

drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
   pointer to incomplete type 'struct gpio_port_t'
      writew(readw(&regs->port_fer) & ~BIT(offset),
                        ^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
      if (readl(&regs->invert_set) & pintbit)
                     ^~
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.

The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.

Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.

Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.

This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.

Cc: Steven Miao <realmz6@gmail.com>
Cc: Huanhuan Feng <huanhuan.feng@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]

The build robot is complaining on Blackfin:

drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
   pointer to incomplete type 'struct gpio_port_t'
      writew(readw(&regs->port_fer) & ~BIT(offset),
                        ^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
      if (readl(&regs->invert_set) & pintbit)
                     ^~
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.

The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.

Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.

Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.

This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.

Cc: Steven Miao <realmz6@gmail.com>
Cc: Huanhuan Feng <huanhuan.feng@analog.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>







tty fix oops when rmmod 8250
2017-12-20T09:01:33+00:00

nixiaoming
nixiaoming@huawei.com

2017-09-15T09:45:56+00:00

ba3e1b3553c512d1f8c0f3c23e800d009983e898

[ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ]

After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver

Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,

Use name in proc_dir_entry instead of driver->driver_name to fix oops

test on linux 4.1.12:

BUG: unable to handle kernel paging request at ffffffffa01979de
IP: [<ffffffff81310f40>] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ... ...  [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G           O    4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
Workqueue: events release_one_tty
task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
RIP: 0010:[<ffffffff81310f40>]  [<ffffffff81310f40>] strchr+0x0/0x30
RSP: 0018:ffff880852887c90  EFLAGS: 00010282
RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
FS:  0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
Stack:
 ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
Call Trace:
 [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0
 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180
 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60
 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0
 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40
 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0
 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20
 [<ffffffff813becca>] release_one_tty+0x5a/0xd0
 [<ffffffff81074159>] process_one_work+0x139/0x420
 [<ffffffff810745a1>] worker_thread+0x121/0x450
 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40
 [<ffffffff8107a16c>] kthread+0xec/0x110
 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220
 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
 [<ffffffff815f7292>] ret_from_fork+0x42/0x70
 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80

Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>





[ Upstream commit c79dde629d2027ca80329c62854a7635e623d527 ]

After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver

Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,

Use name in proc_dir_entry instead of driver->driver_name to fix oops

test on linux 4.1.12:

BUG: unable to handle kernel paging request at ffffffffa01979de
IP: [<ffffffff81310f40>] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ... ...  [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G           O    4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
Workqueue: events release_one_tty
task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
RIP: 0010:[<ffffffff81310f40>]  [<ffffffff81310f40>] strchr+0x0/0x30
RSP: 0018:ffff880852887c90  EFLAGS: 00010282
RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
FS:  0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
Stack:
 ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
 ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
 ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
Call Trace:
 [<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0
 [<ffffffff812354f0>] remove_proc_entry+0x40/0x180
 [<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60
 [<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0
 [<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40
 [<ffffffff813be548>] destruct_tty_driver+0x88/0xe0
 [<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20
 [<ffffffff813becca>] release_one_tty+0x5a/0xd0
 [<ffffffff81074159>] process_one_work+0x139/0x420
 [<ffffffff810745a1>] worker_thread+0x121/0x450
 [<ffffffff81074480>] ? process_scheduled_works+0x40/0x40
 [<ffffffff8107a16c>] kthread+0xec/0x110
 [<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220
 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
 [<ffffffff815f7292>] ret_from_fork+0x42/0x70
 [<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80

Signed-off-by: nixiaoming <nixiaoming@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>