asmad...@codewreck.org wrote on Sat, Dec 02, 2023 at 01:35:18PM +0900:
> > diff --git a/include/trace/events/9p.h b/include/trace/events/9p.h
> > index 4dfa6d7f83ba..8690a7086252 100644
> > --- a/include/trace/events/9p.h
> > +++ b/include/trace/events/9p.h
> > @@ -185,7 +185,8 @@
On Fri, 1 Dec 2023 at 23:59, Justin Chen wrote:
>
>
>
> On 12/1/23 10:07 AM, Steven Rostedt wrote:
> > On Fri, 1 Dec 2023 09:25:59 -0800
> > Justin Chen wrote:
> >
> >>> It appears the sub instruction at 0x6dd0 correctly accounts for the
> >>> extra 8 bytes, so the frame pointer is valid. So it
JP Kobryn wrote on Fri, Dec 01, 2023 at 07:04:10PM -0800:
> An out of bounds read can occur within the tracepoint 9p_protocol_dump().
> In the fast assign, there is a memcpy that uses a constant size of 32
> (macro definition as P9_PROTO_DUMP_SZ). When the copy is invoked, the
> source buffer is
An out of bounds read can occur within the tracepoint 9p_protocol_dump().
In the fast assign, there is a memcpy that uses a constant size of 32
(macro definition as P9_PROTO_DUMP_SZ). When the copy is invoked, the
source buffer is not guaranteed match this size. It was found that in some
cases the
On 12/1/23 10:07 AM, Steven Rostedt wrote:
On Fri, 1 Dec 2023 09:25:59 -0800
Justin Chen wrote:
It appears the sub instruction at 0x6dd0 correctly accounts for the
extra 8 bytes, so the frame pointer is valid. So it is our assumption
that there are no gaps between the stack frames is
On Fri, Dec 01, 2023 at 09:43:34AM -0800, Kees Cook wrote:
> On Mon, 20 Nov 2023 17:11:41 +0200, Andy Shevchenko wrote:
> > A couple of patches are for get the string ops, used in the module,
> > slightly harden. On top a few cleanups.
> >
> > Since the main part is rather hardening, I think the
On Fri, Dec 01, 2023 at 10:12:48AM +0100, Ard Biesheuvel wrote:
> It appears the sub instruction at 0x6dd0 correctly accounts for the
> extra 8 bytes, so the frame pointer is valid. So it is our assumption
> that there are no gaps between the stack frames is invalid.
>
> Could you try the
On 11/29/23 11:10 AM, Mathieu Poirier wrote:
> On Mon, Nov 27, 2023 at 10:33:05AM -0600, Tanmay Shah wrote:
> >
> > On 11/23/23 12:11 PM, Mathieu Poirier wrote:
> > > On Wed, Nov 22, 2023 at 03:00:36PM -0600, Tanmay Shah wrote:
> > > > Hi Mathieu,
> > > >
> > > > Please find my comments below.
On Fri, 1 Dec 2023 09:25:59 -0800
Justin Chen wrote:
> > It appears the sub instruction at 0x6dd0 correctly accounts for the
> > extra 8 bytes, so the frame pointer is valid. So it is our assumption
> > that there are no gaps between the stack frames is invalid.
>
> Thanks for the assistance.
On Mon, 20 Nov 2023 17:11:41 +0200, Andy Shevchenko wrote:
> A couple of patches are for get the string ops, used in the module,
> slightly harden. On top a few cleanups.
>
> Since the main part is rather hardening, I think the Kees' tree is
> the best fit for the series. It also possible to
On 12/1/2023 1:12 AM, Ard Biesheuvel wrote:
On Fri, 1 Dec 2023 at 00:48, Justin Chen wrote:
Hello,
Ran into an odd bug that I am unsure what the solution is. Tested a few
kernels versions and they all fail the same.
FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
On Fri, 1 Dec 2023 10:01:33 -0700
Jeffrey Hugo wrote:
> > +DECLARE_EVENT_CLASS(mhi_process_event_ring,
> > +
> > + TP_PROTO(const char *name, void *rp, __le64 ptr,
> > +__le32 dword0, __le32 dword1),
> > +
> > + TP_ARGS(name, rp, ptr, dword0, dword1),
> > +
> > +
On 11/27/2023 4:09 AM, Krishna chaitanya chundru wrote:
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2.
On Mon, Nov 20, 2023 at 05:11:41PM +0200, Andy Shevchenko wrote:
> A couple of patches are for get the string ops, used in the module,
> slightly harden. On top a few cleanups.
>
> Since the main part is rather hardening, I think the Kees' tree is
> the best fit for the series. It also possible
On 12/01, Eugenio Perez Martin wrote:
> On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
> >
> > Add a bitmask variable that tracks hw vq field changes that
> > are supposed to be modified on next hw vq change command.
> >
> > This will be useful to set multiple vq fields when resuming the
On Fri, Dec 1, 2023 at 11:50 AM Dragos Tatulea wrote:
>
> .set_vq_state will set the indices and mark the fields to be modified in
> the hw vq.
>
> Signed-off-by: Dragos Tatulea
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
>
On Fri, Dec 1, 2023 at 11:50 AM Dragos Tatulea wrote:
>
> Implement vdpa vq and device resume if capability detected. Add support
> for suspend -> ready state change.
>
> Signed-off-by: Dragos Tatulea
Acked-by: Eugenio Pérez
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 67
On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
>
> Add a bitmask variable that tracks hw vq field changes that
> are supposed to be modified on next hw vq change command.
>
> This will be useful to set multiple vq fields when resuming the vq.
>
> The state needs to remain as a parameter as
On Fri, 1 Dec 2023 15:17:35 +0100
Petr Pavlu wrote:
> Ok, keeping the current approach, my plan for v2 is to prepare the
> following patches:
>
> * Fix for the missing increment+decrement of trace_buffered_event_cnt
> on the current CPU in trace_buffered_event_disable().
>
> Replace
On 11/29/23 15:58, Steven Rostedt wrote:
> On Wed, 29 Nov 2023 10:22:23 +0100
> Petr Pavlu wrote:
>
>> Yes, I believe this should address this potential race condition.
>>
>> An alternative would be instead to update
>> trace_event_buffer_lock_reserve() as follows:
>>
>> if
When draining a page_frag_cache, most user are doing
the similar steps, so introduce an API to avoid code
duplication.
Signed-off-by: Yunsheng Lin
---
drivers/net/ethernet/google/gve/gve_main.c | 11 ++-
drivers/net/ethernet/mediatek/mtk_wed_wo.c | 17 ++---
introduce vhost_net_test basing on virtio_test to test
vhost_net changing in the kernel.
Signed-off-by: Yunsheng Lin
---
tools/virtio/Makefile | 8 +-
tools/virtio/vhost_net_test.c | 441 ++
2 files changed, 446 insertions(+), 3 deletions(-)
create
The page frag in vhost_net_page_frag_refill() uses the
'struct page_frag' from skb_page_frag_refill(), but it's
implementation is similar to page_frag_alloc_align() now.
This patch removes vhost_net_page_frag_refill() by using
'struct page_frag_cache' instead of 'struct page_frag',
and allocating
Currently there seems to be three page frag implementions
which all try to allocate order 3 page, if that fails, it
then fail back to allocate order 0 page, and each of them
all allow order 3 page allocation to fail under certain
condition by using specific gfp bits.
The gfp bits for order 3 page
On Fri, Dec 1, 2023 at 11:49 AM Dragos Tatulea wrote:
>
> mlx5_vdpa_destroy_mr contains more logic than _mlx5_vdpa_destroy_mr.
> There is no reason for this to be the case. All the logic can go into
> the unlocked variant.
>
> Using the unlocked version is needed in a follow-up patch. And it also
Fifo head and tail index can be modified with wrong values from
untrusted remote procs. Glink smem is not validating these index
before using to read or write fifo. This can result in out of
bound memory access if head and tail have incorrect values.
Add check for validation of head and tail
Instead of tearing down and setting up vq resources, use vq
suspend/resume during .set_map to speed things up a bit.
The vq mr is updated with the new mapping while the vqs are suspended.
If the device doesn't support resumable vqs, do the old teardown and
setup dance.
Signed-off-by: Dragos
.set_vq_state will set the indices and mark the fields to be modified in
the hw vq.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
include/linux/mlx5/mlx5_ifc_vdpa.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
Addresses get set by .set_vq_address. hw vq addresses will be updated on
next modify_virtqueue.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 9 +
include/linux/mlx5/mlx5_ifc_vdpa.h | 1 +
2 files changed, 10 insertions(+)
diff --git
Implement vdpa vq and device resume if capability detected. Add support
for suspend -> ready state change.
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 67 +++
1 file changed, 60 insertions(+), 7 deletions(-)
diff --git
Add a bitmask variable that tracks hw vq field changes that
are supposed to be modified on next hw vq change command.
This will be useful to set multiple vq fields when resuming the vq.
The state needs to remain as a parameter as it doesn't make sense to
make it part of the vq struct: fw_state
mlx5_vdpa_destroy_mr contains more logic than _mlx5_vdpa_destroy_mr.
There is no reason for this to be the case. All the logic can go into
the unlocked variant.
Using the unlocked version is needed in a follow-up patch. And it also
makes it more consistent with mlx5_vdpa_create_mr.
Necessary for checking if resumable vqs are supported by the hardware.
Actual support will be added in a downstream patch.
Signed-off-by: Dragos Tatulea
---
include/linux/mlx5/mlx5_ifc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h
Add support for resumable vqs in the driver. This is a firmware feature
that can be used for the following benefits:
- Full device .suspend/.resume.
- .set_map doesn't need to destroy and create new vqs anymore just to
update the map. When resumable vqs are supported it is enough to
suspend
On 01.12.2023 12:48, Stefano Garzarella wrote:
> On Fri, Dec 01, 2023 at 11:35:56AM +0300, Arseniy Krasnov wrote:
>>
>>
>> On 01.12.2023 11:27, Stefano Garzarella wrote:
>>> On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100,
On Fri, Dec 01, 2023 at 11:35:56AM +0300, Arseniy Krasnov wrote:
On 01.12.2023 11:27, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 08:58:58AM -0500,
Enable the venus node so that the video encoder/decoder will start
working.
Reviewed-by: Konrad Dybcio
Reviewed-by: Bryan O'Donoghue
Reviewed-by: Vikash Garodia
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff
If the video-firmware node is present, the venus driver assumes we're on
a system that doesn't use TZ for starting venus, like on ChromeOS
devices.
Move the video-firmware node to chrome-common.dtsi so we can use venus
on a non-ChromeOS devices. We also need to move the secure SID 0x2184
for
Not all SC7280 devices ship with ChromeOS firmware. Other devices need
PAS for image authentication. That requires the predefined virtual
address ranges to be passed via scm calls. Define them to enable Venus
on non-CrOS SC7280 devices.
Reviewed-by: Konrad Dybcio
Reviewed-by: Bryan O'Donoghue
Devices with Qualcomm firmware (compared to ChromeOS firmware) need some
changes in the venus driver and dts layout so that venus can initialize.
Do these changes, similar to sc7180.
Signed-off-by: Luca Weiss
---
Changes in v3:
- Move 0x2184 iommu from sc7280.dtsi to sc7280-chrome-common.dtsi
On Tue Nov 28, 2023 at 9:14 AM CET, Vikash Garodia wrote:
>
> On 11/24/2023 9:26 PM, Luca Weiss wrote:
> > On Fri Nov 24, 2023 at 2:35 PM CET, Vikash Garodia wrote:
> >>
> >>
> >> On 11/24/2023 6:23 PM, Dmitry Baryshkov wrote:
> >>> On Fri, 24 Nov 2023 at 14:30, Vikash Garodia
> >>> wrote:
>
On Fri, 1 Dec 2023 at 00:48, Justin Chen wrote:
>
> Hello,
>
> Ran into an odd bug that I am unsure what the solution is. Tested a few
> kernels versions and they all fail the same.
>
> FUNCTION_GRAPH_FP_TEST was enabled with 953f534a7ed6 ("ARM: ftrace:
> enable HAVE_FUNCTION_GRAPH_FP_TEST").
On 01.12.2023 11:27, Stefano Garzarella wrote:
> On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
>> On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
>>> On Thu, Nov 30, 2023 at 08:58:58AM -0500, Michael S. Tsirkin wrote:
>>> > On Thu, Nov 30, 2023 at
On Thu, Nov 30, 2023 at 12:40:43PM -0500, Michael S. Tsirkin wrote:
On Thu, Nov 30, 2023 at 03:11:19PM +0100, Stefano Garzarella wrote:
On Thu, Nov 30, 2023 at 08:58:58AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 30, 2023 at 04:43:34PM +0300, Arseniy Krasnov wrote:
> >
> >
> > On
44 matches
Mail list logo
