#
3c09ec59 |
| 09-Dec-2020 |
Catalin Marinas <catalin.marinas@arm.com> |
Merge branches 'for-next/kvm-build-fix', 'for-next/va-refactor', 'for-next/lto', 'for-next/mem-hotplug', 'for-next/cppc-ffh', 'for-next/pad-image-header', 'for-next/zone-dma-default-32-bit', 'for-nex
Merge branches 'for-next/kvm-build-fix', 'for-next/va-refactor', 'for-next/lto', 'for-next/mem-hotplug', 'for-next/cppc-ffh', 'for-next/pad-image-header', 'for-next/zone-dma-default-32-bit', 'for-next/signal-tag-bits' and 'for-next/cmdline-extended' into for-next/core
* for-next/kvm-build-fix: : Fix KVM build issues with 64K pages KVM: arm64: Fix build error in user_mem_abort()
* for-next/va-refactor: : VA layout changes arm64: mm: don't assume struct page is always 64 bytes Documentation/arm64: fix RST layout of memory.rst arm64: mm: tidy up top of kernel VA space arm64: mm: make vmemmap region a projection of the linear region arm64: mm: extend linear region for 52-bit VA configurations
* for-next/lto: : Upgrade READ_ONCE() to RCpc acquire on arm64 with LTO arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y arm64: alternatives: Remove READ_ONCE() usage during patch operation arm64: cpufeatures: Add capability for LDAPR instruction arm64: alternatives: Split up alternative.h arm64: uaccess: move uao_* alternatives to asm-uaccess.h
* for-next/mem-hotplug: : Memory hotplug improvements arm64/mm/hotplug: Ensure early memory sections are all online arm64/mm/hotplug: Enable MEM_OFFLINE event handling arm64/mm/hotplug: Register boot memory hot remove notifier earlier arm64: mm: account for hotplug memory when randomizing the linear region
* for-next/cppc-ffh: : Add CPPC FFH support using arm64 AMU counters arm64: abort counter_read_on_cpu() when irqs_disabled() arm64: implement CPPC FFH support using AMUs arm64: split counter validation function arm64: wrap and generalise counter read functions
* for-next/pad-image-header: : Pad Image header to 64KB and unmap it arm64: head: tidy up the Image header definition arm64/head: avoid symbol names pointing into first 64 KB of kernel image arm64: omit [_text, _stext) from permanent kernel mapping
* for-next/zone-dma-default-32-bit: : Default to 32-bit wide ZONE_DMA (previously reduced to 1GB for RPi4) of: unittest: Fix build on architectures without CONFIG_OF_ADDRESS mm: Remove examples from enum zone_type comment arm64: mm: Set ZONE_DMA size based on early IORT scan arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges of: unittest: Add test for of_dma_get_max_cpu_address() of/address: Introduce of_dma_get_max_cpu_address() arm64: mm: Move zone_dma_bits initialization into zone_sizes_init() arm64: mm: Move reserve_crashkernel() into mem_init() arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required arm64: Ignore any DMA offsets in the max_zone_phys() calculation
* for-next/signal-tag-bits: : Expose the FAR_EL1 tag bits in siginfo arm64: expose FAR_EL1 tag bits in siginfo signal: define the SA_EXPOSE_TAGBITS bit in sa_flags signal: define the SA_UNSUPPORTED bit in sa_flags arch: provide better documentation for the arch-specific SA_* flags signal: clear non-uapi flag bits when passing/returning sa_flags arch: move SA_* definitions to generic headers parisc: start using signal-defs.h parisc: Drop parisc special case for __sighandler_t
* for-next/cmdline-extended: : Add support for CONFIG_CMDLINE_EXTENDED arm64: Extend the kernel command line from the bootloader arm64: kaslr: Refactor early init command line parsing
show more ...
|
#
33005fd0 |
| 04-Dec-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: refactor file range validation
Refactor all the open-coded validation of file block ranges into a single helper, and teach the bmap scrubber to check the ranges.
Signed-off-by: Darrick J. Wong
xfs: refactor file range validation
Refactor all the open-coded validation of file block ranges into a single helper, and teach the bmap scrubber to check the ranges.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
show more ...
|
#
67457eb0 |
| 04-Dec-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: refactor data device extent validation
Refactor all the open-coded validation of non-static data device extents into a single helper.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> R
xfs: refactor data device extent validation
Refactor all the open-coded validation of non-static data device extents into a single helper.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
show more ...
|
#
da5de110 |
| 29-Nov-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: validate feature support when recovering rmap/refcount intents
The rmap, and refcount log intent items were added to support the rmap and reflink features. Because these features come with cha
xfs: validate feature support when recovering rmap/refcount intents
The rmap, and refcount log intent items were added to support the rmap and reflink features. Because these features come with changes to the ondisk format, the log items aren't tied to a log incompat flag.
However, the log recovery routines don't actually check for those feature flags. The kernel has no business replayng an intent item for a feature that isn't enabled, so check that as part of recovered log item validation. (Note that kernels pre-dating rmap and reflink already fail log recovery on the unknown log item type code.)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
show more ...
|
#
c447ad62 |
| 29-Nov-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: improve the code that checks recovered rmap intent items
The code that validates recovered rmap intent items is kind of a mess -- it doesn't use the standard xfs type validators, and it doesn't
xfs: improve the code that checks recovered rmap intent items
The code that validates recovered rmap intent items is kind of a mess -- it doesn't use the standard xfs type validators, and it doesn't check for things that it should. Fix the validator function to use the standard validation helpers and look for more types of obvious errors.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
show more ...
|
#
dda7ba65 |
| 29-Nov-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: hoist recovered rmap intent checks out of xfs_rui_item_recover
When we recover a rmap intent from the log, we need to validate its contents before we try to replay them. Hoist the checking cod
xfs: hoist recovered rmap intent checks out of xfs_rui_item_recover
When we recover a rmap intent from the log, we need to validate its contents before we try to replay them. Hoist the checking code into a separate function in preparation to refactor this code to use validation helpers.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com>
show more ...
|
#
20c7775a |
| 26-Nov-2020 |
Peter Zijlstra <peterz@infradead.org> |
Merge remote-tracking branch 'origin/master' into perf/core
Further perf/core patches will depend on:
d3f7b1bb2040 ("mm/gup: fix gup_fast with dynamic page table folding")
which is already in Li
Merge remote-tracking branch 'origin/master' into perf/core
Further perf/core patches will depend on:
d3f7b1bb2040 ("mm/gup: fix gup_fast with dynamic page table folding")
which is already in Linus' tree.
show more ...
|
#
05909cd9 |
| 17-Nov-2020 |
Dmitry Torokhov <dmitry.torokhov@gmail.com> |
Merge tag 'v5.9' into next
Sync up with mainline to bring in the latest DTS files.
|
#
4f6b838c |
| 12-Nov-2020 |
Marc Zyngier <maz@kernel.org> |
Merge tag 'v5.10-rc1' into kvmarm-master/next
Linux 5.10-rc1
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
#
666fab4a |
| 07-Nov-2020 |
Ingo Molnar <mingo@kernel.org> |
Merge branch 'linus' into perf/kprobes
Conflicts: include/asm-generic/atomic-instrumented.h kernel/kprobes.c
Use the upstream atomic-instrumented.h checksum, and pick the kprobes version of kerne
Merge branch 'linus' into perf/kprobes
Conflicts: include/asm-generic/atomic-instrumented.h kernel/kprobes.c
Use the upstream atomic-instrumented.h checksum, and pick the kprobes version of kernel/kprobes.c, which effectively reverts this upstream workaround:
645f224e7ba2: ("kprobes: Tell lockdep about kprobe nesting")
Since the new code *should* be fine without nesting.
Knock on wood ...
Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
5f8f9652 |
| 05-Nov-2020 |
Jani Nikula <jani.nikula@intel.com> |
Merge drm/drm-next into drm-intel-next-queued
Catch up with v5.10-rc2 and drm-misc-next.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
01be83ee |
| 04-Nov-2020 |
Thomas Gleixner <tglx@linutronix.de> |
Merge branch 'core/urgent' into core/entry
Pick up the entry fix before further modifications.
|
#
c489573b |
| 02-Nov-2020 |
Maxime Ripard <maxime@cerno.tech> |
Merge drm/drm-next into drm-misc-next
Daniel needs -rc2 in drm-misc-next to merge some patches
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
|
#
4a95857a |
| 29-Oct-2020 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
Merge tag 'drm-intel-fixes-2020-10-29' into gvt-fixes
Backmerge for 5.10-rc1 to apply one extra APL fix.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
|
Revision tags: v5.8.17 |
|
#
f59cddd8 |
| 28-Oct-2020 |
Mark Brown <broonie@kernel.org> |
Merge tag 'v5.10-rc1' into regulator-5.10
Linux 5.10-rc1
|
#
3bfd5f42 |
| 28-Oct-2020 |
Mark Brown <broonie@kernel.org> |
Merge tag 'v5.10-rc1' into spi-5.10
Linux 5.10-rc1
|
#
ce038aea |
| 28-Oct-2020 |
Mark Brown <broonie@kernel.org> |
Merge tag 'v5.10-rc1' into asoc-5.10
Linux 5.10-rc1
|
#
bbe85027 |
| 19-Oct-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge tag 'xfs-5.10-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull more xfs updates from Darrick Wong: "The second large pile of new stuff for 5.10, with changes even more monumen
Merge tag 'xfs-5.10-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
Pull more xfs updates from Darrick Wong: "The second large pile of new stuff for 5.10, with changes even more monumental than last week!
We are formally announcing the deprecation of the V4 filesystem format in 2030. All users must upgrade to the V5 format, which contains design improvements that greatly strengthen metadata validation, supports reflink and online fsck, and is the intended vehicle for handling timestamps past 2038. We're also deprecating the old Irix behavioral tweaks in September 2025.
Coming along for the ride are two design changes to the deferred metadata ops subsystem. One of the improvements is to retain correct logical ordering of tasks and subtasks, which is a more logical design for upper layers of XFS and will become necessary when we add atomic file range swaps and commits. The second improvement to deferred ops improves the scalability of the log by helping the log tail to move forward during long-running operations. This reduces log contention when there are a large number of threads trying to run transactions.
In addition to that, this fixes numerous small bugs in log recovery; refactors logical intent log item recovery to remove the last remaining place in XFS where we could have nested transactions; fixes a couple of ways that intent log item recovery could fail in ways that wouldn't have happened in the regular commit paths; fixes a deadlock vector in the GETFSMAP implementation (which improves its performance by 20%); and fixes serious bugs in the realtime growfs, fallocate, and bitmap handling code.
Summary:
- Deprecate the V4 filesystem format, some disused mount options, and some legacy sysctl knobs now that we can support dates into the 25th century. Note that removal of V4 support will not happen until the early 2030s.
- Fix some probles with inode realtime flag propagation.
- Fix some buffer handling issues when growing a rt filesystem.
- Fix a problem where a BMAP_REMAP unmap call would free rt extents even though the purpose of BMAP_REMAP is to avoid freeing the blocks.
- Strengthen the dabtree online scrubber to check hash values on child dabtree blocks.
- Actually log new intent items created as part of recovering log intent items.
- Fix a bug where quotas weren't attached to an inode undergoing bmap intent item recovery.
- Fix a buffer overrun problem with specially crafted log buffer headers.
- Various cleanups to type usage and slightly inaccurate comments.
- More cleanups to the xattr, log, and quota code.
- Don't run the (slower) shared-rmap operations on attr fork mappings.
- Fix a bug where we failed to check the LSN of finobt blocks during replay and could therefore overwrite newer data with older data.
- Clean up the ugly nested transaction mess that log recovery uses to stage intent item recovery in the correct order by creating a proper data structure to capture recovered chains.
- Use the capture structure to resume intent item chains with the same log space and block reservations as when they were captured.
- Fix a UAF bug in bmap intent item recovery where we failed to maintain our reference to the incore inode if the bmap operation needed to relog itself to continue.
- Rearrange the defer ops mechanism to finish newly created subtasks of a parent task before moving on to the next parent task.
- Automatically relog intent items in deferred ops chains if doing so would help us avoid pinning the log tail. This will help fix some log scaling problems now and will facilitate atomic file updates later.
- Fix a deadlock in the GETFSMAP implementation by using an internal memory buffer to reduce indirect calls and copies to userspace, thereby improving its performance by ~20%.
- Fix various problems when calling growfs on a realtime volume would not fully update the filesystem metadata.
- Fix broken Kconfig asking about deprecated XFS when XFS is disabled"
* tag 'xfs-5.10-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (48 commits) xfs: fix Kconfig asking about XFS_SUPPORT_V4 when XFS_FS=n xfs: fix high key handling in the rt allocator's query_range function xfs: annotate grabbing the realtime bitmap/summary locks in growfs xfs: make xfs_growfs_rt update secondary superblocks xfs: fix realtime bitmap/summary file truncation when growing rt volume xfs: fix the indent in xfs_trans_mod_dquot xfs: do the ASSERT for the arguments O_{u,g,p}dqpp xfs: fix deadlock and streamline xfs_getfsmap performance xfs: limit entries returned when counting fsmap records xfs: only relog deferred intent items if free space in the log gets low xfs: expose the log push threshold xfs: periodically relog deferred intent items xfs: change the order in which child and parent defer ops are finished xfs: fix an incore inode UAF in xfs_bui_recover xfs: clean up xfs_bui_item_recover iget/trans_alloc/ilock ordering xfs: clean up bmap intent item recovery checking xfs: xfs_defer_capture should absorb remaining transaction reservation xfs: xfs_defer_capture should absorb remaining block reservations xfs: proper replay of deferred ops queued during log recovery xfs: remove XFS_LI_RECOVERED ...
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13 |
|
#
4e919af7 |
| 27-Sep-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead to pinning the log tail. Taking up the defer ops chain examples from the previ
xfs: periodically relog deferred intent items
There's a subtle design flaw in the deferred log item code that can lead to pinning the log tail. Taking up the defer ops chain examples from the previous commit, we can get trapped in sequences like this:
Caller hands us a transaction t0 with D0-D3 attached. The defer ops chain will look like the following if the transaction rolls succeed:
t1: D0(t0), D1(t0), D2(t0), D3(t0) t2: d4(t1), d5(t1), D1(t0), D2(t0), D3(t0) t3: d5(t1), D1(t0), D2(t0), D3(t0) ... t9: d9(t7), D3(t0) t10: D3(t0) t11: d10(t10), d11(t10) t12: d11(t10)
In transaction 9, we finish d9 and try to roll to t10 while holding onto an intent item for D3 that we logged in t0.
The previous commit changed the order in which we place new defer ops in the defer ops processing chain to reduce the maximum chain length. Now make xfs_defer_finish_noroll capable of relogging the entire chain periodically so that we can always move the log tail forward. Most chains will never get relogged, except for operations that generate very long chains (large extents containing many blocks with different sharing levels) or are on filesystems with small logs and a lot of ongoing metadata updates.
Callers are now required to ensure that the transaction reservation is large enough to handle logging done items and new intent items for the maximum possible chain length. Most callers are careful to keep the chain lengths low, so the overhead should be minimal.
The decision to relog an intent item is made based on whether the intent was logged in a previous checkpoint, since there's no point in relogging an intent into the same checkpoint.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com>
show more ...
|
Revision tags: v5.8.12 |
|
#
ff4ab5e0 |
| 25-Sep-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: fix an incore inode UAF in xfs_bui_recover
In xfs_bui_item_recover, there exists a use-after-free bug with regards to the inode that is involved in the bmap replay operation. If the mapping op
xfs: fix an incore inode UAF in xfs_bui_recover
In xfs_bui_item_recover, there exists a use-after-free bug with regards to the inode that is involved in the bmap replay operation. If the mapping operation does not complete, we call xfs_bmap_unmap_extent to create a deferred op to finish the unmapping work, and we retain a pointer to the incore inode.
Unfortunately, the very next thing we do is commit the transaction and drop the inode. If reclaim tears down the inode before we try to finish the defer ops, we dereference garbage and blow up. Therefore, create a way to join inodes to the defer ops freezer so that we can maintain the xfs_inode reference until we're done with the inode.
Note: This imposes the requirement that there be enough memory to keep every incore inode in memory throughout recovery.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
show more ...
|
#
e6fff81e |
| 25-Sep-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the log, it's possible that the replay will cause the creation of m
xfs: proper replay of deferred ops queued during log recovery
When we replay unfinished intent items that have been recovered from the log, it's possible that the replay will cause the creation of more deferred work items. As outlined in commit 509955823cc9c ("xfs: log recovery should replay deferred ops in order"), later work items have an implicit ordering dependency on earlier work items. Therefore, recovery must replay the items (both recovered and created) in the same order that they would have been during normal operation.
For log recovery, we enforce this ordering by using an empty transaction to collect deferred ops that get created in the process of recovering a log intent item to prevent them from being committed before the rest of the recovered intent items. After we finish committing all the recovered log items, we allocate a transaction with an enormous block reservation, splice our huge list of created deferred ops into that transaction, and commit it, thereby finishing all those ops.
This is /really/ hokey -- it's the one place in XFS where we allow nested transactions; the splicing of the defer ops list is is inelegant and has to be done twice per recovery function; and the broken way we handle inode pointers and block reservations cause subtle use-after-free and allocator problems that will be fixed by this patch and the two patches after it.
Therefore, replace the hokey empty transaction with a structure designed to capture each chain of deferred ops that are created as part of recovering a single unfinished log intent. Finally, refactor the loop that replays those chains to do so using one transaction per chain.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
show more ...
|
Revision tags: v5.8.11 |
|
#
384ff09b |
| 21-Sep-2020 |
Darrick J. Wong <darrick.wong@oracle.com> |
xfs: don't release log intent items when recovery fails
Nowadays, log recovery will call ->release on the recovered intent items if recovery fails. Therefore, it's redundant to release them from in
xfs: don't release log intent items when recovery fails
Nowadays, log recovery will call ->release on the recovered intent items if recovery fails. Therefore, it's redundant to release them from inside the ->recover functions when they're about to return an error.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Dave Chinner <dchinner@redhat.com>
show more ...
|
Revision tags: v5.8.10, v5.8.9 |
|
#
0ea8a56d |
| 11-Sep-2020 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
Merge drm/drm-next into drm-intel-next-queued
Sync drm-intel-gt-next here so we can have an unified fixes flow.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
Revision tags: v5.8.8 |
|
#
9ddb236f |
| 09-Sep-2020 |
Takashi Iwai <tiwai@suse.de> |
Merge branch 'for-linus' into for-next
Back-merge to apply the tasklet conversion patches that are based on the already applied tasklet API changes on 5.9-rc4.
Signed-off-by: Takashi Iwai <tiwai@su
Merge branch 'for-linus' into for-next
Back-merge to apply the tasklet conversion patches that are based on the already applied tasklet API changes on 5.9-rc4.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
Revision tags: v5.8.7, v5.8.6, v5.4.62 |
|
#
6bde8ef5 |
| 02-Sep-2020 |
Takashi Iwai <tiwai@suse.de> |
Merge branch 'topic/tasklet-convert' into for-linus
Pull tasklet API conversions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|