On Wed, May 15, 2024 at 11:05 PM Michael S. Tsirkin wrote:
>
> There are two issues around seqpacket_allow:
> 1. seqpacket_allow is not initialized when socket is
>created. Thus if features are never set, it will be
>read uninitialized.
> 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then
On Thu, May 16, 2024 at 1:50 AM Kris Van Hees wrote:
>
> On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> > On Sun, May 12, 2024 at 7:42???AM Kris Van Hees
> > wrote:
> > >
> > > Especially for tracing applications, it is convenient to be able to
> > > refer to a symbol using
The pull request you sent on Tue, 14 May 2024 01:22:35 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/
> tags/modules-6.10-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a49468240e89628236b738b5ab9416eae8f90c15
Thank you!
--
The pull request you sent on Wed, 15 May 2024 09:41:46 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> tags/libnvdimm-for-6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c405aa3ea36c1f973a9f10bbcfabc9aeeb38040c
Thank you!
--
On Wed, 15 May 2024 16:55:59 -0500, Haitao Huang
wrote:
On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
wrote:
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{
rt_task() checks if a task has RT priority. But depends on your
dictionary, this could mean it belongs to RT class, or is a 'realtime'
task, which includes RT and DL classes.
Since this has caused some confusion already on discussion [1], it
seemed a clean up is due.
I define the usage of
On Wed, 15 May 2024 08:12:39 -0500, Dmitrii Kuvaiskii
wrote:
Two enclave threads may try to access the same non-present enclave page
simultaneously (e.g., if the SGX runtime supports lazy allocation). The
threads will end up in sgx_encl_eaug_page(), racing to acquire the
enclave lock. The
On Wed, 15 May 2024 08:12:40 -0500, Dmitrii Kuvaiskii
wrote:
Two enclave threads may try to add and remove the same enclave page
simultaneously (e.g., if the SGX runtime supports both lazy allocation
and MADV_DONTNEED semantics). Consider some enclave page added to the
enclave. User space
On Wed, 15 May 2024 01:55:21 -0500, Bojun Zhu
wrote:
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
to give
On Wed, May 15, 2024 at 02:30:37PM -0700, Alexei Starovoitov wrote:
> On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
> wrote:
> >
> > Hello.
> > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> > Recently, our team has discovered a issue in Linux kernel 6.7.
On Tue, May 14, 2024 at 12:33 AM Ubisectech Sirius
wrote:
>
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
Jiri,
please take a look.
>
The pull request you sent on Wed, 15 May 2024 14:24:41 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
> tags/livepatching-for-6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c06da67d0bd3139a97f301b4aa9c482b9d4f29e
Thank you!
On 5/13/24 3:46 PM, Thomas Gleixner wrote:
> On Mon, May 13 2024 at 10:43, Dongli Zhang wrote:
>> On 5/13/24 5:44 AM, Thomas Gleixner wrote:
>>> On Fri, May 10 2024 at 12:06, Dongli Zhang wrote:
>>> Any interrupt which is affine to an outgoing CPU is migrated and
>>> eventually pending moves
On 05/15/24 08:50, Phil Auld wrote:
> > > My point was just to call it rt_task() still.
> >
> > It is called rt_task() still. I just added a new realtime_task() to return
> > true
> > for RT and DL. rt_task() will return true only for RT now.
> >
> > How do you see this should be done
On Mon, May 13, 2024 at 01:43:15PM +0900, Masahiro Yamada wrote:
> On Sun, May 12, 2024 at 7:42???AM Kris Van Hees
> wrote:
> >
> > Especially for tracing applications, it is convenient to be able to
> > refer to a symbol using a pair and to be able
> > to translate an address into a pair.
Hi Linus, Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
tags/libnvdimm-for-6.10
... to get code updates for the nvdimm tree. These have been in
linux-next for a couple of weeks. The changes include removing duplicate
code and updating the nvdimm tree to
> Thank you very much. I understand the changelog is still being discussed
> and those changes look good to me, to which you can add:
>
> Reviewed-by: Reinette Chatre
also for this (with changelog tweak Dave suggested) so that we don't
need a new round:
Reviewed-by: Jarkko Sakkinen
BR, Jarkko
Hi Honggyu,
On Mon, 13 May 2024 20:59:15 +0900 Honggyu Kim wrote:
> Hi SeongJae,
>
> Thanks very much for your work! It got delayed due to the priority
> changes in my workplace for building another heterogeneous memory
> allocator.
> https://github.com/skhynix/hmsdk/wiki/hmalloc
No problem
Hi Dmitrii,
On 5/15/2024 6:12 AM, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to access the same non-present enclave page
> simultaneously (e.g., if the SGX runtime supports lazy allocation). The
> threads will end up in sgx_encl_eaug_page(), racing to acquire the
> enclave lock. The
Hi Dmitrii,
On 5/15/2024 6:12 AM, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to add and remove the same enclave page
> simultaneously (e.g., if the SGX runtime supports both lazy allocation
> and MADV_DONTNEED semantics). Consider some enclave page added to the
> enclave. User space
On 05/15, Edgecombe, Rick P wrote:
>
> On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> >
> > > I'm ok with not using optimized uretprobe when shadow stack is detected
> > > as enabled and we go with current uretprobe in that case
> >
> > But how can we detect it? Again, suppose userspace
On Wed, 2024-05-15 at 17:26 +0200, Oleg Nesterov wrote:
> > I think it will crash, there's explanation in the comment in
> > tools/testing/selftests/x86/test_shadow_stack.c test
>
> OK, thanks...
>
> But test_shadow_stack.c doesn't do ARCH_PRCTL(ARCH_SHSTK_DISABLE) if
> all the tests succeed ?
On 05/15, Jiri Olsa wrote:
>
> On Wed, May 15, 2024 at 01:19:20PM +0200, Oleg Nesterov wrote:
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,
> >
> > enable_shstk()
> > {
> > prctl(ARCH_SHSTK_SHSTK);
On Wed, 2024-05-15 at 08:36 -0600, Jiri Olsa wrote:
> >
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,
The shadow stack could overflow if it is not big enough. However since the
normal stack has return addresses and
On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> Let me repeat I know nothing about shadow stacks, only tried to
> read Documentation/arch/x86/shstk.rst few minutes ago ;)
>
> On 05/13, Jiri Olsa wrote:
> >
> > 1) current uretprobe which are not working at the moment and we change
> >
Hi Rob,
Any feedback on the below topic?
Regards
Luca
On Donnerstag, 25. April 2024 20:54:40 MESZ Luca Weiss wrote:
> On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> > On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > > The qcom,ipc-N properties are essentially
On Wed, May 15, 2024 at 04:50:48PM +0200, Dan Carpenter wrote:
> On Sun, May 12, 2024 at 12:01:55PM -0400, Michael S. Tsirkin wrote:
> > On Fri, May 10, 2024 at 03:50:45PM +0300, Dan Carpenter wrote:
> > > The virtnet_send_command_reply() function returns true on success or
> > > false on failure.
There are two issues around seqpacket_allow:
1. seqpacket_allow is not initialized when socket is
created. Thus if features are never set, it will be
read uninitialized.
2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared,
then seqpacket_allow will not be cleared appropriately
On Sun, May 12, 2024 at 12:01:55PM -0400, Michael S. Tsirkin wrote:
> On Fri, May 10, 2024 at 03:50:45PM +0300, Dan Carpenter wrote:
> > The virtnet_send_command_reply() function returns true on success or
> > false on failure. The "ok" variable is true/false depending on whether
> > it succeeds
On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> Two enclave threads may try to add and remove the same enclave page
> simultaneously (e.g., if the SGX runtime supports both lazy allocation
> and MADV_DONTNEED semantics). Consider some enclave page added to the
> enclave. User space
On Wed, May 15, 2024 at 01:19:20PM +0200, Oleg Nesterov wrote:
> Sorry for the late reply, I was on PTO.
>
> On 05/14, Deepak Gupta wrote:
> >
> > Question,
> >
> > Is it kernel who is maintaining all return probes, meaning original return
> > addresses
> > are saved in kernel data structures on
On Wed, May 15, 2024 at 3:30 AM Peter Zijlstra wrote:
>
> On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
>
> > +static void fixup_uretprobe_trampoline_entries(struct perf_callchain_entry
> > *entry,
> > +int start_entry_idx)
> > +{
>
On Wed May 15, 2024 at 5:15 PM EEST, Dave Hansen wrote:
> On 5/15/24 06:54, Jarkko Sakkinen wrote:
> > I'd cut out 90% of the description out and just make the argument of
> > the wrong error code, and done. The sequence is great for showing
> > how this could happen. The prose makes my head hurt
On 5/15/24 06:54, Jarkko Sakkinen wrote:
> I'd cut out 90% of the description out and just make the argument of
> the wrong error code, and done. The sequence is great for showing
> how this could happen. The prose makes my head hurt tbh.
The changelog is too long, but not fatally so. I'd much
On Wed May 15, 2024 at 4:54 PM EEST, Jarkko Sakkinen wrote:
> On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> > diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> > index 279148e72459..41f14b1a3025 100644
> > --- a/arch/x86/kernel/cpu/sgx/encl.c
> > +++
On Wed May 15, 2024 at 4:12 PM EEST, Dmitrii Kuvaiskii wrote:
> diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
> index 279148e72459..41f14b1a3025 100644
> --- a/arch/x86/kernel/cpu/sgx/encl.c
> +++ b/arch/x86/kernel/cpu/sgx/encl.c
> @@ -382,8 +382,11 @@ static
Two enclave threads may try to access the same non-present enclave page
simultaneously (e.g., if the SGX runtime supports lazy allocation). The
threads will end up in sgx_encl_eaug_page(), racing to acquire the
enclave lock. The winning thread will perform EAUG, set up the page
table entry, and
SGX runtimes such as Gramine may implement EDMM-based lazy allocation of
enclave pages and may support MADV_DONTNEED semantics [1]. The former
implies #PF-based page allocation, and the latter implies the usage of
SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl.
EDMM-based lazy allocation and MADV_DONTNEED
Two enclave threads may try to add and remove the same enclave page
simultaneously (e.g., if the SGX runtime supports both lazy allocation
and MADV_DONTNEED semantics). Consider some enclave page added to the
enclave. User space decides to temporarily remove this page (e.g.,
emulating the
Currently the page_frag API is returning 'virtual address'
or 'va' when allocing and expecting 'virtual address' or
'va' as input when freeing.
As we are about to support new use cases that the caller
need to deal with 'struct page' or need to deal with both
'va' and 'struct page'. In order to
Use appropriate frag_page API instead of caller accessing
'page_frag_cache' directly.
CC: Alexander Duyck
Signed-off-by: Yunsheng Lin
---
drivers/vhost/net.c | 2 +-
include/linux/page_frag_cache.h | 10 ++
mm/page_frag_test.c | 2 +-
net/core/skbuff.c
On Wed, May 15, 2024 at 01:06:13PM +0100 Qais Yousef wrote:
> On 05/15/24 07:20, Phil Auld wrote:
> > On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> > > On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> > > >
> > > > Hi Qais,
> > > >
> > > > On Wed, May 15, 2024 at
Hi Linus,
please pull the latest changes for the kernel livepatching from
git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching
tags/livepatching-for-6.10
==
- Use more informative names for the livepatch transition states.
On Wed May 15, 2024 at 9:55 AM EEST, Bojun Zhu wrote:
> EDMM's ioctl()s support batch operations, which may be
> time-consuming. Try to explicitly give up the CPU as the prefix
> operation at the every begin of "for loop" in
> sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
> to
On 05/15/24 07:20, Phil Auld wrote:
> On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> > On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> > >
> > > Hi Qais,
> > >
> > > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > > rt_task() checks if a task has
Let me repeat I know nothing about shadow stacks, only tried to
read Documentation/arch/x86/shstk.rst few minutes ago ;)
On 05/13, Jiri Olsa wrote:
>
> 1) current uretprobe which are not working at the moment and we change
>the top value of shadow stack with shstk_push_frame
> 2) optimized
Sorry for the late reply, I was on PTO.
On 05/14, Deepak Gupta wrote:
>
> Question,
>
> Is it kernel who is maintaining all return probes, meaning original return
> addresses
> are saved in kernel data structures on per task basis.
Yes. task_struct->utask->return_instances
See
On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> >
> > Hi Qais,
> >
> > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > rt_task() checks if a task has RT priority. But depends on your
> > > dictionary,
On 05/15/24 10:32, Peter Zijlstra wrote:
> On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> >
> > Hi Qais,
> >
> > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > rt_task() checks if a task has RT priority. But depends on your
> > > dictionary, this could mean it
On Wed, May 08, 2024 at 02:26:03PM -0700, Andrii Nakryiko wrote:
> +static void fixup_uretprobe_trampoline_entries(struct perf_callchain_entry
> *entry,
> +int start_entry_idx)
> +{
> +#ifdef CONFIG_UPROBES
> + struct uprobe_task *utask =
On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
>
> Hi Qais,
>
> On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > rt_task() checks if a task has RT priority. But depends on your
> > dictionary, this could mean it belongs to RT class, or is a 'realtime'
> > task, which
Hi folks,
This is the third version of the patch to fix the softlockup in EDMM
iotcl()[1][2].
If we run an enclave equipped with large EPC(30G or greater on my platfrom)
on the Linux with kernel preemptions disabled(by configuring
"CONFIG_PREEMPT_NONE=y"), we will get the following softlockup
EDMM's ioctl()s support batch operations, which may be
time-consuming. Try to explicitly give up the CPU as the prefix
operation at the every begin of "for loop" in
sgx_enclave_{ modify_types | restrict_permissions | remove_pages}
to give other tasks a chance to run, and avoid softlockup warning.
Björn Töpel writes:
> From: Björn Töpel
>
> ZONE_DEVICE pages need DEVMAP PTEs support to function
> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
> in the PTE for DEVMAP mark, add the corresponding helpers, and enable
> ARCH_HAS_PTE_DEVMAP for riscv64.
...and this patch
54 matches
Mail list logo
