Hi Sabrina,
On Fri, Apr 28, 2017 at 6:18 PM, Sabrina Dubroca wrote:
> One small thing here: since you're touching this comment, could you
> move it next to skb_to_sgvec, since that's the function it's supposed
> to document?
Done. I'll wait until next week to resubmit, to
Hi Sabrina,
On Fri, Apr 28, 2017 at 6:18 PM, Sabrina Dubroca wrote:
> One small thing here: since you're touching this comment, could you
> move it next to skb_to_sgvec, since that's the function it's supposed
> to document?
Done. I'll wait until next week to resubmit, to give some more time
2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote:
> This is a defense-in-depth measure in response to bugs like
> 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While
> we're at it, we also limit the amount of recursion this function is
> allowed to do. Not actually providing a
2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote:
> This is a defense-in-depth measure in response to bugs like
> 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While
> we're at it, we also limit the amount of recursion this function is
> allowed to do. Not actually providing a
From: "Jason A. Donenfeld"
Date: Thu, 27 Apr 2017 11:21:51 +0200
> Hey Dave,
>
> David Laight and I have been discussing offlist. It occurred to both
> of us that this could just be turned into a loop because perhaps this
> is actually just tail-recursive. Upon further
From: "Jason A. Donenfeld"
Date: Thu, 27 Apr 2017 11:21:51 +0200
> Hey Dave,
>
> David Laight and I have been discussing offlist. It occurred to both
> of us that this could just be turned into a loop because perhaps this
> is actually just tail-recursive. Upon further inspection, however, the
From: Jason A. Donenfeld
> On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote:
> > Hmm, I think this can actually happen:
>
> Alright, perhaps better to err on the side of caution, then.
You only need to recurse if both pointers are set.
David
From: Jason A. Donenfeld
> On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote:
> > Hmm, I think this can actually happen:
>
> Alright, perhaps better to err on the side of caution, then.
You only need to recurse if both pointers are set.
David
On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote:
> Hmm, I think this can actually happen:
Alright, perhaps better to err on the side of caution, then.
Jason
On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote:
> Hmm, I think this can actually happen:
Alright, perhaps better to err on the side of caution, then.
Jason
2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote:
> However, perhaps there's the chance that fraglist skbs having
> separate fraglists are actually forbidden? Is this the case?
Hmm, I think this can actually happen:
/* net/ipv4/ip_fragment.c */
static int ip_frag_reasm(struct ipq
2017-04-27, 11:21:51 +0200, Jason A. Donenfeld wrote:
> However, perhaps there's the chance that fraglist skbs having
> separate fraglists are actually forbidden? Is this the case?
Hmm, I think this can actually happen:
/* net/ipv4/ip_fragment.c */
static int ip_frag_reasm(struct ipq
Hey Dave,
David Laight and I have been discussing offlist. It occurred to both
of us that this could just be turned into a loop because perhaps this
is actually just tail-recursive. Upon further inspection, however, the
way the current algorithm works, it's possible that each of the
fraglist skbs
Hey Dave,
David Laight and I have been discussing offlist. It occurred to both
of us that this could just be turned into a loop because perhaps this
is actually just tail-recursive. Upon further inspection, however, the
way the current algorithm works, it's possible that each of the
fraglist skbs
14 matches
Mail list logo