On Thu, 2020-01-09 at 07:39:12 UTC, Stephen Rothwell wrote:
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure w
On 25.02.2020 22:56, Stephen Rothwell wrote:
Hi Laurentiu,
On Tue, 25 Feb 2020 11:54:17 +0200 Laurentiu Tudor
wrote:
On 21.02.2020 01:57, Stephen Rothwell wrote:
On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell
wrote:
On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote:
On Thu
Hi Laurentiu,
On Tue, 25 Feb 2020 11:54:17 +0200 Laurentiu Tudor
wrote:
>
> On 21.02.2020 01:57, Stephen Rothwell wrote:
> >
> > On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell
> > wrote:
> >>
> >> On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote:
> >>>
> >>> On Thu, 2020-01-16 at
On 21.02.2020 01:57, Stephen Rothwell wrote:
Hi all,
On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell
wrote:
On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote:
On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:
Hi Timur,
On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi wro
Hi all,
On Thu, 16 Jan 2020 11:37:14 +1100 Stephen Rothwell
wrote:
>
> On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote:
> >
> > On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:
> > > Hi Timur,
> > >
> > > On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi wrote:
> > >
> > > >
On 1/15/20 2:01 PM, Scott Wood wrote:
FWIW I'd rather see the original patch,
that keeps the raw asm hcall stuff as simple wrappers in one place.
I can live with that.
Hi Scott,
On Wed, 15 Jan 2020 14:01:35 -0600 Scott Wood wrote:
>
> On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:
> > Hi Timur,
> >
> > On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi wrote:
> > > On 1/14/20 12:31 AM, Stephen Rothwell wrote:
> > > > +/**
> > > > + * ev_byte_channe
On Thu, 2020-01-16 at 06:42 +1100, Stephen Rothwell wrote:
> Hi Timur,
>
> On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi 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
> > >
Hi Timur,
On Wed, 15 Jan 2020 07:25:45 -0600 Timur Tabi 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
> > +
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.
+ */
+
erPC Mailing
> List ; sw...@redhat.com
> Subject: Re: [PATCH] evh_bytechan: fix out of bounds accesses
>
> Hi Timur,
>
> On Mon, 13 Jan 2020 19:10:11 -0600 Timur Tabi wrote:
> >
> > On 1/13/20 2:25 PM, Stephen Rothwell wrote:
> > > The problem is not really
On Tue, Jan 14, 2020 at 05:53:41AM -0600, Timur Tabi wrote:
> On 1/14/20 2:29 AM, Segher Boessenkool wrote:
> >You have no working lswx I suppose?:-)
>
> I don't know if the P4080 supports lswx, but it does, than that would be
> an elegant way to fix this bug.
No e500 version supports it. Many
On 1/14/20 2:29 AM, Segher Boessenkool wrote:
You have no working lswx I suppose?:-)
I don't know if the P4080 supports lswx, but it does, than that would be
an elegant way to fix this bug.
On 1/14/20 3:18 AM, Laurentiu Tudor wrote:
I can offer myself. I'll send a MAINTAINERS patch if nobody is against it.
Yes, please do. I'm always available if you have any questions on the code.
On 14.01.2020 03:10, Michael Ellerman wrote:
> Laurentiu Tudor writes:
>> Hello,
>>
>> On 13.01.2020 15:48, Timur Tabi wrote:
>>> On 1/13/20 6:26 AM, Michael Ellerman wrote:
I've never heard of it, and I have no idea how to test it.
It's not used by qemu, I guess there is/was a Free
On Mon, Jan 13, 2020 at 07:10:11PM -0600, Timur Tabi wrote:
> Ah, I see now. This is all coming back to me.
>
> I would prefer that ev_byte_channel_send() is updated to access only
> 'count' bytes. If that means adding a memcpy to the
> ev_byte_channel_send() itself, then so be it. Trying to
Hi Timur,
On Mon, 13 Jan 2020 19:10:11 -0600 Timur Tabi wrote:
>
> On 1/13/20 2:25 PM, Stephen Rothwell wrote:
> > The problem is not really the declaration, the problem is that
> > ev_byte_channel_send always accesses 16 bytes from the buffer and it is
> > not always passed a buffer that long (i
On Mon, 2020-01-13 at 19:13 -0600, Timur Tabi wrote:
> On 1/13/20 7:10 PM, Timur Tabi wrote:
> > I would prefer that ev_byte_channel_send() is updated to access only
> > 'count' bytes. If that means adding a memcpy to the
> > ev_byte_channel_send() itself, then so be it. Trying to figure out ho
On 1/13/20 7:10 PM, Timur Tabi wrote:
I would prefer that ev_byte_channel_send() is updated to access only
'count' bytes. If that means adding a memcpy to the
ev_byte_channel_send() itself, then so be it. Trying to figure out how
to stuff n bytes into 4 32-bit registers is probably not wort
Laurentiu Tudor writes:
> Hello,
>
> On 13.01.2020 15:48, Timur Tabi wrote:
>> On 1/13/20 6:26 AM, Michael Ellerman wrote:
>>> I've never heard of it, and I have no idea how to test it.
>>>
>>> It's not used by qemu, I guess there is/was a Freescale hypervisor that
>>> used it.
>>
>> Yes, there i
On 1/13/20 2:25 PM, Stephen Rothwell wrote:
The problem is not really the declaration, the problem is that
ev_byte_channel_send always accesses 16 bytes from the buffer and it is
not always passed a buffer that long (in one case it is passed a
pointer to a single byte). So the alternative to the
Hi Timur,
On Mon, 13 Jan 2020 10:03:18 -0600 Timur Tabi wrote:
>
> Why not simply correct the parameters of ev_byte_channel_send?
>
> static inline unsigned int ev_byte_channel_send(unsigned int handle,
> -unsigned int *count, const char buffer[EV_BYTE_CHANNEL_MAX_BYTES])
> +unsigned int *count,
On Thu, Jan 9, 2020 at 1:41 AM Stephen Rothwell wrote:
>
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure we
On 1/13/20 8:34 AM, Laurentiu Tudor wrote:
There are a few users that I know of, but I can't tell if that's enough
to justify keeping the driver.
[1]https://source.codeaurora.org/external/qoriq/qoriq-yocto-sdk/hypervisor/
IIRC, the driver is the only reasonable way to get a serial console from
Hello,
On 13.01.2020 15:48, Timur Tabi wrote:
> On 1/13/20 6:26 AM, Michael Ellerman wrote:
>> I've never heard of it, and I have no idea how to test it.
>>
>> It's not used by qemu, I guess there is/was a Freescale hypervisor that
>> used it.
>
> Yes, there is/was a Freescale hypervisor that I a
On 1/13/20 6:26 AM, Michael Ellerman wrote:
I've never heard of it, and I have no idea how to test it.
It's not used by qemu, I guess there is/was a Freescale hypervisor that
used it.
Yes, there is/was a Freescale hypervisor that I and a few others worked
on. I've added a couple people on CC
Stephen Rothwell writes:
> ev_byte_channel_send() assumes that its third argument is a 16 byte array.
> Some places where it is called it may not be (or we can't easily tell
> if it is). Newer compilers have started producing warnings about this,
> so make sure we actually pass a 16 byte array.
>
ev_byte_channel_send() assumes that its third argument is a 16 byte array.
Some places where it is called it may not be (or we can't easily tell
if it is). Newer compilers have started producing warnings about this,
so make sure we actually pass a 16 byte array.
There may be more elegant solution
28 matches
Mail list logo
