Linus Torvalds wrote:
> array (or the overflow[] one) is actually used. But I assume you've
> tested this.
>
> Do you want me to apply the patch as-is, or will I be getting a pull
> request with this (and the number-of-slots calculation thing you
> mention in the commit message)?
I can give you
On Mon, Jan 4, 2021 at 4:32 AM David Howells wrote:
>
> How about the attached, then? I
That looks like the right thing, but I didn't check how the name[]
array (or the overflow[] one) is actually used. But I assume you've
tested this.
Do you want me to apply the patch as-is, or will I be getti
Linus Torvalds wrote:
> I htink the right fix would be to try to create a type that actually
> describes that.
How about the attached, then? It's basically what you suggested.
I realised whilst doing this that I'm not quite getting the extended-name
handling correct, but I'll deal with that in
Hi David,
> CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
> attached patch for an explanation). Is replacing the use with memchr() the
> right approach? Or should I be calling __real_strnlen() or whatever it's
> called?
You certainly shouldn't be calling __real_strnlen
On Mon, Dec 21, 2020 at 8:14 AM David Howells wrote:
>
> CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
> attached patch for an explanation). Is replacing the use with memchr() the
> right approach? Or should I be calling __real_strnlen() or whatever it's
> called?
Ugh.
[cc'ing mailing lists]
Hi Daniel,
CONFIG_FORTIFIED_SOURCE=y now causes an oops in strnlen() from afs (see
attached patch for an explanation). Is replacing the use with memchr() the
right approach? Or should I be calling __real_strnlen() or whatever it's
called?
David
---
From: David Howells
6 matches
Mail list logo
