<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/fs/erofs/decompressor.c, branch linux-5.4.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>erofs: fix lz4 inplace decompression</title>
<updated>2024-11-08T15:20:49+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2023-12-06T04:55:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9ff2d260b25df6fe1341a79113d88fecf6bd553e'/>
<id>9ff2d260b25df6fe1341a79113d88fecf6bd553e</id>
<content type='text'>
commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.

Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.

However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
  __________________________________________________________
 |_ direction of decompression --&gt; ____ |_ compressed data _|

Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue.  Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".

Let's strictly use the decompressed buffer for lz4 inplace
decompression for now.  Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order.

Reported-and-tested-by: Juhyung Park &lt;qkrwngud825@gmail.com&gt;
Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace")
Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Cc: stable &lt;stable@vger.kernel.org&gt; # 5.4+
Tested-by: Yifan Zhao &lt;zhaoyifan@sjtu.edu.cn&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3c12466b6b7bf1e56f9b32c366a3d83d87afb4de upstream.

Currently EROFS can map another compressed buffer for inplace
decompression, that was used to handle the cases that some pages of
compressed data are actually not in-place I/O.

However, like most simple LZ77 algorithms, LZ4 expects the compressed
data is arranged at the end of the decompressed buffer and it
explicitly uses memmove() to handle overlapping:
  __________________________________________________________
 |_ direction of decompression --&gt; ____ |_ compressed data _|

Although EROFS arranges compressed data like this, it typically maps two
individual virtual buffers so the relative order is uncertain.
Previously, it was hardly observed since LZ4 only uses memmove() for
short overlapped literals and x86/arm64 memmove implementations seem to
completely cover it up and they don't have this issue.  Juhyung reported
that EROFS data corruption can be found on a new Intel x86 processor.
After some analysis, it seems that recent x86 processors with the new
FSRM feature expose this issue with "rep movsb".

Let's strictly use the decompressed buffer for lz4 inplace
decompression for now.  Later, as an useful improvement, we could try
to tie up these two buffers together in the correct order.

Reported-and-tested-by: Juhyung Park &lt;qkrwngud825@gmail.com&gt;
Closes: https://lore.kernel.org/r/CAD14+f2AVKf8Fa2OO1aAUdDNTDsVzzR6ctU_oJSmTyd6zSYR2Q@mail.gmail.com
Fixes: 0ffd71bcc3a0 ("staging: erofs: introduce LZ4 decompression inplace")
Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Cc: stable &lt;stable@vger.kernel.org&gt; # 5.4+
Tested-by: Yifan Zhao &lt;zhaoyifan@sjtu.edu.cn&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Link: https://lore.kernel.org/r/20231206045534.3920847-1-hsiangkao@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: avoid consecutive detection for Highmem memory</title>
<updated>2022-08-25T09:17:36+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2022-07-08T10:10:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bee4d2ab4db55cf5f22f52d7f7605eda73474d8c'/>
<id>bee4d2ab4db55cf5f22f52d7f7605eda73474d8c</id>
<content type='text'>
[ Upstream commit 448b5a1548d87c246c3d0c3df8480d3c6eb6c11a ]

Currently, vmap()s are avoided if physical addresses are
consecutive for decompressed buffers.

I observed that is very common for 4KiB pclusters since the
numbers of decompressed pages are almost 2 or 3.

However, such detection doesn't work for Highmem pages on
32-bit machines, let's fix it now.

Reported-by: Liu Jinbao &lt;liujinbao1@xiaomi.com&gt;
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Link: https://lore.kernel.org/r/20220708101001.21242-1-hsiangkao@linux.alibaba.com
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 448b5a1548d87c246c3d0c3df8480d3c6eb6c11a ]

Currently, vmap()s are avoided if physical addresses are
consecutive for decompressed buffers.

I observed that is very common for 4KiB pclusters since the
numbers of decompressed pages are almost 2 or 3.

However, such detection doesn't work for Highmem pages on
32-bit machines, let's fix it now.

Reported-by: Liu Jinbao &lt;liujinbao1@xiaomi.com&gt;
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Link: https://lore.kernel.org/r/20220708101001.21242-1-hsiangkao@linux.alibaba.com
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: fix out-of-bound read for shifted uncompressed block</title>
<updated>2020-02-11T12:35:23+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2020-01-07T02:25:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3728834fff19f8adca9bbb1324f13e2be0704fea'/>
<id>3728834fff19f8adca9bbb1324f13e2be0704fea</id>
<content type='text'>
commit 4d2024370d877f9ac8b98694bcff666da6a5d333 upstream.

