The cached writeback mapping is EOF trimmed to try and avoid races
between post-eof block management and writeback that result in
sending cached data to a stale location. The cached mapping is
currently trimmed on the validation check, which leaves a race
window between the time the mapping is cached and when it is trimmed
against the current inode size.
For example, if a new mapping is cached by delalloc conversion on a
blocksize == page size fs, we could cycle various locks, perform
memory allocations, etc. in the writeback codepath before the
associated mapping is eventually trimmed to i_size. This leaves
enough time for a post-eof truncate and file append before the
cached mapping is trimmed. The former event essentially invalidates
a range of the cached mapping and the latter bumps the inode size
such the trim on the next writepage event won't trim all of the
invalid blocks. fstest generic/464 reproduces this scenario
occasionally and causes a lost writeback and stale delalloc blocks
warning on inode inactivation.
To work around this problem, trim the cached writeback mapping as
soon as it is cached in addition to on subsequent validation checks.
This is a minor tweak to tighten the race window as much as possible
until a proper invalidation mechanism is available.
Fixes: 40214d128e07 ("xfs: trim writepage mapping to within eof")
Cc: <stable(a)vger.kernel.org> # v4.14+
Signed-off-by: Brian Foster <bfoster(a)redhat.com>
---
fs/xfs/xfs_aops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 338b9d9984e0..d9048bcea49c 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -449,6 +449,7 @@ xfs_map_blocks(
}
wpc->imap = imap;
+ xfs_trim_extent_eof(&wpc->imap, ip);
trace_xfs_map_blocks_found(ip, offset, count, wpc->io_type, &imap);
return 0;
allocate_blocks:
@@ -459,6 +460,7 @@ xfs_map_blocks(
ASSERT(whichfork == XFS_COW_FORK || cow_fsb == NULLFILEOFF ||
imap.br_startoff + imap.br_blockcount <= cow_fsb);
wpc->imap = imap;
+ xfs_trim_extent_eof(&wpc->imap, ip);
trace_xfs_map_blocks_alloc(ip, offset, count, wpc->io_type, &imap);
return 0;
}
--
2.17.2
On 1/16/19 2:35 PM, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.2, v4.19.15, v4.14.93, v4.9.150, v4.4.170, v3.18.132.
>
> v4.20.2: Build OK!
> v4.19.15: Build OK!
> v4.14.93: Build OK!
> v4.9.150: Failed to apply! Possible dependencies:
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
>
> v4.4.170: Failed to apply! Possible dependencies:
> 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces")
> 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc")
> 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build")
> 234d549662a7 ("doc-rst: video: use reference for VIDIOC_ENUMINPUT")
> 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)")
> 7347081e8a52 ("doc-rst: linux_tv: simplify references")
> 789818845202 ("doc-rst: audio: Fix some cross references")
> 94fff0dc5333 ("doc-rst: dmx_fcalls: improve man-like format")
> 9e00ffca8cc7 ("doc-rst: querycap: fix troubles on some references")
> af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls")
> c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables")
> e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
>
> v3.18.132: Failed to apply! Possible dependencies:
> 0579e6e3a326 ("doc-rst: linux_tv: remove whitespaces")
> 17defc282fe6 ("Documentation: add meta-documentation for Sphinx and kernel-doc")
> 22cba31bae9d ("Documentation/sphinx: add basic working Sphinx configuration and build")
> 5377d91f3e88 ("doc-rst: linux_tv DocBook to reST migration (docs-next)")
> 5699f871d2d5 ("scripts/kernel-doc: Adding cross-reference links to html documentation.")
> 7347081e8a52 ("doc-rst: linux_tv: simplify references")
> af4a4d0db8ab ("doc-rst: linux_tv: Replace reference names to match ioctls")
> b479bfd00e46 ("DocBook: Use a fixed encoding for output")
> c2b66cafdf02 ("[media] v4l: doc: Remove row numbers from tables")
> e6702ee18e24 ("doc-rst: app-pri: Fix a bad reference")
> fb9ffa6a7f7e ("[media] v4l: Add metadata buffer type and format")
>
>
> How should we proceed with this patch?
The Cc to stable of this patch in the pending pull request has a 'for v4.12 and up':
https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.0a&id=8015…
So no need to patch pre-4.12 kernels.
Regards,
Hans
This patch fixes a build failure when using GCC 8.1:
/usr/bin/ld: block/partitions/ldm.o: in function `ldm_parse_tocblock':
block/partitions/ldm.c:153: undefined reference to `strcmp'
This is caused by a new optimization which effectively replaces a
strncmp() call with a strcmp() call. This affects a number of strncmp()
call sites in the kernel.
The entire class of optimizations is avoided with -fno-builtin, which
gets enabled by -ffreestanding. This may avoid possible future build
failures in case new optimizations appear in future compilers.
I haven't done any performance measurements with this patch but I did
count the function calls in a defconfig build. For example, there are now
23 more sprintf() calls and 39 fewer strcpy() calls. The effect on the
other libc functions is smaller.
If this harms performance we can tackle that regression by optimizing
the call sites, ideally using semantic patches. That way, clang and ICC
builds might benfit too.
Cc: stable(a)vger.kernel.org
Reference: https://marc.info/?l=linux-m68k&m=154514816222244&w=2
Signed-off-by: Finn Thain <fthain(a)telegraphics.com.au>
---
arch/m68k/Makefile | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/Makefile b/arch/m68k/Makefile
index 997c9f20ea0f..0a99c276d9a4 100644
--- a/arch/m68k/Makefile
+++ b/arch/m68k/Makefile
@@ -58,7 +58,8 @@ cpuflags-$(CONFIG_M5206e) := $(call cc-option,-mcpu=5206e,-m5200)
cpuflags-$(CONFIG_M5206) := $(call cc-option,-mcpu=5206,-m5200)
KBUILD_AFLAGS += $(cpuflags-y)
-KBUILD_CFLAGS += $(cpuflags-y) -pipe
+KBUILD_CFLAGS += $(cpuflags-y)
+
ifdef CONFIG_MMU
# without -fno-strength-reduce the 53c7xx.c driver fails ;-(
KBUILD_CFLAGS += -fno-strength-reduce -ffixed-a2
@@ -69,6 +70,8 @@ KBUILD_CFLAGS += -D__uClinux__
KBUILD_AFLAGS += -D__uClinux__
endif
+KBUILD_CFLAGS += -pipe -ffreestanding
+
KBUILD_LDFLAGS := -m m68kelf
KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/m68k/kernel/module.lds
--
2.19.2
Hi,
I recently updated the sparc32 root file system in my testbed
with one generated with buildroot.
As a result, sparc32 images no longer boot with v3.16.y and v3.18.y.
The system starts to come up, but stalls while starting syslog.
However, v3.16 and v3.18 do boot.
I bisected v3.18.y and ended up with commit 16c193364b4 ("sparc: Harden
signal return frame checks.") as culprit; bisect results below. Reverting
this commit fixes the problem for both v3.16.y and v3.18.y.
Is it worth spending any time on this, or should I just stop testing
sparc32 boot tests with v3.16.y and v3.18.y ?
Thanks,
Guenter
---
# bad: [fa42fea0d8b49ba65b49a999331950d74827a52d] Linux 3.18.131
# good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
git bisect start 'HEAD' 'v3.18'
# bad: [6e64ac0957e06a81b22f95f3509cc39b07735d3d] usb: increase ohci watchdog delay to 275 msec
git bisect bad 6e64ac0957e06a81b22f95f3509cc39b07735d3d
# good: [3e2003cccc9fb5f73a0d251dbb595f4c6e3a08bd] USB: usbfs: allow URBs to be reaped after disconnection
git bisect good 3e2003cccc9fb5f73a0d251dbb595f4c6e3a08bd
# good: [d6a1481f7411425041271c3084f3c2e399dc6526] ASoC: wm8958: Fix enum ctl accesses in a wrong type
git bisect good d6a1481f7411425041271c3084f3c2e399dc6526
# good: [bc4b57be51fa419cd870398624c763b7afb91154] Btrfs: make btrfs_abort_transaction consider existence of new block groups
git bisect good bc4b57be51fa419cd870398624c763b7afb91154
# bad: [b4d9416d6388fb450b397484e0ab85a154471723] of: fix memory leak related to safe_name()
git bisect bad b4d9416d6388fb450b397484e0ab85a154471723
# good: [35807de76e1c2b7d15eea2f947983fcd043a2db0] clk: rockchip: free memory in error cases when registering clock branches
git bisect good 35807de76e1c2b7d15eea2f947983fcd043a2db0
# bad: [cae1c6c281d8728e98f7e7a8950d6e64746b5bbc] netfilter: arp_tables: simplify translate_compat_table args
git bisect bad cae1c6c281d8728e98f7e7a8950d6e64746b5bbc
# good: [f02212dd4bd88826afccc36146177589eccb699b] tty: vt, return error when con_startup fails
git bisect good f02212dd4bd88826afccc36146177589eccb699b
# bad: [16c193364b4d6ff58c38c209e1e2b5c6fd674123] sparc: Harden signal return frame checks.
git bisect bad 16c193364b4d6ff58c38c209e1e2b5c6fd674123
# good: [09600dd82044bf676e875d3bd9c904193c31c1f0] sfc: on MC reset, clear PIO buffer linkage in TXQs
git bisect good 09600dd82044bf676e875d3bd9c904193c31c1f0
# good: [0396a871c4e3fbbaabb4f2632c1d388a04b68c84] sparc64: Fix numa node distance initialization
git bisect good 0396a871c4e3fbbaabb4f2632c1d388a04b68c84
# good: [2a3e4b3cbee2c53c53e82b6f593160fb6583b24e] sparc/PCI: Fix for panic while enabling SR-IOV
git bisect good 2a3e4b3cbee2c53c53e82b6f593160fb6583b24e
# good: [705de0f20b1751f5816952486589543aaaa0bcbe] sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
git bisect good 705de0f20b1751f5816952486589543aaaa0bcbe
# first bad commit: [16c193364b4d6ff58c38c209e1e2b5c6fd674123] sparc: Harden signal return frame checks.
Changes since v1 [1]:
* Include another patch make sure that function-number zero can be
safely used as an invalid function number (Jeff)
* Add a comment clarifying why zero is an invalid function number (Jeff)
* Pass nfit_mem to cmd_to_func() (Jeff)
* Collect a Tested-by from Sujith
[1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019435.html
---
Quote patch2 changelog:
The _DSM function number validation only happens to succeed when the
generic Linux command number translation corresponds with a
DSM-family-specific function number. This breaks NVDIMM-N
implementations that correctly implement _LSR, _LSW, and _LSI, but do
not happen to publish support for DSM function numbers 4, 5, and 6.
Recall that the support for _LS{I,R,W} family of methods results in the
DIMM being marked as supporting those command numbers at
acpi_nfit_register_dimms() time. The DSM function mask is only used for
ND_CMD_CALL support of non-NVDIMM_FAMILY_INTEL devices.
---
Dan Williams (2):
acpi/nfit: Block function zero DSMs
acpi/nfit: Fix command-supported detection
drivers/acpi/nfit/core.c | 53 ++++++++++++++++++++++++++++++++++------------
1 file changed, 39 insertions(+), 14 deletions(-)