[PATCH] evh_bytechan: fix out of bounds accesses

[Stephen Rothwell]

Hi Laurentiu,

On Tue, 25 Feb 2020 11:54:17 +0200 Laurentiu Tudor <laurentiu.tudor at nxp.com> wrote:
>
> On 21.02.2020 01:57, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell <sfr at canb.auug.org.au> wrote:  
> >>
> >> On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood <swood at redhat.com> wrote:  
> >>>
> >>> On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:  
> >>>>
> >>>> On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi <timur at kernel.org> wrote:  
> >>>>> On 1/14/20 12:31 AM, Stephen Rothwell wrote:  
> >>>>>> +/**
> >>>>>> + * ev_byte_channel_send - send characters to a byte stream
> >>>>>> + * @handle: byte stream handle
> >>>>>> + * @count: (input) num of chars to send, (output) num chars sent
> >>>>>> + * @bp: pointer to chars to send
> >>>>>> + *
> >>>>>> + * Returns 0 for success, or an error code.
> >>>>>> + */
> >>>>>> +static unsigned int ev_byte_channel_send(unsigned int handle,
> >>>>>> +	unsigned int *count, const char *bp)  
> >>>>>
> >>>>> Well, now you've moved this into the .c file and it is no longer
> >>>>> available to other callers.  Anything wrong with keeping it in the .h
> >>>>> file?  
> >>>>
> >>>> There are currently no other callers - are there likely to be in the
> >>>> future?  Even if there are, is it time critical enough that it needs to
> >>>> be inlined everywhere?  
> >>>
> >>> It's not performance critical and there aren't likely to be other users --
> >>> just a matter of what's cleaner.  FWIW I'd rather see the original patch,
> >>> that keeps the raw asm hcall stuff as simple wrappers in one place.  
> >>
> >> And I don't mind either way :-)
> >>
> >> I just want to get rid of the warnings.  
> > 
> > Any progress with this?
> 
> I think that the consensus was to pick up the original patch that is, 
> this one: https://patchwork.ozlabs.org/patch/1220186/
> 
> I've tested it too, so please feel free to add a:
> 
> Tested-by: Laurentiu Tudor <laurentiu.tudor at nxp.com>

So, whose tree should his go via?

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20200226/7543b5c5/attachment.sig>