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
>>
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 +--
> > net/v
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
>
> -stati
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 !PREEMP
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
> > +++ b/include/linux/sche
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 P
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
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 reade
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 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 e
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 c
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:
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)" wrote
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 sufficie
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 i
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 c
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.
>
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 fo
This patch synchronize operstate with admin state per RFC2863.
This is done by trying to toggle the carrier upon open/close and
synchronize with the config change work. This allows propagate status
correctly to stacked devices like:
ip link add link enp0s3 macvlan0 type macvlan
ip link set link e
On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices l
20 matches
Mail list logo
