On Sun, Jun 21, 2020 at 07:08:17AM +0300, Egor Chelak wrote:
> The flags byte of the dirent was accessed as de->flags[0] in a couple of
> places, and not as de->flags[-sbi->s_high_sierra], which is how it's
> accessed elsewhere. This caused a bug, where some files on an HSF disc
> could be
Hello RT Folks!
I'm pleased to announce the 4.19.127-rt55 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.19-rt
Head SHA1: f297d3d16170bd3af56f7310963c727ce2cab5c7
Or to build 4.19.127-rt55
On Mon, Jun 22, 2020 at 10:07:37PM +0200, Jann Horn wrote:
> On Mon, Jun 22, 2020 at 9:31 PM Kees Cook wrote:
> > This provides the ability for architectures to enable kernel stack base
> > address offset randomization. This feature is controlled by the boot
> > param
On Mon, Jun 22, 2020 at 2:15 PM Roman Gushchin wrote:
>
> On Mon, Jun 22, 2020 at 02:04:29PM -0700, Shakeel Butt wrote:
> > On Mon, Jun 22, 2020 at 1:37 PM Roman Gushchin wrote:
> > >
> > > On Mon, Jun 22, 2020 at 12:21:28PM -0700, Shakeel Butt wrote:
> > > > On Mon, Jun 8, 2020 at 4:07 PM Roman
On Mon, Jun 22, 2020 at 01:48:45PM -0400, Tejun Heo wrote:
It should be obvious that representing each consecutive memory range with a
separate directory entry is far from an optimal way of representing
something like this. It's outright silly.
On 6/22/20 11:03 AM, Greg Kroah-Hartman wrote:
On Mon, Jun 22, 2020 at 12:40:49PM -0700, Randy Dunlap wrote:
> On 6/22/20 12:31 PM, Kees Cook wrote:
> > This provides the ability for architectures to enable kernel stack base
> > address offset randomization. This feature is controlled by the boot
> > param "randomize_kstack_offset=on/off",
Hello Alexandre,
On 1/10/20 11:30 PM, Alexandre Belloni wrote:
> Add a driver for the PMC clocks of the sama5d3.
>
> Signed-off-by: Alexandre Belloni
> ---
> Changes in v2:
> - fixed the output range for the paripheral clocks
> - added a comment why the PMC driver can't be a platform driver
>
On Mon, 2020-06-22 at 21:48 +0100, Quentin Monnet wrote:
> Checkpatch reports warnings when some specific structs are not declared
> as const in the code. The list of structs to consider was initially
> defined in the checkpatch.pl script itself, but it was later moved to an
> external file
It's better to use /bin/sh instead of /bin/bash in order to run the tests
in the BusyBox shell.
Fixes: 6ea3dfe1e073 ("selftests: add TPM 2.0 tests")
Cc: sta...@vger.kernel.org
Cc: linux-integr...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Jarkko Sakkinen
---
On Sun, Jun 21, 2020 at 07:08:17AM +0300, Egor Chelak wrote:
> The flags byte of the dirent was accessed as de->flags[0] in a couple of
> places, and not as de->flags[-sbi->s_high_sierra], which is how it's
> accessed elsewhere. This caused a bug, where some files on an HSF disc
> could be
'test -f' is suitable only for *regular* files. Use 'test -e' instead.
Cc: Nikita Sobolev
Cc: linux-integr...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
Fixes: 5627f9cffee7 ("Kernel selftests: Add check if TPM devices are supported")
Signed-off-by: Jarkko Sakkinen
---
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup
A few fixes for tools/testing/selftests/tpm.
Jarkko Sakkinen (3):
Revert "tpm: selftest: cleanup after unseal with wrong auth/policy
test"
selftests: tpm: Use 'test -e' instead of 'test -f'
selftests: tpm: Use /bin/sh instead of /bin/bash
tools/testing/selftests/tpm2/test_smoke.sh | 9
On 6/22/20 10:53 AM, Tejun Heo wrote:
I don't know. The above highlights the absurdity of the approach itself to
me. You seem to be aware of it too in writing: 250,000 "devices".
Just because it is absurd doesn't mean it wasn't built that way :)
I agree, and I'm trying to influence the next
On Mon, Jun 22, 2020 at 02:04:29PM -0700, Shakeel Butt wrote:
> On Mon, Jun 22, 2020 at 1:37 PM Roman Gushchin wrote:
> >
> > On Mon, Jun 22, 2020 at 12:21:28PM -0700, Shakeel Butt wrote:
> > > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> > > >
> > > > Instead of having two sets of
On Mon, Jun 22, 2020 at 02:03:28PM -0700, H. Peter Anvin wrote:
> On 2020-06-22 14:01, Tom Rini wrote:
> >
> > I'm picky here because, well, there's a whole lot of moving parts in the
> > pre-kernel world. In a strict sense, "UEFI" doesn't do anything with
> > the kernel but based on hpa's
On Mon, Jun 22, 2020 at 01:48:45PM -0700, H. Peter Anvin wrote:
> On 2020-06-22 13:40, Tom Rini wrote:
> > On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
> >
> >> The other thing you ought to consider fixing:
> >> initrd is documented as follows:
> >>
> >> initrd=
On Mon, Jun 22, 2020 at 1:37 PM Roman Gushchin wrote:
>
> On Mon, Jun 22, 2020 at 12:21:28PM -0700, Shakeel Butt wrote:
> > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> > >
> > > Instead of having two sets of kmem_caches: one for system-wide and
> > > non-accounted allocations and the
Am 2020-06-14 12:26, schrieb Michael Walle:
Hi Rob,
Am 2020-06-10 00:03, schrieb Rob Herring:
[..]
Yes, we should use 'reg' whenever possible. If we don't have 'reg',
then you shouldn't have a unit-address either and you can simply match
on the node name (standard DT driver matching is with
On Mon, Jun 22, 2020 at 10:04:18AM -0700, Nick Desaulniers wrote:
> On Fri, Jun 19, 2020 at 8:30 PM Kees Cook wrote:
> >
> > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > (or can in the future), and suppresses unrelated compiler warnings (e.g.
> > "unused variable").
On 2020-06-22 14:01, Tom Rini wrote:
>
> I'm picky here because, well, there's a whole lot of moving parts in the
> pre-kernel world. In a strict sense, "UEFI" doesn't do anything with
> the kernel but based on hpa's comments I assume that at least the
> in-kernel UEFI stub does what
On Mon, Jun 22, 2020 at 01:56:24PM -0700, ron minnich wrote:
> So, let me first add, the comment can be removed as needed. Comments
> offered only for clarification.
Noted, thanks.
> On Mon, Jun 22, 2020 at 1:40 PM Tom Rini wrote:
>
> > But what do you mean UEFI "consumes" initrd= ?
>
>
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on sparc-next/master]
[also build test WARNING on linux/master linus/master v5.8-rc2 next-20200622]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Mon, Jun 22, 2020 at 1:18 PM Todd Kjos wrote:
>
> On Mon, Jun 22, 2020 at 1:09 PM Christian Brauner
> wrote:
> >
> > On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> > > The binder driver makes the assumption proc->context pointer is invariant
> > > after
> > > initialization (as
v2:
- split by architecture, rebase to v5.8-rc2
v1: https://lore.kernel.org/lkml/20200228002244.15240-1-keesc...@chromium.org/
A recent bug[1] was solved for builds linked with ld.lld, and tracking
it down took way longer than it needed to (a year). Ultimately, it
boiled down to differences
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly named in the linker
script.
Explicitly include debug sections when they're present. Add .eh_frame*
to discard as it
Use the common DISCARDS rule for the linker script in an effort to
regularize the linker script to prepare for warning on orphaned
sections. Additionally clean up left-over no-op macros.
Signed-off-by: Kees Cook
Acked-by: Will Deacon
---
arch/arm64/kernel/vmlinux.lds.S | 5 ++---
1 file
So, let me first add, the comment can be removed as needed. Comments
offered only for clarification.
On Mon, Jun 22, 2020 at 1:40 PM Tom Rini wrote:
> But what do you mean UEFI "consumes" initrd= ?
What I mean is, there are bootloaders that will, if they see initrd=
in the command line,
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly named in the linker
script.
Add the common debugging sections. Discard the unused note, rel, plt,
dyn, and hash
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly named in the linker
script.
Discards the unused rela, plt, and got sections that are not needed
in the final vmlinux,
v2:
- split by architecture, rebase to v5.8-rc2
v1: https://lore.kernel.org/lkml/20200228002244.15240-1-keesc...@chromium.org/
A recent bug[1] was solved for builds linked with ld.lld, and tracking
it down took way longer than it needed to (a year). Ultimately, it
boiled down to differences
For vmlinux linking, no architecture uses the .gnu.version* section,
so remove it via the common DISCARDS macro in preparation for adding
--orphan-handling=warn more widely.
Signed-off-by: Kees Cook
---
include/asm-generic/vmlinux.lds.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Hello Pavel
On Fri, Jun 19, 2020 at 11:07:19PM +0200, Pavel Machek wrote:
> On Fri 2020-06-19 16:32:47, Greg Kroah-Hartman wrote:
> > From: Serge Semin
> >
> > [ Upstream commit f0410bbf7d0fb80149e3b17d11d31f5b5197873e ]
> >
> > DW APB SSI DMA-part of the driver may need to perform the
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dd0d718152e4c65b173070d48ea9dfc06894c3e5
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to
define address spaces
date: 4 days ago
config: arm64-randconfig-s031-20200622 (attached
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly named in the linker
script.
Use common macros for debug sections, discards, and text stubs. Add
discards for unwanted
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly named in the linker
script.
Specifically, this would have made a recently fixed bug very obvious:
ld: warning: orphan
Checkpatch reports warnings when some specific structs are not declared
as const in the code. The list of structs to consider was initially
defined in the checkpatch.pl script itself, but it was later moved to an
external file (scripts/const_structs.checkpatch). This introduced two
minor issues:
v2:
- split by architecture, rebase to v5.8-rc2
v1: https://lore.kernel.org/lkml/20200228002244.15240-1-keesc...@chromium.org/
A recent bug[1] was solved for builds linked with ld.lld, and tracking
it down took way longer than it needed to (a year). Ultimately, it
boiled down to differences
On 2020-06-22 13:40, Tom Rini wrote:
> On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
>
>> The other thing you ought to consider fixing:
>> initrd is documented as follows:
>>
>> initrd= [BOOT] Specify the location of the initial ramdisk
>>
>> for bootloaders only.
psb_accel_2d_copy() checks direction PSB_2D_COPYORDER_BR2TL twice.
Based on psb_accel_2d_copy_direction() results, PSB_2D_COPYORDER_TL2BR
should be checked instead in the second direction check.
Fixes: 4d8d096e9ae8 ("gma500: introduce the framebuffer support code")
Cc: sta...@vger.kernel.org
On Sat, 20 Jun 2020 10:49:21 +0800 Li Heng wrote:
> t4_prep_fw goto bye tag with positive return value when something
> bad happened and which can not free resource in adap_init0.
> so fix it to return negative value.
>
> Fixes: 16e47624e76b ("cxgb4: Add new scheme to update T4/T5 firmware")
>
Hi,
the first patch in this series is a small but significant variation in how
the lp87565 driver enables the output rails, to allow the kernel to always
know when it is enabling an output. However it can change existing
behaviour (depending on the hardware setup) and thus it should be carefully
Hi Rob,
On 17/06/20 19:11, Rob Herring wrote:
> On Wed, 17 Jun 2020 15:11:43 +0200, Luca Ceresoli wrote:
>> The definition of "xxx-in-supply" was generic, thus define in detail the
>> possible cases for each chip variant.
>>
>> Also document that the only possible I2C slave address is 0x60 as per
Add the LP87524-Q1 to the LP87565 bindings document along with an example.
Signed-off-by: Luca Ceresoli
---
Changes in v3:
- fix yaml errors
Changes in v2:
- RFC,v1 was based on the txt file, rewrite for yaml
- use uppercase consistently in model names (Lee Jones)
- replace "regulator" ->
The definition of "xxx-in-supply" was generic, thus define in detail the
possible cases for each chip variant.
Also document that the only possible I2C slave address is 0x60 as per the
datasheet and fix the second example accordingly.
Signed-off-by: Luca Ceresoli
---
Changes in v3:
- fix
This driver enables outputs by setting bit EN_BUCKn in the BUCKn_CTRL1
register. However, if bit EN_PIN_CTRLn in the same register is set, the
output is actually enabled only if EN_BUCKn is set AND an enable pin is
active. Since the driver does not touch EN_PIN_CTRLn, the choice is left to
the
Add support for the LP87524B/J/P-Q1 Four 4-MHz Buck Converter. This is a
variant of the LP87565 having 4 single-phase outputs and up to 10 A of
total output current.
Signed-off-by: Luca Ceresoli
Acked-for-MFD-by: Lee Jones
---
Changes in v3: none
Changes in v2:
- replace "regulator" ->
On Mon, Jun 22, 2020 at 01:02:16PM -0700, ron minnich wrote:
> The other thing you ought to consider fixing:
> initrd is documented as follows:
>
> initrd= [BOOT] Specify the location of the initial ramdisk
>
> for bootloaders only.
>
> UEFI consumes initrd from the command
On Mon, Jun 22, 2020 at 12:21:28PM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin wrote:
> >
> > Instead of having two sets of kmem_caches: one for system-wide and
> > non-accounted allocations and the second one shared by all accounted
> > allocations, we can use just
On Mon, Jun 22, 2020 at 8:50 AM Sedat Dilek wrote:
>
> When building with LLVM_IAS=1 means using Clang's Integrated Assembly (IAS)
> from LLVM/Clang >= v10.0.1-rc1+ instead of GNU/as from GNU/binutils
> I see the following breakage in Debian/testing AMD64:
>
> :15:74: error: too many positional
clk_s is checked twice in a row in ni_init_smc_spll_table().
fb_div should be checked instead.
Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)")
Cc: sta...@vger.kernel.org
Signed-off-by: Denis Efremov
---
drivers/gpu/drm/radeon/ni_dpm.c | 2 +-
1 file changed, 1
On Mon, 2020-06-22 at 21:37 +0200, Julia Lawall wrote:
> Fix the parameter names in the comment to correspond to those in the
> function header.
>
> Drop comments about return values when there is no return value.
Done by hand or script?
[]
> diff --git
Hi,
On Mon, Jun 22, 2020 at 5:16 AM Stanimir Varbanov
wrote:
>
> From: Mansur Alisha Shaik
>
> Currently we are considering the instances which are available
> in core->inst list for load calculation in min_loaded_core()
> function, but this is incorrect because by the time we call
>
Running the crypto manager self tests with
CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors
when using the ccp-crypto driver:
alg: skcipher: cbc-des3-ccp encryption failed on test vector 0;
expected_error=0, actual_error=-5 ...
alg: skcipher: ctr-aes-ccp decryption
Hi Mathieu,
On 6/22/20 12:35 PM, Mathieu Poirier wrote:
Hi Suman,
Apologies for the late reply, this one slipped through the cracks...
No problem :)
On Fri, Jun 12, 2020 at 05:49:10PM -0500, Suman Anna wrote:
Texas Instruments' K3 generation SoCs have specific modules/register
spaces
On June 19, 2020 5:03:33 PM PDT, ron minnich wrote:
>It seems fine to me, but I did not initially object to the use of that
>name anyway. hpa, what do you think?
>
>On Fri, Jun 19, 2020 at 7:31 AM Tom Rini wrote:
>>
>> Most architectures have been passing the location of an initrd via
>the
>>
> -Original Message-
> From: Intel-wired-lan On Behalf Of
> Gustavo A. R. Silva
> Sent: Friday, June 19, 2020 10:56 AM
> To: Kirsher, Jeffrey T ; David S. Miller
> ; Jakub Kicinski
> Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-
> ker...@vger.kernel.org
> Subject:
Running a guest with a virtio-iommu protecting virtio devices
is broken since commit 515e5b6d90d4 ("dma-mapping: use vmap insted
of reimplementing it"). Before the conversion, the size was
page aligned in __get_vm_area_node(). Doing so fixes the
regression.
Fixes: 515e5b6d90d4 ("dma-mapping: use
Move mmu_audit.c and mmutrace.h under mmu/ where they belong.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/{ => mmu}/mmu_audit.c | 0
arch/x86/kvm/{ => mmu}/mmutrace.h | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/x86/kvm/{ => mmu}/mmu_audit.c (100%)
rename
Add mmu/mmu_internal.h to hold declarations and definitions that need
to be shared between various mmu/ files, but should not be used by
anything outside of the MMU.
Begin populating mmu_internal.h with declarations of the helpers used by
page_track.c.
Signed-off-by: Sean Christopherson
---
Make 'struct kvm_mmu_page' MMU-only, nothing outside of the MMU should
be poking into the gory details of shadow pages.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_host.h | 46 ++-
arch/x86/kvm/mmu/mmu_internal.h | 48
Rename KVM's accessor for retrieving a 'struct kvm_mmu_page' from the
associated host physical address to better convey what the function is
doing.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 20 ++--
arch/x86/kvm/mmu/mmu_audit.c| 6 +++---
Move more files to the mmu/ directory, and an mmu_internal.h to share
stuff amongst the mmu/ files, and clean up the helpers for retrieving a
shadow page from a sptep and/or hpa.
Sean Christopherson (6):
KVM: x86/mmu: Move mmu_audit.c and mmutrace.h into the mmu/
sub-directory
KVM:
Move kvm_mmu_available_pages() from mmu.h to mmu.c, it has a single
caller and has no business being exposed via mmu.h.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu.h | 9 -
arch/x86/kvm/mmu/mmu.c | 9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git
Introduce sptep_to_sp() to reduce the boilerplate code needed to get the
shadow page associated with a spte pointer, and to improve readability
as it's not immediately obvious that "page_header" is a KVM-specific
accessor for retrieving a shadow page.
Signed-off-by: Sean Christopherson
---
On Mon, Jun 22, 2020 at 1:09 PM Christian Brauner
wrote:
>
> On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> > The binder driver makes the assumption proc->context pointer is invariant
> > after
> > initialization (as documented in the kerneldoc header for struct proc).
> > However,
Fix the parameter names in the comment to correspond to those in the
function header.
Drop comments about return values when there is no return value.
Signed-off-by: Julia Lawall
---
arch/arm/mach-omap2/omap-secure.c| 2 +-
arch/arm/mach-prima2/rtciobrg.c | 2
num_extents is already checked in the next if condition and can
be safely removed.
Signed-off-by: Denis Efremov
---
fs/btrfs/tests/free-space-tree-tests.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/fs/btrfs/tests/free-space-tree-tests.c
b/fs/btrfs/tests/free-space-tree-tests.c
index
On Mon, Jun 22, 2020 at 03:28:13PM -0400, Mimi Zohar wrote:
> On Mon, 2020-06-22 at 14:27 -0300, Bruno Meneguele wrote:
> > IMA_APPRAISE_BOOTPARAM has been marked as dependent on !IMA_ARCH_POLICY in
> > compile time, enforcing the appraisal whenever the kernel had the arch
> > policy option
On Mon, Jun 22, 2020 at 08:46:17AM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote:
> > Not doable as page refcount can change for things unrelated to GUP, with
> > John changes we can identify GUP and we could potentialy copy GUPed page
> > instead of
Am 22.06.20 um 22:06 schrieb Miguel Ojeda:
On Mon, Jun 22, 2020 at 7:29 PM Joe Perches wrote:
scripts/get_maintainer.pl --self-test=links has a reachability test
using wget.
Perhaps a script like that could be used for http:// vs https://
+1
Not sure about `--no-check-certificate` if
On Thu, 2020-06-18 at 16:11 -0400, Maurizio Drocco wrote:
> From: Maurizio
>
> If PCRs 8 - 9 are set (i.e. not all-zeros), cal_bootaggr should include
> them into the digest.
>
> Signed-off-by: Maurizio Drocco
> ---
> src/evmctl.c | 16 +++-
> 1 file changed, 15 insertions(+), 1
Use "mc" for local variables to shorten line lengths and provide
consistent names, which will be especially helpful when some of the
helpers are moved to common KVM code in future patches.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
Drop the "page" variants of the topup/free memory cache helpers, using
the existence of an associated kmem_cache to select the correct alloc
or free routine.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 37
Note, patch 18 will conflict with the p4d rework in 5.8. I originally
stated I would send v2 only after that got pulled into Paolo's tree, but
I got my timing wrong, i.e. I was thinking that would have already
happened. I'll send v3 if necessary. I wanted to get v2 out there now
that I actually
Avoid refilling the memory caches and potentially slow reclaim/swap when
handling a fast page fault, which does not need to allocate any new
objects.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3
Topup memory caches after walking the GVA->GPA translation during a
shadow page fault, there is no need to ensure the caches are full when
walking the GVA. As of commit f5a1e9f89504f ("KVM: MMU: remove call
to kvm_mmu_pte_write from walk_addr"), the FNAME(walk_addr) flow no
longer add rmaps via
Clean up the minimums in mmu_topup_memory_caches() to document the
driving mechanisms behind the minimums. Now that encountering an empty
cache is unlikely to trigger BUG_ON(), it is less dangerous to be more
precise when defining the minimums.
For rmaps, the logic is 1 parent PTE per level,
Attempt to allocate a new object instead of crashing KVM (and likely the
kernel) if a memory cache is unexpectedly empty. Use GFP_ATOMIC for the
allocation as the caches are used while holding mmu_lock. The immediate
BUG_ON() makes the code unnecessarily explosive and led to confusing
minimums
Set __GFP_ZERO for the shadow page memory cache and drop the explicit
clear_page() from kvm_mmu_get_page(). This moves the cost of zeroing a
page to the allocation time of the physical page, i.e. when topping up
the memory caches, and thus avoids having to zero out an entire page
while holding
Add a gfp_zero flag to 'struct kvm_mmu_memory_cache' and use it to
control __GFP_ZERO instead of hardcoding a call to kmem_cache_zalloc().
A future patch needs such a flag for the __get_free_page() path, as
gfn arrays do not need/want the allocator to zero the memory. Convert
the kmem_cache paths
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
> On 6/21/20 4:20 PM, Zi Yan wrote:
>> On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
>>
>>> Support transparent huge page migration to ZONE_DEVICE private memory.
>>> A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
>>>
Track the kmem_cache used for non-page KVM MMU memory caches instead of
passing in the associated kmem_cache when filling the cache. This will
allow consolidating code and other cleanups.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
Return errors directly from mmu_topup_memory_caches() instead of
branching to a label that does the same.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff
Don't bother filling the gfn array cache when the caller is a fully
direct MMU, i.e. won't need a gfn array for shadow pages.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 18 ++
arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
2 files
Rename the memory helpers that will soon be moved to common code and be
made globaly available via linux/kvm_host.h. "mmu" alone is not a
sufficient namespace for globally available KVM symbols.
Opportunistically add "nr_" in mmu_memory_cache_free_objects() to make
it clear the function returns
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving MIPS to the common memory cache
implementation.
No functional change intended.
Signed-off-by: Sean Christopherson
---
On Mon, Jun 22, 2020 at 01:07:15PM -0700, Todd Kjos wrote:
> The binder driver makes the assumption proc->context pointer is invariant
> after
> initialization (as documented in the kerneldoc header for struct proc).
> However, in commit f0fe2c0f050d ("binder: prevent UAF for binderfs devices
>
Move to the common MMU memory cache implementation now that the common
code and MIPS's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
arch/mips/include/asm/Kbuild | 1 -
Move x86's memory cache helpers to common KVM code so that they can be
reused by arm64 and MIPS in future patches.
Suggested-by: Christoffer Dall
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 53 --
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving arm64 to the common memory cache
implementation.
No functional change intended.
Tested-by: Marc Zyngier
Signed-off-by:
Move to the common MMU memory cache implementation now that the common
code and arm64's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Tested-by: Marc Zyngier
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/Kbuild |
Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to make
the struct and its usage compatible with the common 'struct
kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code
churn when arm64 moves to the common implementation in a future patch, at
the cost of temporarily
Use GFP_KERNEL_ACCOUNT instead of GFP_KERNEL when allocating pages for
the the GPA page tables. The primary motivation for accounting the
allocations is to align with the common KVM memory cache helpers in
preparation for moving to the common implementation in a future patch.
The actual
Move x86's 'struct kvm_mmu_memory_cache' to common code in anticipation
of moving the entire x86 implementation code to common KVM and reusing
it for arm64 and MIPS. Add a new architecture specific asm/kvm_types.h
to control the existence and parameters of the struct. The new header
is needed to
Use separate caches for allocating shadow pages versus gfn arrays. This
sets the stage for specifying __GFP_ZERO when allocating shadow pages
without incurring extra cost for gfn arrays.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
On Mon, Jun 22, 2020 at 9:31 PM Kees Cook wrote:
> This provides the ability for architectures to enable kernel stack base
> address offset randomization. This feature is controlled by the boot
> param "randomize_kstack_offset=on/off", with its default value set by
>
601 - 700 of 1749 matches
Mail list logo
