nd filesystem testing on arm64
> > > dragonboard-410c the following kernel warnings / errors noticed and system
> > > halted and did not recover with selftests Kconfig enabled running the
> > > kernel
> > > Linux next tag next-20250804.
> > >
> > > Regressio
On Fri, Jun 13, 2025 at 3:21 AM Jason Wang wrote:
>
> On Thu, Jun 12, 2025 at 3:25 PM Eugenio Perez Martin
> wrote:
> >
> > On Thu, Jun 12, 2025 at 2:30 AM Jason Wang wrote:
> > >
> > > On Fri, Jun 6, 2025 at 7:50 PM Eugenio Pérez wrote:
> > > >
> > > > Make one IOTLB domain per address space,
On 8/7/25 9:43 AM, Mukesh Ojha wrote:
> fw_name in qcom_mdt_bins_are_split() seems unused now, it may have
> used in the past for logging it but due to code refactor this parameter
> is unused now.
>
> Signed-off-by: Mukesh Ojha
> ---
Reviewed-by: Konrad Dybcio
Konrad
On Tue, Jun 10, 2025 at 10:36 AM Jason Wang wrote:
>
> On Mon, Jun 9, 2025 at 2:11 PM Eugenio Perez Martin
> wrote:
> >
> > On Mon, Jun 9, 2025 at 3:50 AM Jason Wang wrote:
> > >
> > > On Mon, Jun 9, 2025 at 9:41 AM Jason Wang wrote:
> > > >
> > > > On Fri, Jun 6, 2025 at 7:50 PM Eugenio Pérez
On Wed, Aug 06, 2025 at 08:59:59AM +0200, Christophe Leroy wrote:
>
>
> Le 05/08/2025 à 13:59, Venkat Rao Bagalkote a écrit :
> >
> > On 05/08/25 1:04 pm, Christophe Leroy wrote:
> > >
> > >
> > > Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
> > > > bpf_jit_emit_probe_mem_store() is in
On Tue, Aug 05, 2025 at 09:45:39AM +0200, Christophe Leroy wrote:
>
>
> Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
> > This patch series introduces support for the PROBE_MEM32,
> > bpf_addr_space_cast and PROBE_ATOMIC instructions in the powerpc BPF JIT,
> > facilitating the implementat
On Tue, Aug 05, 2025 at 09:29:07AM +0200, Christophe Leroy wrote:
>
>
> Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
> > LLVM generates bpf_addr_space_cast instruction while translating
> > pointers between native (zero) address space and
> > __attribute__((address_space(N))). The addr_sp
On Wed, Aug 06, 2025 at 11:17:34AM -0700, Yonghong Song wrote:
SNIP
> > diff --git a/tools/testing/selftests/bpf/Makefile
> > b/tools/testing/selftests/bpf/Makefile
> > index 910d8d6402ef..68cf6a9cf05f 100644
> > --- a/tools/testing/selftests/bpf/Makefile
> > +++ b/tools/testing/selftests/bpf/Ma
system
> > halted and did not recover with selftests Kconfig enabled running the kernel
> > Linux next tag next-20250804.
> >
> > Regression Analysis:
> > - New regression? Yes
> > - Reproducibility? Re-validation is in progress
> >
> > First seen o
On 8/6/25 8:24 PM, Wei Yang wrote:
On Wed, Aug 06, 2025 at 06:30:37PM +0530, Donet Tom wrote:
[...]
Child process inherit the ksm_merging_pages from parent, which is reasonable
to me. But I am confused why ksm_unmerge() would just reset ksm_merging_pages
for parent and leave ksm_merging_pages
On Tue, Aug 05, 2025 at 10:20:43PM -0400, Zi Yan wrote:
[...]
>
>- if (in_folio_offset < 0 ||
>- in_folio_offset >= folio_nr_pages(folio)) {
>+ if (in_folio_offset < 0 || in_folio_offset >= nr_pages) {
> if (!split_folio_to_order(fol
On Tue, Aug 05, 2025 at 10:20:43PM -0400, Zi Yan wrote:
>Current behavior is to move to next PAGE_SIZE and split, but that makes it
>hard to check after-split folio orders. This is a preparation patch to
>allow more precise split_huge_page_test check in an upcoming commit.
>
>split_folio_to_order()
On 2025/8/6 10:20, Zi Yan wrote:
They are useful information for debugging split huge page tests.
Signed-off-by: Zi Yan
LGTM.
Reviewed-by: Baolin Wang
---
mm/huge_memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
inde
On 2025/8/6 10:20, Zi Yan wrote:
The helper gathers an folio order statistics of folios within a virtual
address range and checks it against a given order list. It aims to provide
a more precise folio order check instead of just checking the existence of
PMD folios.
Signed-off-by: Zi Yan
---
On Wed, Aug 06, 2025 at 12:07:05PM -0700, Jeff Johnson wrote:
> On 8/6/2025 10:25 AM, Mukesh Ojha wrote:
> > pas id is not used in qcom_mdt_load_no_init() and it should not
> > be used as it is non-PAS specific function and has no relation
> > to PAS specific mechanism.
> ...> @@ -353,7 +353,7 @@ s
On Wed, Aug 06, 2025 at 02:46:00PM -0700, Suren Baghdasaryan wrote:
> On Wed, Aug 6, 2025 at 12:03 PM Lorenzo Stoakes
> wrote:
> >
> > On Wed, Aug 06, 2025 at 08:59:04AM -0700, Suren Baghdasaryan wrote:
> > > Utilize per-vma locks to stabilize vma after lookup without taking
> > > mmap_lock during
On Wed, Aug 06, 2025 at 03:01:45PM -0700, Bjorn Andersson wrote:
> On Wed, Aug 06, 2025 at 10:55:28PM +0530, Mukesh Ojha wrote:
> > Firmware binaries may lack section headers, in which case
> > the e_shentsize field in the ELF header can be zero.
> >
> > Update mdt_header_valid() to correctly hand
On 07/08/25 2:09 AM, Bala-Vignesh-Reddy wrote:
> Resolve compiler warning about always true condition in ksft_test_result
> in tpidr2, passing actual function.
>
> This silences -Waddress warning while maintaining test functionality.
Might be better to just add the compiler warning in the commit
Hi David,
On Thu, Jul 31, 2025 at 11:06:50PM +0200, David Heidelberg via B4 Relay wrote:
> With the growing popularity of running upstream Linux on mobile devices,
> we're beginning to run into more and more edgecases. The OnePlus 6 is a
> fairly well supported 2018 era smartphone, selling over a
On Thu, Aug 07, 2025 at 12:46:17PM +1000, Aleksa Sarai wrote:
> It felt odd to use "return ret;" at the start and switch to "return n;"
> at the end, but feel free to change it when applying.
s/ret/err/ would take care of that, as well as clarifying the intent -
not that "mutex_lock_interruptible
Hi Zi,
Thanks for the patch.
I have a nit suggestion to centralize some of the macro definitions
for better consistency and reusability.
On [Date of patch], Zi Yan wrote:
> diff --git a/tools/testing/selftests/mm/vm_util.c
> b/tools/testing/selftests/mm/vm_util.c
> ...
> +#define PGMAP_PRESENT
On 2025-08-06, Al Viro wrote:
> On Thu, Aug 07, 2025 at 03:55:23AM +1000, Aleksa Sarai wrote:
>
> > - goto err_free;
> > - ret = -EFAULT;
> > - if (copy_to_user(_buf, p, n) != 0)
> > - goto err_free;
> > + if (copy_to_user(_buf, p, n))
> > + n = -EFAULT;
> >
On Wed, Aug 6, 2025 at 6:54 PM Jiapeng Chong
wrote:
>
> Avoid pointer type value compared with 0 to make code clear.
>
> ./tools/testing/selftests/bpf/progs/mem_rdonly_untrusted.c:221:10-11: WARNING
> comparing pointer to 0.
>
> Reported-by: Abaci Robot
Hey Abaci folks,
stop sending this kind
On Wed, 2025-08-06 at 11:11 +0300, Elena Reshetova wrote:
> == Background ==
>
> ENCLS[EUPDATESVN] is a new SGX instruction [1] which allows enclave
> attestation to include information about updated microcode SVN without a
> reboot. Before an EUPDATESVN operation can be successful, all SGX memory
On Wed, 2025-08-06 at 11:11 +0300, Elena Reshetova wrote:
> All running enclaves and cryptographic assets (such as internal SGX
> encryption keys) are assumed to be compromised whenever an SGX-related
> microcode update occurs. To mitigate this assumed compromise the new
> supervisor SGX instructio
On Wed, 2025-08-06 at 11:11 +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.
I would also add some text to explain why other error codes are not
defined:
EUPDATESVN will be ca
On Wed, 2025-08-06 at 11:11 +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
> ---
> arch/x86/include/asm/sgx.h | 6 ++
> 1 file change
On Wed, 2025-08-06 at 11:11 +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.
You may need to pay attention to text wrap, anyway ...
>
> Reviewed-by: Dave Hansen
> Signed-
served this problem in other patches too. Could you check all
changelogs and re-wrap the text if needed?
Back to technical:
"virtual EPC" is also opened from the userspace, so using "hypervisor"
doesn't look quite right to me.
Also, it would be better to mention the "why
On Wed, Aug 06, 2025 at 10:55:28PM +0530, Mukesh Ojha wrote:
> Firmware binaries may lack section headers, in which case
> the e_shentsize field in the ELF header can be zero.
>
> Update mdt_header_valid() to correctly handle this scenario
> by adjusting the validation logic accordingly.
>
As I
On Wed, Aug 6, 2025 at 12:03 PM Lorenzo Stoakes
wrote:
>
> On Wed, Aug 06, 2025 at 08:59:04AM -0700, Suren Baghdasaryan wrote:
> > Utilize per-vma locks to stabilize vma after lookup without taking
> > mmap_lock during PROCMAP_QUERY ioctl execution. If vma lock is
> > contended, we fall back to mm
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
[also build test ERROR on net/main linus/master v6.16 next-20250806]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as
On Wed, Aug 06, 2025 at 03:34:55PM -0300, Igor Torrente wrote:
> Hello,
>
> The commit `206cc44588f7 virtio: reject shm region if length is zero` breaks
> the Virtio-gpu `host_visible` feature.
>
> As you can see in the snippet below, host_visible_region is zero because of
> the `kzalloc`.
> I
On Thu, Aug 07, 2025 at 03:55:23AM +1000, Aleksa Sarai wrote:
> - goto err_free;
> - ret = -EFAULT;
> - if (copy_to_user(_buf, p, n) != 0)
> - goto err_free;
> + if (copy_to_user(_buf, p, n))
> + n = -EFAULT;
> ret = n;
> -
> -err_free:
>
On 8/6/2025 10:25 AM, Mukesh Ojha wrote:
> pas id is not used in qcom_mdt_load_no_init() and it should not
> be used as it is non-PAS specific function and has no relation
> to PAS specific mechanism.
...> @@ -353,7 +353,7 @@ static int __qcom_mdt_load(struct device *dev, const
struct firmware *fw,
On Wed, Aug 06, 2025 at 08:59:04AM -0700, Suren Baghdasaryan wrote:
> Utilize per-vma locks to stabilize vma after lookup without taking
> mmap_lock during PROCMAP_QUERY ioctl execution. If vma lock is
> contended, we fall back to mmap_lock but take it only momentarily
> to lock the vma and release
On Wed, Aug 6, 2025 at 11:04 AM Lorenzo Stoakes
wrote:
>
> On Wed, Aug 06, 2025 at 08:59:03AM -0700, Suren Baghdasaryan wrote:
> > Refactor struct proc_maps_private so that the fields used by PROCMAP_QUERY
> > ioctl are moved into a separate structure. In the next patch this allows
> > ioctl to re
On 8/6/25 2:24 AM, Jiawei Zhao wrote:
When using GCC on x86-64 to compile an usdt prog with -O1 or higher
optimization, the compiler will generate SIB addressing mode for global
array and PC-relative addressing mode for global variable,
e.g. "1@-96(%rbp,%rax,8)" and "-1@4+t1(%rip)".
In this p
On 8/6/25 2:24 AM, Jiawei Zhao wrote:
When using GCC on x86-64 to compile an usdt prog with -O1 or higher
optimization, the compiler will generate SIB addressing mode for global
array and PC-relative addressing mode for global variable,
e.g. "1@-96(%rbp,%rax,8)" and "-1@4+t1(%rip)".
The curre
On Wed, Aug 06, 2025 at 08:59:03AM -0700, Suren Baghdasaryan wrote:
> Refactor struct proc_maps_private so that the fields used by PROCMAP_QUERY
> ioctl are moved into a separate structure. In the next patch this allows
> ioctl to reuse some of the functions used for reading /proc/pid/maps
> withou
On 8/6/25 12:48 PM, Hiago De Franco wrote:
From: Hiago De Franco
As of today, pinging the remote processor during k3_rproc_request_mbox()
does not have any functional effect. This behavior was originally based on
the OMAP remoteproc driver, where the idea was to send messages such as
suspend re
On Mon, Aug 04, 2025 at 06:11:51PM +0530, Mukesh Ojha wrote:
> Firmware binaries may lack section headers, in which case
> the e_shentsize field in the ELF header can be zero.
>
> Update mdt_header_valid() to correctly handle this scenario
> by adjusting the validation logic accordingly.
>
Thank
Hello:
This patch was applied to riscv/linux.git (for-next)
by Alexandre Ghiti :
On Fri, 11 Jul 2025 13:19:24 + you wrote:
> This selftest tests all the currently emulated instructions (except for
> the RV32 compressed ones which are left as a future exercise for a RV32
> user). For the FPU i
On Tue, Aug 05, 2025 at 10:20:42PM -0400, Zi Yan wrote:
> They are useful information for debugging split huge page tests.
>
> Signed-off-by: Zi Yan
Seems reasonable, so:
Reviewed-by: Lorenzo Stoakes
> ---
> mm/huge_memory.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
On Wed, 30 Jul 2025 19:53:01 +0530 Pranav Tyagi
wrote:
Hi Pranav,
Thank you for this patch! Sorry for the late response, thank you for bumping
the patch. I just have a few comments about the commit message.
> Replace typeof() with __auto_type in the swap() macro in uffd-stress.c.
> __auto_type
On Wed, Aug 06, 2025 at 09:15:50PM +0530, Pranav Tyagi wrote:
> On Wed, Jul 30, 2025 at 7:53 PM Pranav Tyagi wrote:
> >
> > Replace typeof() with __auto_type in the swap() macro in uffd-stress.c.
> > __auto_type was introduced in GCC 4.9 and reduces the compile time for
> > all compilers. No funct
On Wed, 6 Aug 2025 08:59:04 -0700 Suren Baghdasaryan wrote:
> Utilize per-vma locks to stabilize vma after lookup without taking
> mmap_lock during PROCMAP_QUERY ioctl execution. If vma lock is
> contended, we fall back to mmap_lock but take it only momentarily
> to lock the vma and release the
On Wed, 6 Aug 2025 08:59:03 -0700 Suren Baghdasaryan wrote:
> Refactor struct proc_maps_private so that the fields used by PROCMAP_QUERY
> ioctl are moved into a separate structure. In the next patch this allows
> ioctl to reuse some of the functions used for reading /proc/pid/maps
> without usi
On Wed, Aug 6, 2025 at 8:33 PM Alexei Starovoitov
wrote:
>
> On Wed, Aug 6, 2025 at 4:02 AM Pranav Tyagi wrote:
> >
> > Replace typeof() with __auto_type in xdp_synproxy_kern.c.
> > __auto_type was introduced in GCC 4.9 and reduces the compile time for
> > all compilers. No functional changes int
On Wed, Jul 30, 2025 at 7:53 PM Pranav Tyagi wrote:
>
> Replace typeof() with __auto_type in the swap() macro in uffd-stress.c.
> __auto_type was introduced in GCC 4.9 and reduces the compile time for
> all compilers. No functional changes intended.
>
> Signed-off-by: Pranav Tyagi
> ---
> tools/
On Wed, Aug 6, 2025 at 8:59 PM Jakub Kicinski wrote:
>
> On Wed, 6 Aug 2025 13:50:16 +0530 Pranav Tyagi wrote:
> > Replace typeof() with __auto_type in iou-zcrx.c.
> > __auto_type was introduced in GCC 4.9 and reduces the compile time for
> > all compilers. No functional changes intended.
>
> Yet
On Wed, 6 Aug 2025 13:50:16 +0530 Pranav Tyagi wrote:
> Replace typeof() with __auto_type in iou-zcrx.c.
> __auto_type was introduced in GCC 4.9 and reduces the compile time for
> all compilers. No functional changes intended.
Yet another unnecessary compiler feature. Please no.
On Wed, Aug 6, 2025 at 4:02 AM Pranav Tyagi wrote:
>
> Replace typeof() with __auto_type in xdp_synproxy_kern.c.
> __auto_type was introduced in GCC 4.9 and reduces the compile time for
> all compilers. No functional changes intended.
>
> Signed-off-by: Pranav Tyagi
> ---
> tools/testing/selftes
Ping -- please let me know if there's anything else I must address.
I've ensured v6 still applies on mm-new.
Thanks,
Ujwal
On Wed, Aug 06, 2025 at 06:30:37PM +0530, Donet Tom wrote:
[...]
>> Child process inherit the ksm_merging_pages from parent, which is reasonable
>> to me. But I am confused why ksm_unmerge() would just reset ksm_merging_pages
>> for parent and leave ksm_merging_pages in child process unchanged.
>>
he kernel
> Linux next tag next-20250804.
>
> Regression Analysis:
> - New regression? Yes
> - Reproducibility? Re-validation is in progress
>
> First seen on the next-20250804
> Good: next-20250801
> Bad: next-20250804
>
> Test regression: next-20250804 Unable to h
On 6 Aug 2025, at 8:47, David Hildenbrand wrote:
> On 06.08.25 04:20, Zi Yan wrote:
>> Current behavior is to move to next PAGE_SIZE and split, but that makes it
>> hard to check after-split folio orders. This is a preparation patch to
>> allow more precise split_huge_page_test check in an upcomin
On 8/4/2025 5:41 AM, Mukesh Ojha wrote:
> pas id is not used in qcom_mdt_load_no_init() and it should not
> be used as it is non-PAS specific function and has no relation
> to PAS specific mechanism.
>
> Signed-off-by: Mukesh Ojha
> ---
> drivers/media/platform/qcom/venus/firmware.c | 4 ++--
>
On 8/5/25 10:33 PM, Wei Yang wrote:
On Tue, Aug 05, 2025 at 11:39:15AM +0530, Donet Tom wrote:
On 8/4/25 2:41 PM, Wei Yang wrote:
On Tue, Jul 29, 2025 at 11:03:59AM +0530, Aboorva Devarajan wrote:
From: Donet Tom
[...]
diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c
b/too
On 06.08.25 04:20, Zi Yan wrote:
Current behavior is to move to next PAGE_SIZE and split, but that makes it
hard to check after-split folio orders. This is a preparation patch to
allow more precise split_huge_page_test check in an upcoming commit.
split_folio_to_order() part is not changed, sinc
On 06.08.25 04:20, Zi Yan wrote:
They are useful information for debugging split huge page tests.
Signed-off-by: Zi Yan
---
Acked-by: David Hildenbrand
--
Cheers,
David / dhildenb
On Wed, Aug 06, 2025 at 11:34:57AM +0100, Pedro Falcato wrote:
> On Tue, Aug 05, 2025 at 08:21:23PM +0100, Lorenzo Stoakes wrote:
> > +cc Pedro
> >
> > On Tue, Aug 05, 2025 at 03:09:54PM -0400, Zi Yan wrote:
> > > On 5 Aug 2025, at 15:00, Lorenzo Stoakes wrote:
> > >
> > > > On Tue, Aug 05, 2025 at
Tested this series of patches with virtio-net regression tests,
everything works fine.
Tested-by: Lei Yang
On Tue, Jul 29, 2025 at 10:34 AM Jason Wang wrote:
>
> On Mon, Jul 28, 2025 at 6:17 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Jul 28, 2025 at 02:41:29PM +0800, Jason Wang wrote:
> > >
On Tue, Aug 05, 2025 at 08:21:23PM +0100, Lorenzo Stoakes wrote:
> +cc Pedro
>
> On Tue, Aug 05, 2025 at 03:09:54PM -0400, Zi Yan wrote:
> > On 5 Aug 2025, at 15:00, Lorenzo Stoakes wrote:
> >
> > > On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
> > >> diff --git a/tools/testing/selftests
On 24/07/2025 09:12, John Garry wrote:
Hi Carlos,
I was expecting you to pick these up.
Shall I resend next week after v6.17-rc1 is released?
Thanks,
John
This series contains an atomic writes fix for DAX support on xfs and
an improvement to WARN against using IOCB_ATOMIC on the DAX write pa
On Wed, Feb 19, 2025 at 10:09:06AM -0500, Joel Fernandes wrote:
>
>
> On 2/19/2025 8:58 AM, Paul E. McKenney wrote:
> > On Wed, Feb 19, 2025 at 08:25:38AM -0500, Joel Fernandes wrote:
> >> On Tue, Feb 18, 2025 at 09:47:27AM -0800, syzbot wrote:
> >>> Hello,
> >>>
> >>> syzbot found the following
On 8/4/2025 6:11 PM, Mukesh Ojha wrote:
> pas id is not used in qcom_mdt_load_no_init() and it should not
> be used as it is non-PAS specific function and has no relation
> to PAS specific mechanism.
>
> Signed-off-by: Mukesh Ojha
> ---
> drivers/media/platform/qcom/venus/firmware.c | 4 ++--
Le 05/08/2025 à 13:59, Venkat Rao Bagalkote a écrit :
On 05/08/25 1:04 pm, Christophe Leroy wrote:
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
bpf_jit_emit_probe_mem_store() is introduced to emit instructions for
storing memory values depending on the size (byte, halfword,
word,
On Wed, Aug 06, 2025 at 03:31:10PM +1000, Aleksa Sarai wrote:
> Userspace generally expects APIs that return EMSGSIZE to allow for them
> to adjust their buffer size and retry the operation. However, the
> fscontext log would previously clear the message even in the EMSGSIZE
> case.
>
> Given that
On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
>FORCE_READ() converts input value x to its pointer type then reads from
>address x. This is wrong. If x is a non-pointer, it would be caught it
>easily. But all FORCE_READ() callers are trying to read from a pointer and
>FORCE_READ() basicall
On Mon, Aug 04, 2025 at 07:17:02AM -0700, Jeff Johnson wrote:
> On 8/4/2025 5:41 AM, Mukesh Ojha wrote:
> > pas id is not used in qcom_mdt_load_no_init() and it should not
> > be used as it is non-PAS specific function and has no relation
> > to PAS specific mechanism.
> >
> > Signed-off-by: Mukes
Hi Zi Yan, Lorenzo,
Thank you for the detailed discussion. I have been following the
thread closely and it has been very insightful.
Zi Yan's fix is excellent and I appreciate the rigorous analysis.
Lorenzo's feedback has also deepened my own understanding of the
subtleties around the FORCE_REA
On 05.08.25 19:51, Zi Yan wrote:
FORCE_READ() converts input value x to its pointer type then reads from
address x. This is wrong. If x is a non-pointer, it would be caught it
easily. But all FORCE_READ() callers are trying to read from a pointer and
FORCE_READ() basically reads a pointer to a po
, -3, -4};
-static volatile struct {
- int x;
- signed char y;
-} t1 = { 1, -127 };
+/*
+ * TODO: At O2 optimization level, t1's USDT argument spec becomes
-1@4+t1(%rip).
+ * Since libbpf doesn't support RIP addressing mode yet, this causes "unrecognized
register&q
+cc Pedro
On Tue, Aug 05, 2025 at 03:09:54PM -0400, Zi Yan wrote:
> On 5 Aug 2025, at 15:00, Lorenzo Stoakes wrote:
>
> > On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
> >> diff --git a/tools/testing/selftests/mm/vm_util.h
> >> b/tools/testing/selftests/mm/vm_util.h
> >> index c20298ae9
On Thu, 17 Jul 2025 at 09:14, Amir Goldstein wrote:
>
> On Thu, Jun 19, 2025 at 12:04 PM Christian Brauner wrote:
> >
> > On Thu, 12 Jun 2025 17:40:29 +0800, Chen Linxuan wrote:
> > > This patch add a simple functional test for the "abort" file
> > > in fusectlfs (/sys/fs/fuse/connections/ID/abou
On 5 Aug 2025, at 15:00, Lorenzo Stoakes wrote:
> On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
>> FORCE_READ() converts input value x to its pointer type then reads from
>> address x. This is wrong. If x is a non-pointer, it would be caught it
>> easily. But all FORCE_READ() callers are
On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
> FORCE_READ() converts input value x to its pointer type then reads from
> address x. This is wrong. If x is a non-pointer, it would be caught it
> easily. But all FORCE_READ() callers are trying to read from a pointer and
> FORCE_READ() basi
On Sat, Aug 2, 2025 at 2:24 AM Menglong Dong wrote:
>
> The test script is provided by Kuniyuki in [1], which is used to test the
> selection of the TCP reuseport socket problem.
>
> Link:
> https://lore.kernel.org/netdev/20250801040757.156-1-kun...@google.com/ [1]
> Signed-off-by: Menglong D
On Tue, Aug 05, 2025 at 02:48:25PM -0400, Zi Yan wrote:
> On 5 Aug 2025, at 14:38, Jann Horn wrote:
>
> > On Tue, Aug 5, 2025 at 7:51 PM Zi Yan wrote:
> >> FORCE_READ() converts input value x to its pointer type then reads from
> >> address x. This is wrong. If x is a non-pointer, it would be caug
On 5 Aug 2025, at 14:38, Jann Horn wrote:
> On Tue, Aug 5, 2025 at 7:51 PM Zi Yan wrote:
>> FORCE_READ() converts input value x to its pointer type then reads from
>> address x. This is wrong. If x is a non-pointer, it would be caught it
>> easily. But all FORCE_READ() callers are trying to read
On Mon, Aug 04, 2025 at 04:14:26PM -0500, Andrew Davis wrote:
> On 8/4/25 2:31 PM, Hiago De Franco wrote:
> > Hi Andrew,
> >
> > Sorry for the delay, I am back this week, I was testing the patches and
> > removing the ping was not enough, there is one extra message being sent,
> > which is the k3_
On Tue, Aug 5, 2025 at 7:51 PM Zi Yan wrote:
> FORCE_READ() converts input value x to its pointer type then reads from
> address x. This is wrong. If x is a non-pointer, it would be caught it
> easily. But all FORCE_READ() callers are trying to read from a pointer and
> FORCE_READ() basically read
On Tue, Aug 05, 2025 at 11:39:15AM +0530, Donet Tom wrote:
>
>On 8/4/25 2:41 PM, Wei Yang wrote:
>> On Tue, Jul 29, 2025 at 11:03:59AM +0530, Aboorva Devarajan wrote:
>> > From: Donet Tom
>> >
[...]
>> > diff --git a/tools/testing/selftests/mm/ksm_functional_tests.c
>> > b/tools/testing/selftest
Thanks David for your insightful review comments.
On Tue, Aug 5, 2025 at 1:47 AM David Hildenbrand wrote:
>
> On 05.08.25 03:36, Sudarsan Mahendran wrote:
> > Enable these tests to be run on other pfnmap'ed memory like
> > NVIDIA's EGM.
> >
> > Add '--' as a separator to pass in file path. This
Sagi Shahar wrote:
> On Mon, Jul 21, 2025 at 4:51 PM Ira Weiny wrote:
> >
> > On Fri, Jun 13, 2025 at 12:13:32PM -0700, Sagi Shahar wrote:
> > > From: Isaku Yamahata
> > >
> >
> > [snip]
> >
> > >
> > > diff --git a/tools/testing/selftests/kvm/lib/x86/processor.c
> > > b/tools/testing/selftests/
On Fri, 01 Aug 2025 16:14:15 +0200, Duje Mihanović wrote:
> On the pxav3 controller, increasing the drive strength of the data pins
> might be required to maintain stability on fast bus clocks (above 100
> MHz). Add a state_uhs pinctrl to allow this.
>
> The existing state_cmd_gpio pinctrl is ch
On Tue, Aug 5, 2025 at 7:18 AM Vlastimil Babka wrote:
>
> On 8/5/25 1:15 AM, Suren Baghdasaryan wrote:
> > Utilize per-vma locks to stabilize vma after lookup without taking
> > mmap_lock during PROCMAP_QUERY ioctl execution. If vma lock is
> > contended, we fall back to mmap_lock but take it only
On 8/5/25 1:15 AM, Suren Baghdasaryan wrote:
> Utilize per-vma locks to stabilize vma after lookup without taking
> mmap_lock during PROCMAP_QUERY ioctl execution. If vma lock is
> contended, we fall back to mmap_lock but take it only momentarily
> to lock the vma and release the mmap_lock. In a ve
On Mon, Aug 04, 2025 at 07:17:02AM -0700, Jeff Johnson wrote:
> On 8/4/2025 5:41 AM, Mukesh Ojha wrote:
> > pas id is not used in qcom_mdt_load_no_init() and it should not
> > be used as it is non-PAS specific function and has no relation
> > to PAS specific mechanism.
> >
> > Signed-off-by: Mukes
On 8/5/25 1:15 AM, Suren Baghdasaryan wrote:
> Refactor struct proc_maps_private so that the fields used by PROCMAP_QUERY
> ioctl are moved into a separate structure. In the next patch this allows
> ioctl to reuse some of the functions used for reading /proc/pid/maps
> without using file->private_d
On Tue, Aug 05, 2025 at 11:38:07AM +0200, Geert Uytterhoeven wrote:
> Hi Stafford,
>
> On Tue, 5 Aug 2025 at 11:15, Stafford Horne wrote:
> > On Tue, Aug 05, 2025 at 08:40:57AM +, ChenMiao wrote:
> > > From: chenmiao
> > >
> > > We need a text patching mechanism to ensure that in the subsequ
On 05/08/25 11:57 am, Saket Kumar Bhaskar wrote:
This patch series introduces support for the PROBE_MEM32,
bpf_addr_space_cast and PROBE_ATOMIC instructions in the powerpc BPF JIT,
facilitating the implementation of BPF arena and arena atomics.
The last patch in the series has fix for arena sp
On 05/08/25 1:04 pm, Christophe Leroy wrote:
Le 05/08/2025 à 08:27, Saket Kumar Bhaskar a écrit :
bpf_jit_emit_probe_mem_store() is introduced to emit instructions for
storing memory values depending on the size (byte, halfword,
word, doubleword).
Build break with this patch
CC arc
, Asit K
> ; Scarlata, Vincent R
> ;
> Cai, Chong ; Aktas, Erdem ;
> Annapurve, Vishal ; Bondarevska, Nataliia
> ; Raynor, Scott
> Subject: Re: [PATCH v10 4/6] x86/sgx: Define error codes for use by
> ENCLS[EUPDATESVN]
>
> On 8/4/25 00:21, Reshetova, E
On Fri, Jul 18, 2025 at 02:03:55PM +0300, Nikolay Kuratov wrote:
> When operating on struct vhost_net_ubuf_ref, the following execution
> sequence is theoretically possible:
> CPU0 is finalizing DMA operation CPU1 is doing
> VHOST_NET_SET_BACKEND
> //
Hi Stafford,
On Tue, 5 Aug 2025 at 11:15, Stafford Horne wrote:
> On Tue, Aug 05, 2025 at 08:40:57AM +, ChenMiao wrote:
> > From: chenmiao
> >
> > We need a text patching mechanism to ensure that in the subsequent
> > implementation of jump_label, the code can be modified to the correct
> >
On Tue, Aug 05, 2025 at 08:40:57AM +, ChenMiao wrote:
> From: chenmiao
>
> We need a text patching mechanism to ensure that in the subsequent
> implementation of jump_label, the code can be modified to the correct
> location. Therefore, FIX_TEXT_POKE0 has been added as a mapping area.
>
> An
I also considered this approach. In the initial design, there was a
size_t len parameter, but since OpenRISC doesn't support it yet, it
was removed to only support single instructions. If there are plans to
support modifying multiple instructions in the future, we can simply
add size_t lento this A
Thanks for the quick review. You're right—this patch is a false
positive. Modern compilers zero out the remaining fields, so the fix
isn't needed.
I'll be withdrawing all the patches and will ensure we more carefully
evaluate our robot's findings before submitting in the future.
Thanks for your h
1 - 100 of 473901 matches
Mail list logo
