On 1/15/21 4:56 PM, Chris Wilson wrote:
> Quoting Jinoh Kang (2021-01-15 16:23:31)
>> If GUP-ineligible pages are passed to a GEM userptr object, -EFAULT is
>> returned only when the object is actually bound.
>>
>> The xf86-video-intel userspace driver cannot differentiate this
>> condition, and ma
Add a fallback default for IO_SPACE_BASE (at 0) for when an architecture
does not define a value.
Signed-off-by: John Garry
---
include/asm-generic/io.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 9ea83d80eb6f..4d74a0c696ca 10
Start the PCI MMIO region at IO_SPACE_BASE, and warn on any accesses below
that address. Those accesses are also discarded.
This is only for CONFIG_INDIRECT_PIO currently, and support can be added
later for !CONFIG_INDIRECT_PIO.
Signed-off-by: John Garry
---
include/linux/logic_pio.h | 5 +
Make IO space base address to be configurable through IO_SPACE_BASE.
This will allow architectures which do not natively support IO ports -
like arm64 - to harden against legacy ISA-based drivers which use
hardcoded addresses to access IO ports.
Any attempts for these drivers to request a resourc
On Fri, Jan 15, 2021 at 11:20:50AM -0500, Johannes Weiner wrote:
> On Wed, Jan 13, 2021 at 03:46:54PM +0100, Michal Hocko wrote:
> > On Tue 12-01-21 11:30:11, Johannes Weiner wrote:
> > > When a value is written to a cgroup's memory.high control file, the
> > > write() context first tries to reclai
This is a reboot of my original series to address the problem of drivers
for legacy ISA devices accessing unmapped IO port regions on arm64 systems
and causing the system to crash.
There was another recent report of such an issue [0], and some old ones
[1] and [2] for reference.
The background is
Introduce IO_SPACE_BASE, which is the base address of the IO port region.
0x1 is chosen intentionally to exclude legacy ISA IO port address
range.
Signed-off-by: John Garry
---
arch/arm64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/io.h b/arch
On Wed, Jan 6, 2021 at 10:57 AM Ryan Chen wrote:
>
> Hello John, Joel, Jae,
> For this should be set LCLK to be CRITICAL it will fix LPC related
> driver. (KCS/BT/SNOOP)
> I have send the patch before.
>
> https://patchwork.ozlabs.org/project/linux-aspeed/patch/2020092807
On Wed, 13 Jan 2021 12:03:20 +0100, Marek Szyprowski wrote:
> When Exynos power domain driver was introduced, the only way to ensure
> that power domains will be instantiated before the devices which belongs
> to them was to initialize them early enough, before the devices are
> instantiated in the
The simple_ondemand devfreq governor is used by quite a few devices, like
GPUs, DSPs, memory controllers, etc. It implements algorithm which tries
to predict the device frequency based on past statistics. There are two
tunables for the algorithm: 'upthreshold' and 'downdifferential'. These
tunables
On Fri, Jan 15, 2021 at 12:54:26PM +0100, Konrad Dybcio wrote:
> I might be wrong but it looks as if you forgot to add a compatible for
> the "sm8350_usb3_uniphy_cfg" configuration.
Not wrong at all! My mistake, will add it in v2.
Thanks,
Jack
--
The Qualcomm Innovation Center, Inc. is a member
On Fri, Jan 15, 2021 at 06:00:36PM +0100, Andrey Konovalov wrote:
> On Fri, Jan 15, 2021 at 5:56 PM Catalin Marinas
> wrote:
> >
> > On Fri, Jan 15, 2021 at 05:30:40PM +0100, Andrey Konovalov wrote:
> > > On Wed, Jan 13, 2021 at 5:54 PM Catalin Marinas
> > > wrote:
> > > > On Wed, Jan 13, 2021
This patch rejiggers the i2c-hid code so that the OF (Open Firmware
aka Device Tree) and ACPI support is separated out a bit. The OF and
ACPI drivers are now separate modules that wrap the core module.
Essentially, what we're doing here:
* Make "power up" and "power down" a function that can be (
The goal of this series is to support the Goodix GT7375P touchscreen.
This touchscreen is special because it has power sequencing
requirements that necessitate driving a reset GPIO.
To do this, we totally rejigger the way i2c-hid is organized so that
it's easier to jam the Goodix support in ther
The i2c-hid driver has been split in two. Let's enable both halves.
Signed-off-by: Douglas Anderson
Acked-by: Will Deacon
---
(no changes since v4)
Changes in v4:
- ("arm64: defconfig: Update config names for i2c-hid rejigger") new for v4.
arch/arm64/configs/defconfig | 3 ++-
1 file change
This adds new bindings for the Goodix GT7375P touchscreen. While this
touchscreen's communications are based on the generic "i2c-over-hid"
protocol, it needs special power sequencing and thus gets its own
compatible and bindings.
Signed-off-by: Douglas Anderson
Reviewed-by: Rob Herring
---
(no
On Wed, Jan 06, 2021 at 08:19:06PM +0800, Argus Lin wrote:
> MT6359 audio codec support accessory detect features, adds MT6359
> accdet driver to support plug detection and key detection.
> ---
> sound/soc/codecs/Kconfig |7 +
> sound/soc/codecs/Makefile|2 +
> sound/soc/c
On Wed, Jan 13, 2021 at 06:38:53PM +0100, Adrien Grassein wrote:
> The Nitrogen8M Mini is an ARM based single board computer (SBC).
>
> Signed-off-by: Adrien Grassein
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
You received here a review tag
Goodix i2c-hid touchscreens are mostly i2c-hid compliant but have some
special power sequencing requirements, including the need to drive a
reset line during the sequencing.
Let's use the new rejiggering of i2c-hid to support this with a thin
wrapper driver to support the first Goodix i2c-hid touc
Hi Vinod,
On Fri, Jan 15, 2021 at 06:17:36PM +0530, Vinod Koul wrote:
> On 15-01-21, 12:54, Konrad Dybcio wrote:
> > I might be wrong but it looks as if you forgot to add a compatible
> > for the "sm8350_usb3_uniphy_cfg" configuration.
I believe Konrad was referring to the driver in which I had n
On Thu, Jan 14, 2021 at 7:12 PM Davidlohr Bueso wrote:
>
> This was replaced with a kauditd_wait kthread long ago,
> back in:
>
> b7d1125817c (AUDIT: Send netlink messages from a separate kernel thread)
>
> Update the stale comment.
>
> Signed-off-by: Davidlohr Bueso
> ---
> kernel/audit.c
This is a RFC series to support userfaultfd upon shmem and hugetlbfs.
PS. Note that there's a known issue [0] with tlb against uffd-wp/soft-dirty in
general and Nadav is working on it. It may or may not directly affect
shmem/hugetlbfs since there're no COW on shared mappings normally. Private
sh
The first_index/last_index parameters in zap_details are actually only used in
unmap_mapping_range_tree(). At the meantime, this function is only called by
unmap_mapping_pages() once. Instead of passing these two variables through the
whole stack of page zapping code, remove them from zap_details
This patch introduces a very special swap-like pte for file-backed memories.
Currently it's only defined for x86_64 only, but as long as any arch that can
properly define the UFFD_WP_SWP_PTE_SPECIAL value as requested, it should
conceptually work too.
We will use this special pte to arm the ptes
Firstly, pass wp_copy into shmem_mfill_atomic_pte() through the stack.
Then apply the UFFD_WP bit properly when the UFFDIO_COPY on shmem is with
UFFDIO_COPY_MODE_WP.
One thing to mention is that shmem_mfill_atomic_pte() needs to set the dirty
bit in pte even if UFFDIO_COPY_MODE_WP is set. The rea
Firstly, the comment in zap_pte_range() is misleading because it checks against
details rather than check_mappings, so it's against what the code did.
Meanwhile, it's confusing too on not explaining why passing in the details
pointer would mean to skip all swap entries. New user of zap_details co
File-backed memory differs from anonymous memory in that even if the pte is
missing, the data could still resides either in the file or in page/swap cache.
So when wr-protect a pte, we need to consider none ptes too.
We do that by installing the uffd-wp special swap pte as a marker. So when
there
Huge zero page is handled in a special path in copy_huge_pmd(), however it
should share most codes with a normal thp page. Trying to share more code with
it by removing the special path. The only leftover so far is the huge zero
page refcounting (mm_get_huge_zero_page()), because that's separatel
Note that the special uffd-wp swap pte can be left over even if the page under
the pte got evicted. Normally when evict a page, we will unmap the ptes by
walking through the reverse mapping. However we never tracked such information
for the special swap ptes because they're not real mappings but
Teach hugetlbfs code to wr-protect none ptes just in case the page cache
existed for that pte. Meanwhile we also need to be able to recognize a uffd-wp
marker pte and remove it for uffd_wp_resolve.
Since at it, introduce a variable "psize" to replace all references to the huge
page size fetcher.
Give unmap_mapping_pages() more power by allowing to specify a zap flag so that
it can pass in more information than "whether we'd also like to zap cow pages".
With the new flag, we can remove the even_cow parameter because even_cow==false
equals to zap_flags==ZAP_FLAG_CHECK_MAPPING, while even_cow
Just like what we've done with shmem uffd-wp special ptes, we shouldn't drop
uffd-wp special swap pte for hugetlb too, only if we're going to unmap the
whole vma, or we're punching a hole with safe locks held.
For example, remove_inode_hugepages() is safe to drop uffd-wp ptes, because it
has taken
We don't have "huge" version of PTE_SWP_UFFD_WP_SPECIAL, instead when necessary
we split the thp if the huge page is uffd wr-protected previously.
However split the thp is not enough, because file-backed thp is handled totally
differently comparing to anonymous thps - rather than doing a real spli
We've had all the necessary changes ready for both shmem and hugetlbfs. Turn
on all the shmem/hugetlbfs switches for userfaultfd-wp.
Now we can remove the flags parameter for vma_can_userfault() since not used
any more. Meanwhile, we can expand UFFD_API_RANGE_IOCTLS_BASIC with
_UFFDIO_WRITEPROTE
This is to let hugetlbfs be prepared to also recognize swap special ptes just
like uffd-wp special swap ptes.
Signed-off-by: Peter Xu
---
mm/hugetlb.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index dd2acb8b3f0f..16a0
Prepare for it to be called outside of mm/hugetlb.c.
Signed-off-by: Peter Xu
---
include/linux/hugetlb.h | 8
mm/hugetlb.c| 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 27ada597a8e6..8841d1
Teach the hugetlb page fault code to understand uffd-wp special pte. For
example, when seeing such a pte we need to convert any write fault into a read
one (which is fake - we'll retry the write later if so). Meanwhile, for
handle_userfault() we'll need to make sure we must wait for the special s
It is a preparation work to be able to behave differently in the per
architecture huge_pte_alloc() according to different VMA attributes.
Signed-off-by: Peter Xu
---
arch/arm64/mm/hugetlbpage.c | 2 +-
arch/ia64/mm/hugetlbpage.c| 3 ++-
arch/mips/mm/hugetlbpage.c| 4 ++--
arch/parisc/m
Huge pmd sharing could bring problem to userfaultfd. The thing is that
userfaultfd is running its logic based on the special bits on page table
entries, however the huge pmd sharing could potentially share page table
entries for different address ranges. That could cause issues on either:
- Wh
This starts from passing cp_flags into hugetlb_change_protection() so hugetlb
will be able to handle MM_CP_UFFD_WP[_RESOLVE] requests.
huge_pte_clear_uffd_wp() is introduced to handle the case where the
UFFDIO_WRITEPROTECT is requested upon migrating huge page entries.
Signed-off-by: Peter Xu
--
Hook up hugetlbfs_fault() with the capability to handle userfaultfd-wp faults.
We do this slightly earlier than hugetlb_cow() so that we can avoid taking some
extra locks that we definitely don't need.
Signed-off-by: Peter Xu
---
mm/hugetlb.c | 19 +++
1 file changed, 19 inserti
File-backed memories are prone to unmap/swap so the ptes are always unstable.
This could lead to userfaultfd-wp information got lost when unmapped or swapped
out on such types of memory, for example, shmem. To keep such an information
persistent, we will start to use the newly introduced swap-like
Huge pmd sharing for hugetlbfs is racy with userfaultfd-wp because
userfaultfd-wp is always based on pgtable entries, so they cannot be shared.
Walk the hugetlb range and unshare all such mappings if there is, right before
UFFDIO_REGISTER will succeed and return to userspace.
This will pair with
It should be handled similarly like other uffd-wp wr-protected ptes: we should
pass it over when the dst_vma has VM_UFFD_WP armed, otherwise drop it.
Signed-off-by: Peter Xu
---
mm/memory.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memor
pte_unmap_same() will always unmap the pte pointer. After the unmap, vmf->pte
will not be valid any more. We should clear it.
It was safe only because no one is accessing vmf->pte after pte_unmap_same()
returns, since the only caller of pte_unmap_same() (so far) is do_swap_page(),
where vmf->pte
Instead of trying to introduce one variable for every new zap_details fields,
let's introduce a flag so that it can start to encode true/false informations.
Let's start to use this flag first to clean up the only check_mapping variable.
Firstly, the name "check_mapping" implies this is a "boolean"
PM8019 provides 6 GPIOs. Add a compatible to support that.
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 1 +
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicet
Firstly, pass the wp_copy variable into hugetlb_mcopy_atomic_pte() thoughout
the stack. Then, apply the UFFD_WP bit if UFFDIO_COPY_MODE_WP is with
UFFDIO_COPY. Introduce huge_pte_mkuffd_wp() for it.
Note that similar to how we've handled shmem, we'd better keep setting the
dirty bit even if UFFD
We used to have special swap entries, like migration entries, hw-poison
entries, device private entries, etc.
Those "special swap entries" reside in the range that they need to be at least
swap entries first, and their types are decided by swp_type(entry).
This patch introduces another idea calle
PM8019 provides 6 MPPs. Add a compatible to support them.
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt | 1 +
drivers/pinctrl/qcom/pinctrl-spmi-mpp.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree
These include:
1. When remove migration pmd entry, should keep the uffd-wp bit from swap
pte. Note that we need to do this after setting write bit just in case we
need to remove it.
2. When change huge pmd and convert write -> read migration entry, persist
the same uffd-wp bit
We tried to do something similar in b569a1760782 ("userfaultfd: wp: drop
_PAGE_UFFD_WP properly when fork") previously, but it's not doing it all
right.. A few fixes around the code path:
1. We were referencing VM_UFFD_WP vm_flags on the _old_ vma rather than the
new vma. That's overlooke
Adds missing license and/or copyright headers for KCSAN source files.
Signed-off-by: Marco Elver
---
Documentation/dev-tools/kcsan.rst | 3 +++
include/linux/kcsan-checks.h | 6 ++
include/linux/kcsan.h | 7 +++
kernel/kcsan/atomic.h | 5 +
kernel/kcsan/c
From: Dongseok Yi
Date: Fri, 15 Jan 2021 22:20:35 +0900
> UDP/IP header of UDP GROed frag_skbs are not updated even after NAT
> forwarding. Only the header of head_skb from ip_finish_output_gso ->
> skb_gso_segment is updated but following frag_skbs are not updated.
>
> A call path skb_mac_gso_s
File-backed memory is prone to being unmapped at any time. It means all
information in the pte will be dropped, including the uffd-wp flag.
Since the uffd-wp info cannot be stored in page cache or swap cache, persist
this wr-protect information by installing the special uffd-wp marker pte when
we
After we added support for shmem and hugetlbfs, we can turn uffd-wp test on
always now.
Signed-off-by: Peter Xu
---
tools/testing/selftests/vm/userfaultfd.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testin
On Fri, Jan 15, 2021 at 04:47:18PM +, Mark Rutland wrote:
> On Fri, Jan 15, 2021 at 02:24:46PM +, Mark Brown wrote:
> > +3. Considerations
> > + 3.1 Identifying successful termination
> It looks like we forgot to update this with the addition of the new
> section 3, so this need
Hi,
On Fri, Jan 15, 2021 at 6:58 AM Benjamin Tissoires
wrote:
>
> > Thanks, but don't spend too much time on it, unless something really
> > jumps out. I'll debug that tomorrow. It's much easier with an actual
> > device than by just looking at the code.
> >
>
> Well, that's weird. Now suspend re
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Fixes: 96be2e0da85e ("octeontx2-af: Su
From: Mark Rutland
Add documentation for reliable stacktrace. This is intended to describe
the semantics and to be an aid for implementing architecture support for
HAVE_RELIABLE_STACKTRACE.
Unwinding is a subtle area, and architectures vary greatly in both
implementation and the set of concerns
On Fri, Jan 15, 2021 at 2:50 PM Greg KH wrote:
>
> Minor comments, if in the future, you really do want to mess around in sysfs:
>
Thanks! Guess most of these comments apply even if I choose another FS
to mess around with.
> No copyright notice for the file? While acceptable, odds are your
> cor
On Wed, Jan 13, 2021 at 06:38:54PM +0100, Adrien Grassein wrote:
> Tested with a basic Build Root configuration booting from sdcard.
>
> Signed-off-by: Adrien Grassein
> ---
> arch/arm64/boot/dts/freescale/Makefile| 1 +
> .../dts/freescale/imx8mm-nitrogen8mm_rev2.dts | 417 +++
Respin of George's patch series enabling UBSAN for hyp/nVHE code.
Updates in v3:
* rebased onto v5.11-rc3
* added base commit info
Updates in v2:
* CONFIG_KVM_ARM_DEBUG_BUFFER removed; __kvm_check_ubsan_buffer is
called directly instead of via __kvm_arm_check_debug_buffer.
* Bugfixing
From: George Popescu
Share a buffer between the kernel and the hyp/nVHE code by using the
macros from kvm_debug_buffer.h.
The hyp/nVHE code requires a write index which counts how many elements
have been writtens inside the buffer and the kernel requires a read
index which counts how many element
From: George-Aurelian Popescu
Implement UBSan handlers inside nVHe hyp code, as empty functions for the
moment, so the undefined behaviours, that are triggered there, will be
linked to them, not to the ones defined in kernel-proper lib/ubsan.c.
In this way, enabling UBSAN_MISC won't cause a link
From: George Popescu
The handler for the load invalid value undefined behaviour is
implemented at EL2. The EL2 handler's parameters are stored inside the buffer.
They are used by the symetric handler from EL1.
Signed-off-by: George Popescu
Signed-off-by: Elena Petrova
---
arch/arm64/include/a
From: George Popescu
The data from __ubsan_handle_builtin_unreachable is passed to the buffer
and printed inside the kernel by its simetric handler.
Signed-off-by: George Popescu
Signed-off-by: Elena Petrova
---
arch/arm64/include/asm/kvm_ubsan.h | 3 +++
arch/arm64/kvm/hyp/nvhe/ubsan.c|
From: George Popescu
Whenever an arithmetic overflow: addition, substraction, multiplication,
division or negating happens inside the hyp/nVHE code,
an __ubsan_handle_*_overflow is called.
All the overflow handlers are sharing the same structure called
overflow_data.
Signed-off-by: George Popes
From: George Popescu
If an out of bounds happens inside the hyp/nVHE code, the ubsan_out_of_bounds
handler stores the logging data inside the kvm_ubsan_buffer. The one responsible
for printing is the kernel ubsan_out_of_bounds handler. The process of
decapsulating the data from the buffer is stra
From: George Popescu
Type mismatch undefiend behaviour handler provides two handlers with two
data structures type_mismatch_data and type_mismatch_data_v1. Both can be
stored inside a common data structure: type_mismatch_data_common, which
differs of type_mismatch_data only by keeping a pointer t
On Fri, Jan 15, 2021, Tom Lendacky wrote:
> On 1/13/21 6:37 PM, Sean Christopherson wrote:
> > Skip SEV's expensive WBINVD and DF_FLUSH if there are no SEV ASIDs
> > waiting to be reclaimed, e.g. if SEV was never used. This "fixes" an
> > issue where the DF_FLUSH fails during hardware teardown if
From: George Popescu
__ubsan_handle_shift_out_of_bounds data is passed to the buffer inside
hyp/nVHE. This data is passed to the original handler from kernel.
The 64bit values of the shift expression operands are stored as the lhs
and rhs pointers, so there is no need to dereference them.
Signe
From: George-Aurelian Popescu
Test the UBsan functionality inside hyp/nVHE.
Because modules are not supported inside of hyp/nVHE code, the default
testing module for UBSan can not be used.
New functions have to be defined inside of hyp/nVHE.
They are called in kvm_get_mdcr_el2, to test UBSAN when
On Fri, 15 Jan 2021 17:12:51 +
Mark Brown wrote:
> On Fri, Jan 15, 2021 at 04:47:18PM +, Mark Rutland wrote:
> > On Fri, Jan 15, 2021 at 02:24:46PM +, Mark Brown wrote:
>
> > > +3. Considerations
> > > + 3.1 Identifying successful termination
>
> > It looks like we for
On 2021-01-14 12:35, Viresh Kumar wrote:
The "oprofile" user-space tools don't use the kernel OPROFILE support
any more, and haven't in a long time. User-space has been converted to
the perf interfaces.
Remove kernel's old oprofile support.
Suggested-by: Christoph Hellwig
Suggested-by: Linus T
On Fri, Jan 15, 2021 at 5:03 AM Rafael J. Wysocki wrote:
>
> On Fri, Jan 15, 2021 at 11:03 AM Stephan Gerhold wrote:
> >
> > Hi,
> >
> > On Thu, Jan 14, 2021 at 11:31:12AM -0800, Saravana Kannan wrote:
> > > On Thu, Jan 14, 2021 at 10:41 AM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > From: R
Newer AMD processors have a feature to virtualize the use of the
SPEC_CTRL MSR on the guest. The series adds the feature support
and enables the feature on SVM.
---
v3:
1. Taken care of recent changes in vmcb_save_area. Needed to adjust the save
area spec_ctrl definition.
2. Taken care of
Newer AMD processors have a feature to virtualize the use of the
SPEC_CTRL MSR. Presence of this feature is indicated via CPUID
function 0x800A_EDX[20]: GuestSpecCtrl. When present, the
SPEC_CTRL MSR is automatically virtualized.
Signed-off-by: Babu Moger
Acked-by: Borislav Petkov
---
arch/
On Tue, 2020-09-15 at 20:49 -0400, Eric Snowberg wrote:
> The Secure Boot Forbidden Signature Database, dbx, contains a list of
> now revoked signatures and keys previously approved to boot with UEFI
> Secure Boot enabled. The dbx is capable of containing any number of
> EFI_CERT_X509_SHA256_GUID,
Newer AMD processors have a feature to virtualize the use of the
SPEC_CTRL MSR. A hypervisor may wish to impose speculation controls on
guest execution or a guest may want to impose its own speculation
controls. Therefore, the processor implements both host and guest
versions of SPEC_CTRL. Presence
On Fri, Jan 15, 2021 at 7:03 AM Lukas Bulwahn wrote:
>
> Commit e7e832ce6fa7 ("fs: add LSM-supporting anon-inode interface") adds
> more kerneldoc description, but also a few new warnings on
> anon_inode_getfd_secure() due to missing parameter descriptions.
>
> Rephrase to appropriate kernel-doc f
On Fri, Jan 15, 2021 at 2:49 PM Alexander Potapenko wrote:
>
> On Fri, Jan 15, 2021 at 2:16 PM Marco Elver wrote:
> >
> > On Thu, Jan 14, 2021 at 08:36PM +0100, Andrey Konovalov wrote:
> > > Add a test for kmem_cache_alloc/free_bulk to make sure there are no
> > > false-positives when these funct
On Thu, 14 Jan 2021 11:11:27 +0100, Enrico Weigelt, metux IT consult wrote:
> Also print out the phandle ID on error message, as a debug aid.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
> drivers/of/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, tha
The current fixed metadata version format (version 0), means that adding
metadata parameter items renders files from a previous version of perf
unreadable. Per CPU parameters appear in a fixed order, but there is no
field to indicate the number of ETM parameters per CPU.
This patch updates the per
On 2021-01-15 4:54 a.m., Mimi Zohar wrote:
On Thu, 2021-01-07 at 20:07 -0800, Tushar Sugandhi wrote:
IMA measures files and buffer data such as keys, command-line arguments
passed to the kernel on kexec system call, etc. While these measurements
are necessary for monitoring and validating th
On Thu, Dec 10, 2020 at 02:23:07AM +0800, John Garry wrote:
> Add a helper function to free the CPU rcache for all online CPUs.
>
> There also exists a function of the same name in
> drivers/iommu/intel/iommu.c, but the parameters are different, and there
> should be no conflict.
>
> Signed-off-b
On Thu, Dec 10, 2020 at 02:23:08AM +0800, John Garry wrote:
> A similar crash to the following could be observed if initial CPU rcache
> magazine allocations fail in init_iova_rcaches():
Any idea why that's happening? This fix seems ok but if we're expecting
allocation failures for the loaded mag
On Fri, 15 Jan 2021 11:45:43 +, Quentin Perret wrote:
> From: KarimAllah Ahmed
>
> Mark the memory region with NOMAP flag instead of completely removing it
> from the memory blocks. That makes the FDT handling consistent with the EFI
> memory map handling.
>
> Cc: Rob Herring
> Cc: Frank Ro
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Fixes: 96be2e0da85e ("octeontx2-af: Su
Hi Liu Ying,
I promised I would have a second, more in-depth, look at this and I finally
managed to do it.
I have to admit it was a challenge. Partially because I'm not very familiar
with DPU but mostly because of the abundance of macros used. It's true, macros
make the code more compact. However
On Fri, 15 Jan 2021 11:45:44 +, Quentin Perret wrote:
> From: Nicolas Boichat
>
> If the device tree is incorrectly configured, and attempts to
> define a "no-map" reserved memory that overlaps with the kernel
> data/code, the kernel would crash quickly after boot, with no
> obvious clue abou
From: Rob Herring
The code for setting up the /chosen node in the device tree
and updating the memory reservation for the next kernel has been
moved to of_kexec_setup_new_fdt() defined in "drivers/of/kexec.c".
Use the common of_kexec_setup_new_fdt() to setup the device tree
and update the memory
From: Rob Herring
The code for setting up the /chosen node in the device tree
and updating the memory reservation for the next kernel has been
moved to of_kexec_setup_new_fdt() defined in "drivers/of/kexec.c".
Use the common of_kexec_setup_new_fdt() to setup the device tree
and update the memory
On Fri, Jan 15, 2021, Like Xu wrote:
> Ping ?
>
> On 2020/12/30 16:19, Like Xu wrote:
> > The HW_REF_CPU_CYCLES event on the fixed counter 2 is pseudo-encoded as
> > 0x0300 in the intel_perfmon_event_map[]. Correct its usage.
> >
> > Fixes: 62079d8a4312 ("KVM: PMU: add proper support for fixed co
On kexec file load Integrity Measurement Architecture (IMA) subsystem
may verify the IMA signature of the kernel and initramfs, and measure
it. The command line parameters passed to the kernel in the kexec call
may also be measured by IMA. A remote attestation service can verify
a TPM quote based
Address and size of the buffer containing the IMA measurement log need
to be passed from the current kernel to the next kernel on kexec.
Add address and size fields to "struct kimage_arch" for ARM64 platform
to hold the address and size of the IMA measurement log buffer.
Update CONFIG_KEXEC_FILE
create_dtb() function allocates kernel virtual memory for
the device tree blob (DTB). This is not consistent with other
architectures, such as powerpc, which calls kmalloc() for allocating
memory for the DTB.
Call kmalloc() to allocate memory for the DTB, and kfree() to free
the allocated memory.
From: Rob Herring
The architecture specific field, elfcorehdr_addr in struct kimage_arch,
that holds the address of the buffer in memory for ELF core header for
powerpc has a different name than the one used for arm64. This makes
it hard to have a common code for setting up the device tree for
k
arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
sets up the address and size of the IMA measurement list in
the architecture specific fields in kimage struct. This function does not
have architecture specific code, but is currently limited to powerpc.
Move arch_ima_add_kexec_buf
fdt_appendprop_addrrange() function adds a property, with the given name,
to the device tree at the given node offset, and also sets the address
and size of the property. This function should be used to add
"linux,ima-kexec-buffer" property to the device tree and set the address
and size of the IM
901 - 1000 of 1585 matches
Mail list logo
