Hi Lukas,
As mentioned offlist, reviewing and testing this is on my TODO list, but
here are some early notes ...
On Thu, May 16, 2024 at 03:30:05PM +0200, Lukas Hruska wrote:
> Livepatches need to access external symbols which can't be handled
> by the normal relocation mechanism. It is needed
On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 5/28/24 23:30, Mathieu Poirier wrote:
> > On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> >> 1) on start:
> >> - Using the TEE loader, the resource table is loaded by an external entity.
On Wed, 29 May 2024 14:47:57 -0400
Steven Rostedt wrote:
> Let me make a debug patch (that crashes on this issue) for that kernel,
> and perhaps you could bisect it?
Can you try this on 6.6-rc1 and see if it gives you any other splats?
Hmm, you can switch it to WARN_ON and that way it may not
On Wed, 29 May 2024 21:36:08 +0300
Ilkka Naulapää wrote:
> applied your patch without others, so trace and panic there.
> Screenshot attached. Also tested kernels backward and found out that
Bah, it's still in an RCU callback, which doesn't tell us why a
normal inode is being sent to the trace
Hi Jeremy,
Thanks for the reply.
> > mctp-i2c rx implementation doesn't call
> > __i2c_transfer which calls the i2c reply trace function.
>
> No, but we can trace the i2c rx path through the trace_i2c_slave
> tracepoint. It is a little messier than tracing trace_i2c_write, but
> has been
Hi Masami,
On Wed, 2024-05-29 at 08:38 +0900, Masami Hiramatsu wrote:
> On Wed, 29 May 2024 01:46:40 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Mon, 27 May 2024 19:29:07 -0400
> > Steven Rostedt wrote:
> >
> > > On Sun, 26 May 2024 19:10:57 +0900
> > > "Masami Hiramatsu (Google)"
On Samstag, 25. Mai 2024 18:47:08 MESZ Krzysztof Kozlowski wrote:
> On 24/05/2024 19:55, Luca Weiss wrote:
> > On Donnerstag, 23. Mai 2024 08:19:11 MESZ Krzysztof Kozlowski wrote:
> >> On 23/05/2024 08:16, Luca Weiss wrote:
> >>> On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
On 22.05.2024 3:08 PM, Bartosz Golaszewski wrote:
> On Wed, May 22, 2024 at 3:06 PM wrote:
>>
>> On 22/05/2024 15:04, Bartosz Golaszewski wrote:
>>> On Wed, May 22, 2024 at 2:42 PM wrote:
On 22/05/2024 14:08, Bartosz Golaszewski wrote:
> From: Tengfei Fan
>
> Document the
From: mpdeso...@suse.com
On Wed, 2 Sep 2020 15:45:33 +0200 (CEST) Miroslav Benes
wrote:
> Hi,
>
> first, I'm sorry for the late reply. Thanks, Josh, for the reminder.
>
> CCing Nicolai. Nicolai, could you take a look at the proposed
> documentation too, please? You have more up-to-date
From: mpdeso...@suse.com
On Thu, 16 May 2024 15:30:03 +0200 Lukas Hruska wrote:
> Summary
> ---
>
> This is a significantly simplified version of the original klp-convert tool.
> The klp-convert code has never got a proper review and also clean ups
> were not easy. The last version was v7,
From: mpdeso...@suse.com
On Tue, 21 Jul 2020 12:14:07 -0400 Joe Lawrence
wrote:
> The livepatch samples aren't very careful with respect to compiler
> IPA-optimization of target kernel functions.
>
> Add a quick disclaimer and pointer to the compiler-considerations.rst
> file to warn
On 2024-05-29 11:34:09 [+0100], Qais Yousef wrote:
> > behaviour. But then it is insistent which matters only in the RT case.
> > Puh. Any sched folks regarding policy?
>
> I am not sure I understood you here. Could you rephrase please?
Right now a SCHED_OTHER task boosted to a realtime priority
On 05/29/24 10:29, Sebastian Andrzej Siewior wrote:
> On 2024-05-27 18:26:50 [+0100], Qais Yousef wrote:
> > > In order to be PI-boosted you need to acquire a lock and the only lock
> > > you can sleep while acquired without generating a warning is a mutex_t
> > > (or equivalent sleeping lock) on
On 05/29/24 09:34, Sebastian Andrzej Siewior wrote:
> On 2024-05-28 00:45:08 [+0100], Qais Yousef wrote:
> > diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> > index 5cb88b748ad6..87d2370dd3db 100644
> > --- a/include/linux/sched/deadline.h
> > +++
On 2024-05-27 18:26:50 [+0100], Qais Yousef wrote:
> > In order to be PI-boosted you need to acquire a lock and the only lock
> > you can sleep while acquired without generating a warning is a mutex_t
> > (or equivalent sleeping lock) on PREEMPT_RT.
>
> Note we care about the behavior for
On 2024-05-28 00:45:08 [+0100], Qais Yousef wrote:
> diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> index 5cb88b748ad6..87d2370dd3db 100644
> --- a/include/linux/sched/deadline.h
> +++ b/include/linux/sched/deadline.h
> @@ -10,7 +10,7 @@
>
> #include
>
>
Hi, MST!
> > include/linux/virtio_vsock.h| 2 +-
> > include/net/af_vsock.h | 25 ++-
> > include/uapi/linux/virtio_vsock.h | 1 +
> > include/uapi/linux/vm_sockets.h | 14 ++
> > net/vmw_vsock/af_vsock.c| 116 +--
> >
Hello Mathieu,
On 5/28/24 23:30, Mathieu Poirier wrote:
> On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
>> 1) on start:
>> - Using the TEE loader, the resource table is loaded by an external entity.
>> In such case the resource table address is not find from the firmware but
On Tue May 28, 2024 at 11:35 PM CEST, Bjorn Andersson wrote:
> On Fri, May 10, 2024 at 02:27:09PM GMT, Luca Weiss wrote:
> > Add the required nodes for sound playback via a connected external
> > display (DisplayPort over USB-C).
> >
> > Signed-off-by: Luca Weiss
> > ---
> > Depends on a bunch
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Mon, 27 May 2024 19:04:18 +0200 you wrote:
> The sysctl core is preparing to only expose instances of
> struct ctl_table as "const".
> This will also affect the ctl_table argument of sysctl handlers.
>
> As the
On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote:
> On Thu, 23 May 2024 at 01:48, Bjorn Andersson
> wrote:
> >
> > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> > > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote:
> > > >
> > > > Dmitry Baryshkov writes:
> >
On Sun, 18 Feb 2024 21:57:24 +0100, Luca Weiss wrote:
> Finally touch the hfpll doc and convert it to yaml, and do some related
> changes along the way.
>
>
Applied, thanks!
[3/3] arm64: dts: qcom: qcs404: Use qcs404-hfpll compatible for hfpll
commit:
On Thu, 25 Apr 2024 21:14:29 +0200, Luca Weiss wrote:
> The mboxes property has been supported in those bindings since a while
> and was always meant to the replace qcom,ipc properties, so let's mark
> qcom,ipc as deprecated - and update the examples to use mboxes.
>
> Related:
>
On Wed, 08 May 2024 10:12:53 +0200, Luca Weiss wrote:
> Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0
> which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6
> and not gpll0.
>
> Adjust the parents of these clocks to make Linux report the correct rate
>
On Thu, 18 Apr 2024 08:36:53 +0200, Luca Weiss wrote:
> With the patches to add vibration support for PMI632 finally applied,
> let's enable this for the PMI632 PMIC and Fairphone 3 smartphone.
>
>
Hi Tal,
Thanks for the contribution! Some comments:
> mctp-i2c rx implementation doesn't call
> __i2c_transfer which calls the i2c reply trace function.
No, but we can trace the i2c rx path through the trace_i2c_slave
tracepoint. It is a little messier than tracing trace_i2c_write, but
has been
On Wed, 29 May 2024 01:46:40 +0900
Masami Hiramatsu (Google) wrote:
> On Mon, 27 May 2024 19:29:07 -0400
> Steven Rostedt wrote:
>
> > On Sun, 26 May 2024 19:10:57 +0900
> > "Masami Hiramatsu (Google)" wrote:
> >
> > > Hi,
> > >
> > > Here is a series of some fixes/improvements for the test
On Fri, May 10, 2024 at 02:27:09PM GMT, Luca Weiss wrote:
> Add the required nodes for sound playback via a connected external
> display (DisplayPort over USB-C).
>
> Signed-off-by: Luca Weiss
> ---
> Depends on a bunch of patches upstream doing bringup of Display (DSI),
> DisplayPort, GPU, and
On Tue, May 21, 2024 at 10:09:59AM +0200, Arnaud Pouliquen wrote:
> 1) on start:
> - Using the TEE loader, the resource table is loaded by an external entity.
> In such case the resource table address is not find from the firmware but
> provided by the TEE remoteproc framework.
> Use the
rproc_coredump(rproc);
> + }
> +
> + if (le32_to_cpu(subsystem->encryption_status) != MINIDUMP_SS_ENCR_DONE)
> {
> + dev_err(>dev, "Minidump not ready, skipping\n");
> + return;
> + }
> +
> + /**
> + * Clear ou
On Tue, May 21, 2024 at 10:09:58AM +0200, Arnaud Pouliquen wrote:
> Split rproc_start()to prepare the update of the management of
I don't see any "splitting" for rproc_start() in this patch. Please consider
rewording or removing.
> the cache table on start, for the support of the firmware
On Wed, Apr 24, 2024 at 02:52:14PM -0700, Andrii Nakryiko wrote:
> Profiling shows that calling nr_possible_cpus() in objpool_pop() takes
> a noticeable amount of CPU (when profiled on 80-core machine), as we
> need to recalculate number of set bits in a CPU bit mask. This number
> can't change,
On Tue, May 21, 2024 at 10:09:56AM +0200, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
On Tue, May 21, 2024 at 06:23:16PM +0200, Gwenael Treuveur wrote:
> Manage interrupt coming from coprocessor also when state is
> ATTACHED.
>
> Fixes: 35bdafda40cc ("remoteproc: stm32_rproc: Add mutex protection for
> workqueue")
> Signed-off-by: Gwenael Treuveur
> Acked-by: Arnaud Pouliquen
On Tue, 28 May 2024 07:51:30 +0300
Ilkka Naulapää wrote:
> yeah, the cache_from_obj tracing bug (without panic) has been
> displayed quite some time now - maybe even since 6.7.x or so. I could
> try checking a few versions back for this and try bisecting it if I
> can find when this started.
>
On Tue, 09 Apr 2024 20:36:35 +0200, Luca Weiss wrote:
> Resolve the dt validation failure on Nexus 5.
>
>
Applied, thanks!
[2/2] ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name
commit: 92b9ce5b11d7ba281f5bf0029185d5c891b29344
Best regards,
--
Bjorn Andersson
On Mon, 08 Apr 2024 21:32:02 +0200, Luca Weiss wrote:
> Finally fix a warning about the apcs-global syscon used on msm8974 that
> has been around forever.
>
>
Applied, thanks!
[2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
commit:
On Mon, 27 May 2024 19:29:07 -0400
Steven Rostedt wrote:
> On Sun, 26 May 2024 19:10:57 +0900
> "Masami Hiramatsu (Google)" wrote:
>
> > Hi,
> >
> > Here is a series of some fixes/improvements for the test modules and boot
> > time selftest of kprobe events. I found a WARNING message with
Hi,
Sorry for late reply.
On Fri, 10 May 2024 10:20:56 +0200
Vlastimil Babka wrote:
> On 5/10/24 9:59 AM, wuqiang.matt wrote:
> > On 2024/5/7 21:55, Vlastimil Babka wrote:
> >>
> >>> + } while (!try_cmpxchg_acquire(>tail, , tail + 1));
> >>> +
> >>> + /* now the tail position is reserved for
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
...
First, why is SGX so special here? How is the SGX problem different
than what the core mm code does?
> --- a/arch/x86/kernel/cpu/sgx/encl.h
> +++ b/arch/x86/kernel/cpu/sgx/encl.h
> @@ -25,6 +25,9 @@
> /* 'desc' bit marking that the page is being
On 5/17/24 04:06, Dmitrii Kuvaiskii wrote:
> We wrote a trivial stress test to reproduce the hangs observed in
> real-world applications. The test stresses #PF-based page allocation and
> SGX_IOC_ENCLAVE_REMOVE_PAGES flows in the SGX driver:
This seems like something we'd want in the kernel SGX
On Thu, 18 Apr 2024 09:44:19 +0300, Dmitry Baryshkov wrote:
> Enable the FastRPC and glink-edge nodes on MSM8996 platform. Tested on
> APQ8096 Dragonboard820c.
>
>
Applied, thanks!
[2/3] arm64: dts: qcom: msm8996: add glink-edge nodes
commit: 56ae780a4387d71dd709895acd95112d01f37fb4
On 5/20/24 07:42, Yang Li wrote:
> The patch updates the function documentation comment for
> rv_en(dis)able_monitor to adhere to the kernel-doc specification.
>
> Signed-off-by: Yang Li
Acked-by: Daniel Bristot de Oliveira
Thanks
-- Daniel
Hi Arnd,
On Thu, Apr 4, 2024 at 4:52 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with W=1 in some configurations produces a false positive
> warning for kallsyms:
>
> kernel/kallsyms.c: In function '__sprint_symbol.isra':
> kernel/kallsyms.c:503:17: error: 'strcpy' source
On 2024/5/28 15:43, David Hildenbrand wrote:
> Am 28.05.24 um 09:11 schrieb kernel test robot:
>>
>>
>> Hello,
>>
>> kernel test robot noticed
>> "BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report" on:
>>
>> commit: d99e3140a4d33e26066183ff727d8f02f56bec64 ("mm: turn
>>
On 28/05/2024 09:26, Bartosz Golaszewski wrote:
> On Mon, May 27, 2024 at 10:56 AM Krzysztof Kozlowski wrote:
>>
>> On 27/05/2024 10:43, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski
>>>
>>> Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and
>>> GPDSP1 on the
On Tue, May 28, 2024 at 09:43:39AM +0200, David Hildenbrand wrote:
> Likely that's just a page_type check racing against concurrent
> mapcount changes.
>
> In __folio_rmap_sanity_checks() we check
> VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio);
Yeah, and that "collides" with
last =
Am 28.05.24 um 09:11 schrieb kernel test robot:
Hello,
kernel test robot noticed
"BUG:KCSAN:data-race_in_folio_remove_rmap_ptes/print_report" on:
commit: d99e3140a4d33e26066183ff727d8f02f56bec64 ("mm: turn folio_test_hugetlb into
a PageType")
On Mon, May 27, 2024 at 10:56 AM Krzysztof Kozlowski wrote:
>
> On 27/05/2024 10:43, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and
> > GPDSP1 on the SA8775p SoC.
> >
> > Co-developed-by: Tengfei Fan
>
>
Hello,
On Mon, May 27, 2024 at 01:51:49PM +0100, Russell King (Oracle) wrote:
> On Mon, May 27, 2024 at 02:28:59PM +0200, Uwe Kleine-König wrote:
> > On Mon, May 27, 2024 at 08:56:16AM +0100, Russell King (Oracle) wrote:
> > > On Mon, May 27, 2024 at 09:43:41AM +0200, Thorsten Scherer wrote:
> >
yeah, the cache_from_obj tracing bug (without panic) has been
displayed quite some time now - maybe even since 6.7.x or so. I could
try checking a few versions back for this and try bisecting it if I
can find when this started.
--Ilkka
On Tue, May 28, 2024 at 1:31 AM Steven Rostedt wrote:
>
>
I tried 6.10-rc1 and it still ends up to panic
--Ilkka
On Tue, May 28, 2024 at 12:44 AM Steven Rostedt wrote:
>
> On Mon, 27 May 2024 20:14:42 +0200
> Greg KH wrote:
>
> > On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > > Hi Steven,
> > >
> > > I took some time and
On Thu, 14 Mar 2024 20:00:13 +0100, Luca Weiss wrote:
> Add the dts for "hlte" which is a phablet from 2013.
>
>
Applied, thanks!
[2/2] ARM: dts: qcom: msm8974: Add Samsung Galaxy Note 3
commit: b4f6c63bf34d8da1b769483bb1f4a603c53896ce
Best regards,
--
Bjorn Andersson
On Fri, 10 May 2024 14:27:07 +0200, Luca Weiss wrote:
> Validated on Fairphone 5 (QCM6490) smartphone by using DisplayPort over
> USB-C audio, connected to a TV, with a basic UCM to enable
> 'DISPLAY_PORT_RX Audio Mixer MultiMedia1':
>
On Mon, 19 Feb 2024 22:43:15 +0100, Bryant Mairs wrote:
> This series adds support for samsung-milletwifi, the smaller cousin
> to samsung-matisselte. I've used the manufacturer's naming convention
> for consistency.
>
> Hardware currently supported:
> - Display
> - Cover detection
> - Physical
On Wed, 08 May 2024 18:34:33 +0200, Adam Skladowski wrote:
> This patch series provide support for display subsystem, gpu
> and also adds wireless connectivity subsystem support.
>
> Changes since v3
>
> 1. Minor styling fixes
> 2. Converted qcom,ipc into mailbox on wcnss patch
On 5/27/2024 4:43 PM, Bartosz Golaszewski wrote:
From: Tengfei Fan
Add nodes for remoteprocs: ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 for
SA8775p SoCs.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
On 5/27/2024 4:43 PM, Bartosz Golaszewski wrote:
From: Tengfei Fan
Add support for PIL loading on ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 on
SA8775p SoCs.
Signed-off-by: Tengfei Fan
Co-developed-by: Bartosz Golaszewski
Signed-off-by: Bartosz Golaszewski
---
On 5/27/2024 4:56 PM, Krzysztof Kozlowski wrote:
On 27/05/2024 10:43, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and
GPDSP1 on the SA8775p SoC.
Co-developed-by: Tengfei Fan
Missing SoB.
Signed-off-by:
On Mon, May 27, 2024 at 07:49:14PM GMT, Steven Rostedt wrote:
> On Mon, 27 May 2024 18:44:56 +0900
> Tatsuya S wrote:
>
> > On setting set_ftrace_pid, a extra entry generated by ftrace_pid_func()
> > is shown on stack trace(CONFIG_UNWINDER_FRAME_POINTER=y).
> >
> > [004] .
On Tue, 23 Apr 2024 16:23:38 +
Beau Belgrave wrote:
> The ABI documentation indicates that field separators do not need a
> space between them, only a ';'. When no spacing is used, the register
> must work. Any subsequent register, with or without spaces, must match
> and not return
On Mon, 27 May 2024 18:44:56 +0900
Tatsuya S wrote:
> On setting set_ftrace_pid, a extra entry generated by ftrace_pid_func()
> is shown on stack trace(CONFIG_UNWINDER_FRAME_POINTER=y).
>
> [004] .68.459382:
> => 0xa00090af
> => ksys_read
> => __x64_sys_read
> =>
RT hat on, I really don't like the above fix. The
> > rb_check_pages() iterates all subbuffers which makes the time interrupts
> > are disabled non-deterministic.
>
> I see, this applies also to the same rb_check_pages() validation invoked
> from ring_buffer_read_finish().
>
On Sun, 26 May 2024 19:10:57 +0900
"Masami Hiramatsu (Google)" wrote:
> Hi,
>
> Here is a series of some fixes/improvements for the test modules and boot
> time selftest of kprobe events. I found a WARNING message with some boot
> time selftest configuration, which came from the combination of
On Fri, 24 May 2024 12:50:08 +0200
"Linux regression tracking (Thorsten Leemhuis)"
wrote:
> > - Affected Versions: Before kernel version 6.8.10, the bug caused a
> > quick display of a kernel trace dump before the shutdown/reboot
> > completed. Starting from version 6.8.10 and continuing into
On Mon, 27 May 2024 20:14:42 +0200
Greg KH wrote:
> On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> > Hi Steven,
> >
> > I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> > panic inducing commit:
> >
> > 414fb08628143 (tracefs: Reset permissions on remount
On Mon, May 27, 2024 at 07:40:21PM +0300, Ilkka Naulapää wrote:
> Hi Steven,
>
> I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
> panic inducing commit:
>
> 414fb08628143 (tracefs: Reset permissions on remount if permissions are
> options)
>
> I reverted that commit to 6.9.2
Hello,
On Thu, 23 May 2024, Ismael Luceno wrote:
> In the context of the SCTP SNAT/DNAT handler, these calls can only
> return true.
>
> Ref: e10d3ba4d434 ("ipvs: Fix checksumming on GSO of SCTP packets")
checkpatch.pl prefers to see the "commit" word:
Ref: commit
On 05/23/24 11:45, Steven Rostedt wrote:
> On Wed, 15 May 2024 23:05:36 +0100
> Qais Yousef wrote:
> > diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> > index df3aca89d4f5..5cb88b748ad6 100644
> > --- a/include/linux/sched/deadline.h
> > +++
On 05/21/24 13:00, Sebastian Andrzej Siewior wrote:
> On 2024-05-15 23:05:36 [+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 includes RT and DL classes.
> >
>
On Fri, Mar 29, 2024 at 01:26:20PM GMT, Luca Weiss wrote:
> Type-C port management functionality lives inside of the PMIC block on
> pm7250b.
>
> The Type-C port management logic controls orientation detection,
> vbus/vconn sense and to send/receive Type-C Power Domain messages.
>
pm7250b is
Hi Steven,
I took some time and bisected the 6.8.9 - 6.8.10 and git gave the
panic inducing commit:
414fb08628143 (tracefs: Reset permissions on remount if permissions are options)
I reverted that commit to 6.9.2 and now it only serves the trace but
the panic is gone. But I can live with it.
On Mon, May 27, 2024 at 02:28:59PM +0200, Uwe Kleine-König wrote:
> On Mon, May 27, 2024 at 08:56:16AM +0100, Russell King (Oracle) wrote:
> > On Mon, May 27, 2024 at 09:43:41AM +0200, Thorsten Scherer wrote:
> > > Hello,
> > >
> > > in the context of a panic on an i.MX25 based v6.9 kernel [1]
On Mon, 27 May 2024 11:43:52 +0200
Carlos López wrote:
> btf_find_struct_member() might return NULL or an error via the
> ERR_PTR() macro. However, its caller in parse_btf_field() only checks
> for the NULL condition. Fix this by using IS_ERR() and returning the
> error up the stack.
>
Thanks
On Mon, May 27, 2024 at 08:56:16AM +0100, Russell King (Oracle) wrote:
> On Mon, May 27, 2024 at 09:43:41AM +0200, Thorsten Scherer wrote:
> > Hello,
> >
> > in the context of a panic on an i.MX25 based v6.9 kernel [1] Uwe pointed me
> > to
> > this thread. With the proposed code change applied
On Thu, 23 May 2024 at 01:48, Bjorn Andersson wrote:
>
> On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
> > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote:
> > >
> > > Dmitry Baryshkov writes:
> > >
> > > > On Tue, 21 May 2024 at 12:52, wrote:
> > > >>
> > > >> On 21/05/2024
eaders which can swap in a new reader page
>> then
>> + * the caller should take cpu_buffer->reader_lock.
>> */
>> static void rb_check_pages(struct ring_buffer_per_cpu *cpu_buffer)
>> {
>> @@ -2200,8 +2205,13 @@ int ring_buffer_resize(struct trace_buff
On Mon, May 27, 2024 at 10:43:52AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Enable all remoteproc nodes on the sa8775p-ride board and point to the
> appropriate firmware files.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm64/boot/dts/qcom/sa8775p-ride.dts |
On Mon, May 27, 2024 at 10:43:51AM +0200, Bartosz Golaszewski wrote:
> From: Tengfei Fan
>
> Add nodes for remoteprocs: ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 for
> SA8775p SoCs.
>
> Signed-off-by: Tengfei Fan
> Co-developed-by: Bartosz Golaszewski
> Signed-off-by: Bartosz Golaszewski
> ---
>
On Mon, May 27, 2024 at 10:43:50AM +0200, Bartosz Golaszewski wrote:
> From: Tengfei Fan
>
> Add support for PIL loading on ADSP, CDSP0, CDSP1, GPDSP0 and GPDSP1 on
> SA8775p SoCs.
>
> Signed-off-by: Tengfei Fan
> Co-developed-by: Bartosz Golaszewski
> Signed-off-by: Bartosz Golaszewski
>
On 27/05/2024 10:43, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Document the components used to boot the ADSP, CDSP0, CDSP1, GPDSP0 and
> GPDSP1 on the SA8775p SoC.
>
> Co-developed-by: Tengfei Fan
Missing SoB.
> Signed-off-by: Bartosz Golaszewski
...
> +
> +allOf:
> + -
On 5/27/24 4:52 오후, Michael S. Tsirkin wrote:
> On Mon, May 27, 2024 at 04:13:31PM +0900, ysk...@gmail.com wrote:
>> From: Yunseong Kim
>>
>> The virtio_device need to fail checking when create the geust/host pipe.
>
> typo
Thank you for code review Michael.
Sorry, there was a typo in my
On Mon, May 27, 2024 at 09:43:41AM +0200, Thorsten Scherer wrote:
> Hello,
>
> in the context of a panic on an i.MX25 based v6.9 kernel [1] Uwe pointed me to
> this thread. With the proposed code change applied the procedure
>
> # set to some known good (randomly guessed) filter function
On Mon, May 27, 2024 at 04:13:31PM +0900, ysk...@gmail.com wrote:
> From: Yunseong Kim
>
> The virtio_device need to fail checking when create the geust/host pipe.
typo
>
> Signed-off-by: Yunseong Kim
I guess ...
> ---
> tools/virtio/vringh_test.c | 4 ++--
> 1 file changed, 2
Hello,
in the context of a panic on an i.MX25 based v6.9 kernel [1] Uwe pointed me to
this thread. With the proposed code change applied the procedure
# set to some known good (randomly guessed) filter function and enable
function_graph
echo mtdblock_open > set_ftrace_filter
echo
On Mon, May 27, 2024 at 08:17:19AM GMT, Masami Hiramatsu wrote:
> On Sun, 26 May 2024 22:51:53 +0800
> kernel test robot wrote:
>
> > Hi Tatsuya,
> >
> > kernel test robot noticed the following build warnings:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on
On Mon, 27 May 2024 09:37:47 +0900
Masami Hiramatsu (Google) wrote:
> > The diff between this and Masami's last update is at the end of this email.
> >
>
> Thanks for update the patches!
> I think your changes are good. I just have some comments and replied.
> So, the plan is to push this
On Mon, 27 May 2024 09:34:36 +0900
Masami Hiramatsu (Google) wrote:
> > @@ -110,11 +253,13 @@ void ftrace_graph_stop(void)
> > /* Add a function return address to the trace stack on thread info.*/
> > static int
> > ftrace_push_return_trace(unsigned long ret, unsigned long func,
> > -
On Fri, 24 May 2024 22:36:52 -0400
Steven Rostedt wrote:
> [
> Resend for some of you as I missed a comma in the Cc and
> quilt died sending this out.
> ]
>
> This is a continuation of the function graph multi user code.
> I wrote a proof of concept back in 2019 of this code[1] and
> Masami
On Fri, 24 May 2024 22:36:56 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Allow for multiple users to attach to function graph tracer at the same
> time. Only 16 simultaneous users can attach to the tracer. This is because
> there's an array that stores the pointers to the
On Mon, 27 May 2024 09:09:49 +0900
Masami Hiramatsu (Google) wrote:
> > Note, we do not care about races. If a bit is set before the gops is
> > assigned, it only wastes time looking at the element and ignoring it (as
> > it did before this bitmask is added).
>
> This is OK because anyway we
On Mon, 27 May 2024 09:04:34 +0900
Masami Hiramatsu (Google) wrote:
> > bitmap = get_bitmap_bits(current, offset);
> > - for (i = 0; i < FGRAPH_ARRAY_SIZE; i++) {
> > +
> > + for_each_set_bit(i, , sizeof(bitmap) * BITS_PER_BYTE) {
> > struct fgraph_ops *gops =
On Fri, 24 May 2024 22:37:12 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of looping through all the elements of fgraph_array[] to see if
> there's an gops attached to one and then calling its gops->func(). Create
> a fgraph_array_bitmask that sets bits when an
On Fri, 24 May 2024 22:37:11 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of iterating through the entire fgraph_array[] and seeing if one
> of the bitmap bits are set to know to call the array's retfunc() function,
> use for_each_set_bit() on the bitmap itself.
On Fri, 24 May 2024 22:37:11 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of iterating through the entire fgraph_array[] and seeing if one
> of the bitmap bits are set to know to call the array's retfunc() function,
> use for_each_set_bit() on the bitmap itself.
On Sun, 26 May 2024 22:51:53 +0800
kernel test robot wrote:
> Hi Tatsuya,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on rostedt-trace/for-next v6.9 next-20240523]
> [cannot apply to
On Sun, 26 May 2024 14:27:56 +0200
Carlos López wrote:
>
> Hi,
>
> On 26/5/24 12:17, Masami Hiramatsu (Google) wrote:
> > On Sat, 25 May 2024 20:21:32 +0200
> > Carlos López wrote:
> >
> >> btf_find_struct_member() might return NULL or an error via the
> >> ERR_PTR() macro. However, its
Hi Tatsuya,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on rostedt-trace/for-next v6.9 next-20240523]
[cannot apply to rostedt-trace/for-next-urgent]
[If your patch is applied to the wrong git tree, kindly drop us a
Hi,
On 26/5/24 12:17, Masami Hiramatsu (Google) wrote:
On Sat, 25 May 2024 20:21:32 +0200
Carlos López wrote:
btf_find_struct_member() might return NULL or an error via the
ERR_PTR() macro. However, its caller in parse_btf_field() only checks
for the NULL condition. Fix this by using
On Sat, 25 May 2024 20:21:32 +0200
Carlos López wrote:
> btf_find_struct_member() might return NULL or an error via the
> ERR_PTR() macro. However, its caller in parse_btf_field() only checks
> for the NULL condition. Fix this by using IS_ERR() and returning the
> error up the stack.
>
Thanks
1 - 100 of 2410341 matches
Mail list logo
