On 04/22/16 20:52, Matt Fleming wrote:
> On Thu, 21 Apr, at 06:21:11PM, Laszlo Ersek wrote:
>>
>> ... How about this instead?
>
> Your patch looks fine to me. I've gone ahead and stuck it in the
> urgent EFI queue.
I intended to probe for opinions first, and then (if appropriate) submit
the patch
On Thu, 21 Apr, at 06:21:11PM, Laszlo Ersek wrote:
>
> ... How about this instead?
Your patch looks fine to me. I've gone ahead and stuck it in the
urgent EFI queue.
Thanks everyone!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://li
On 21/04/16 16:13, Peter Jones wrote:
On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote:
( Good Lord, I hate doing string manipulation in C )
(yep)
On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
So, "len" does not include the room for the terminating NUL-byte here.
When "le
( Good Lord, I hate doing string manipulation in C )
On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
>
> So, "len" does not include the room for the terminating NUL-byte here.
> When "len" is passed to ucs2_as_utf8(), with the proposed patch applied,
> a NUL byte will be produced in "name", bu
On 04/21/16 14:18, Matt Fleming wrote:
> ( Good Lord, I hate doing string manipulation in C )
>
> On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
>>
>> So, "len" does not include the room for the terminating NUL-byte here.
>> When "len" is passed to ucs2_as_utf8(), with the proposed patch appli
On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote:
> ( Good Lord, I hate doing string manipulation in C )
(yep)
>
> On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote:
> >
> > So, "len" does not include the room for the terminating NUL-byte here.
> > When "len" is passed to ucs2_as_ut
On Wed, 20 Apr 2016, Chris Wilson wrote:
> If the caller, in this case efivarfs_callback(), only provides sufficent
> room for the expanded utf8 and not enough to include the terminating NUL
> byte, that NUL byte is skipped. When the caller then interprets it as a
> string, it may then read from p
On 04/20/16 10:37, Chris Wilson wrote:
> If the caller, in this case efivarfs_callback(), only provides sufficent
> room for the expanded utf8 and not enough to include the terminating NUL
> byte, that NUL byte is skipped. When the caller then interprets it as a
> string, it may then read from past
On 04/20/16 11:41, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 11:36:37AM +0200, Laszlo Ersek wrote:
>> On 04/20/16 10:37, Chris Wilson wrote:
>>> If the caller, in this case efivarfs_callback(), only provides sufficent
>>> room for the expanded utf8 and not enough to include the terminating NUL
On Wed, Apr 20, 2016 at 11:36:37AM +0200, Laszlo Ersek wrote:
> On 04/20/16 10:37, Chris Wilson wrote:
> > If the caller, in this case efivarfs_callback(), only provides sufficent
> > room for the expanded utf8 and not enough to include the terminating NUL
> > byte, that NUL byte is skipped.
>
> H
On 04/20/16 10:37, Chris Wilson wrote:
> If the caller, in this case efivarfs_callback(), only provides sufficent
> room for the expanded utf8 and not enough to include the terminating NUL
> byte, that NUL byte is skipped.
How does that occur? In efivarfs_callback() [fs/efivarfs/super.c], we have
If the caller, in this case efivarfs_callback(), only provides sufficent
room for the expanded utf8 and not enough to include the terminating NUL
byte, that NUL byte is skipped. When the caller then interprets it as a
string, it may then read from past its allocated memory:
[ 170.605647] WARNING:
12 matches
Mail list logo