[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071009.133107.98747322.davem@davemloft.net>
Date: Tue, 09 Oct 2007 13:31:07 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 5/7] [XFRM] user: Move attribute copying code into
copy_to_user_state_extra
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Tue, 09 Oct 2007 22:36:35 +0800
> [XFRM] user: Move attribute copying code into copy_to_user_state_extra
>
> Here's a good example of code duplication leading to code rot. The
> notification patch did its own netlink message creation for xfrm states.
> It duplicated code that was already in dump_one_state. Guess what, the
> next time (and the time after) when someone updated dump_one_state the
> notification path got zilch.
>
> This patch moves that code from dump_one_state to copy_to_user_state_extra
> and uses it in xfrm_notify_sa too. Unfortunately whoever updates this
> still needs to update xfrm_sa_len since the notification path wants to
> know the exact size for allocation.
>
> At least I've added a comment saying so and if someone still forgest, we'll
> have a WARN_ON telling us so.
>
> I also changed the security size calculation to use xfrm_user_sec_ctx since
> that's what we actually put into the skb. However it makes no practical
> difference since it has the same size as xfrm_sec_ctx.
>
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
Applied, thanks!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists