Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_AL
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again are really just windows into package configuration.
Out of these MSRs, on
We will introduce the concept of MSRs that may not be handled in kernel
space soon. Some MSRs are directly passed through to the guest, effectively
making them handled by KVM from user space's point of view.
This patch introduces all logic required to ensure that MSRs that
user space wants trapped
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
v7 -> v8:
s/KVM_MSR_ALLOW/KVM_MSR_FILTER/g
---
arch/x86
From: Aaron Lewis
Prepare vmx and svm for a subsequent change that ensures the MSR permission
bitmap is set to allow an MSR that userspace is tracking to force a vmx_vmexit
in the guest.
Signed-off-by: Aaron Lewis
Reviewed-by: Oliver Upton
[agraf: rebase, adapt SVM scheme to nested changes tha
On 25/09/2020 12:53, Robin Murphy wrote:
---
drivers/iommu/iova.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 45a251da5453..05e0b462e0d9 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/io
On Thu, Sep 24, 2020 at 12:03 PM Chanwoo Choi wrote:
>
> Dear Rafael,
>
> This is devfreq-next pull request for v5.9-rc7. I add detailed description of
> this pull request on the following tag. Please pull devfreq with following
> updates.
> - tag name : devfreq-fixes-for-5.9-rc7
Pulled, thanks!
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
> >
> > Hi Daniel/Arnd.
> >
> > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > > The fbde
On Fri, Sep 25, 2020 at 03:25:15PM +0800, Willy Liu wrote:
> There are two chip pins named TXDLY and RXDLY which actually adds the 2ns
> delays to TXC and RXC for TXD/RXD latching. These two pins can config via
> 4.7k-ohm resistor to 3.3V hw setting, but also config via software setting
> (extensio
- On Sep 24, 2020, at 4:33 PM, rostedt rost...@goodmis.org wrote:
> On Thu, 24 Sep 2020 16:27:34 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I'd be a bit more specific: so far, the msr.h use-case requires to include
>> directly tracepoint-defs.h and use a tracepoint_enabled() macro defined
On Thu, Sep 24, 2020 at 10:01 AM wrote:
>
> From: zhuguangqing
>
> Currently, if CONFIG_SUSPEND=n and CONFIG_CPU_IDLE=y, the function
> cpuidle_enter_s2idle() is declared but not defined, it may cause error
> when cpuidle_enter_s2idle() is called.
>
> If CONFIG_SUSPEND=y and CONFIG_CPU_IDLE=n, th
Add arm64 subdirectory into the table of Contents for zh_CN,
then add other translations in arm64 conveniently.
Signed-off-by: Bailu Lin
---
Changes in v4:
- Remove index.rst's inappropriate License claim.
Changes in v3:
- Correct email encoding format.
Changes in v2:
- Fix patch description.
On Fri, Sep 25, 2020 at 2:56 PM Kent Gibson wrote:
>
> On Fri, Sep 25, 2020 at 01:12:14PM +0300, Andy Shevchenko wrote:
> > On Thu, Sep 24, 2020 at 12:48 PM Kent Gibson wrote:
> > > On Thu, Sep 24, 2020 at 11:39:03AM +0300, Andy Shevchenko wrote:
> > > > On Thu, Sep 24, 2020 at 5:39 AM Kent Gibso
From: Kan Liang
Previously, the MSR uncore for the Ice Lake and Tiger Lake are
identical. The code path is shared. However, with recent update, the
global MSR_UNC_PERF_GLOBAL_CTRL register and ARB uncore unit are changed
for the Ice Lake. Split the Ice Lake and Tiger Lake MSR uncore support.
The
Hello,
syzbot found the following issue on:
HEAD commit:3fc826f1 Merge branch 'net-dsa-bcm_sf2-Additional-DT-chang..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=158f800990
kernel config: https://syzkaller.appspot.com/x/.config?x=51fb40e67d1e3dec
das
Hello,
syzbot found the following issue on:
HEAD commit:171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead390
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
das
On 25/09/20 16:10 +0200, Alejandro Colomar wrote:
On 2020-09-25 15:20, Alejandro Colomar wrote:
'nitems()' calculates the length of an array in number of items.
It is safe: if a pointer is passed to the macro (or function, in C++),
the compilation is broken due to:
- In >= C11: _Static_asser
On Fri, Sep 25, 2020 at 3:26 PM Kent Gibson wrote:
> On Fri, Sep 25, 2020 at 12:35:49PM +0300, Andy Shevchenko wrote:
> > On Thu, Sep 24, 2020 at 6:07 AM Kent Gibson wrote:
> > > On Wed, Sep 23, 2020 at 06:47:28PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Sep 22, 2020 at 5:35 AM Kent Gibson
>> There were once RFC patches to make use of it in ACPI, but it could be
>> solved using different interfaces [1].
>>
>>
>> While I'd love to rip it out completely, I think it would break old
>> lsmem/chmem completely - and I assume that's not acceptable. I was
>> wondering what would be considere
On Tue, Sep 22, 2020 at 6:47 AM Pujin Shi wrote:
>
> Include the linux/idle_inject.h header to fix W=1 build warning:
>
> drivers/powercap/idle_inject.c:152:6: warning: no previous prototype for
> ‘idle_inject_set_duration’ [-Wmissing-prototypes]
> drivers/powercap/idle_inject.c:167:6: wa
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and
On Thu, Sep 24, 2020 at 10:38 PM Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 8:59 PM Maximilian Luz
> wrote:
> > On 9/24/20 10:26 AM, Arnd Bergmann wrote:
> > > On Thu, Sep 24, 2020 at 1:28 AM Maximilian Luz
> > > wrote:
>
> > > Note that drivers that connect to the bus typically don't live
On Fri, Sep 25, 2020 at 11:05:58AM +0800, Dave Young wrote:
> Hi,
>
> On 09/24/20 at 01:16pm, boris.ostrov...@oracle.com wrote:
> >
> > On 9/24/20 12:43 PM, Michael Kelley wrote:
> > > From: Eric W. Biederman Sent: Thursday, September
> > > 24, 2020 9:26 AM
> > >> Michael Kelley writes:
> > >>
On Fri, 25 Sep 2020 12:55:13 +0530
Naresh Kamboju wrote:
> On Fri, 25 Sep 2020 at 10:45, Greg Kroah-Hartman
> wrote:
> >
> > On Fri, Sep 25, 2020 at 10:13:05AM +0530, Naresh Kamboju wrote:
> > > >From stable rc 4.18.1 onwards to today's stable rc 4.19.147
> > >
> > > There are two problems
Explain no_user_shstk/no_user_ibt kernel parameters, and introduce a new
document on Control-flow Enforcement Technology (CET).
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
v13:
- Change X86_INTEL_* to X86_*.
v12:
- Remove ARCH_X86_CET_MMAP_SHSTK information.
v11:
- Add back GLIBC tun
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
This is the second part of CET and enables Indirect Branch Tracking (IBT).
It is built on top of
From: "H.J. Lu"
When Indirect Branch Tracking (IBT) is enabled, vDSO functions may be
called indirectly, and must have ENDBR32 or ENDBR64 as the first
instruction. The compiler must support -fcf-protection=branch so that it
can be used to compile vDSO.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-
Vsyscall entry points are effectively branch targets. Mark them with
ENDBR64 opcodes. When emulating the RET instruction, unwind shadow stack
and reset IBT state machine.
Signed-off-by: Yu-cheng Yu
---
v13:
- Check shadow stack address is canonical.
- Change from writing to MSRs to writing to C
An indirect CALL/JMP moves the indirect branch tracking (IBT) state machine
to WAIT_ENDBR status until the instruction reaches an ENDBR opcode. If the
CALL/JMP does not reach an ENDBR opcode, the processor raises a control-
protection fault. WAIT_ENDBR status can be read from MSR_IA32_U_CET.
WAI
Introduce Kconfig option X86_BRANCH_TRACKING_USER.
Indirect Branch Tracking (IBT) provides protection against CALL-/JMP-
oriented programming attacks. It is active when the kernel has this
feature enabled, and the processor and the application support it.
When this feature is enabled, legacy non-
Update arch_setup_elf_property() for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
---
v9:
- Change cpu_feature_enabled() to static_cpu_has().
arch/x86/Kconfig | 2 ++
arch/x86/kernel/process_64.c | 8
2 files changed, 10 insertions(+)
diff --git a/arch/x86/Kconfig
Introduce user-mode Indirect Branch Tracking (IBT) support. Update setup
routines to include IBT.
Signed-off-by: Yu-cheng Yu
---
v10:
- Change no_cet_ibt to no_user_ibt.
v9:
- Change cpu_feature_enabled() to static_cpu_has().
v2:
- Change noibt to no_cet_ibt.
arch/x86/include/asm/cet.h
From: "H.J. Lu"
Add ENDBR32 to __kernel_vsyscall entry point.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Acked-by: Andy Lutomirski
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S
b/arch/x86/e
From: "H.J. Lu"
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE for Indirect Branch
Tracking.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/kernel/cet_prctl.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cet_prctl.c b/arch/x86
On Thu, Sep 24, 2020 at 10:17 PM Maximilian Luz wrote:
> On 9/24/20 10:30 AM, Andy Shevchenko wrote:
> > On Wed, Sep 23, 2020 at 6:32 PM Arnd Bergmann wrote:
> >> On Wed, Sep 23, 2020 at 5:15 PM Maximilian Luz
> >> wrote:
...
> >> I think this should go to drivers/platform/x86 or drivers/plat
On 9/24/20 1:38 PM, Arvind Sankar wrote:
> On Thu, Sep 24, 2020 at 10:58:35AM -0400, Ross Philipson wrote:
>> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
>> later AMD SKINIT) to vector to during the late launch. The symbol
>> sl_stub_entry is that entry point and its off
On Fri, Sep 25, 2020 at 11:31:14AM +0100, Mark Rutland wrote:
> Hi,
>
> Sorry to come to this so late; I've been meaning to provide feedback on
> this for a while but have been indisposed for a bit due to an injury.
>
> On Fri, Sep 25, 2020 at 11:50:29AM +0200, Peter Zijlstra wrote:
> > On Fri, S
On Fri, 25 Sep 2020 10:54:58 -0400
Steven Rostedt wrote:
> The crash looks like its cr3 related, which I believe Peter Zijlstra
s/cr3/cr2/
-- Steve
> did a restructuring of that code to not let it be an issue anymore.
> I'll have to look deeper. The rework may be too intrusive to backport,
>
On 9/24/20 10:08 PM, Randy Dunlap wrote:
> On 9/24/20 7:58 AM, Ross Philipson wrote:
>> Initial bits to bring in Secure Launch functionality. Add Kconfig
>> options for compiling in/out the Secure Launch code.
>>
>> Signed-off-by: Ross Philipson
>
> Hi,
> from Documentation/process/coding-style.r
Control-flow Enforcement Technology (CET) adds five MSRs. Introduce them
and their XSAVES supervisor states:
MSR_IA32_U_CET (user-mode CET settings),
MSR_IA32_PL3_SSP (user-mode Shadow Stack pointer),
MSR_IA32_PL0_SSP (kernel-mode Shadow Stack pointer),
MSR_IA32_PL1_SSP (Privilege
On Mon, 31 Aug 2020 13:22:35 +0200 SeongJae Park wrote:
> On Thu, 20 Aug 2020 09:27:38 +0200 SeongJae Park wrote:
>
> > On Mon, 17 Aug 2020 12:51:22 +0200 SeongJae Park wrote:
> >
> > > From: SeongJae Park
> > >
[...]
> > > Introduction
> > >
> > >
> > > DAMON is a data access
On Fri, Sep 25, 2020 at 04:49:28PM +0200, David Hildenbrand wrote:
> >> There were once RFC patches to make use of it in ACPI, but it could be
> >> solved using different interfaces [1].
> >>
> >>
> >> While I'd love to rip it out completely, I think it would break old
> >> lsmem/chmem completely -
On Fri, Sep 25, 2020 at 4:47 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3fc826f1 Merge branch 'net-dsa-bcm_sf2-Additional-DT-chang..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=158f800990
> kernel config:
This series was original by a bug fix in nvme-over-tcp driver which only
checked whether a page was allocated from slab allcoator, but forgot to
check its page_count: The page handled by sendpage should be neither a
Slab page nor 0 page_count page.
As Sagi Grimberg suggested, the original fix is r
Currently nvme_tcp_try_send_data() doesn't use kernel_sendpage() to
send slab pages. But for pages allocated by __get_free_pages() without
__GFP_COMP, which also have refcount as 0, they are still sent by
kernel_sendpage() to remote end, this is problematic.
The new introduced helper sendpage_ok()
commit a10674bf2406 ("tcp: detecting the misuse of .sendpage for Slab
objects") adds the checks for Slab pages, but the pages don't have
page_count are still missing from the check.
Network layer's sendpage method is not designed to send page_count 0
pages neither, therefore both PageSlab() and pa
If a page sent into kernel_sendpage() is a slab page or it doesn't have
ref_count, this page is improper to send by the zero copy sendpage()
method. Otherwise such page might be unexpected released in network code
path and causes impredictable panic due to kernel memory management data
structure co
In iscsci driver, iscsi_tcp_segment_map() uses the following code to
check whether the page should or not be handled by sendpage:
if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
The "page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)" part is to
make sure the page can b
In libceph, ceph_tcp_sendpage() does the following checks before handle
the page by network layer's zero copy sendpage method,
if (page_count(page) >= 1 && !PageSlab(page))
This check is exactly what sendpage_ok() does. This patch replace the
open coded checks by sendpage_ok() as a code cl
In _drbd_send_page() a page is checked by following code before sending
it by kernel_sendpage(),
(page_count(page) < 1) || PageSlab(page)
If the check is true, this page won't be send by kernel_sendpage() and
handled by sock_no_sendpage().
This kind of check is exactly what macro sendpage_
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY_HW or _PAGE_COW. Change _PAGE_DIRTY to _PAGE_DIRTY_BITS.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
Cc: David Airlie
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Zhen
Kernel read-only PTEs are setup as _PAGE_DIRTY_HW. Since these become
shadow stack PTEs, remove the dirty bit.
Signed-off-by: Yu-cheng Yu
Cc: "H. Peter Anvin"
Cc: Kees Cook
Cc: Thomas Gleixner
Cc: Dave Hansen
Cc: Christoph Hellwig
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Borislav Petkov
C
Pte_modify() changes a PTE to 'newprot'. It doesn't use the pte_*()
helpers that a previous patch fixed up, so we need a new site.
Introduce fixup_dirty_pte() to set the dirty bits based on _PAGE_RW, and
apply the same changes to pmd_modify().
Signed-off-by: Yu-cheng Yu
---
v10:
- Replace _PAGE
The original problem was from nvme-over-tcp code, who mistakenly uses
kernel_sendpage() to send pages allocated by __get_free_pages() without
__GFP_COMP flag. Such pages don't have refcount (page_count is 0) on
tail pages, sending them by kernel_sendpage() may trigger a kernel panic
from a corrupte
On Tue, Sep 22, 2020 at 09:52:43PM -0400, Joel Fernandes wrote:
> On Tue, Sep 22, 2020 at 09:46:22PM -0400, Joel Fernandes wrote:
> > On Fri, Aug 28, 2020 at 11:29:27PM +0200, Peter Zijlstra wrote:
> > >
> > >
> > > This is still a horrible patch..
> >
> > Hi Peter,
> > I wrote a new patch simil
Hi Dan,
On 2020-9-25 18:57, Dan Carpenter wrote:
On Fri, Sep 25, 2020 at 05:06:33PM +0800, Chao Yu wrote:
Hi,
I don't see any problem here, thanks for your report. :)
I bet the uninitialize value is because "max_depth" is zero.
I agree with you, thanks for the hint. :)
Thanks,
352
24.09.2020 15:00, Pavel Machek пишет:
> On Sun 2020-09-06 22:51:02, Dmitry Osipenko wrote:
>> Acer Iconia Tab A500 is an Android tablet device which has two LEDs
>> embedded into the Power Button. Orange LED indicates "battery charging"
>> status and white LED indicates "wake-up/charge-done" status
Hi All,
This is regarding the KASLR feature support on ARM for the kernel
version 4.9 and 4.14.
Is KASLR supported on ARM-32 Linux 4.9 and above ?
Is it dependent on CONFIG_RANDOMIZE_BASE or
/proc/sys/kernel/randomize_va_space ?
Is there any relation between these two?
Is the changing kernel symb
On 2020-09-25 16:14:09 [+0200], Jerome Brunet wrote:
> Looks like we need to do manually what IRQF_ONESHOT was doing for us :(
IRQF_ONESHOT disables the IRQ at the irqchip level. You must ensure that
the device keeps quite. Usually you mast the interrupt source at the
device lee.
> This brings a
>
> It's a slow age-out, but watch out, you might have to revert things...
>
> good luck!
Yeah, I always liked playing with fire ;)
Thanks for the insights Greg!
--
Thanks,
David / dhildenb
On Mon 21 Sep 03:24 CDT 2020, Liu Shixin wrote:
> Simplify the return expression.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Liu Shixin
> ---
> drivers/media/platform/qcom/venus/hfi_venus.c | 28 +++
> 1 file changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/dr
Hi Geert, Mateusz,
On Fri, Sep 25, 2020 at 03:16:02PM +0200, Geert Uytterhoeven wrote:
> Hi Mateusz,
>
> On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> wrote:
> > From: Pawel Czarnecki
> >
> > This commit adds driver for the FPGA-based LiteX SoC
> > Controller from LiteX SoC builder.
> >
>
On Fri, 25 Sep 2020 10:59:14 -0400
Steven Rostedt wrote:
> On Fri, 25 Sep 2020 10:54:58 -0400
> Steven Rostedt wrote:
>
>
> > The crash looks like its cr3 related, which I believe Peter Zijlstra
>
> s/cr3/cr2/
>
Specifically, commits:
a0d14b8909de55139b8702fe0c7e80b69763dcfb ("x86/mm, tr
What fair pay measures in Linux space really becomes, is unification of
Green and Maruf politics (west / east).
With a solid basis in La Quran. (using the La prefix here, for a better
understanding, more like the arabic version).
This should really be the big thing, happening in our times, an
Can_follow_write_pte() ensures a read-only page is COWed by checking the
FOLL_COW flag, and uses pte_dirty() to validate the flag is still valid.
Like a writable data page, a shadow stack page is writable, and becomes
read-only during copy-on-write, but it is always dirty. Thus, in the
can_follow
A shadow stack page is made writable by pte_mkwrite_shstk(), which sets
_PAGE_DIRTY_HW. There are a few places that call pte_mkwrite() directly
and miss the maybe_mkwrite() fixup in the previous patch. Fix them with
maybe_mkwrite():
- do_anonymous_page() and migrate_vma_insert_page() check VM_WR
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
---
v10:
- Use arch_shadow_stack_mapping() to make meaning clear.
v8:
- Change shadow stake pages from data_vm to stack_vm.
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c
Hi,
> On 25 Sep 2020, at 00:49, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> The VCPUOP_register_runstate_memory_area hypercall takes a virtual
> address of a buffer as a parameter. The semantics of the hypercall are
> such that the virtual address should always be valid.
>
> When
This patch adds basic shadow stack enabling/disabling routines. A task's
shadow stack is allocated from memory with VM_SHSTK flag and has a fixed
size of min(RLIMIT_STACK, 4GB).
Signed-off-by: Yu-cheng Yu
---
v12:
- Split cet_disable_free_shstk() into disable and free parts, because
only the d
Hi Paul,
在 2020/9/24 上午1:29, Paul Cercueil 写道:
Hi Zhou,
Le jeu. 24 sept. 2020 à 0:26, 周琰杰 (Zhou Yanjie)
a écrit :
Used the generic PHY framework API to create the PHY, this driver
supoorts USB OTG PHY used in JZ4770 SoC, JZ4780 SoC, X1000 SoC,
and X1830 SoC.
Tested-by: 周正 (Zhou Zheng)
Test
An ELF file's .note.gnu.property indicates architecture features of the
file.. Introduce feature definitions for Shadow Stack and Indirect Branch
Tracking.
Signed-off-by: Yu-cheng Yu
---
include/uapi/linux/elf.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/linux/elf.
On Fri, Sep 25, 2020 at 11:07:06AM -0400, Steven Rostedt wrote:
> On Fri, 25 Sep 2020 10:59:14 -0400
> Steven Rostedt wrote:
>
> > On Fri, 25 Sep 2020 10:54:58 -0400
> > Steven Rostedt wrote:
> >
> >
> > > The crash looks like its cr3 related, which I believe Peter Zijlstra
> >
> > s/cr3/cr
The kernel allocates (and frees on thread exit) a new shadow stack for a
pthread child.
It is possible for the kernel to complete the clone syscall and set the
child's shadow stack pointer to NULL and let the child thread allocate
a shadow stack for itself. There are two issues in thi
Hi Jisheng,
On 25/09/2020 10:27, Jisheng Zhang wrote:
...
>> Could you please try below patch?
>>
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
>> b/drivers/pci/controller/dwc/pcie-designware-host.c
>> index bf25d783b5c5..7e5dc54d060e 100644
>> --- a/drivers/pci/controlle
On Mon 21 Sep 08:10 CDT 2020, Qinglang Miao wrote:
> Simplify the return expression.
>
Reviewed-by: Bjorn Andersson
> Signed-off-by: Qinglang Miao
> ---
> drivers/media/platform/qcom/venus/helpers.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/media
Hi,
On Wed, Sep 23, 2020 at 08:57:02AM +0800, Icenowy Zheng wrote:
> Pine64 PineCube is an IP camera based on Allwinner S3 chip.
>
> This patchset tries to add support for it.
>
> In order to make sure the system do not hang when camera is brought up,
> a fix to AXP209 driver is needed (sent ind
Hi,
On Wed, Sep 16, 2020 at 07:59:41PM +0200, Martin Cerveny wrote:
> Add support for "allwinner,simple-framebuffer"
> with "mixer0-lcd0" pipeline from boot loader (u-boot).
> It depends on boot loader implementation of DE2/TCON0
> setup with LCD.
>
> Signed-off-by: Martin Cerveny
queued for 5.
On Fri, 2020-09-25 at 23:01 +0800, Coly Li wrote:
> In libceph, ceph_tcp_sendpage() does the following checks before handle
> the page by network layer's zero copy sendpage method,
> if (page_count(page) >= 1 && !PageSlab(page))
>
> This check is exactly what sendpage_ok() does. This patch r
On Fri, 25 Sep 2020 10:41:56 -0400 (EDT)
Mathieu Desnoyers wrote:
> With the current dependencies of tracepoint.h, I would argue that we should
> only do the trampoline work-around for cases where there is an unavoidable
> circular dependency, like the case of msr.h. For other headers which don't
On Fri, Sep 25, 2020 at 11:01:13PM +0800, Coly Li wrote:
> The original problem was from nvme-over-tcp code, who mistakenly uses
> kernel_sendpage() to send pages allocated by __get_free_pages() without
> __GFP_COMP flag. Such pages don't have refcount (page_count is 0) on
> tail pages, sending the
This is a Chinese translated version of Documentation/arm64/amu.rst
Signed-off-by: Bailu Lin
---
Changes in v3:
- Remove Documentation/arm64/amu.rst's inappropriate License claim.
Changes in v2:
- Add index to arm64 directoy.
- Fix a document format error.
- Correct email encoding format.
---
On Tue, Sep 15, 2020 at 12:32:01PM +0200, Peter Zijlstra wrote:
> The C3 BusMaster idle code takes lock in a number of places, some deep
> inside the ACPI code. Instead of wrapping it all in RCU_NONIDLE, have
> the driver take over RCU-idle duty and avoid flipping RCU state back
> and forth a lot.
From: Chao Yu
As syzbot reported:
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x21c/0x280 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:122
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:219
f2fs_lookup+0xe05/0x1a80 fs/f2fs/namei.c:503
lookup_op
clang --target= is how we can specify a particular toolchain
triple to be use, fix the two occurences in the documentation.
Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/
Clang/LLVM")
Signed-off-by: Florian Fainelli
---
Documentation/kbuild/llvm.rst | 4 ++--
1 file
On Mon 21 Sep 05:38 CDT 2020, Amit Pundir wrote:
> On Thu, 17 Sep 2020 at 21:35, Bjorn Andersson
> wrote:
> >
> > On Thu 17 Sep 02:41 CDT 2020, Amit Pundir wrote:
> >
> > > Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
> > > phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
>
On Fri, Sep 25, 2020 at 5:20 PM Guenter Roeck wrote:
>
> On Tue, Sep 15, 2020 at 12:32:01PM +0200, Peter Zijlstra wrote:
> > The C3 BusMaster idle code takes lock in a number of places, some deep
> > inside the ACPI code. Instead of wrapping it all in RCU_NONIDLE, have
> > the driver take over RCU
On Fri, Sep 25, 2020 at 06:51:37AM +0200, Christoph Hellwig wrote:
> Hi Al,
>
> this series changes import_iovec to transparently deal with compat iovec
> structures, and then cleanups up a lot of code dupliation.
OK, I can live with that. Applied, let's see if it passes smoke tests
into -next i
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: 0ddfb1cf3b6b07c97cff16ea69931d986f9622ee
Gitweb:
https://git.kernel.org/tip/0ddfb1cf3b6b07c97cff16ea69931d986f9622ee
Author:Tom Lendacky
AuthorDate:Fri, 25 Sep 2020 08:38:26 -05:00
Committer:
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
Will,
> Given that the pool is relatively small (i.e. when compared with our virtual
> address space), dedicating an area of virtual space sounds like it makes
> the most sense here. How early do you need it to be available?
How do we assign struct pages to a fixed virtual space area (I'm
current
INCSSP(Q/D) increments shadow stack pointer and 'pops and discards' the
first and the last elements in the range, effectively touches those memory
areas.
The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes and
255 * 4 = 1020 bytes by INCSSPD. Both ranges are far from PAGE_SIZE.
Thus, p
An ELF file's .note.gnu.property indicates arch features supported by the
file. These features are extracted by arch_parse_elf_property() and stored
in 'arch_elf_state'. Introduce arch_setup_elf_property() for enabling such
features. The first use-case of this function is shadow stack.
ARM64 is
On Fri, Sep 25, 2020 at 5:33 AM Jonathan Cameron wrote:
>
> On Wed, 23 Sep 2020 16:03:39 +0300
> Alexandru Ardelean wrote:
>
> > The intent here is to minimize the use of iio_buffer_set_attrs(). Since we
> > are planning to add support for multiple IIO buffers per IIO device, the
> > issue has to
Hi Kevin,
On Mon, Aug 24, 2020 at 11:16 PM Kevin Hilman wrote:
[...]
> Applied, thanks!
>
> [1/1] ARM: dts: meson8: remove two invalid interrupt lines from the GPU node
> commit: b468412409c0e5752ad3396b147cac563ff8dd3b
this one still seems to be sitting in the v5.9/fixes branch
I don't see
On Thu 24 Sep 11:31 CDT 2020, Kalle Valo wrote:
> Amit Pundir writes:
>
> > Workaround to get WiFi working on Xiaomi Poco F1 (sdm845)
> > phone. We get a non-fatal QMI_ERR_MALFORMED_MSG_V01 error
> > message in ath10k_qmi_host_cap_send_sync(), but we can still
> > bring up WiFi services successf
On Fri, Sep 25, 2020 at 08:20:00AM -0700, Guenter Roeck wrote:
> On Tue, Sep 15, 2020 at 12:32:01PM +0200, Peter Zijlstra wrote:
> > The C3 BusMaster idle code takes lock in a number of places, some deep
> > inside the ACPI code. Instead of wrapping it all in RCU_NONIDLE, have
> > the driver take o
ervisor instruction fetch in kernel mode
[8.480669][T0] #PF: error_code(0x0010) - not-present page
[8.486518][T0] PGD 0 P4D 0
[8.489757][T0] Oops: 0010 [#1] SMP KASAN PTI
[8.494476][T0] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I
5.9.0-rc6-next-20200925 #2
[
- On Sep 25, 2020, at 11:14 AM, rostedt rost...@goodmis.org wrote:
> On Fri, 25 Sep 2020 10:41:56 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> With the current dependencies of tracepoint.h, I would argue that we should
>> only do the trampoline work-around for cases where there is an unavoida
On Fri, Sep 25, 2020 at 4:08 PM Arnd Bergmann wrote:
> On Sat, Sep 19, 2020 at 10:19 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Fri, Sep 18, 2020 at 02:46:15PM +0200, Arnd Bergmann wrote:
> > > Hi Christoph, Russell,
> > >
> > > Here is an updated series for removing set_fs() from arch
On Fri, 25 Sep 2020 17:12:45 +0200
Greg Kroah-Hartman wrote:
> > Specifically, commits:
> >
> > a0d14b8909de55139b8702fe0c7e80b69763dcfb ("x86/mm, tracing: Fix CR2
> > corruption")
> > 6879298bd0673840cadd1fb36d7225485504ceb4 ("x86/entry/64: Prevent clobbering
> > of saved CR2 value")
> > b8f7
501 - 600 of 1475 matches
Mail list logo
