This is a note to let you know that I've just added the patch titled
dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 8 Nov 2017 12:02:25 +0200
Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ]
The used 0x1f mask is only valid for am335x family of SoC, different family
using this type of crossbar might have different number of electable
events. In case of am43xx family 0x3f mask should have been used for
example.
Instead of trying to handle each family's mask, just use u8 type to store
the mux value since the event offsets are aligned to byte offset.
Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -46,12 +46,12 @@ struct ti_am335x_xbar_data {
struct ti_am335x_xbar_map {
u16 dma_line;
- u16 mux_val;
+ u8 mux_val;
};
-static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val)
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val & 0x1f, iomem + event);
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
@@ -102,7 +102,7 @@ static void *ti_am335x_xbar_route_alloca
}
map->dma_line = (u16)dma_spec->args[0];
- map->mux_val = (u16)dma_spec->args[2];
+ map->mux_val = (u8)dma_spec->args[2];
dma_spec->args[2] = 0;
dma_spec->args_count = 2;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.4/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
This is a note to let you know that I've just added the patch titled
dmaengine: rcar-dmac: use TCRB instead of TCR for residue
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Date: Thu, 19 Oct 2017 01:15:13 +0000
Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ]
SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below.
TCR TCRB
[SOURCE] -> [DMAC] -> [SINK]
In the MEM_TO_DEV direction, what really matters is how much data has
been written to the device. If the DMA is interrupted between read and
write, then, the data doesn't end up in the destination, so shouldn't
be counted. TCRB is thus the register we should use in this cases.
In the DEV_TO_MEM direction, the situation is more complex. Both the
read and write side are important. What matters from a data consumer
point of view is how much data has been written to memory.
On the other hand, if the transfer is interrupted between read and
write, we'll end up losing data. It can also be important to report.
In the MEM_TO_MEM direction, what matters is of course how much data
has been written to memory from data consumer point of view.
Here, because read and write have independent data buffers, it will
take a while for TCR and TCRB to become equal. Thus we should check
TCRB in this case, too.
Thus, all cases we should check TCRB instead of TCR.
Without this patch, Sound Capture has noise after PluseAudio support
(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because
the recorder will use wrong residue counter which indicates transferred
from sound device, but in reality the data was not yet put to memory
and recorder will record it.
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1180,7 +1180,7 @@ static unsigned int rcar_dmac_chan_get_r
}
/* Add the residue for the current chunk. */
- residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
+ residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
return residue;
}
Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are
queue-4.4/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
This is a note to let you know that I've just added the patch titled
dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Matthias Kaehlcke <mka(a)chromium.org>
Date: Mon, 13 Mar 2017 14:30:29 -0700
Subject: dmaengine: Fix array index out of bounds warning in __get_unmap_pool()
From: Matthias Kaehlcke <mka(a)chromium.org>
[ Upstream commit 23f963e91fd81f44f6b316b1c24db563354c6be8 ]
This fixes the following warning when building with clang and
CONFIG_DMA_ENGINE_RAID=n :
drivers/dma/dmaengine.c:1102:11: error: array index 2 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
return &unmap_pool[2];
^ ~
drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
static struct dmaengine_unmap_pool unmap_pool[] = {
^
drivers/dma/dmaengine.c:1104:11: error: array index 3 is past the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
return &unmap_pool[3];
^ ~
drivers/dma/dmaengine.c:1083:1: note: array 'unmap_pool' declared here
static struct dmaengine_unmap_pool unmap_pool[] = {
Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org>
Reviewed-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/dmaengine.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1023,12 +1023,14 @@ static struct dmaengine_unmap_pool *__ge
switch (order) {
case 0 ... 1:
return &unmap_pool[0];
+#if IS_ENABLED(CONFIG_DMA_ENGINE_RAID)
case 2 ... 4:
return &unmap_pool[1];
case 5 ... 7:
return &unmap_pool[2];
case 8:
return &unmap_pool[3];
+#endif
default:
BUG();
return NULL;
Patches currently in stable-queue which might be from mka(a)chromium.org are
queue-4.4/bluetooth-btusb-driver-to-enable-the-usb-wakeup-feature.patch
queue-4.4/dmaengine-fix-array-index-out-of-bounds-warning-in-__get_unmap_pool.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix buffer lengths in test_aead_speed()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:22:00 +0300
Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
[ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ]
Fix the way the length of the buffers used for
encryption / decryption are computed.
For e.g. in case of encryption, input buffer does not contain
an authentication tag.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -410,7 +410,7 @@ static void test_aead_speed(const char *
}
sg_init_aead(sg, xbuf,
- *b_size + (enc ? authsize : 0));
+ *b_size + (enc ? 0 : authsize));
sg_init_aead(sgout, xoutbuf,
*b_size + (enc ? authsize : 0));
@@ -418,7 +418,9 @@ static void test_aead_speed(const char *
sg_set_buf(&sg[0], assoc, aad_size);
sg_set_buf(&sgout[0], assoc, aad_size);
- aead_request_set_crypt(req, sg, sgout, *b_size, iv);
+ aead_request_set_crypt(req, sg, sgout,
+ *b_size + (enc ? 0 : authsize),
+ iv);
aead_request_set_ad(req, aad_size);
if (secs)
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.4/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
clk: tegra: Fix cclk_lp divisor register
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-tegra-fix-cclk_lp-divisor-register.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Date: Tue, 19 Sep 2017 04:48:10 +0200
Subject: clk: tegra: Fix cclk_lp divisor register
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
[ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ]
According to comments in code and common sense, cclk_lp uses its
own divisor, not cclk_g's.
Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30")
Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1063,7 +1063,7 @@ static void __init tegra30_super_clk_ini
* U71 divider of cclk_lp.
*/
clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3",
- clk_base + SUPER_CCLKG_DIVIDER, 0,
+ clk_base + SUPER_CCLKLP_DIVIDER, 0,
TEGRA_DIVIDER_INT, 16, 8, 1, NULL);
clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL);
Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are
queue-4.4/clk-tegra-fix-cclk_lp-divisor-register.patch
This is a note to let you know that I've just added the patch titled
clk: mediatek: add the option for determining PLL source clock
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Chen Zhong <chen.zhong(a)mediatek.com>
Date: Thu, 5 Oct 2017 11:50:23 +0800
Subject: clk: mediatek: add the option for determining PLL source clock
From: Chen Zhong <chen.zhong(a)mediatek.com>
[ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ]
Since the previous setup always sets the PLL using crystal 26MHz, this
doesn't always happen in every MediaTek platform. So the patch added
flexibility for assigning extra member for determining the PLL source
clock.
Signed-off-by: Chen Zhong <chen.zhong(a)mediatek.com>
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/mediatek/clk-mtk.h | 1 +
drivers/clk/mediatek/clk-pll.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -174,6 +174,7 @@ struct mtk_pll_data {
uint32_t pcw_reg;
int pcw_shift;
const struct mtk_pll_div_table *div_table;
+ const char *parent_name;
};
void mtk_clk_register_plls(struct device_node *node,
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -302,7 +302,10 @@ static struct clk *mtk_clk_register_pll(
init.name = data->name;
init.ops = &mtk_pll_ops;
- init.parent_names = &parent_name;
+ if (data->parent_name)
+ init.parent_names = &data->parent_name;
+ else
+ init.parent_names = &parent_name;
init.num_parents = 1;
clk = clk_register(NULL, &pll->hw);
Patches currently in stable-queue which might be from chen.zhong(a)mediatek.com are
queue-4.4/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
This is a note to let you know that I've just added the patch titled
btrfs: add missing memset while reading compressed inline extents
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Date: Fri, 10 Mar 2017 16:45:44 -0500
Subject: btrfs: add missing memset while reading compressed inline extents
From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
[ Upstream commit e1699d2d7bf6e6cce3e1baff19f9dd4595a58664 ]
This is a story about 4 distinct (and very old) btrfs bugs.
Commit c8b978188c ("Btrfs: Add zlib compression support") added
three data corruption bugs for inline extents (bugs #1-3).
Commit 93c82d5750 ("Btrfs: zero page past end of inline file items")
fixed bug #1: uncompressed inline extents followed by a hole and more
extents could get non-zero data in the hole as they were read. The fix
was to add a memset in btrfs_get_extent to zero out the hole.
Commit 166ae5a418 ("btrfs: fix inline compressed read err corruption")
fixed bug #2: compressed inline extents which contained non-zero bytes
might be replaced with zero bytes in some cases. This patch removed an
unhelpful memset from uncompress_inline, but the case where memset is
required was missed.
There is also a memset in the decompression code, but this only covers
decompressed data that is shorter than the ram_bytes from the extent
ref record. This memset doesn't cover the region between the end of the
decompressed data and the end of the page. It has also moved around a
few times over the years, so there's no single patch to refer to.
This patch fixes bug #3: compressed inline extents followed by a hole
and more extents could get non-zero data in the hole as they were read
(i.e. bug #3 is the same as bug #1, but s/uncompressed/compressed/).
The fix is the same: zero out the hole in the compressed case too,
by putting a memset back in uncompress_inline, but this time with
correct parameters.
The last and oldest bug, bug #0, is the cause of the offending inline
extent/hole/extent pattern. Bug #0 is a subtle and mostly-harmless quirk
of behavior somewhere in the btrfs write code. In a few special cases,
an inline extent and hole are allowed to persist where they normally
would be combined with later extents in the file.
A fast reproducer for bug #0 is presented below. A few offending extents
are also created in the wild during large rsync transfers with the -S
flag. A Linux kernel build (git checkout; make allyesconfig; make -j8)
will produce a handful of offending files as well. Once an offending
file is created, it can present different content to userspace each
time it is read.
Bug #0 is at least 4 and possibly 8 years old. I verified every vX.Y
kernel back to v3.5 has this behavior. There are fossil records of this
bug's effects in commits all the way back to v2.6.32. I have no reason
to believe bug #0 wasn't present at the beginning of btrfs compression
support in v2.6.29, but I can't easily test kernels that old to be sure.
It is not clear whether bug #0 is worth fixing. A fix would likely
require injecting extra reads into currently write-only paths, and most
of the exceptional cases caused by bug #0 are already handled now.
Whether we like them or not, bug #0's inline extents followed by holes
are part of the btrfs de-facto disk format now, and we need to be able
to read them without data corruption or an infoleak. So enough about
bug #0, let's get back to bug #3 (this patch).
An example of on-disk structure leading to data corruption found in
the wild:
item 61 key (606890 INODE_ITEM 0) itemoff 9662 itemsize 160
inode generation 50 transid 50 size 47424 nbytes 49141
block group 0 mode 100644 links 1 uid 0 gid 0
rdev 0 flags 0x0(none)
item 62 key (606890 INODE_REF 603050) itemoff 9642 itemsize 20
inode ref index 3 namelen 10 name: DB_File.so
item 63 key (606890 EXTENT_DATA 0) itemoff 8280 itemsize 1362
inline extent data size 1341 ram 4085 compress(zlib)
item 64 key (606890 EXTENT_DATA 4096) itemoff 8227 itemsize 53
extent data disk byte 5367308288 nr 20480
extent data offset 0 nr 45056 ram 45056
extent compression(zlib)
Different data appears in userspace during each read of the 11 bytes
between 4085 and 4096. The extent in item 63 is not long enough to
fill the first page of the file, so a memset is required to fill the
space between item 63 (ending at 4085) and item 64 (beginning at 4096)
with zero.
Here is a reproducer from Liu Bo, which demonstrates another method
of creating the same inline extent and hole pattern:
Using 'page_poison=on' kernel command line (or enable
CONFIG_PAGE_POISONING) run the following:
# touch foo
# chattr +c foo
# xfs_io -f -c "pwrite -W 0 1000" foo
# xfs_io -f -c "falloc 4 8188" foo
# od -x foo
# echo 3 >/proc/sys/vm/drop_caches
# od -x foo
This produce the following on my box:
Correct output: file contains 1000 data bytes followed
by zeros:
0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd
*
0001740 cdcd cdcd cdcd cdcd 0000 0000 0000 0000
0001760 0000 0000 0000 0000 0000 0000 0000 0000
*
0020000
Actual output: the data after the first 1000 bytes
will be different each run:
0000000 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd
*
0001740 cdcd cdcd cdcd cdcd 6c63 7400 635f 006d
0001760 5f74 6f43 7400 435f 0053 5f74 7363 7400
0002000 435f 0056 5f74 6164 7400 645f 0062 5f74
(...)
Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org>
Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Chris Mason <clm(a)fb.com>
Signed-off-by: Chris Mason <clm(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/inode.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -6735,6 +6735,20 @@ static noinline int uncompress_inline(st
max_size = min_t(unsigned long, PAGE_CACHE_SIZE, max_size);
ret = btrfs_decompress(compress_type, tmp, page,
extent_offset, inline_size, max_size);
+
+ /*
+ * decompression code contains a memset to fill in any space between the end
+ * of the uncompressed data and the end of max_size in case the decompressed
+ * data ends up shorter than ram_bytes. That doesn't cover the hole between
+ * the end of an inline extent and the beginning of the next block, so we
+ * cover that region here.
+ */
+
+ if (max_size + pg_offset < PAGE_SIZE) {
+ char *map = kmap(page);
+ memset(map + pg_offset + max_size, 0, PAGE_SIZE - max_size - pg_offset);
+ kunmap(page);
+ }
kfree(tmp);
return ret;
}
Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are
queue-4.4/btrfs-add-missing-memset-while-reading-compressed-inline-extents.patch
This is a note to let you know that I've just added the patch titled
bcache: fix wrong cache_misses statistics
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bcache-fix-wrong-cache_misses-statistics.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
Date: Mon, 30 Oct 2017 14:46:34 -0700
Subject: bcache: fix wrong cache_misses statistics
From: "tang.junhui" <tang.junhui(a)zte.com.cn>
[ Upstream commit c157313791a999646901b3e3c6888514ebc36d62 ]
Currently, Cache missed IOs are identified by s->cache_miss, but actually,
there are many situations that missed IOs are not assigned a value for
s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO
(s->iop.bypass = 1), or the cache_bio allocate failed. In these situations,
it will go to out_put or out_submit, and s->cache_miss is null, which leads
bch_mark_cache_accounting() to treat this IO as a hit IO.
[ML: applied by 3-way merge]
Signed-off-by: tang.junhui <tang.junhui(a)zte.com.cn>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/request.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -468,6 +468,7 @@ struct search {
unsigned recoverable:1;
unsigned write:1;
unsigned read_dirty_data:1;
+ unsigned cache_missed:1;
unsigned long start_time;
@@ -653,6 +654,7 @@ static inline struct search *search_allo
s->orig_bio = bio;
s->cache_miss = NULL;
+ s->cache_missed = 0;
s->d = d;
s->recoverable = 1;
s->write = (bio->bi_rw & REQ_WRITE) != 0;
@@ -776,7 +778,7 @@ static void cached_dev_read_done_bh(stru
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
bch_mark_cache_accounting(s->iop.c, s->d,
- !s->cache_miss, s->iop.bypass);
+ !s->cache_missed, s->iop.bypass);
trace_bcache_read(s->orig_bio, !s->cache_miss, s->iop.bypass);
if (s->iop.error)
@@ -795,6 +797,8 @@ static int cached_dev_cache_miss(struct
struct cached_dev *dc = container_of(s->d, struct cached_dev, disk);
struct bio *miss, *cache_bio;
+ s->cache_missed = 1;
+
if (s->cache_miss || s->iop.bypass) {
miss = bio_next_split(bio, sectors, GFP_NOIO, s->d->bio_split);
ret = miss == bio ? MAP_DONE : MAP_CONTINUE;
Patches currently in stable-queue which might be from tang.junhui(a)zte.com.cn are
queue-4.4/bcache-fix-wrong-cache_misses-statistics.patch
This is a note to let you know that I've just added the patch titled
bcache: explicitly destroy mutex while exiting
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
bcache-explicitly-destroy-mutex-while-exiting.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Liang Chen <liangchen.linux(a)gmail.com>
Date: Mon, 30 Oct 2017 14:46:35 -0700
Subject: bcache: explicitly destroy mutex while exiting
From: Liang Chen <liangchen.linux(a)gmail.com>
[ Upstream commit 330a4db89d39a6b43f36da16824eaa7a7509d34d ]
mutex_destroy does nothing most of time, but it's better to call
it to make the code future proof and it also has some meaning
for like mutex debug.
As Coly pointed out in a previous review, bcache_exit() may not be
able to handle all the references properly if userspace registers
cache and backing devices right before bch_debug_init runs and
bch_debug_init failes later. So not exposing userspace interface
until everything is ready to avoid that issue.
Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com>
Reviewed-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Coly Li <colyli(a)suse.de>
Reviewed-by: Eric Wheeler <bcache(a)linux.ewheeler.net>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bcache/super.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -2083,6 +2083,7 @@ static void bcache_exit(void)
if (bcache_major)
unregister_blkdev(bcache_major, "bcache");
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
}
static int __init bcache_init(void)
@@ -2101,14 +2102,15 @@ static int __init bcache_init(void)
bcache_major = register_blkdev(0, "bcache");
if (bcache_major < 0) {
unregister_reboot_notifier(&reboot);
+ mutex_destroy(&bch_register_lock);
return bcache_major;
}
if (!(bcache_wq = create_workqueue("bcache")) ||
!(bcache_kobj = kobject_create_and_add("bcache", fs_kobj)) ||
- sysfs_create_files(bcache_kobj, files) ||
bch_request_init() ||
- bch_debug_init(bcache_kobj))
+ bch_debug_init(bcache_kobj) ||
+ sysfs_create_files(bcache_kobj, files))
goto err;
return 0;
Patches currently in stable-queue which might be from liangchen.linux(a)gmail.com are
queue-4.4/bcache-explicitly-destroy-mutex-while-exiting.patch
This is a note to let you know that I've just added the patch titled
ath9k: fix tx99 potential info leak
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ath9k-fix-tx99-potential-info-leak.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Miaoqing Pan <miaoqing(a)codeaurora.org>
Date: Wed, 27 Sep 2017 09:13:34 +0800
Subject: ath9k: fix tx99 potential info leak
From: Miaoqing Pan <miaoqing(a)codeaurora.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(a)codeaurora.org>
Reviewed-by: Christoph Böhmwalder <christoph(a)boehmwalder.at>
Signed-off-by: Kalle Valo <kvalo(a)qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/tx99.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -180,6 +180,9 @@ static ssize_t write_file_tx99(struct fi
ssize_t len;
int r;
+ if (count < 1)
+ return -EINVAL;
+
if (sc->cur_chan->nvifs > 1)
return -EOPNOTSUPP;
@@ -187,6 +190,8 @@ static ssize_t write_file_tx99(struct fi
if (copy_from_user(buf, user_buf, len))
return -EFAULT;
+ buf[len] = '\0';
+
if (strtobool(buf, &start))
return -EINVAL;
Patches currently in stable-queue which might be from miaoqing(a)codeaurora.org are
queue-4.4/ath9k-fix-tx99-potential-info-leak.patch
This is a note to let you know that I've just added the patch titled
arm-ccn: perf: Prevent module unload while PMU is in use
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Date: Fri, 3 Nov 2017 11:45:18 +0000
Subject: arm-ccn: perf: Prevent module unload while PMU is in use
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
[ Upstream commit c7f5828bf77dcbd61d51f4736c1d5aa35663fbb4 ]
When the PMU driver is built as a module, the perf expects the
pmu->module to be valid, so that the driver is prevented from
being unloaded while it is in use. Fix the CCN pmu driver to
fill in this field.
Fixes: a33b0daab73a0 ("bus: ARM CCN PMU driver")
Cc: Pawel Moll <pawel.moll(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bus/arm-ccn.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/bus/arm-ccn.c
+++ b/drivers/bus/arm-ccn.c
@@ -1260,6 +1260,7 @@ static int arm_ccn_pmu_init(struct arm_c
/* Perf driver registration */
ccn->dt.pmu = (struct pmu) {
+ .module = THIS_MODULE,
.attr_groups = arm_ccn_pmu_attr_groups,
.task_ctx_nr = perf_invalid_context,
.event_init = arm_ccn_pmu_event_init,
Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are
queue-4.4/arm-ccn-perf-prevent-module-unload-while-pmu-is-in-use.patch
This is a note to let you know that I've just added the patch titled
afs: Prevent callback expiry timer overflow
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-prevent-callback-expiry-timer-overflow.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Tina Ruchandani <ruchandani.tina(a)gmail.com>
Date: Thu, 16 Mar 2017 16:27:46 +0000
Subject: afs: Prevent callback expiry timer overflow
From: Tina Ruchandani <ruchandani.tina(a)gmail.com>
[ Upstream commit 56e714312e7dbd6bb83b2f78d3ec19a404c7649f ]
get_seconds() returns real wall-clock seconds. On 32-bit systems
this value will overflow in year 2038 and beyond. This patch changes
afs_vnode record to use ktime_get_real_seconds() instead, for the
fields cb_expires and cb_expires_at.
Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/fsclient.c | 2 +-
fs/afs/inode.c | 7 ++++---
fs/afs/internal.h | 4 ++--
3 files changed, 7 insertions(+), 6 deletions(-)
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -139,7 +139,7 @@ static void xdr_decode_AFSCallBack(const
vnode->cb_version = ntohl(*bp++);
vnode->cb_expiry = ntohl(*bp++);
vnode->cb_type = ntohl(*bp++);
- vnode->cb_expires = vnode->cb_expiry + get_seconds();
+ vnode->cb_expires = vnode->cb_expiry + ktime_get_real_seconds();
*_bp = bp;
}
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -244,12 +244,13 @@ struct inode *afs_iget(struct super_bloc
vnode->cb_version = 0;
vnode->cb_expiry = 0;
vnode->cb_type = 0;
- vnode->cb_expires = get_seconds();
+ vnode->cb_expires = ktime_get_real_seconds();
} else {
vnode->cb_version = cb->version;
vnode->cb_expiry = cb->expiry;
vnode->cb_type = cb->type;
- vnode->cb_expires = vnode->cb_expiry + get_seconds();
+ vnode->cb_expires = vnode->cb_expiry +
+ ktime_get_real_seconds();
}
}
@@ -322,7 +323,7 @@ int afs_validate(struct afs_vnode *vnode
!test_bit(AFS_VNODE_CB_BROKEN, &vnode->flags) &&
!test_bit(AFS_VNODE_MODIFIED, &vnode->flags) &&
!test_bit(AFS_VNODE_ZAP_DATA, &vnode->flags)) {
- if (vnode->cb_expires < get_seconds() + 10) {
+ if (vnode->cb_expires < ktime_get_real_seconds() + 10) {
_debug("callback expired");
set_bit(AFS_VNODE_CB_BROKEN, &vnode->flags);
} else {
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -375,8 +375,8 @@ struct afs_vnode {
struct rb_node server_rb; /* link in server->fs_vnodes */
struct rb_node cb_promise; /* link in server->cb_promises */
struct work_struct cb_broken_work; /* work to be done on callback break */
- time_t cb_expires; /* time at which callback expires */
- time_t cb_expires_at; /* time used to order cb_promise */
+ time64_t cb_expires; /* time at which callback expires */
+ time64_t cb_expires_at; /* time used to order cb_promise */
unsigned cb_version; /* callback version */
unsigned cb_expiry; /* callback expiry time */
afs_callback_type_t cb_type; /* type of callback */
Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
This is a note to let you know that I've just added the patch titled
afs: Populate group ID from vnode status
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-populate-group-id-from-vnode-status.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Marc Dionne <marc.dionne(a)auristor.com>
Date: Thu, 16 Mar 2017 16:27:43 +0000
Subject: afs: Populate group ID from vnode status
From: Marc Dionne <marc.dionne(a)auristor.com>
[ Upstream commit 6186f0788b31f44affceeedc7b48eb10faea120d ]
The group was hard coded to GLOBAL_ROOT_GID; use the group
ID that was received from the server.
Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -69,7 +69,7 @@ static int afs_inode_map_status(struct a
set_nlink(inode, vnode->status.nlink);
inode->i_uid = vnode->status.owner;
- inode->i_gid = GLOBAL_ROOT_GID;
+ inode->i_gid = vnode->status.group;
inode->i_size = vnode->status.size;
inode->i_ctime.tv_sec = vnode->status.mtime_server;
inode->i_ctime.tv_nsec = 0;
Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
This is a note to let you know that I've just added the patch titled
afs: Populate and use client modification time
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-populate-and-use-client-modification-time.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Marc Dionne <marc.dionne(a)auristor.com>
Date: Thu, 16 Mar 2017 16:27:47 +0000
Subject: afs: Populate and use client modification time
From: Marc Dionne <marc.dionne(a)auristor.com>
[ Upstream commit ab94f5d0dd6fd82e7eeca5e7c8096eaea0a0261f ]
The inode timestamps should be set from the client time
in the status received from the server, rather than the
server time which is meant for internal server use.
Set AFS_SET_MTIME and populate the mtime for operations
that take an input status, such as file/dir creation
and StoreData. If an input time is not provided the
server will set the vnode times based on the current server
time.
In a situation where the server has some skew with the
client, this could lead to the client seeing a timestamp
in the future for a file that it just created or wrote.
Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/fsclient.c | 18 +++++++++---------
fs/afs/inode.c | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -105,7 +105,7 @@ static void xdr_decode_AFSFetchStatus(co
vnode->vfs_inode.i_mode = mode;
}
- vnode->vfs_inode.i_ctime.tv_sec = status->mtime_server;
+ vnode->vfs_inode.i_ctime.tv_sec = status->mtime_client;
vnode->vfs_inode.i_mtime = vnode->vfs_inode.i_ctime;
vnode->vfs_inode.i_atime = vnode->vfs_inode.i_ctime;
vnode->vfs_inode.i_version = data_version;
@@ -703,8 +703,8 @@ int afs_fs_create(struct afs_server *ser
memset(bp, 0, padsz);
bp = (void *) bp + padsz;
}
- *bp++ = htonl(AFS_SET_MODE);
- *bp++ = 0; /* mtime */
+ *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME);
+ *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */
*bp++ = 0; /* owner */
*bp++ = 0; /* group */
*bp++ = htonl(mode & S_IALLUGO); /* unix mode */
@@ -981,8 +981,8 @@ int afs_fs_symlink(struct afs_server *se
memset(bp, 0, c_padsz);
bp = (void *) bp + c_padsz;
}
- *bp++ = htonl(AFS_SET_MODE);
- *bp++ = 0; /* mtime */
+ *bp++ = htonl(AFS_SET_MODE | AFS_SET_MTIME);
+ *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */
*bp++ = 0; /* owner */
*bp++ = 0; /* group */
*bp++ = htonl(S_IRWXUGO); /* unix mode */
@@ -1192,8 +1192,8 @@ static int afs_fs_store_data64(struct af
*bp++ = htonl(vnode->fid.vnode);
*bp++ = htonl(vnode->fid.unique);
- *bp++ = 0; /* mask */
- *bp++ = 0; /* mtime */
+ *bp++ = htonl(AFS_SET_MTIME); /* mask */
+ *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */
*bp++ = 0; /* owner */
*bp++ = 0; /* group */
*bp++ = 0; /* unix mode */
@@ -1269,8 +1269,8 @@ int afs_fs_store_data(struct afs_server
*bp++ = htonl(vnode->fid.vnode);
*bp++ = htonl(vnode->fid.unique);
- *bp++ = 0; /* mask */
- *bp++ = 0; /* mtime */
+ *bp++ = htonl(AFS_SET_MTIME); /* mask */
+ *bp++ = htonl(vnode->vfs_inode.i_mtime.tv_sec); /* mtime */
*bp++ = 0; /* owner */
*bp++ = 0; /* group */
*bp++ = 0; /* unix mode */
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -71,7 +71,7 @@ static int afs_inode_map_status(struct a
inode->i_uid = vnode->status.owner;
inode->i_gid = vnode->status.group;
inode->i_size = vnode->status.size;
- inode->i_ctime.tv_sec = vnode->status.mtime_server;
+ inode->i_ctime.tv_sec = vnode->status.mtime_client;
inode->i_ctime.tv_nsec = 0;
inode->i_atime = inode->i_mtime = inode->i_ctime;
inode->i_blocks = 0;
Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
This is a note to let you know that I've just added the patch titled
afs: Migrate vlocation fields to 64-bit
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-migrate-vlocation-fields-to-64-bit.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Tina Ruchandani <ruchandani.tina(a)gmail.com>
Date: Thu, 16 Mar 2017 16:27:46 +0000
Subject: afs: Migrate vlocation fields to 64-bit
From: Tina Ruchandani <ruchandani.tina(a)gmail.com>
[ Upstream commit 8a79790bf0b7da216627ffb85f52cfb4adbf1e4e ]
get_seconds() returns real wall-clock seconds. On 32-bit systems
this value will overflow in year 2038 and beyond. This patch changes
afs's vlocation record to use ktime_get_real_seconds() instead, for the
fields time_of_death and update_at.
Signed-off-by: Tina Ruchandani <ruchandani.tina(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/callback.c | 7 ++++---
fs/afs/internal.h | 7 ++++---
fs/afs/server.c | 6 +++---
fs/afs/vlocation.c | 16 +++++++++-------
4 files changed, 20 insertions(+), 16 deletions(-)
--- a/fs/afs/callback.c
+++ b/fs/afs/callback.c
@@ -362,7 +362,7 @@ static void afs_callback_updater(struct
{
struct afs_server *server;
struct afs_vnode *vnode, *xvnode;
- time_t now;
+ time64_t now;
long timeout;
int ret;
@@ -370,7 +370,7 @@ static void afs_callback_updater(struct
_enter("");
- now = get_seconds();
+ now = ktime_get_real_seconds();
/* find the first vnode to update */
spin_lock(&server->cb_lock);
@@ -424,7 +424,8 @@ static void afs_callback_updater(struct
/* and then reschedule */
_debug("reschedule");
- vnode->update_at = get_seconds() + afs_vnode_update_timeout;
+ vnode->update_at = ktime_get_real_seconds() +
+ afs_vnode_update_timeout;
spin_lock(&server->cb_lock);
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -11,6 +11,7 @@
#include <linux/compiler.h>
#include <linux/kernel.h>
+#include <linux/ktime.h>
#include <linux/fs.h>
#include <linux/pagemap.h>
#include <linux/skbuff.h>
@@ -247,7 +248,7 @@ struct afs_cache_vhash {
*/
struct afs_vlocation {
atomic_t usage;
- time_t time_of_death; /* time at which put reduced usage to 0 */
+ time64_t time_of_death; /* time at which put reduced usage to 0 */
struct list_head link; /* link in cell volume location list */
struct list_head grave; /* link in master graveyard list */
struct list_head update; /* link in master update list */
@@ -258,7 +259,7 @@ struct afs_vlocation {
struct afs_cache_vlocation vldb; /* volume information DB record */
struct afs_volume *vols[3]; /* volume access record pointer (index by type) */
wait_queue_head_t waitq; /* status change waitqueue */
- time_t update_at; /* time at which record should be updated */
+ time64_t update_at; /* time at which record should be updated */
spinlock_t lock; /* access lock */
afs_vlocation_state_t state; /* volume location state */
unsigned short upd_rej_cnt; /* ENOMEDIUM count during update */
@@ -271,7 +272,7 @@ struct afs_vlocation {
*/
struct afs_server {
atomic_t usage;
- time_t time_of_death; /* time at which put reduced usage to 0 */
+ time64_t time_of_death; /* time at which put reduced usage to 0 */
struct in_addr addr; /* server address */
struct afs_cell *cell; /* cell in which server resides */
struct list_head link; /* link in cell's server list */
--- a/fs/afs/server.c
+++ b/fs/afs/server.c
@@ -237,7 +237,7 @@ void afs_put_server(struct afs_server *s
spin_lock(&afs_server_graveyard_lock);
if (atomic_read(&server->usage) == 0) {
list_move_tail(&server->grave, &afs_server_graveyard);
- server->time_of_death = get_seconds();
+ server->time_of_death = ktime_get_real_seconds();
queue_delayed_work(afs_wq, &afs_server_reaper,
afs_server_timeout * HZ);
}
@@ -272,9 +272,9 @@ static void afs_reap_server(struct work_
LIST_HEAD(corpses);
struct afs_server *server;
unsigned long delay, expiry;
- time_t now;
+ time64_t now;
- now = get_seconds();
+ now = ktime_get_real_seconds();
spin_lock(&afs_server_graveyard_lock);
while (!list_empty(&afs_server_graveyard)) {
--- a/fs/afs/vlocation.c
+++ b/fs/afs/vlocation.c
@@ -340,7 +340,8 @@ static void afs_vlocation_queue_for_upda
struct afs_vlocation *xvl;
/* wait at least 10 minutes before updating... */
- vl->update_at = get_seconds() + afs_vlocation_update_timeout;
+ vl->update_at = ktime_get_real_seconds() +
+ afs_vlocation_update_timeout;
spin_lock(&afs_vlocation_updates_lock);
@@ -506,7 +507,7 @@ void afs_put_vlocation(struct afs_vlocat
if (atomic_read(&vl->usage) == 0) {
_debug("buried");
list_move_tail(&vl->grave, &afs_vlocation_graveyard);
- vl->time_of_death = get_seconds();
+ vl->time_of_death = ktime_get_real_seconds();
queue_delayed_work(afs_wq, &afs_vlocation_reap,
afs_vlocation_timeout * HZ);
@@ -543,11 +544,11 @@ static void afs_vlocation_reaper(struct
LIST_HEAD(corpses);
struct afs_vlocation *vl;
unsigned long delay, expiry;
- time_t now;
+ time64_t now;
_enter("");
- now = get_seconds();
+ now = ktime_get_real_seconds();
spin_lock(&afs_vlocation_graveyard_lock);
while (!list_empty(&afs_vlocation_graveyard)) {
@@ -622,13 +623,13 @@ static void afs_vlocation_updater(struct
{
struct afs_cache_vlocation vldb;
struct afs_vlocation *vl, *xvl;
- time_t now;
+ time64_t now;
long timeout;
int ret;
_enter("");
- now = get_seconds();
+ now = ktime_get_real_seconds();
/* find a record to update */
spin_lock(&afs_vlocation_updates_lock);
@@ -684,7 +685,8 @@ static void afs_vlocation_updater(struct
/* and then reschedule */
_debug("reschedule");
- vl->update_at = get_seconds() + afs_vlocation_update_timeout;
+ vl->update_at = ktime_get_real_seconds() +
+ afs_vlocation_update_timeout;
spin_lock(&afs_vlocation_updates_lock);
Patches currently in stable-queue which might be from ruchandani.tina(a)gmail.com are
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
This is a note to let you know that I've just added the patch titled
afs: Flush outstanding writes when an fd is closed
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-flush-outstanding-writes-when-an-fd-is-closed.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: David Howells <dhowells(a)redhat.com>
Date: Thu, 16 Mar 2017 16:27:45 +0000
Subject: afs: Flush outstanding writes when an fd is closed
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit 58fed94dfb17e89556b5705f20f90e5b2971b6a1 ]
Flush outstanding writes in afs when an fd is closed. This is what NFS and
CIFS do.
Reported-by: Marc Dionne <marc.c.dionne(a)gmail.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/file.c | 1 +
fs/afs/internal.h | 1 +
fs/afs/write.c | 14 ++++++++++++++
3 files changed, 16 insertions(+)
--- a/fs/afs/file.c
+++ b/fs/afs/file.c
@@ -29,6 +29,7 @@ static int afs_readpages(struct file *fi
const struct file_operations afs_file_operations = {
.open = afs_open,
+ .flush = afs_flush,
.release = afs_release,
.llseek = generic_file_llseek,
.read_iter = generic_file_read_iter,
--- a/fs/afs/internal.h
+++ b/fs/afs/internal.h
@@ -749,6 +749,7 @@ extern int afs_writepages(struct address
extern void afs_pages_written_back(struct afs_vnode *, struct afs_call *);
extern ssize_t afs_file_write(struct kiocb *, struct iov_iter *);
extern int afs_writeback_all(struct afs_vnode *);
+extern int afs_flush(struct file *, fl_owner_t);
extern int afs_fsync(struct file *, loff_t, loff_t, int);
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -741,6 +741,20 @@ out:
}
/*
+ * Flush out all outstanding writes on a file opened for writing when it is
+ * closed.
+ */
+int afs_flush(struct file *file, fl_owner_t id)
+{
+ _enter("");
+
+ if ((file->f_mode & FMODE_WRITE) == 0)
+ return 0;
+
+ return vfs_fsync(file, 0);
+}
+
+/*
* notification that a previously read-only page is about to become writable
* - if it returns an error, the caller will deliver a bus error signal
*/
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch
queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch
queue-4.4/afs-fix-missing-put_page.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
queue-4.4/afs-fix-afs_kill_pages.patch
This is a note to let you know that I've just added the patch titled
afs: Fix the maths in afs_fs_store_data()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-fix-the-maths-in-afs_fs_store_data.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: David Howells <dhowells(a)redhat.com>
Date: Thu, 16 Mar 2017 16:27:47 +0000
Subject: afs: Fix the maths in afs_fs_store_data()
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit 146a1192783697810b63a1e41c4d59fc93387340 ]
afs_fs_store_data() works out of the size of the write it's going to make,
but it uses 32-bit unsigned subtraction in one place that gets
automatically cast to loff_t.
However, if to < offset, then the number goes negative, but as the result
isn't signed, this doesn't get sign-extended to 64-bits when placed in a
loff_t.
Fix by casting the operands to loff_t.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/fsclient.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/afs/fsclient.c
+++ b/fs/afs/fsclient.c
@@ -1225,7 +1225,7 @@ int afs_fs_store_data(struct afs_server
_enter(",%x,{%x:%u},,",
key_serial(wb->key), vnode->fid.vid, vnode->fid.vnode);
- size = to - offset;
+ size = (loff_t)to - (loff_t)offset;
if (first != last)
size += (loff_t)(last - first) << PAGE_SHIFT;
pos = (loff_t)first << PAGE_SHIFT;
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch
queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch
queue-4.4/afs-fix-missing-put_page.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
queue-4.4/afs-fix-afs_kill_pages.patch
This is a note to let you know that I've just added the patch titled
afs: Fix page leak in afs_write_begin()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-fix-page-leak-in-afs_write_begin.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: David Howells <dhowells(a)redhat.com>
Date: Thu, 16 Mar 2017 16:27:48 +0000
Subject: afs: Fix page leak in afs_write_begin()
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit 6d06b0d25209c80e99c1e89700f1e09694a3766b ]
afs_write_begin() leaks a ref and a lock on a page if afs_fill_page()
fails. Fix the leak by unlocking and releasing the page in the error path.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/write.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -148,12 +148,12 @@ int afs_write_begin(struct file *file, s
kfree(candidate);
return -ENOMEM;
}
- *pagep = page;
- /* page won't leak in error case: it eventually gets cleaned off LRU */
if (!PageUptodate(page) && len != PAGE_CACHE_SIZE) {
ret = afs_fill_page(vnode, key, index << PAGE_CACHE_SHIFT, page);
if (ret < 0) {
+ unlock_page(page);
+ put_page(page);
kfree(candidate);
_leave(" = %d [prep]", ret);
return ret;
@@ -161,6 +161,9 @@ int afs_write_begin(struct file *file, s
SetPageUptodate(page);
}
+ /* page won't leak in error case: it eventually gets cleaned off LRU */
+ *pagep = page;
+
try_again:
spin_lock(&vnode->writeback_lock);
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch
queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch
queue-4.4/afs-fix-missing-put_page.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
queue-4.4/afs-fix-afs_kill_pages.patch
This is a note to let you know that I've just added the patch titled
afs: Fix missing put_page()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-fix-missing-put_page.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: David Howells <dhowells(a)redhat.com>
Date: Thu, 16 Mar 2017 16:27:43 +0000
Subject: afs: Fix missing put_page()
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit 29c8bbbd6e21daa0997d1c3ee886b897ee7ad652 ]
In afs_writepages_region(), inside the loop where we find dirty pages to
deal with, one of the if-statements is missing a put_page().
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/write.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -503,6 +503,7 @@ static int afs_writepages_region(struct
if (PageWriteback(page) || !PageDirty(page)) {
unlock_page(page);
+ put_page(page);
continue;
}
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch
queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch
queue-4.4/afs-fix-missing-put_page.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
queue-4.4/afs-fix-afs_kill_pages.patch
This is a note to let you know that I've just added the patch titled
afs: Fix afs_kill_pages()
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-fix-afs_kill_pages.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: David Howells <dhowells(a)redhat.com>
Date: Thu, 16 Mar 2017 16:27:48 +0000
Subject: afs: Fix afs_kill_pages()
From: David Howells <dhowells(a)redhat.com>
[ Upstream commit 7286a35e893176169b09715096a4aca557e2ccd2 ]
Fix afs_kill_pages() in two ways:
(1) If a writeback has been partially flushed, then if we try and kill the
pages it contains, some of them may no longer be undergoing writeback
and end_page_writeback() will assert.
Fix this by checking to see whether the page in question is actually
undergoing writeback before ending that writeback.
(2) The loop that scans for pages to kill doesn't increase the first page
index, and so the loop may not terminate, but it will try to process
the same pages over and over again.
Fix this by increasing the first page index to one after the last page
we processed.
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/write.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -299,10 +299,14 @@ static void afs_kill_pages(struct afs_vn
ASSERTCMP(pv.nr, ==, count);
for (loop = 0; loop < count; loop++) {
- ClearPageUptodate(pv.pages[loop]);
+ struct page *page = pv.pages[loop];
+ ClearPageUptodate(page);
if (error)
- SetPageError(pv.pages[loop]);
- end_page_writeback(pv.pages[loop]);
+ SetPageError(page);
+ if (PageWriteback(page))
+ end_page_writeback(page);
+ if (page->index >= first)
+ first = page->index + 1;
}
__pagevec_release(&pv);
Patches currently in stable-queue which might be from dhowells(a)redhat.com are
queue-4.4/afs-flush-outstanding-writes-when-an-fd-is-closed.patch
queue-4.4/afs-fix-the-maths-in-afs_fs_store_data.patch
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-prevent-callback-expiry-timer-overflow.patch
queue-4.4/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-fix-page-leak-in-afs_write_begin.patch
queue-4.4/afs-fix-missing-put_page.patch
queue-4.4/afs-migrate-vlocation-fields-to-64-bit.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
queue-4.4/afs-fix-afs_kill_pages.patch
This is a note to let you know that I've just added the patch titled
afs: Adjust mode bits processing
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
afs-adjust-mode-bits-processing.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:47:43 CET 2017
From: Marc Dionne <marc.dionne(a)auristor.com>
Date: Thu, 16 Mar 2017 16:27:44 +0000
Subject: afs: Adjust mode bits processing
From: Marc Dionne <marc.dionne(a)auristor.com>
[ Upstream commit 627f46943ff90bcc32ddeb675d881c043c6fa2ae ]
Mode bits for an afs file should not be enforced in the usual
way.
For files, the absence of user bits can restrict file access
with respect to what is granted by the server.
These bits apply regardless of the owner or the current uid; the
rest of the mode bits (group, other) are ignored.
Signed-off-by: Marc Dionne <marc.dionne(a)auristor.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/afs/security.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/fs/afs/security.c
+++ b/fs/afs/security.c
@@ -340,17 +340,22 @@ int afs_permission(struct inode *inode,
} else {
if (!(access & AFS_ACE_LOOKUP))
goto permission_denied;
+ if ((mask & MAY_EXEC) && !(inode->i_mode & S_IXUSR))
+ goto permission_denied;
if (mask & (MAY_EXEC | MAY_READ)) {
if (!(access & AFS_ACE_READ))
goto permission_denied;
+ if (!(inode->i_mode & S_IRUSR))
+ goto permission_denied;
} else if (mask & MAY_WRITE) {
if (!(access & AFS_ACE_WRITE))
goto permission_denied;
+ if (!(inode->i_mode & S_IWUSR))
+ goto permission_denied;
}
}
key_put(key);
- ret = generic_permission(inode, mask);
_leave(" = %d", ret);
return ret;
Patches currently in stable-queue which might be from marc.dionne(a)auristor.com are
queue-4.4/afs-populate-group-id-from-vnode-status.patch
queue-4.4/afs-adjust-mode-bits-processing.patch
queue-4.4/afs-populate-and-use-client-modification-time.patch
alg_setkey do not check the keylen whether it is zero, so the key
may be ZERO_SIZE_PTR when keylen is 0, which will pass the
copy_from_user's checking and be passed to the lower functions as key.
If the lower functions only check the key if it is NULL, ZERO_SIZE_PTR
will pass the checking, and will cause null ptr dereference, so it's
better to intercept the invalid parameters in the upper functions.
This patch is also suitable to fix CVE-2017-15116 for stable trees.
Signed-off-by: Li Kun <hw.likun(a)huawei.com>
---
crypto/af_alg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 337cf38..10f22f3 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -210,6 +210,8 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
u8 *key;
int err;
+ if (!keylen)
+ return -EINVAL;
key = sock_kmalloc(sk, keylen, GFP_KERNEL);
if (!key)
return -ENOMEM;
--
1.8.3.4
This is a note to let you know that I've just added the patch titled
xfs: truncate pagecache before writeback in xfs_setattr_size()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 14:12:35 CET 2017
From: Eryu Guan <eguan(a)redhat.com>
Date: Wed, 1 Nov 2017 21:43:50 -0700
Subject: xfs: truncate pagecache before writeback in xfs_setattr_size()
From: Eryu Guan <eguan(a)redhat.com>
[ Upstream commit 350976ae21873b0d36584ea005076356431b8f79 ]
On truncate down, if new size is not block size aligned, we zero the
rest of block to avoid exposing stale data to user, and
iomap_truncate_page() skips zeroing if the range is already in
unwritten state or a hole. Then we writeback from on-disk i_size to
the new size if this range hasn't been written to disk yet, and
truncate page cache beyond new EOF and set in-core i_size.
The problem is that we could write data between di_size and newsize
before removing the page cache beyond newsize, as the extents may
still be in unwritten state right after a buffer write. As such, the
page of data that newsize lies in has not been zeroed by page cache
invalidation before it is written, and xfs_do_writepage() hasn't
triggered it's "zero data beyond EOF" case because we haven't
updated in-core i_size yet. Then a subsequent mmap read could see
non-zeros past EOF.
I occasionally see this in fsx runs in fstests generic/112, a
simplified fsx operation sequence is like (assuming 4k block size
xfs):
fallocate 0x0 0x1000 0x0 keep_size
write 0x0 0x1000 0x0
truncate 0x0 0x800 0x1000
punch_hole 0x0 0x800 0x800
mapread 0x0 0x800 0x800
where fallocate allocates unwritten extent but doesn't update
i_size, buffer write populates the page cache and extent is still
unwritten, truncate skips zeroing page past new EOF and writes the
page to disk, punch_hole invalidates the page cache, at last mapread
reads the block back and sees non-zero beyond EOF.
Fix it by moving truncate_setsize() to before writeback so the page
cache invalidation zeros the partial page at the new EOF. This also
triggers "zero data beyond EOF" in xfs_do_writepage() at writeback
time, because newsize has been set and page straddles the newsize.
Also fixed the wrong 'end' param of filemap_write_and_wait_range()
call while we're at it, the 'end' is inclusive and should be
'newsize - 1'.
Suggested-by: Dave Chinner <dchinner(a)redhat.com>
Signed-off-by: Eryu Guan <eguan(a)redhat.com>
Acked-by: Dave Chinner <dchinner(a)redhat.com>
Reviewed-by: Brian Foster <bfoster(a)redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_iops.c | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -871,22 +871,6 @@ xfs_setattr_size(
return error;
/*
- * We are going to log the inode size change in this transaction so
- * any previous writes that are beyond the on disk EOF and the new
- * EOF that have not been written out need to be written here. If we
- * do not write the data out, we expose ourselves to the null files
- * problem. Note that this includes any block zeroing we did above;
- * otherwise those blocks may not be zeroed after a crash.
- */
- if (did_zeroing ||
- (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) {
- error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
- ip->i_d.di_size, newsize);
- if (error)
- return error;
- }
-
- /*
* We've already locked out new page faults, so now we can safely remove
* pages from the page cache knowing they won't get refaulted until we
* drop the XFS_MMAP_EXCL lock after the extent manipulations are
@@ -902,9 +886,29 @@ xfs_setattr_size(
* user visible changes). There's not much we can do about this, except
* to hope that the caller sees ENOMEM and retries the truncate
* operation.
+ *
+ * And we update in-core i_size and truncate page cache beyond newsize
+ * before writeback the [di_size, newsize] range, so we're guaranteed
+ * not to write stale data past the new EOF on truncate down.
*/
truncate_setsize(inode, newsize);
+ /*
+ * We are going to log the inode size change in this transaction so
+ * any previous writes that are beyond the on disk EOF and the new
+ * EOF that have not been written out need to be written here. If we
+ * do not write the data out, we expose ourselves to the null files
+ * problem. Note that this includes any block zeroing we did above;
+ * otherwise those blocks may not be zeroed after a crash.
+ */
+ if (did_zeroing ||
+ (newsize > ip->i_d.di_size && oldsize != ip->i_d.di_size)) {
+ error = filemap_write_and_wait_range(VFS_I(ip)->i_mapping,
+ ip->i_d.di_size, newsize - 1);
+ if (error)
+ return error;
+ }
+
error = xfs_trans_alloc(mp, &M_RES(mp)->tr_itruncate, 0, 0, 0, &tp);
if (error)
return error;
Patches currently in stable-queue which might be from eguan(a)redhat.com are
queue-4.9/ext4-fix-fdatasync-2-after-fallocate-2-operation.patch
queue-4.9/xfs-truncate-pagecache-before-writeback-in-xfs_setattr_size.patch