>
> On Mon, May 19, 2025 at 10:24:31AM +0300, Elena Reshetova wrote:
> > SGX enclaves have an attestation mechanism. An enclave might,
> > for instance, need to attest to its state before it is given
> > a special decryption key. Since SGX must trust the CPU microcode,
> > attestation incorporat
> > Yes, meaning is different, see above.
>
> So that's rather convoluted:
>
> atomic64_inc_not_zero(): returns 1 on successful increase, 0 on
> failure
> sgx_inc_usage_count(): returns 0 on successful increase, 1 on
> failure
> sgx_open():returns 0 on
> >
> > > Why not just fail sgx_open() (e.g., return -EBUSY, or -EAGAIN) in that
> > > case?
> > > Userspace can then retry?
> >
> > The idea on the patch was that such a scenario where we run out of entropy
> > should not happen in real life unless RDSEED is under stress (in case we
> > accident
> +/**
> > + * sgx_updatesvn() - Attempt to call ENCLS[EUPDATESVN]
> > + * If EPC is empty, this instruction attempts to update CPUSVN to the
> > + * currently loaded microcode update SVN and generate new
> > + * cryptographic assets.sgx_updatesvn() Most of the time, there will
>
> Is there somet
> Maybe just use raw atomic_inc() and atomic_dec() at the sites?
>
> IMHO, it makes only sense to wrap, when it makes sense to wrap.
You mean for this patch or overall? For overall we discussed in v4
why we would like to raise it to atomic64.
Or do I misunderstand your comment?
Best Regards,
Ele
> > > > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> > > b/arch/x86/kernel/cpu/sgx/driver.c
> > > > index 7f8d1e11dbee..b5ffe104af4c 100644
> > > > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > > > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > > > @@ -19,6 +19,7 @@ static int sgx_open(struct inode *in
Hi Mathieu,
On 19/05/25 20:07, Mathieu Poirier wrote:
> On Sat, May 17, 2025 at 06:53:29PM +0530, Beleswar Prasad Padhi wrote:
>> On 5/16/2025 9:15 PM, Mathieu Poirier wrote:
>>> On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
The rproc_detach() function invokes __rproc_detach
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Fri, 16 May 2025 15:51:48 -0700 you wrote:
> Fix misspelling reported by codespell
>
> Signed-off-by: Sumanth Gavini
> ---
> tools/testing/selftests/drivers/net/lib/py/env.py | 2 +-
> 1 file changed, 1 insertio
On Mon, May 19, 2025 at 07:14:40PM -0700, Drew Fustini wrote:
> Convert the PMEM device tree binding from text to YAML. This will allow
> device trees with pmem-region nodes to pass dtbs_check.
>
> Signed-off-by: Drew Fustini
> ---
> v2: remove the txt file to make the conversion complete
Krzysz
Convert the PMEM device tree binding from text to YAML. This will allow
device trees with pmem-region nodes to pass dtbs_check.
Signed-off-by: Drew Fustini
---
v2: remove the txt file to make the conversion complete
.../devicetree/bindings/pmem/pmem-region.txt | 65 ---
.../dev
On Sat, 17 May 2025 19:27:49 +0200, Konrad Dybcio wrote:
> SC8280XP features a SLPI, much like its distant relative, SM8350.
>
> This series adds the bindings and dt node for it (also cleaning up the
> DTSI in meantime)
>
>
Applied, thanks!
[2/5] arm64: dts: qcom: sc8280xp: Fix node order
This patchset adds KVM selftests for LoongArch system, currently only
some common test cases are supported and pass to run. These test cases
are listed as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_tes
Add KVM selftests header files for LoongArch, including processor.h
and kvm_util_arch.h. It mainly contains LoongArch CSR register and page
table entry definition.
Signed-off-by: Bibo Mao
Signed-off-by: Huacai Chen
---
.../testing/selftests/kvm/include/kvm_util.h | 5 +
.../kvm/include/loong
Add ucall test support for LoongArch, ucall method on LoongArch uses
undefined mmio area. It will cause vCPU exiting to hypervisor so that
hypervisor can communicate with vCPU.
Signed-off-by: Bibo Mao
Signed-off-by: Huacai Chen
---
.../selftests/kvm/include/loongarch/ucall.h | 20 ++
Some common KVM test cases are supported on LoongArch now as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_test
kvm_binary_stats_test
kvm_create_max_vcpus
kvm_page_table_test
memslot_modification_stress_test
On LoongArch system, 16K page is used in general and GVA width is 47 bit
while GPA width is 47 bit also, here add new VM mode VM_MODE_P47V47_16K.
Signed-off-by: Bibo Mao
Signed-off-by: Huacai Chen
---
tools/testing/selftests/kvm/include/kvm_util.h | 1 +
tools/testing/selftests/kvm/lib/kvm_util
Add core KVM selftests support for LoongArch, it includes exception
handler, mmu page table setup and vCPU startup entry support.
Signed-off-by: Bibo Mao
Signed-off-by: Huacai Chen
---
.../selftests/kvm/lib/loongarch/exception.S | 59 +++
.../selftests/kvm/lib/loongarch/processor.c | 347 +
On Mon, 19 May 2025 02:35:13 + Mina Almasry wrote:
> +addr = cfg.addr_v[ipver]
> +if ipver == "6":
> +addr = "[" + addr + "]"
You want baddr ?
https://web.git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/tools/testing/selftests/drivers/net/lib/py/env.py#n155
I
On Mon, 19 May 2025 13:18:24 -0700 Stanislav Fomichev wrote:
> On 05/19, Mina Almasry wrote:
> > On Mon, May 19, 2025 at 8:25 AM Stanislav Fomichev
> > wrote:
> > >
> > > On 05/19, Mina Almasry wrote:
> > > > As far as I can tell the ksft_disruptive here is unnecessary. These
> > > > tests ar
> >
> > > +
> > > + for (int i = 0; i < RDRAND_RETRY_LOOPS; i++) {
> > > + ret = __eupdatesvn();
> > > +
> > > + /* Stop on success or unexpected errors: */
> > > + if (ret != SGX_INSUFFICIENT_ENTROPY)
> > > + break;
> > > + }
> > > +
> > > + /*
> > > + * S
On Mon, 2025-05-19 at 11:47 +, Reshetova, Elena wrote:
> > On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > > Currently SGX does not have a global counter to count the
> > > active users from userspace or hypervisor. Implement such a counter,
> > > sgx_usage_count. It will be used
On Mon, 19 May 2025 19:20:31 +0530 Ujwal Kundur wrote:
> I'm not sure about the protocol here, should I roll a PATCH v4 or a
> new patch entirely?
Those two are the same thing.
I dropped the v3 patch, my inbox eagerly awaits v4, thanks.
Hi Jonathan,
Em 19/05/2025 17:30, Jonathan Velez escreveu:
On May 15, 2025, at 1:45 PM, Jonathan Velez wrote:
futex_wait_timeout: Fix usage() message to clarify timeout value unit
Signed-off-by: Jonathan Velez
---
tools/testing/selftests/futex/functional/futex_wait_timeout.c | 2 +-
1 file
Hi Linus,
When the merge window opens, please pull the RCU changes for v6.16:
The following changes since commit 0af2f6be1b4281385b618cb86ad946eded089ac8:
Linux 6.15-rc1 (2025-04-06 13:11:33 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rcu/li
> On May 15, 2025, at 1:45 PM, Jonathan Velez wrote:
>
> futex_wait_timeout: Fix usage() message to clarify timeout value unit
>
> Signed-off-by: Jonathan Velez
> ---
> tools/testing/selftests/futex/functional/futex_wait_timeout.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On 05/19, Mina Almasry wrote:
> On Mon, May 19, 2025 at 8:37 AM Stanislav Fomichev
> wrote:
> >
> > On 05/19, Mina Almasry wrote:
> > > ncdevmem supports drivers that are limited to either 3-tuple or 5-tuple
> > > FS support, but the ksft is currently 3-tuple only. Support drivers that
> > > have
On 05/19, Mina Almasry wrote:
> On Mon, May 19, 2025 at 8:32 AM Stanislav Fomichev
> wrote:
> >
> > On 05/19, Mina Almasry wrote:
> > > ncdevmem supports both ipv4 and ipv6, but the ksft is currently
> > > ipv6-only. Propagate the ipv4 support to the ksft, so that folks that
> > > are limited to
On 05/19, Mina Almasry wrote:
> On Mon, May 19, 2025 at 8:25 AM Stanislav Fomichev
> wrote:
> >
> > On 05/19, Mina Almasry wrote:
> > > As far as I can tell the ksft_disruptive here is unnecessary. These
> > > tests are largerly independent, and when one test fails, it's nice to
> > > know the re
Hello,
We extended the CFP until tomorrow May 20, 2025, at 11:59 PM (MDT). If you
didn't submit your session, it is the last chance now.
Best,
- Gus
--
Gustavo Padovan
Collabora Ltd.
On Tue, 13 May 2025 13:54:25 -0300 Gustavo Padovan
wrote ---
> Hello,
>
> It is the last week
Hello Sean/Paolo,
On 5/12/2025 11:46 PM, Gupta, Pankaj wrote:
> On 5/13/2025 12:16 AM, Ashish Kalra wrote:
>> From: Ashish Kalra
>>
>> During platform init, SNP initialization may fail for several reasons,
>> such as firmware command failures and incompatible versions. However,
>> the KVM capabil
On Mon, May 19, 2025 at 10:24:31AM +0300, Elena Reshetova wrote:
> SGX enclaves have an attestation mechanism. An enclave might,
> for instance, need to attest to its state before it is given
> a special decryption key. Since SGX must trust the CPU microcode,
> attestation incorporates the microc
On Mon, May 19, 2025 at 10:24:30AM +0300, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> comp
On Mon, May 19, 2025 at 8:37 AM Stanislav Fomichev wrote:
>
> On 05/19, Mina Almasry wrote:
> > ncdevmem supports drivers that are limited to either 3-tuple or 5-tuple
> > FS support, but the ksft is currently 3-tuple only. Support drivers that
> > have 5-tuple FS supported by adding a ksft arg.
>
On Mon, May 19, 2025 at 8:32 AM Stanislav Fomichev wrote:
>
> On 05/19, Mina Almasry wrote:
> > ncdevmem supports both ipv4 and ipv6, but the ksft is currently
> > ipv6-only. Propagate the ipv4 support to the ksft, so that folks that
> > are limited to these networks can also test.
> >
> > Signed-
On Mon, May 19, 2025 at 8:25 AM Stanislav Fomichev wrote:
>
> On 05/19, Mina Almasry wrote:
> > As far as I can tell the ksft_disruptive here is unnecessary. These
> > tests are largerly independent, and when one test fails, it's nice to
> > know the results from all the other test cases.
>
> We c
On Mon, May 19, 2025 at 11:47:32AM +, Reshetova, Elena wrote:
> > On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > > Currently SGX does not have a global counter to count the
> > > active users from userspace or hypervisor. Implement such a counter,
> > > sgx_usage_count. It will b
Hi Ulf,
On Mon, May 19, 2025 at 04:33:30PM +0200, Ulf Hansson wrote:
> On Fri, 9 May 2025 at 21:13, Hiago De Franco wrote:
> >
> > On Fri, May 09, 2025 at 12:37:02PM +0200, Ulf Hansson wrote:
> > > On Thu, 8 May 2025 at 22:28, Hiago De Franco
> > > wrote:
> > > >
> > > > Hello,
> > > >
> > > >
On Mon, May 19, 2025 at 10:24:27AM +0300, Elena Reshetova wrote:
> Currently SGX does not have a global counter to count the
> active users from userspace or hypervisor. Implement such a counter,
> sgx_usage_count. It will be used by the driver when attempting
> to call EUPDATESVN SGX instruction.
From: Hiago De Franco
This SCU API returns the power mode of a given resource.
As example, remoteproc/imx_rproc.c can now use this function to check
the power mode of the remote core to properly set "attached" or
"offline" modes.
Since there is no proper firmware/imx file to place this function
From: Hiago De Franco
When the remote core is started before Linux boots (e.g., by the
bootloader), the driver currently is not able to attach because it only
checks for cores running in different partitions. If the core was kicked
by the bootloader, it is in the same partition as Linux and it is
From: Hiago De Franco
For the i.MX8X and i.MX8 family SoCs, when the M-core is powered up
by the bootloader, M-core and Linux are in same SCFW (System Controller
Firmware) partition, so linux has permission to control M-core.
But when M-core is started, the SCFW will automatically enable the clo
From: Hiago De Franco
For the i.MX8X and i.MX8 family SoCs, currently when the remotecore is
started by the bootloader and the M core and A core are in the same
partition, the driver is not capable to detect the remote core and
report the correct state of it.
This series of patches implement an
> FWIW: I reviewed the patch above ([1]) already but didn't hear anything
> back.
Sorry for the delay on this, last week was busier than expected on my
end. I'm aiming to send the revised patch within the next couple of
days.
On Mon, May 19, 2025 at 9:40 AM Mark Rutland wrote:
> I've had a quick
On Mon, May 19, 2025 at 9:46 AM Suren Baghdasaryan wrote:
>
> On Mon, May 19, 2025 at 9:38 AM David Wang <00107...@163.com> wrote:
> >
> > When module load fails after memory for codetag section is ready,
> > codetag section memory will not be properly released. This
> > causes memory leak, and if
Hi Mark,
Thanks for your review and the fixups!
On Mon, May 19, 2025 at 6:41 AM Mark Rutland wrote:
>
[...]
>
> ... and then in future we can add anything spdecific to reliable
> stacktrace there.
>
> That aside, this generally looks good to me. The only thing that I note
> is that we're lacking
On Fri, May 16, 2025 at 03:51:48PM -0700, Sumanth Gavini wrote:
> Fix misspelling reported by codespell
>
> Signed-off-by: Sumanth Gavini
Thanks,
With this change this file appears to be codespell-clean.
Reviewed-by: Simon Horman
...
On Mon, May 19, 2025 at 9:38 AM David Wang <00107...@163.com> wrote:
>
> When module load fails after memory for codetag section is ready,
> codetag section memory will not be properly released. This
> causes memory leak, and if next module load happens to get the
> same module address, codetag may
On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> ARM folks, please share your thoughts on this work. To fully support
> livepatching of kernel modules, we also need [1]. We hope we can
> land this in the 6.16 kernel.
>
> Thanks,
> Song
>
> [1]
> https://lore.kernel.org/linux-arm-kerne
When module load fails after memory for codetag section is ready,
codetag section memory will not be properly released. This
causes memory leak, and if next module load happens to get the
same module address, codetag may pick the uninitialized section
when manipulating tags during module unload, an
* Elena Reshetova wrote:
> @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> *file)
> struct sgx_encl *encl;
> int ret;
>
> + ret = sgx_inc_usage_count();
> + if (ret)
> + return -EBUSY;
So if sgx_inc_usage_count() returns nonzero, it
At 2025-05-20 00:03:16, "Suren Baghdasaryan" wrote:
>On Sun, May 18, 2025 at 3:12 AM David Wang <00107...@163.com> wrote:
>>
>> When module load failed after memory for codetag sections ready,
>
>nit: s/ready/is ready
>
>> codetag section memory was not properly released. This
>> causes memory le
Hi!
> Every time I open Documentation/CodingStyle it says the party moved
> somewhere else. :-(
>
> Of course, I forget where it moved to by the next time.
Yes please. I was hiting this way too often, too.
Best regards,
Pavel
--
On 5/19/25 00:24, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> compromise, a new supervisor
On Sun, May 18, 2025 at 3:12 AM David Wang <00107...@163.com> wrote:
>
> When module load failed after memory for codetag sections ready,
nit: s/ready/is ready
> codetag section memory was not properly released. This
> causes memory leak, and if next module load happens to got the
nit: s/happens
On 05/19, Mina Almasry wrote:
> This variable is unused and can be removed.
>
> Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomichev
On 05/19, Mina Almasry wrote:
> The current test just sends "hello\nworld" and verifies that is the
> string received on the RX side. That is fine, but improve the test a bit
> by sending 1K data. The test should be improved further to send more
> data, but for now this should be a welcome improvem
On 05/19, Mina Almasry wrote:
> Preserve the error code returned by sock_cmsg_send and return that on
> err.
>
> Signed-off-by: Mina Almasry
> ---
> net/ipv4/tcp.c | 24 ++--
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
On 05/19, Mina Almasry wrote:
> ncdevmem supports drivers that are limited to either 3-tuple or 5-tuple
> FS support, but the ksft is currently 3-tuple only. Support drivers that
> have 5-tuple FS supported by adding a ksft arg.
>
> Signed-off-by: Mina Almasry
>
> ---
> .../testing/selftests/dr
On 05/19, Mina Almasry wrote:
> This exit_wait seems necessary to make the rx side test pass for me.
> I think this is just missed from the original test add patch. Add it now.
>
> Signed-off-by: Mina Almasry
Acked-by: Stanislav Fomichev
On 05/19, Mina Almasry wrote:
> ncdevmem supports both ipv4 and ipv6, but the ksft is currently
> ipv6-only. Propagate the ipv4 support to the ksft, so that folks that
> are limited to these networks can also test.
>
> Signed-off-by: Mina Almasry
>
> ---
> .../selftests/drivers/net/hw/devmem.py
On 05/19, Mina Almasry wrote:
> As far as I can tell the ksft_disruptive here is unnecessary. These
> tests are largerly independent, and when one test fails, it's nice to
> know the results from all the other test cases.
We currently don't do anything special for disruptive tests. I'm assuming
an
On Sat, May 17, 2025 at 05:57:40PM +0530, Sameeksha Sankpal wrote:
> Signed-off-by: Sameeksha Sankpal
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/tes
On Thu, May 15, 2025 at 02:45:22PM +0200, Petr Pavlu wrote:
> On 5/15/25 12:04, Joel Granados wrote:
> > On Thu, May 15, 2025 at 10:04:53AM +0200, Petr Pavlu wrote:
> >> On 5/9/25 14:54, Joel Granados wrote:
> >>> Move module sysctl (modprobe_path and modules_disabled) out of sysctl.c
> >>> and int
Introduce new eptdev abstraction based on anonymous inode. The new API
is exactly same with legacy one except:
- It's anonymous and devnode/path free.
- Its fops->open() is empty.
Signed-off-by: Dawei Li
---
drivers/rpmsg/rpmsg_char.c | 49 ++
drivers/rpmsg/r
Implement RPMSG_CREATE_EPT_FD_IOCTL, new uAPI for rpmsg ctrl, which
shares most of operations of RPMSG_CREATE_EPT_IOCTL except that it
returns fd representing eptdev to userspace directly.
Possible calling procedures for userspace are:
- fd = open("/dev/rpmsg_ctrlX")
- ioctl(fd, RPMSG_CREATE_EPT_F
Hi,
This is V3 of series which introduce new uAPI(RPMSG_CREATE_EPT_FD_IOCTL)
for rpmsg subsystem.
Current uAPI implementation for rpmsg ctrl & char device manipulation is
abstracted in procedures below:
- fd = open("/dev/rpmsg_ctrlX")
- ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info); /dev/rpmsgY devnod
Current uAPI implementation for rpmsg ctrl & char device manipulation is
abstracted in procedures below:
- fd = open("/dev/rpmsg_ctrlX")
- ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info); /dev/rpmsgY devnode is
generated.
- fd_ep = open("/dev/rpmsgY", O_RDWR)
- operations on fd_ep(write, read, poll ioct
On Mon, 12 May 2025 at 05:46, Peng Fan wrote:
>
> On Fri, May 09, 2025 at 04:13:08PM -0300, Hiago De Franco wrote:
> >On Fri, May 09, 2025 at 12:37:02PM +0200, Ulf Hansson wrote:
> >> On Thu, 8 May 2025 at 22:28, Hiago De Franco wrote:
> >> >
> >> > Hello,
> >> >
> >> > On Thu, May 08, 2025 at 12
On Mon, May 19, 2025 at 03:28:47PM +0200, David Hildenbrand wrote:
> On 16.05.25 20:07, Mark Brown wrote:
> > On Fri, May 16, 2025 at 04:12:08PM +0200, David Hildenbrand wrote:
> > [Converting to kselftet_harness]
> > > > That'd certainly work, though doing that is more surgery on the test
> > > >
On Mon, 19 May 2025 at 16:39, Ulf Hansson wrote:
>
> On Mon, 12 May 2025 at 05:46, Peng Fan wrote:
> >
> > On Fri, May 09, 2025 at 04:13:08PM -0300, Hiago De Franco wrote:
> > >On Fri, May 09, 2025 at 12:37:02PM +0200, Ulf Hansson wrote:
> > >> On Thu, 8 May 2025 at 22:28, Hiago De Franco
> > >
Some thoughts after reading the related code:
offline_pages() is a little convoluted, since it has two steps to make
sure a range of memory can be offlined:
1. start_isolate_page_range() checks unmovable (maybe not migratable
is more precise) pages using has_unmovable_pages(), but leaves unmov
On Sat, May 17, 2025 at 06:53:29PM +0530, Beleswar Prasad Padhi wrote:
>
> On 5/16/2025 9:15 PM, Mathieu Poirier wrote:
> > On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> > > The rproc_detach() function invokes __rproc_detach() before
> > > rproc_unprepare_device(). The __rproc_
On Fri, 9 May 2025 at 21:13, Hiago De Franco wrote:
>
> On Fri, May 09, 2025 at 12:37:02PM +0200, Ulf Hansson wrote:
> > On Thu, 8 May 2025 at 22:28, Hiago De Franco wrote:
> > >
> > > Hello,
> > >
> > > On Thu, May 08, 2025 at 12:03:33PM +0200, Ulf Hansson wrote:
> > > > On Wed, 7 May 2025 at 18
On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek wrote:
> >
> [...]
> > >
> > > [1]
> > > https://lore.kernel.org/live-patching/20250127213310.2496133-1-wn...@google.com/
> > > [2]
> > > https://lore.kernel.org/live-patching/20250129232936.1
Thanks for the review and testing!
>> -static void retry_copy_page(int ufd, struct uffdio_copy *uffdio_copy,
>> - unsigned long offset)
>> +static void retry_copy_page(uffd_global_test_opts_t *gopts, struct
>> uffdio_copy *uffdio_copy,
>> +
On Thu, Mar 20, 2025 at 10:15:58AM -0700, Song Liu wrote:
> With proper exception boundary detection, it is possible to implment
> arch_stack_walk_reliable without sframe.
>
> Note that, arch_stack_walk_reliable does not guarantee getting reliable
> stack in all scenarios. Instead, it can reliably
On Fri, May 16, 2025 at 6:35 PM Michael S. Tsirkin wrote:
>
> On Fri, May 16, 2025 at 09:30:01AM +0800, Jason Wang wrote:
> > On Wed, May 14, 2025 at 10:24 PM Michael S. Tsirkin wrote:
> > >
> > > On Wed, May 14, 2025 at 10:19:05AM -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Apr 09, 2025 at
On 16.05.25 20:07, Mark Brown wrote:
On Fri, May 16, 2025 at 04:12:08PM +0200, David Hildenbrand wrote:
On 16.05.25 15:09, Mark Brown wrote:
I'm afraid we have other such tests that report duplicate conditions. cow.c
is likely another candidate (written by me ;) ).
That one's not come up f
Hi Martin,
On 17/05/2025 00:48, Martin KaFai Lau wrote:
> On 3/20/25 10:48 AM, Matthieu Baerts (NGI0) wrote:
>> From: Geliang Tang
>>
>> This patch adds a "cgroup/getsockopt" program "iters_subflow" to test the
>> newly added mptcp_subflow bpf_iter.
>>
>> Export mptcp_subflow helpers bpf_iter_mpt
On Fri, May 16, 2025 at 09:53:36AM -0700, Song Liu wrote:
> On Thu, Apr 10, 2025 at 8:17 AM Petr Mladek wrote:
> >
> [...]
> > >
> > > [1]
> > > https://lore.kernel.org/live-patching/20250127213310.2496133-1-wn...@google.com/
> > > [2]
> > > https://lore.kernel.org/live-patching/20250129232936.1
* Reshetova, Elena wrote:
>
> > * Elena Reshetova wrote:
> >
> > > @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> > *file)
> > > struct sgx_encl *encl;
> > > int ret;
> > >
> > > + ret = sgx_inc_usage_count();
> > > + if (ret)
> > > + return -EBUSY;
>
On Mon, 2025-05-19 at 10:47 +, Huang, Kai wrote:
> > +/* Counter to count the active SGX users */
> > +static atomic64_t sgx_usage_count;
> > +
> > +int sgx_inc_usage_count(void)
> > +{
> > + atomic64_inc(&sgx_usage_count);
> > + return 0;
> > +}
>
> What's the purpose of the returning int
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Currently SGX does not have a global counter to count the
> > active users from userspace or hypervisor. Implement such a counter,
> > sgx_usage_count. It will be used by the driver when attempting
> > to call EUPDATESVN SGX instructio
> * Elena Reshetova wrote:
>
> > Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> > is supported. This will be used by SGX driver to perform CPU
> > SVN updates.
> >
> > Signed-off-by: Elena Reshetova
> > ---
> > arch/x86/include/asm/cpufeatures.h | 1 +
> > arch/x86/ke
On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> process can know the execution state of EUPDATESVN and notify
> userspace.
>
> Signed-off-by: Elena Reshetova
> ---
[...]
>
> /**
> @@ -73,6 +74,11 @@ enum sgx_encls_fun
> On Mon, 2025-05-19 at 10:47 +, Huang, Kai wrote:
> > > +/* Counter to count the active SGX users */
> > > +static atomic64_t sgx_usage_count;
> > > +
> > > +int sgx_inc_usage_count(void)
> > > +{
> > > + atomic64_inc(&sgx_usage_count);
> > > + return 0;
> > > +}
> >
> > What's the purpose of
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > The SGX attestation architecture assumes a compromise
> > of all running enclaves and cryptographic assets
> > (like internal SGX encryption keys) whenever a microcode
> > update affects SGX. To mitigate the impact of this presumed
> >
On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> The SGX attestation architecture assumes a compromise
> of all running enclaves and cryptographic assets
> (like internal SGX encryption keys) whenever a microcode
> update affects SGX. To mitigate the impact of this presumed
> compromise,
On Mon, 2025-05-19 at 11:30 +, Reshetova, Elena wrote:
> > On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > > process can know the execution state of EUPDATESVN and notify
> > > userspace.
> > >
> > > Signed-off-b
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Add error codes for ENCLS[EUPDATESVN], then SGX CPUSVN update
> > process can know the execution state of EUPDATESVN and notify
> > userspace.
> >
> > Signed-off-by: Elena Reshetova
> > ---
>
> [...]
>
> >
> > /**
> > @@ -73,6 +74,
> On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> > Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> > is supported. This will be used by SGX driver to perform CPU
> > SVN updates.
> >
> > Signed-off-by: Elena Reshetova
> > ---
> > arch/x86/include/asm/cpufeatures.
> * Elena Reshetova wrote:
>
> > @@ -19,10 +19,15 @@ static int sgx_open(struct inode *inode, struct file
> *file)
> > struct sgx_encl *encl;
> > int ret;
> >
> > + ret = sgx_inc_usage_count();
> > + if (ret)
> > + return -EBUSY;
>
> So if sgx_inc_usage_count() returns no
On Mon, May 19, 2025 at 03:12:39PM +0800, Lijuan Gao wrote:
>
>
> 在 5/18/2025 12:59 AM, Konrad Dybcio 写道:
> > On 5/17/25 12:11 AM, Dmitry Baryshkov wrote:
> > > On Fri, May 16, 2025 at 11:27:06AM +0800, Lijuan Gao wrote:
> > > > Add nodes for remoteprocs: ADSP and CDSP for QCS615 SoC to enable pr
On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> Add a flag indicating whenever ENCLS[EUPDATESVN] SGX instruction
> is supported. This will be used by SGX driver to perform CPU
> SVN updates.
>
> Signed-off-by: Elena Reshetova
> ---
> arch/x86/include/asm/cpufeatures.h | 1 +
>
On Mon, 2025-05-19 at 10:24 +0300, Elena Reshetova wrote:
> Currently SGX does not have a global counter to count the
> active users from userspace or hypervisor. Implement such a counter,
> sgx_usage_count. It will be used by the driver when attempting
> to call EUPDATESVN SGX instruction.
>
> Su
Hi Martin,
Thank you for your reply!
On 17/05/2025 00:34, Martin KaFai Lau wrote:
> On 3/20/25 10:48 AM, Matthieu Baerts (NGI0) wrote:
(...)
>> @BPF maintainers: we would like to allow this new mptcp_subflow bpf_iter
>> to be used with struct_ops, but only with the two new ones we are going
>>
On 2025/5/12 下午2:53, Huacai Chen wrote:
Hi, Bibo,
On Sun, Apr 27, 2025 at 2:45 PM Bibo Mao wrote:
This patchset adds KVM selftests for LoongArch system, currently only
some common test cases are supported and pass to run. These test cases
are listed as following:
coalesced_io_test
On Sat, May 17, 2025 at 07:27:49PM +0200, Konrad Dybcio wrote:
> SC8280XP features a SLPI, much like its distant relative, SM8350.
Please get into the habit of spelling out *and* explaining internal
Qualcomm acronyms like "SLPI" so that your cover letter and commit
messages makes sense to people o
Fixes a grammatical error in the output where the word 'to' was missing.
Signed-off-by: Anish Dabhane
---
tools/testing/selftests/cachestat/test_cachestat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/cachestat/test_cachestat.c
b/tools/testing/sel
This patchset introduces SIOCINQ ioctl support for vsock, indicating the
number of unread bytes.
Similar to SIOCOUTQ ioctl, the information is transport-dependent. The
first patch introduces a new callback, unread_bytes, in vsock transport,
and adds ioctl support in AF_VSOCK.
The second patch imp
1 - 100 of 116 matches
Mail list logo