rq-&gt;out[1] should be valid before accessing. Otherwise,
in very rare cases, out-of-bound dirty onstack rq-&gt;out[1]
can equal to *in and lead to unintended memmove behavior.

Link: https://lore.kernel.org/r/20200107022546.19432-1-gaoxiang25@huawei.com
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Cc: &lt;stable@vger.kernel.org&gt; # 5.3+
Reviewed-by: Chao Yu &lt;yuchao0@huawei.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4d2024370d877f9ac8b98694bcff666da6a5d333 upstream.

rq-&gt;out[1] should be valid before accessing. Otherwise,
in very rare cases, out-of-bound dirty onstack rq-&gt;out[1]
can equal to *in and lead to unintended memmove behavior.

Link: https://lore.kernel.org/r/20200107022546.19432-1-gaoxiang25@huawei.com
Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend")
Cc: &lt;stable@vger.kernel.org&gt; # 5.3+
Reviewed-by: Chao Yu &lt;yuchao0@huawei.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: rename errln/infoln/debugln to erofs_{err, info, dbg}</title>
<updated>2019-09-05T18:10:09+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2019-09-04T02:09:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f761fa253b49f657de7ef6f695a124e08e56c3a'/>
<id>4f761fa253b49f657de7ef6f695a124e08e56c3a</id>
<content type='text'>
Add prefix "erofs_" to these functions and print
sb-&gt;s_id as a prefix to erofs_{err, info} so that
the user knows which file system is affected.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-23-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add prefix "erofs_" to these functions and print
sb-&gt;s_id as a prefix to erofs_{err, info} so that
the user knows which file system is affected.

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-23-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: kill use_vmap module parameter</title>
<updated>2019-09-05T18:10:09+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2019-09-04T02:09:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=73d03931be2ffbc3049f3ec53251d9b29887de12'/>
<id>73d03931be2ffbc3049f3ec53251d9b29887de12</id>
<content type='text'>
As Christoph said [1],
"vm_map_ram is supposed to generally behave better.  So if
it doesn't please report that that to the arch maintainer
and linux-mm so that they can look into the issue.  Having
user make choices of deep down kernel internals is just
a horrible interface.

Please talk to maintainers of other bits of the kernel
if you see issues and / or need enhancements. "

Let's redo the previous conclusion and kill the vmap
approach.

[1] https://lore.kernel.org/r/20190830165533.GA10909@infradead.org/
Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-21-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As Christoph said [1],
"vm_map_ram is supposed to generally behave better.  So if
it doesn't please report that that to the arch maintainer
and linux-mm so that they can look into the issue.  Having
user make choices of deep down kernel internals is just
a horrible interface.

Please talk to maintainers of other bits of the kernel
if you see issues and / or need enhancements. "

Let's redo the previous conclusion and kill the vmap
approach.

[1] https://lore.kernel.org/r/20190830165533.GA10909@infradead.org/
Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-21-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: add "erofs_" prefix for common and short functions</title>
<updated>2019-09-05T18:10:08+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2019-09-04T02:09:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=99634bf388db04048b83a075358a1d166e7300fb'/>
<id>99634bf388db04048b83a075358a1d166e7300fb</id>
<content type='text'>
Add erofs_ prefix to free_inode, alloc_inode, ...

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-19-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add erofs_ prefix to free_inode, alloc_inode, ...

Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-19-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: use feature_incompat rather than requirements</title>
<updated>2019-09-05T18:10:07+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2019-09-04T02:08:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=426a930891cf17c5c16f12e8e2c8cb75c4cfff3c'/>
<id>426a930891cf17c5c16f12e8e2c8cb75c4cfff3c</id>
<content type='text'>
As Christoph said [1], "This is only cosmetic, why
not stick to feature_compat and feature_incompat?"

In my thought, requirements means "incompatible"
instead of "feature" though.

[1] https://lore.kernel.org/r/20190902125109.GA9826@infradead.org/
Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-7-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As Christoph said [1], "This is only cosmetic, why
not stick to feature_compat and feature_incompat?"

In my thought, requirements means "incompatible"
instead of "feature" though.

[1] https://lore.kernel.org/r/20190902125109.GA9826@infradead.org/
Reported-by: Christoph Hellwig &lt;hch@infradead.org&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190904020912.63925-7-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: remove all likely/unlikely annotations</title>
<updated>2019-08-30T07:02:02+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>gaoxiang25@huawei.com</email>
</author>
<published>2019-08-29T16:38:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d8a09b093d7073465c824f74caf315c073d3875'/>
<id>8d8a09b093d7073465c824f74caf315c073d3875</id>
<content type='text'>
As Dan Carpenter suggested [1], I have to remove
all erofs likely/unlikely annotations.

