From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 4 Feb 2008 09:00:27 +1100
> On Sun, Feb 03, 2008 at 11:04:44AM +, Al Viro wrote:
> > IMO that at least deserves a comment near xfrm_input()...
>
> Sure. There is already a comment about encap_type < 0 in there, but
> I think you'll probably be
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 3 Feb 2008 11:20:19 +1100
> [IPSEC]: Fix bogus usage of u64 on input sequence number
>
> Al Viro spotted a bogus use of u64 on the input sequence number which
> is big-endian. This patch fixes it by giving the input sequence number
> its own member
On Sun, Feb 03, 2008 at 11:04:44AM +, Al Viro wrote:
>
> So what you are saying is
> * callers of xfrm_input_resume() are in callbacks that couldn't
> have been set other than from esp_input()/esp6_input()
> * these two could have only been called via ->type->input()
> * ->typ
On Sun, Feb 03, 2008 at 02:05:16PM +1100, Herbert Xu wrote:
> On Sun, Feb 03, 2008 at 12:37:19AM +, Al Viro wrote:
> >
> > This is still very odd... Where do you initialize ->seq.input? What
>
> In xfrm_input.
>
> > guarantees that async call of xfrm_input() will be always preceded by
> > a
On Sun, Feb 03, 2008 at 12:37:19AM +, Al Viro wrote:
>
> This is still very odd... Where do you initialize ->seq.input? What
In xfrm_input.
> guarantees that async call of xfrm_input() will be always preceded by
> at least one non-async one?
OK I admit it isn't pretty. But the encap_type
On Sun, Feb 03, 2008 at 11:20:19AM +1100, Herbert Xu wrote:
> Al Viro spotted a bogus use of u64 on the input sequence number which
> is big-endian. This patch fixes it by giving the input sequence number
> its own member in the xfrm_skb_cb structure.
This is still very odd... Where do you initi
On Sat, Feb 02, 2008 at 11:58:27PM +, Al Viro wrote:
> What's going on with XFRM_SKB_CB(skb)->seq? Almost all users
> expect it to be u32 (feeding it to htonl()), except xfrm_input().
> That one expects __be32 in there - check what it does to seq and
> you'll see. Moreover, it updates t
