On 2021/02/11 1:54, Andy Shevchenko wrote:
> On Thu, Feb 11, 2021 at 01:39:41AM +0900, Tetsuo Handa wrote:
>> On 2021/02/11 1:18, Steven Rostedt wrote:
>>> The point of this exercise is to be able to debug the *same* kernel that
>>> someone is having issues with. And this is to facilitate that debu
On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote:
> On Tuesday 09 February 2021 18:07:41 nnet wrote:
> > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > > > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > > > On Tue, 09 Feb 2021 15:16:
On Tue, 9 Feb 2021 16:02:53 -0800
Ben Widawsky wrote:
> Provide enough functionality to utilize the mailbox of a memory device.
> The mailbox is used to interact with the firmware running on the memory
> device. The flow is proven with one implemented command, "identify".
> Because the class code
Hi Bjorn,
Can you ack this for merging through my topic branch with the other
follow_pfn/iomem revoke fixes for 5.12?
If not, what's the plan for getting this (or equivalent functionality)
in for 5.13? I have more of these follow_pfn/iomem revoke patches on
top, so I'd like to get the first cut m
Cc: Jens Axboe
> Cc: linux-fsde...@vger.kernel.org
> ---
> fs/io_uring.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> --- linux-next-20210210.orig/fs/io_uring.c
> +++ linux-next-20210210/fs/io_uring.c
> @@ -5145,14 +5145,12 @@ static int
On Wed, Feb 10, 2021 at 08:22:00AM -0800, Hugh Dickins wrote:
> On Tue, 9 Feb 2021, Hugh Dickins wrote:
> > On Tue, 9 Feb 2021, Johannes Weiner wrote:
> >
> > > Page writeback doesn't hold a page reference, which allows truncate to
> > > free a page the second PageWriteback is cleared. This used t
On 2021-02-10 12:25 AM, Manivannan Sadhasivam wrote:
From: Loic Poulain
mhi_deinit_chan_ctxt functionthat takes care of unitializing channel
s/functionthat/function that, uninitializing
resources, including unmapping coherent MHI areas, can be called
from different path in case of controller
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-5.11-rc8
with top-most commit fe0af09074bfeb46a35357e67635eefe33cdfc49
Revert "ACPICA: Interpreter: fix memory leak by using existing buffer"
on top of commit 92bf22614b21a2706f4993b2
Quoting Gwendal Grignou (2021-02-10 00:29:45)
> On Tue, Feb 9, 2021 at 6:51 PM Stephen Boyd wrote:
> > + if (event_type == EC_MKBP_EVENT_SWITCH) {
> > + data = container_of(nb, struct cros_ec_mkbp_proximity_data,
> > + notifier);
> > +
On Wed, Feb 10, 2021 at 12:22:35AM -0800, Kees Cook wrote:
> On Thu, Dec 17, 2020 at 04:50:41PM -0800, Joe Perches wrote:
> > On Thu, 2020-12-17 at 17:56 -0600, Bjorn Helgaas wrote:
> > > From: Bjorn Helgaas
> > >
> > > The lkml.org, marc.info, spinics.net, etc archives are not quite as useful
>
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: ca247283781d754216395a41c5e8be8ec79a5f1c
Gitweb:
https://git.kernel.org/tip/ca247283781d754216395a41c5e8be8ec79a5f1c
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:45 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 66fcd98883816dba3b66da20b5fc86fa410638b5
Gitweb:
https://git.kernel.org/tip/66fcd98883816dba3b66da20b5fc86fa410638b5
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:44 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: c46f52231e79af025e2c89e889d69ec20a4c024f
Gitweb:
https://git.kernel.org/tip/c46f52231e79af025e2c89e889d69ec20a4c024f
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:46 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 6456a2a69ee16ad402f26d272d0b67ce1d25061f
Gitweb:
https://git.kernel.org/tip/6456a2a69ee16ad402f26d272d0b67ce1d25061f
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:43 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 5042d40a264c8a508d58ed71e4c07b05175b3635
Gitweb:
https://git.kernel.org/tip/5042d40a264c8a508d58ed71e4c07b05175b3635
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:42 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: ec352711ceba890ea3a0c182c2d49c86c1a5e30e
Gitweb:
https://git.kernel.org/tip/ec352711ceba890ea3a0c182c2d49c86c1a5e30e
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:35 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 03c81ea3331658f613bb2913d33764a4e0410cbd
Gitweb:
https://git.kernel.org/tip/03c81ea3331658f613bb2913d33764a4e0410cbd
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:39 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 56e62cd28aaae2fcbec8af67b05843c47c6da170
Gitweb:
https://git.kernel.org/tip/56e62cd28aaae2fcbec8af67b05843c47c6da170
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:38 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: f42a40fd53fb5c77bae67d917d66078dbaa46bc2
Gitweb:
https://git.kernel.org/tip/f42a40fd53fb5c77bae67d917d66078dbaa46bc2
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:36 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: ef2544fb3f6457b79fc73cea39dafd67ee0f2824
Gitweb:
https://git.kernel.org/tip/ef2544fb3f6457b79fc73cea39dafd67ee0f2824
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:37 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: d24df8ecf9b6f81029f520ae7158a8670a28d70b
Gitweb:
https://git.kernel.org/tip/d24df8ecf9b6f81029f520ae7158a8670a28d70b
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:34 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 2cc624b0a7e68ba8957b18600181f7d5b0f3e1b6
Gitweb:
https://git.kernel.org/tip/2cc624b0a7e68ba8957b18600181f7d5b0f3e1b6
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:41 -08:00
Committer:
The following commit has been merged into the x86/mm branch of tip:
Commit-ID: 35f1c89b0cce247bf0213df243ed902989b1dcda
Gitweb:
https://git.kernel.org/tip/35f1c89b0cce247bf0213df243ed902989b1dcda
Author:Andy Lutomirski
AuthorDate:Tue, 09 Feb 2021 18:33:33 -08:00
Committer:
From: Colin Ian King
The assignment to dma_dev has been performed twice in one
statement. Fix this by removing the extraneous assignment.
Addresses-Coverity: ("Evaluation order violation")
Fixes: fdcd02a641e2 ("media: uvcvideo: Use dma_alloc_noncontiguos API")
Signed-off-by: Colin Ian King
---
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.11-rc8
with top-most commit d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c
cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
on top of commit 92bf22614b21a2706
On Wed, Feb 10, 2021 at 05:34:38PM +, Phillip Potter wrote:
> On Wed, Feb 10, 2021 at 06:12:54PM +0100, Greg KH wrote:
> > On Wed, Feb 10, 2021 at 05:00:03PM +, Phillip Potter wrote:
> > > Remove do/while loops from DBG_871X, MSG_8192C and DBG_8192C. Also
> > > fix opening brace placements
On Wed, Feb 10, 2021 at 09:32:09AM -0800, John Stultz wrote:
> On Wed, Feb 10, 2021 at 8:26 AM Minchan Kim wrote:
> >
> > Linux VM is not hard to support PAGE_ALLOC_COSTLY_ODER allocation
> > so normally expects driver passes __GFP_NOWARN in that case
> > if they has fallback options.
> >
> > syst
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages.[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com/
[2]
https://lore.kernel.org/lkml/2021020911093
On Wed, 2021-02-10 at 17:06 +, Julien Grall wrote:
> From: Julien Grall
>
> After Commit 3499ba8198cad ("xen: Fix event channel callback via
> INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
> recent to a guest hang during boot.
>
> If there hang wasn't there, we would
On 2/10/21 3:42 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210209:
>
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; did you mean ‘register_cpu’?
[-Werror=implicit-function-declar
On Tue, Feb 09, 2021 at 04:17:38PM -0500, Jerome Glisse wrote:
> > > Yes, I would like to avoid the long term pin constraints as well if
> > > possible I
> > > just haven't found a solution yet. Are you suggesting it might be
> > > possible to
> > > add a callback in the page migration logic to
On Wed, Feb 10, 2021 at 06:26:54PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 09, 2021 at 05:58:59PM -0500, Paul Gortmaker wrote:
> > The basic objective here was to add support for "nohz_full=8-N" and/or
> > "rcu_nocbs="4-N" -- essentially introduce "N" as a portable reference
> > to the last cor
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
---
.../admin-guide/kernel-parameters.txt | 6 +
Documentation/x86/index.rst | 1 +
Doc
After the introduction of _PAGE_COW, a modified page's PTE can have either
_PAGE_DIRTY 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: Zhenyu
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the existing bits.
They chose to repurpose a lightly-used state: Write=0, Dirty=1.
The reason it's lightly
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
pte_
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This re
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].
CET can protect applications and the kernel. This series enables only
application-level protect
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> This direction sounds at least...possible. Using MMU notifiers instead of pins
> is definitely appealing. I'm not quite clear on the callback idea above, but
> overall it seems like taking advantage of the ZONE_DEVICE tracking of page
On 2/10/21 9:23 AM, Rob Herring wrote:
On Tue, Feb 09, 2021 at 10:21:52AM -0800, Lakshmi Ramasubramanian wrote:
From: Rob Herring
Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec. The differences are either omissions that arm64 should have
or additional properties th
On 2021-02-08, Sergey Senozhatsky wrote:
>> Can we please also ask the kernel test robot to test this patch?
Oliver Sang from LKP was able to verify that the RCU stall problem is
not seen anymore on their side. See his response below.
Thanks Oliver!
John Ogness
On 2021-02-10, Oliver Sang wrot
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-Shadow Stac
A shadow stack PTE must be read-only and have _PAGE_DIRTY set. However,
read-only and Dirty PTEs also exist for copy-on-write (COW) pages. These
two cases are handled differently for page faults. Introduce VM_SHSTK to
track shadow stack VMAs.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
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.
Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow
Stack or Indirect Branch Tracking (or both) is present. Also introduce
related cpu init/setup functions.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 +-
arch/x
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can s
Add CPU feature flags for Control-flow Enforcement Technology (CET).
CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cpufeatures.h | 2 ++
arch/x86/include/asm
On Tue, Feb 09, 2021 at 03:11:41PM +0100, Andrew Lunn wrote:
> > Regarding splitting the series up. I don't see a problem in just
> > sending the cover-letter patch and actual GPIO-related patches to
> > the GPIO-maintainers with no need to have them added to Cc in the rest
> > of the series.
>
>
On Wed, Feb 10, 2021 at 12:25:31PM -0500, Mathieu Desnoyers wrote:
- On Feb 10, 2021, at 12:09 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Feb 10, 2021 at 11:04:19AM -0500, Mathieu Desnoyers wrote:
Hi,
While reconciling the lttng-modules writeback instrumentation wit
On 2/10/21 9:20 AM, Rob Herring wrote:
On Tue, Feb 09, 2021 at 10:21:55AM -0800, Lakshmi Ramasubramanian wrote:
The fields ima_buffer_addr and ima_buffer_size in "struct kimage_arch"
for powerpc are used to carry forward the IMA measurement list across
kexec system call. These fields are not ar
Control-flow Enforcement Technology (CET) introduces these MSRs:
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 Level 1 shadow stack pointer),
MSR_IA32
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but
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
Reviewed-by: Kees Cook
---
arch/x86/kernel/cet_prctl.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/cet_prctl.c b/ar
Introduce user-mode Indirect Branch Tracking (IBT) support. Add routines
for the setup/disable of IBT.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 3 +++
arch/x86/kernel/cet.c | 33 +
2 files changed, 36 insertions(+)
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
On Wednesday 10 February 2021 09:34:07 nnet wrote:
> On Wed, Feb 10, 2021, at 1:23 AM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 18:07:41 nnet wrote:
> > > On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> > > > On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > > > > On Tue, Feb 9, 2021, at 3:2
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix, ar
On Tue, Feb 09, 2021 at 10:22:47PM +, Song Bao Hua (Barry Song) wrote:
> The problem is that SVA declares we can use any memory of a process
> to do I/O. And in real scenarios, we are unable to customize most
> applications to make them use the pool. So we are looking for some
> extension gene
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
When serving a page fault, maybe_mkwrite() makes a PTE writable if its vma
has VM_WRITE.
A shadow stack vma has VM_SHSTK. Its PTEs have _PAGE_DIRTY, but not
_PAGE_WRITE. In fork(), _PAGE_DIRTY is cleared to effect copy-on-write,
and in page fault, _PAGE_DIRTY is restored and the shadow stack pag
> > > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > > index c4ba3aa0a05d..08eaa8e52083 100644
> > > --- a/drivers/cxl/Kconfig
> > > +++ b/drivers/cxl/Kconfig
> > > @@ -33,6 +33,24 @@ config CXL_MEM
> > >
> > > If unsure say 'm'.
> > >
> > > +config CXL_MEM_RAW_COMMANDS
> > >
Introduce basic shadow stack enabling/disabling/allocation 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
Reviewed-by: Kees Cook
---
arch/x86/include/asm/cet.h | 28 ++
arch/x86/in
Indirect branch tracking is a hardware security feature that verifies near
indirect call/jump instructions arrive at intended targets, which are
labeled by the compiler with ENDBR opcodes. If such instructions reach
unlabeled locations, the processor raises control-protection faults.
Check the co
When an indirect CALL/JMP instruction is executed and before it reaches
the target, it is in 'WAIT_ENDBR' status, which can be read from
MSR_IA32_U_CET. The status is part of a task's status before a signal is
raised and preserved in the signal frame. It is restored for sigreturn.
IBT state mach
Le mardi 09 février 2021 à 21:10 -0600, Jeff LaBundy a écrit :
> Hi Vincent,
>
> On Tue, Feb 09, 2021 at 07:58:33PM +0100, Vincent Knecht wrote:
> > Le mardi 09 février 2021 à 10:13 -0600, Rob Herring a écrit :
> > > On Thu, Jan 21, 2021 at 06:43:47PM +0100, Vincent Knecht wrote:
> > > > This adds
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
testing/scsi/aacraid
branch HEAD: b3519d554ac927b6d1dd3a65831b5e464a5a1347 scsi: aacraid: Replace
one-element array with flexible-array member
elapsed time: 1286m
configs tested: 92
configs skipped: 2
The follo
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-
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function
do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce vm_fla
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/
On Mon, Feb 8, 2021 at 3:54 PM Peter Xu wrote:
>
> On Thu, Feb 04, 2021 at 10:34:31AM -0800, Axel Rasmussen wrote:
> > +enum mcopy_atomic_mode {
> > + /* A normal copy_from_user into the destination range. */
> > + MCOPY_ATOMIC_NORMAL,
> > + /* Don't copy; map the destination range to
An ELF file's .note.gnu.property indicates features the file supports.
The property is parsed at loading time and passed to arch_setup_elf_
property(). Update it for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
---
arch/x86/kernel/process_64.c | 8
1 fil
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
Reviewed-by: Kees Cook
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/sys
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 x86 feature definitions and arch_setup_elf_property(), which
enables such features. The first use-case of this funct
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
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
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT status
*(args + 1) = shadow stack base address
*(args + 2) = shadow stack size
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack.
The token is distin
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters. Mu
>
> Currently, exception event status can be read from wExceptionEventStatus
> attribute (sysfs file attributes/exception_event_status under the UFS host
> controller device directory). Polling that attribute to track UFS exception
> events is impractical, so add a tracepoint to track exception ev
> -Original Message-
> From: Dan Williams
> Sent: Tuesday, February 9, 2021 11:30 AM
> To: Greg KH
> Cc: Chen, Mike Ximing ; Linux Kernel Mailing List
> ; Arnd Bergmann ; Pierre-Louis
> Bossart ; Gage Eads
>
> Subject: Re: [PATCH v10 01/20] dlb: add skeleton for DLB driver
>
> On Tue
On 21-02-10 18:03:35, ariel.sib...@microchip.com wrote:
> > > > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > > > index c4ba3aa0a05d..08eaa8e52083 100644
> > > > --- a/drivers/cxl/Kconfig
> > > > +++ b/drivers/cxl/Kconfig
> > > > @@ -33,6 +33,24 @@ config CXL_MEM
> > > >
> > > >
Bonjour Nicolas,
On Wed, Feb 10, 2021 at 11:11 AM Nicolas Dufresne wrote:
>
> Are you sure you aren't just running out of CMA ? This is the only things that
> comes to mind at the moment, sorry if it's not that useful.
Thanks for the suggestion! No worries, this is such a strange/weird
problem,
On 21-02-10 08:55:57, Ben Widawsky wrote:
> On 21-02-10 15:07:59, Jonathan Cameron wrote:
> > On Wed, 10 Feb 2021 13:32:52 +
> > Jonathan Cameron wrote:
> >
> > > On Tue, 9 Feb 2021 16:02:53 -0800
> > > Ben Widawsky wrote:
> > >
> > > > Provide enough functionality to utilize the mailbox of
On 2/9/21 9:43 PM, Roman Gushchin wrote:
> On Tue, Feb 09, 2021 at 09:46:38AM -0800, Yang Shi wrote:
>> Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but actually
>> the
>> map size can be calculated via shrinker_nr_max, so it seems unnecessary to
>> keep both.
>> Remove memcg_s
On 1/29/21 7:25 PM, Tetsuo Handa wrote:
On 2021/01/30 6:18, Shuah Khan wrote:
In this console log:
It seems "this console log" refers to
https://syzkaller.appspot.com/x/log.txt?x=1045303450 .
06:57:50 executing program 1:
socketpair$tipc(0x1e, 0x2, 0x0, &(0x7fc0)={0xfff
On Sat, Dec 5, 2020 at 9:56 AM Serge Semin
wrote:
>
> In accordance with the USB HCD/DRD schema all the USB controllers are
> supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
> existing DT-nodes will be renamed in a subsequent patch let's first make
> sure the DWC3 Qualcomm dri
On 2/9/21 6:46 PM, Yang Shi wrote:
> The shrinker_info is dereferenced in a couple of places via
> rcu_dereference_protected
> with different calling conventions, for example, using mem_cgroup_nodeinfo
> helper
> or dereferencing memcg->nodeinfo[nid]->shrinker_info. And the later patch
> will ad
On Wed, Feb 10, 2021 at 11:29 AM Serge Semin
wrote:
>
> In accordance with the USB HCD/DRD schema all the USB controllers are
> supposed to have DT-nodes named with prefix "^usb(@.*)?". Since the
> existing DT-nodes will be renamed in a subsequent patch let's first make
> sure the DWC3 Qualcomm d
On Tue, 9 Feb 2021 16:02:54 -0800
Ben Widawsky wrote:
> From: Dan Williams
>
> Create the /sys/bus/cxl hierarchy to enumerate:
>
> * Memory Devices (per-endpoint control devices)
>
> * Memory Address Space Devices (platform address ranges with
> interleaving, performance, and persistence at
On 1/26/21 2:13 AM, Shiyang Ruan wrote:
> The return value of range_parse() indicates the size when it is
> positive. The error code should be negative.
>
> Signed-off-by: Shiyang Ruan
Reviewed-by: Joao Martins
Although, FWIW, there was another patch exactly like this a couple
months ago, alb
On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> drivers/of/property.o: In function `parse_interrupts':
> property.c:(.text+0x14e0): undefined reference to `of_i
Thanks Rob for your review comments.
diff --git a/include/dt-bindings/clock/qcom,gcc-sc7280.h
b/include/dt-bindings/clock/qcom,gcc-sc7280.h
new file mode 100644
index 000..3295bd4
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-sc7280.h
@@ -0,0 +1,215 @@
+/* SPDX-License-Identifier:
On 2/10/21 9:28 AM, Serge Semin wrote:
> As the subject states this series is an attempt to harmonize the xHCI,
> EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> framework of the patchset [1].
>
> Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> contr
On Wed, Feb 10, 2021 at 05:38:21PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
>
> ./drivers/infiniband/hw/qedr/qedr.h:629:9-10: WARNING: return of 0/1 in
> function 'qedr_qp_has_rq' with return type bool.
>
> ./drivers/infiniband/hw/qedr/qedr.h:620:9-10: WARNING: return o
Thanks Stephen for your review comments.
On 1/13/2021 1:36 AM, Stephen Boyd wrote:
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: bi_tcxo_ao
+ - const: sleep_clk
+ - const: pcie_0_pipe_clk
+ - const: pcie_1_pipe_clk
+ - const: usb3_phy_wrapper_gcc_usb30_
Hi Drew,
url:
https://github.com/0day-ci/linux/commits/Drew-Fustini/pinctrl-pinmux-Add-pinmux-select-debugfs-file/20210210-160108
base:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: i386-randconfig-m021-20210209 (attached as .config)
compiler: gcc-9
All userspace ioctls major/magic number should be documented in
Documentation/userspace-api/ioctl/ioctl-number.rst, so add
the entry for .
Signed-off-by: Randy Dunlap
Cc: Andrey Vagin
Cc: Serge Hallyn
Cc: Eric W. Biederman
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet
---
Feel free to mod
On 11/13/20 5:08 PM, Yonghong Song wrote:
>
>
> On 11/12/20 9:37 PM, Matt Mullins wrote:
>> On Wed, Nov 11, 2020 at 03:57:50PM +0100, Dmitry Vyukov wrote:
>>> On Mon, Nov 2, 2020 at 12:54 PM syzbot
>>> wrote:
Hello,
syzbot found the following issue on:
HEAD commi
On 2/9/21 6:46 PM, Yang Shi wrote:
> Currently registered shrinker is indicated by non-NULL shrinker->nr_deferred.
> This approach is fine with nr_deferred at the shrinker level, but the
> following
> patches will move MEMCG_AWARE shrinkers' nr_deferred to memcg level, so their
> shrinker->nr_defe
On Wed, Feb 10, 2021 at 08:15:27PM +0800, Stephen Zhang wrote:
> Nathan Chancellor 于2021年2月10日周三 上午3:27写道：
>
> > Just as an FYI, your email was HTML, which means it won't hit LKML.
>
>
> Thanks for pointing that out. The existence of a GFW makes it difficult for
> me to connect
> to the mail se
901 - 1000 of 1651 matches
Mail list logo
