On Wed, Dec 18, 2024 at 03:54:28PM +0530, Ekansh Gupta wrote:
> For registered buffers, fastrpc driver sends the buffer information
> to remote subsystem. There is a problem with current implementation
> where the page address is being sent with an offset leading to
> improper buffer address on DSP. This is leads to functional failures
> as DSP expects base address in page information and extracts offset
> information from remote arguments. Mask the offset and pass the base
> page address to DSP.
>
> Fixes: 80f3afd72bd4 ("misc: fastrpc: consider address offset before sending to DSP")
This was committed in 2019. Are you saying that the driver has been
broken since that time? If so, what is the impact? Because I've
definitely been running fastrpc workload after that moment.
Also, is there any reason for neglecting checkpatch warning?
> Cc: stable <stable@xxxxxxxxxx>
> Signed-off-by: Ekansh Gupta <quic_ekangupt@xxxxxxxxxxx>
> ---
> drivers/misc/fastrpc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index 48d08eeb2d20..cfa1546c9e3f 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -992,7 +992,7 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
> mmap_read_lock(current->mm);
> vma = find_vma(current->mm, ctx->args[i].ptr);
> if (vma)
> - pages[i].addr += ctx->args[i].ptr -
> + pages[i].addr += (ctx->args[i].ptr & PAGE_MASK) -
> vma->vm_start;
> mmap_read_unlock(current->mm);
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