[1] https://lore.kernel.org/linux-fsdevel/20190829154346.GK23584@kadam/
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190829163827.203274-1-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As Dan Carpenter suggested [1], I have to remove
all erofs likely/unlikely annotations.

[1] https://lore.kernel.org/linux-fsdevel/20190829154346.GK23584@kadam/
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190829163827.203274-1-gaoxiang25@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>erofs: move erofs out of staging</title>
<updated>2019-08-24T12:20:10+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@aol.com</email>
</author>
<published>2019-08-22T21:36:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=47e4937a4a7ca4184fd282791dfee76c6799966a'/>
<id>47e4937a4a7ca4184fd282791dfee76c6799966a</id>
<content type='text'>
EROFS filesystem has been merged into linux-staging for a year.

EROFS is designed to be a better solution of saving extra storage
space with guaranteed end-to-end performance for read-only files
with the help of reduced metadata, fixed-sized output compression
and decompression inplace technologies.

In the past year, EROFS was greatly improved by many people as
a staging driver, self-tested, betaed by a large number of our
internal users, successfully applied to almost all in-service
HUAWEI smartphones as the part of EMUI 9.1 and proven to be stable
enough to be moved out of staging.

EROFS is a self-contained filesystem driver. Although there are
still some TODOs to be more generic, we have a dedicated team
actively keeping on working on EROFS in order to make it better
with the evolution of Linux kernel as the other in-kernel filesystems.

As Pavel suggested, it's better to do as one commit since git
can do moves and all histories will be saved in this way.

Let's promote it from staging and enhance it more actively as
a "real" part of kernel for more wider scenarios!

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: Pavel Machek &lt;pavel@denx.de&gt;
Cc: David Sterba &lt;dsterba@suse.cz&gt;
Cc: Amir Goldstein &lt;amir73il@gmail.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Darrick J . Wong &lt;darrick.wong@oracle.com&gt;
Cc: Dave Chinner &lt;david@fromorbit.com&gt;
Cc: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Richard Weinberger &lt;richard@nod.at&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Chao Yu &lt;yuchao0@huawei.com&gt;
Cc: Miao Xie &lt;miaoxie@huawei.com&gt;
Cc: Li Guifu &lt;bluce.liguifu@huawei.com&gt;
Cc: Fang Wei &lt;fangwei1@huawei.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
EROFS filesystem has been merged into linux-staging for a year.

EROFS is designed to be a better solution of saving extra storage
space with guaranteed end-to-end performance for read-only files
with the help of reduced metadata, fixed-sized output compression
and decompression inplace technologies.

In the past year, EROFS was greatly improved by many people as
a staging driver, self-tested, betaed by a large number of our
internal users, successfully applied to almost all in-service
HUAWEI smartphones as the part of EMUI 9.1 and proven to be stable
enough to be moved out of staging.

EROFS is a self-contained filesystem driver. Although there are
still some TODOs to be more generic, we have a dedicated team
actively keeping on working on EROFS in order to make it better
with the evolution of Linux kernel as the other in-kernel filesystems.

As Pavel suggested, it's better to do as one commit since git
can do moves and all histories will be saved in this way.

Let's promote it from staging and enhance it more actively as
a "real" part of kernel for more wider scenarios!

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Alexander Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Cc: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: Pavel Machek &lt;pavel@denx.de&gt;
Cc: David Sterba &lt;dsterba@suse.cz&gt;
Cc: Amir Goldstein &lt;amir73il@gmail.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Cc: Darrick J . Wong &lt;darrick.wong@oracle.com&gt;
Cc: Dave Chinner &lt;david@fromorbit.com&gt;
Cc: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
Cc: Jan Kara &lt;jack@suse.cz&gt;
Cc: Richard Weinberger &lt;richard@nod.at&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Chao Yu &lt;yuchao0@huawei.com&gt;
Cc: Miao Xie &lt;miaoxie@huawei.com&gt;
Cc: Li Guifu &lt;bluce.liguifu@huawei.com&gt;
Cc: Fang Wei &lt;fangwei1@huawei.com&gt;
Signed-off-by: Gao Xiang &lt;gaoxiang25@huawei.com&gt;
Link: https://lore.kernel.org/r/20190822213659.5501-1-hsiangkao@aol.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
