From: Greg KH <gregkh@linuxfoundation.org>
To: jeyr@codeaurora.org
Cc: linux-arm-msm@vger.kernel.org, srinivas.kandagatla@linaro.org,
linux-kernel@vger.kernel.org, fastrpc.upstream@qti.qualcomm.com
Subject: Re: [PATCH v3] misc: fastrpc: fix improper packet size calculation
Date: Fri, 19 Nov 2021 13:53:44 +0100 [thread overview]
Message-ID: <YZeeWMGFev2D+4zr@kroah.com> (raw)
In-Reply-To: <56123f5e39e4cc7691da5d0d61468a97@codeaurora.org>
On Fri, Nov 19, 2021 at 06:19:27PM +0530, jeyr@codeaurora.org wrote:
> On 2021-09-21 18:43, jeyr@codeaurora.org wrote:
> > On 2021-09-21 18:10, Greg KH wrote:
> > > On Tue, Sep 21, 2021 at 06:03:42PM +0530, jeyr@codeaurora.org wrote:
> > > > On 2021-09-21 17:22, Greg KH wrote:
> > > > > On Tue, Sep 21, 2021 at 05:18:15PM +0530, Jeya R wrote:
> > > > > > The buffer list is sorted and this is not being considered while
> > > > > > calculating packet size. This would lead to improper copy length
> > > > > > calculation for non-dmaheap buffers which would eventually cause
> > > > > > sending improper buffers to DSP.
> > > > > >
> > > > > > Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke
> > > > > > method")
> > > > > > Signed-off-by: Jeya R <jeyr@codeaurora.org>
> > > > > > Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > > > >
> > > > > Does this also need to go to the stable kernels?
> > > > Yes, this needs to go to stable kernels also as this fixes a
> > > > potential issue
> > > > which is easily reproducible.
> > >
> > >
> > >
> > > >
> > > > >
> > > > > > ---
> > > > > > Changes in v3:
> > > > > > - relocate patch change list
> > > > > >
> > > > > > Changes in v2:
> > > > > > - updated commit message to proper format
> > > > > > - added fixes tag to commit message
> > > > > > - removed unnecessary variable initialization
> > > > > > - removed length check during payload calculation
> > > > > >
> > > > > > drivers/misc/fastrpc.c | 10 ++++++----
> > > > > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> > > > > > index beda610..69d45c4 100644
> > > > > > --- a/drivers/misc/fastrpc.c
> > > > > > +++ b/drivers/misc/fastrpc.c
> > > > > > @@ -719,16 +719,18 @@ static int fastrpc_get_meta_size(struct
> > > > > > fastrpc_invoke_ctx *ctx)
> > > > > > static u64 fastrpc_get_payload_size(struct fastrpc_invoke_ctx *ctx,
> > > > > > int metalen)
> > > > > > {
> > > > > > u64 size = 0;
> > > > > > - int i;
> > > > > > + int oix;
> > > > >
> > > > > What does "oix" stand for? What was wrong with i?
> > > > It is just a general convention we use. "oix" is used to iterate
> > > > through
> > > > sorted overlap buffer list and use "i" to get corresponding
> > > > unsorted list
> > > > index. We follow the same convention at other places also, for
> > > > example:
> > > > fastrpc_get_args function.
> > >
> > > That is the only place it is used in all of the whole kernel tree. It
> > > is not a normal variable for a loop, so who is "we" here?
> > The convention was followed for the same file(fastrpc.c). As part of
> > fastrpc_get_args
> > function, while iterating through sorted buffer list, oix is used as
> > index and to
> > get unsorted index "raix", it is using "i". Just following the same way
> > here to
> > have better understanding. Please let me know if this is a concern, it
> > can be updated
> > to "i", "j" etc.
> >
> > -- Thanks
> > >
> > > thanks,
> > >
> > > greg k-h
> Hello Greg,
>
> Is this bug-fix patch planned to be released?
Released in what way?
I do not see it in any tree anywhere, perhaps it needs to be resubmitted
to be accepted?
thanks,
greg k-h
next prev parent reply other threads:[~2021-11-19 12:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 11:48 [PATCH v3] misc: fastrpc: fix improper packet size calculation Jeya R
2021-09-21 11:52 ` Greg KH
2021-09-21 12:33 ` jeyr
2021-09-21 12:40 ` Greg KH
2021-09-21 13:13 ` jeyr
2021-11-19 12:49 ` jeyr
2021-11-19 12:53 ` Greg KH [this message]
2021-11-23 6:12 ` jeyr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZeeWMGFev2D+4zr@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=fastrpc.upstream@qti.qualcomm.com \
--cc=jeyr@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srinivas.kandagatla@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).